gmane.os.freebsd.architechture archive

1299 archived articles, newest first (page 7 of 13). Latest articles →

porch(1) tty tests
Fri, 27 Sep 2024 00:18:44 -0500
Kyle Evans <[email protected]> • #24039
Re: Deprecating RSA ssh host keys in 16
Fri, 27 Sep 2024 00:25:36 +0200
Christian Weisgerber <[email protected]> • #24038
Re: Deprecating RSA ssh host keys in 16
Wed, 25 Sep 2024 20:42:49 +0000
Colin Percival <[email protected]> • #24037
Re: Deprecating RSA ssh host keys in 16
Wed, 25 Sep 2024 19:24:54 +0200
Dag-Erling Smørgrav <[email protected]> • #24036
Re: Deprecating RSA ssh host keys in 16
Wed, 25 Sep 2024 15:19:15 +0000
Colin Percival <[email protected]> • #24035
Re: Deprecating RSA ssh host keys in 16
Tue, 24 Sep 2024 19:20:11 +0000
Shawn Webb <[email protected]> • #24034
Re: Deprecating RSA ssh host keys in 16
Tue, 24 Sep 2024 19:16:04 +0000
Shawn Webb <[email protected]> • #24033
Deprecating RSA ssh host keys in 16
Tue, 24 Sep 2024 18:41:00 +0000
Colin Percival <[email protected]> • #24032
Re: That's how (why) BSD is dying (Was: BPF64)
Mon, 16 Sep 2024 11:15:30 +1000
Simon Burge <[email protected]> • #24031
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Thu, 12 Sep 2024 12:04:35 +0100
David Chisnall <[email protected]> • #24030
Re: That's how (why) BSD is dying (Was: BPF64)
Thu, 12 Sep 2024 07:13:12 +0000
"Poul-Henning Kamp" <[email protected]> • #24029
Re: That's how (why) BSD is dying (Was: BPF64)
Thu, 12 Sep 2024 03:26:14 +0300
Vadim Goncharov <[email protected]> • #24028
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Thu, 12 Sep 2024 02:57:17 +0300
Vadim Goncharov <[email protected]> • #24027
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Wed, 11 Sep 2024 12:21:09 +0100
David Chisnall <[email protected]> • #24026
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Wed, 11 Sep 2024 12:05:18 +0300
Vadim Goncharov <[email protected]> • #24025
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Wed, 11 Sep 2024 10:14:44 +0800
Philip Paeps <[email protected]> • #24024
Re: That's how (why) BSD is dying (Was: BPF64)
Tue, 10 Sep 2024 16:55:15 -0800
Rob Wing <[email protected]> • #24023
That's how (why) BSD is dying (Was: BPF64)
Wed, 11 Sep 2024 02:47:35 +0300
Vadim Goncharov <[email protected]> • #24022
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 15:05:21 -0800
Rob Wing <[email protected]> • #24021
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Wed, 11 Sep 2024 01:12:28 +0300
Vadim Goncharov <[email protected]> • #24020
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 20:04:40 +0100
Alexander Nasonov <[email protected]> • #24019
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 18:17:11 +0300
Vadim Goncharov <[email protected]> • #24018
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 15:58:25 +0100
David Chisnall <[email protected]> • #24017
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 14:41:20 +0000
"Gavin D. Howard" <[email protected]> • #24016
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 14:32:56 +0000
"Poul-Henning Kamp" <[email protected]> • #24015
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 16:29:29 +0200
Daniel Ebdrup Jensen <[email protected]> • #24014
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 10:29:19 -0400
Justin Hibbits <[email protected]> • #24013
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 10:24:24 -0400 (EDT)
Mouse <[email protected]> • #24012
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 16:44:47 +0300
Vadim Goncharov <[email protected]> • #24011
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 13:35:11 +0000
"Poul-Henning Kamp" <[email protected]> • #24010
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 16:09:15 +0300
Vadim Goncharov <[email protected]> • #24009
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 13:59:02 +0100
David Chisnall <[email protected]> • #24008
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 12:24:07 +0000
"Poul-Henning Kamp" <[email protected]> • #24007
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 12:51:08 +0100
Bob Bishop <[email protected]> • #24006
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 14:45:57 +0300
Vadim Goncharov <[email protected]> • #24005
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 10:31:43 +0200
Martin Husemann <[email protected]> • #24004
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 10:08:07 +0200
Martin Husemann <[email protected]> • #24003
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 06:38:50 +0000
"Poul-Henning Kamp" <[email protected]> • #24002
Re: [tcpdump-workers] BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Mon, 9 Sep 2024 23:03:39 -0400 (EDT)
Mouse <[email protected]> • #24001
BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
Tue, 10 Sep 2024 04:05:44 +0300
Vadim Goncharov <[email protected]> • #24000
libc++ futures and ports/personal libc++ use vs. what functionality is not to be used in the world/kernel: "import std" and such
Tue, 3 Sep 2024 10:07:55 -0700
Mark Millard <[email protected]> • #23999
Re: FreeBSD libc++ , ports, and import std or import std.compat : what if potential ports start using them over time?
Mon, 29 Jul 2024 22:14:55 -0700
Mark Millard <[email protected]> • #23998
Re: FreeBSD libc++ , ports, and import std or import std.compat : what if potential ports start using them over time?
Mon, 29 Jul 2024 18:18:52 +0200
Dimitry Andric <[email protected]> • #23997
Re: FreeBSD libc++ , ports, and import std or import std.compat : what if potential ports start using them over time?
Mon, 29 Jul 2024 09:01:46 -0700
Mark Millard <[email protected]> • #23996
Re: FreeBSD libc++ , ports, and import std or import std.compat : what if potential ports start using them over time?
Mon, 29 Jul 2024 10:54:56 -0400
Charlie Li <[email protected]> • #23995
Re: Default NO_CLEAN=yes in 15+
Sat, 27 Jul 2024 22:50:12 -0400
Ed Maste <[email protected]> • #23994
FreeBSD libc++ , ports, and import std or import std.compat : what if potential ports start using them over time?
Sat, 27 Jul 2024 11:08:02 -0700
Mark Millard <[email protected]> • #23993
Re: Towards __deprecated in cdefs.h
Fri, 26 Jul 2024 07:58:58 +0000
"Poul-Henning Kamp" <[email protected]> • #23992
Re: Towards __deprecated in cdefs.h
Fri, 26 Jul 2024 10:35:11 +0800
Zhenlei Huang <[email protected]> • #23991
Re: Towards __deprecated in cdefs.h
Thu, 25 Jul 2024 18:18:43 -0600
Warner Losh <[email protected]> • #23990
Re: Towards __deprecated in cdefs.h
Thu, 25 Jul 2024 17:57:12 -0600
Warner Losh <[email protected]> • #23989
Re: Towards __deprecated in cdefs.h
Thu, 25 Jul 2024 21:12:40 +0000
Brooks Davis <[email protected]> • #23988
Towards __deprecated in cdefs.h
Thu, 25 Jul 2024 13:41:06 -0600
Warner Losh <[email protected]> • #23987
Re: Default NO_CLEAN=yes in 15+
Wed, 24 Jul 2024 08:56:41 -0600
Warner Losh <[email protected]> • #23986
Re: Default NO_CLEAN=yes in 15+
Wed, 24 Jul 2024 14:33:41 +0000 (UTC)
"Bjoern A. Zeeb" <[email protected]> • #23985
Re: Default NO_CLEAN=yes in 15+
Wed, 24 Jul 2024 17:44:39 +0900
Tomoaki AOKI <[email protected]> • #23984
RE: Default NO_CLEAN=yes in 15+
Wed, 24 Jul 2024 00:31:23 -0700
Mark Millard <[email protected]> • #23983
Re: Default NO_CLEAN=yes in 15+
Wed, 24 Jul 2024 07:11:02 +0200
Dag-Erling Smørgrav <[email protected]> • #23982
Re: Default NO_CLEAN=yes in 15+
Tue, 23 Jul 2024 23:46:01 +0200
Tomek CEDRO <[email protected]> • #23981
Re: Default NO_CLEAN=yes in 15+
Tue, 23 Jul 2024 17:29:12 -0400
John Baldwin <[email protected]> • #23980
Re: Default NO_CLEAN=yes in 15+
Tue, 23 Jul 2024 16:37:08 -0400
Ed Maste <[email protected]> • #23979
Re: Default NO_CLEAN=yes in 15+
Tue, 23 Jul 2024 20:33:28 +0000
Brooks Davis <[email protected]> • #23978
Re: Default NO_CLEAN=yes in 15+
Tue, 23 Jul 2024 20:08:17 +0000
Shawn Webb <[email protected]> • #23977
Re: Default NO_CLEAN=yes in 15+
Tue, 23 Jul 2024 15:05:15 -0500
Kyle Evans <[email protected]> • #23976
Re: Default NO_CLEAN=yes in 15+
Tue, 23 Jul 2024 14:03:52 -0600
Warner Losh <[email protected]> • #23975
Default NO_CLEAN=yes in 15+
Tue, 23 Jul 2024 15:58:13 -0400
John Baldwin <[email protected]> • #23974
Refining KASSERT
Mon, 15 Jul 2024 17:35:56 -0400
John Baldwin <[email protected]> • #23973
Re: FreeBSD-base update & make delete-old issues
Tue, 25 Jun 2024 16:47:57 -0700 (PDT)
Roger Marquis <[email protected]> • #23972
Re: Minimum gcc and clang supported to generate FreeBSD binaries
Thu, 20 Jun 2024 13:30:03 -0700
Bakul Shah <[email protected]> • #23971
Re: Minimum gcc and clang supported to generate FreeBSD binaries
Thu, 20 Jun 2024 13:00:42 -0600
Warner Losh <[email protected]> • #23970
Re: Minimum gcc and clang supported to generate FreeBSD binaries
Thu, 20 Jun 2024 10:43:40 -0700
Bakul Shah <[email protected]> • #23969
Re: FreeBSD-base update & make delete-old issues
Thu, 20 Jun 2024 05:48:27 -0700 (PDT)
Roger Marquis <[email protected]> • #23968
Re: Minimum gcc and clang supported to generate FreeBSD binaries
Thu, 20 Jun 2024 13:13:02 +0200
Dimitry Andric <[email protected]> • #23967
Re: Minimum gcc and clang supported to generate FreeBSD binaries
Thu, 20 Jun 2024 13:04:40 +0200
Alexander Leidinger <[email protected]> • #23966
Re: FreeBSD-base update & make delete-old issues
Thu, 20 Jun 2024 09:32:09 +0200
Emmanuel Vadot <[email protected]> • #23965
Re: Minimum gcc and clang supported to generate FreeBSD binaries
Thu, 20 Jun 2024 00:49:57 -0600
Warner Losh <[email protected]> • #23964
Re: Minimum gcc and clang supported to generate FreeBSD binaries
Wed, 19 Jun 2024 23:40:11 -0700
Bakul Shah <[email protected]> • #23963
Re: Minimum gcc and clang supported to generate FreeBSD binaries
Thu, 20 Jun 2024 00:18:53 -0600
Warner Losh <[email protected]> • #23962
Re: Minimum gcc and clang supported to generate FreeBSD binaries
Thu, 20 Jun 2024 00:10:23 -0600
Warner Losh <[email protected]> • #23961
Re: Minimum gcc and clang supported to generate FreeBSD binaries
Thu, 20 Jun 2024 07:47:02 +0300
Konstantin Belousov <[email protected]> • #23960
FreeBSD-base update & make delete-old issues
Wed, 19 Jun 2024 20:37:36 -0700 (PDT)
Roger Marquis <[email protected]> • #23959
Re: Minimum gcc and clang supported to generate FreeBSD binaries
Thu, 20 Jun 2024 02:26:10 +0000
Minsoo Choo <[email protected]> • #23958
Re: Minimum gcc and clang supported to generate FreeBSD binaries
Wed, 19 Jun 2024 18:26:12 -0700
Bakul Shah <[email protected]> • #23957
Minimum gcc and clang supported to generate FreeBSD binaries
Wed, 19 Jun 2024 19:01:28 -0600
Warner Losh <[email protected]> • #23956
Re: Kernel device for iwlwifi in 13.3?
Wed, 12 Jun 2024 19:13:41 +0000 (UTC)
"Bjoern A. Zeeb" <[email protected]> • #23955
Re: Kernel device for iwlwifi in 13.3?
Wed, 12 Jun 2024 12:00:41 -0600
Warner Losh <[email protected]> • #23954
Re: Kernel device for iwlwifi in 13.3?
Wed, 12 Jun 2024 10:47:18 -0700 (PDT)
Roger Marquis <[email protected]> • #23953
Re: Kernel device for iwlwifi in 13.3?
Wed, 12 Jun 2024 14:28:46 +0000 (UTC)
"Bjoern A. Zeeb" <[email protected]> • #23952
Re: Kernel device for iwlwifi in 13.3?
Sun, 9 Jun 2024 19:38:06 -0700 (PDT)
Roger Marquis <[email protected]> • #23951
Re: Kernel device for iwlwifi in 13.3?
Sat, 8 Jun 2024 17:35:35 -0700
Enji Cooper <[email protected]> • #23950
Re: Kernel device for iwlwifi in 13.3?
Sat, 08 Jun 2024 07:34:05 +0200
Dag-Erling Smørgrav <[email protected]> • #23949
Kernel device for iwlwifi in 13.3?
Fri, 7 Jun 2024 11:13:26 -0700 (PDT)
Roger Marquis <[email protected]> • #23948
Re: removing support for kernel stack swapping
Tue, 4 Jun 2024 15:43:51 -0700
John Baldwin <[email protected]> • #23947
Re: removing support for kernel stack swapping
Wed, 5 Jun 2024 00:28:49 +0300
Konstantin Belousov <[email protected]> • #23946
Re: removing support for kernel stack swapping
Tue, 04 Jun 2024 21:23:46 +0000
"Poul-Henning Kamp" <[email protected]> • #23945
Re: removing support for kernel stack swapping
Tue, 4 Jun 2024 21:14:41 +0000
Colin Percival <[email protected]> • #23944
Re: removing support for kernel stack swapping
Tue, 04 Jun 2024 20:43:02 +0000
"Poul-Henning Kamp" <[email protected]> • #23943
Re: removing support for kernel stack swapping
Tue, 4 Jun 2024 22:33:30 +0300
Konstantin Belousov <[email protected]> • #23942
Re: removing support for kernel stack swapping
Tue, 4 Jun 2024 09:59:24 -0700
John Baldwin <[email protected]> • #23941
Re: removing support for kernel stack swapping
Tue, 04 Jun 2024 08:23:22 -0700
Cy Schubert <[email protected]> • #23940
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.