Re: how to force all packets to be ipv4 not v6
On Sun, 31 Mar 2013 01:20:17 -0400 Aryeh Friedman aryeh.fried...@gmail.com wrote: I have a host that for ISP reasons must have a ipv6 addr as well as the ipv4 but the ISP does not offer external ipv6 routing but all the commanes (ssh, ftp, etc.) default to ipv6 and need special options to use 4 is there anyway to force them to always use 4? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org A kick and dirty way would be to comment the line: options INET6 # IPv6 communications protocols from your kernel config and recompile. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winblows FREE) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Ports: make fails, if DESTDIR path has spaces
Under 9.0-RELEASE-p6 -- #!/bin/sh # Contains 9.0 world DESTDIR='/usr/TZ ONE'; export DESTDIR cd /usr/ports/benchmarks/unixbench /usr/bin/make showconfig -- Errors: --- [: /usr/TZ: unexpected operator === Creating some important subdirectories [: /usr/TZ: unexpected operator === /tmp subdirectory has been successfully created [: /usr/TZ: unexpected operator === /dev subdirectory has been successfully created mktemp: mkdtemp failed on /usr/TZ: File exists === Failed to create temporary mount point *** Error code 9 Stop in /usr/ports/benchmarks/unixbench. --- Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: libprocstat(3): retrieve process command line args and environment
On Fri, Mar 29, 2013 at 02:31:57PM +0200, Mikolaj Golub wrote:
On Fri, Mar 29, 2013 at 11:22:45AM +0200, Konstantin Belousov wrote:
On Thu, Mar 28, 2013 at 11:18:21PM +0200, Mikolaj Golub wrote:
On Thu, Mar 28, 2013 at 12:51:34PM +0200, Konstantin Belousov wrote:
In the generic Elf 64bit draft specification I have, the notes sections
are specified to consists of entries, each of which is an array of
8-byte
words. I think we are right using the 8-byte alignment.
I have impression many implementations use 4-byte alignment. E.g. in
NetBSD:
sys/kern/core_elf32.c:
#define ELFROUNDSIZE4 /* XXX Should it be sizeof(Elf_Word)? */
#define elfround(x) roundup((x), ELFROUNDSIZE)
Note that this is core_elf32. I am concerned with the 64-bit cores.
core_elf64.c:
#define ELFSIZE 64
#include core_elf32.c
Also, the 4-bytes alignment is described in the comments in the glibc
csu/abi-note.S.
Also, we have inconsistency with imgactl_elf.c/parse_notes(), which
uses 4-byte alignment:
note = (const Elf_Note *)((const char *)(note + 1) +
roundup2(note-n_namesz, sizeof(Elf32_Addr)) +
roundup2(note-n_descsz, sizeof(Elf32_Addr)));
I suppose there were no issues before, because accidentally the sizes
of all notes we had were 8 bytes aligned.
Indeed, both ABI and NOINIT notes have size which is multiple of 8.
Now, when I add new notes it will break things. I don't have strong
opinion, it will be ok for me to leave 8-byte alignment and fix
issues, just want to have strong support here :-)
Well, while the issue is discussed and decided, you could just make
your new notes size be multiple of 8 too.
I thought about this too. Then I need to be more caerful when
extracting stats from notes, because the length returned by
procstat_core_get() can be more than a real payload.
Ok, I will try this way.
I could add length to the note header, which is currently contains
only structsize, so it would became something like:
struct {
int structsize;
int lenght;
}
But not sure it is worth doing, especially if the forced 8-bit
alignment is a temporary mesure.
No, it is definitely not worth it.
I inspected imgact_elf.c:parse_note(), imgact_elf.c:putnote() and
rtld.c:digest_notes(). Only putnote() uses 8-byte alignment.
Every other OS and our !coredump code assumes 4-byte alignment.
Does changing the putnote() to align on the 4-byte boundary cause
real change in the core file notes layout ?
pgppHqvLntCg7.pgp
Description: PGP signature
Re: libprocstat(3): retrieve process command line args and environment
On Sun, Mar 31, 2013 at 04:40:47PM +0300, Konstantin Belousov wrote: I inspected imgact_elf.c:parse_note(), imgact_elf.c:putnote() and rtld.c:digest_notes(). Only putnote() uses 8-byte alignment. Every other OS and our !coredump code assumes 4-byte alignment. Thanks! Does changing the putnote() to align on the 4-byte boundary cause real change in the core file notes layout ? Currently, we store only 4 types of notes in a core file: #define NT_PRSTATUS 1 /* Process status. */ #define NT_FPREGSET 2 /* Floating point registers. */ #define NT_PRPSINFO 3 /* Process state info. */ #define NT_THRMISC 7 /* Thread miscellaneous info. */ I checked the sizes of structures inserted into the notes, and on amd64 they all are multiple of 8: (kgdb) p sizeof(prpsinfo_t) % 8 $1 = 0 (kgdb) p sizeof(prstatus_t) % 8 $2 = 0 (kgdb) p sizeof(prfpregset_t) % 8 $3 = 0 (kgdb) p sizeof(thrmisc_t) % 8 $4 = 0 so both 4-byte and 8-byte aligned. I believe that the patch below will not change the current core file notes layout, will make things consistent in our tree, and will make adding my procstat notes easier, if I use 4-byte alignment. Are you ok if I commit it before introducing my changes? Index: sys/kern/imgact_elf.c === --- sys/kern/imgact_elf.c (revision 248706) +++ sys/kern/imgact_elf.c (working copy) @@ -1538,10 +1538,10 @@ __elfN(putnote)(void *dst, size_t *off, const char *off += sizeof note; if (dst != NULL) bcopy(name, (char *)dst + *off, note.n_namesz); - *off += roundup2(note.n_namesz, sizeof(Elf_Size)); + *off += roundup2(note.n_namesz, sizeof(Elf32_Size)); if (dst != NULL) bcopy(desc, (char *)dst + *off, note.n_descsz); - *off += roundup2(note.n_descsz, sizeof(Elf_Size)); + *off += roundup2(note.n_descsz, sizeof(Elf32_Size)); } static boolean_t Also, shouldn't we update then the following comment in sys/elf_common.h? /* * Note header. The .note section contains an array of notes. Each * begins with this header, aligned to a word boundary. Immediately * following the note header is n_namesz bytes of name, padded to the * next word boundary. Then comes n_descsz bytes of descriptor, again * padded to a word boundary. The values of n_namesz and n_descsz do * not include the padding. */ -- Mikolaj Golub ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Ports: make fails, if DESTDIR path has spaces
Try DESTDIR='/usr/TZ\ ONE'; export DESTDIR. You need to escape the space. On 3/31/2013 8:38 AM, rank1see...@gmail.com wrote: Under 9.0-RELEASE-p6 -- #!/bin/sh # Contains 9.0 world DESTDIR='/usr/TZ ONE'; export DESTDIR cd /usr/ports/benchmarks/unixbench /usr/bin/make showconfig -- Errors: --- [: /usr/TZ: unexpected operator === Creating some important subdirectories [: /usr/TZ: unexpected operator === /tmp subdirectory has been successfully created [: /usr/TZ: unexpected operator === /dev subdirectory has been successfully created mktemp: mkdtemp failed on /usr/TZ: File exists === Failed to create temporary mount point *** Error code 9 Stop in /usr/ports/benchmarks/unixbench. --- Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Ports: make fails, if DESTDIR path has spaces
On 31 March 2013 14:38, rank1see...@gmail.com wrote: Under 9.0-RELEASE-p6 -- #!/bin/sh # Contains 9.0 world DESTDIR='/usr/TZ ONE'; export DESTDIR cd /usr/ports/benchmarks/unixbench /usr/bin/make showconfig -- Errors: --- [: /usr/TZ: unexpected operator === Creating some important subdirectories [: /usr/TZ: unexpected operator === /tmp subdirectory has been successfully created [: /usr/TZ: unexpected operator === /dev subdirectory has been successfully created mktemp: mkdtemp failed on /usr/TZ: File exists === Failed to create temporary mount point *** Error code 9 Stop in /usr/ports/benchmarks/unixbench. Yeah, don't do that. Spaces in directories will always cause problems; I suppose someone could fix it in bsd.port.mk, but it will probably break somewhere else; spaces in Make variables have a special meaning. Use an underscore if you're desperate. Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Ports: make fails, if DESTDIR path has spaces
El día Sunday, March 31, 2013 a las 05:29:18PM +0100, Chris Rees escribió: Yeah, don't do that. +1 Spaces in directories will always cause problems; I suppose someone could fix it in bsd.port.mk, but it will probably break somewhere else; spaces in Make variables have a special meaning. Use an underscore if you're desperate. Until today I thought that this, spaces in file or dir names, have been the typically attitude of Windows minded people; if it now comes to FreeBSD hackers, the world is coming to its end :-) matthias -- Sent from my FreeBSD netbook Matthias Apitz | - No system with backdoors like Apple/Android E-mail: g...@unixarea.de | - Never being an iSlave WWW: http://www.unixarea.de/ | - No proprietary attachments, no HTML/RTF in E-mail phone: +49-170-4527211 | - Respect for open standards ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: libprocstat(3): retrieve process command line args and environment
On Sun, Mar 31, 2013 at 06:53:00PM +0300, Mikolaj Golub wrote: On Sun, Mar 31, 2013 at 04:40:47PM +0300, Konstantin Belousov wrote: I inspected imgact_elf.c:parse_note(), imgact_elf.c:putnote() and rtld.c:digest_notes(). Only putnote() uses 8-byte alignment. Every other OS and our !coredump code assumes 4-byte alignment. Thanks! Does changing the putnote() to align on the 4-byte boundary cause real change in the core file notes layout ? Currently, we store only 4 types of notes in a core file: #define NT_PRSTATUS 1 /* Process status. */ #define NT_FPREGSET 2 /* Floating point registers. */ #define NT_PRPSINFO 3 /* Process state info. */ #define NT_THRMISC 7 /* Thread miscellaneous info. */ I checked the sizes of structures inserted into the notes, and on amd64 they all are multiple of 8: (kgdb) p sizeof(prpsinfo_t) % 8 $1 = 0 (kgdb) p sizeof(prstatus_t) % 8 $2 = 0 (kgdb) p sizeof(prfpregset_t) % 8 $3 = 0 (kgdb) p sizeof(thrmisc_t) % 8 $4 = 0 so both 4-byte and 8-byte aligned. Well, FreeBSD supports some more 64bit architectures, besides amd64. At least on powerpc64, I get prpsinfo 120 0 prstatus_t 344 0 prfpregset_t 264 0 thrmisc_t 24 0 Second column is sizeof(), third is sizeof() % 8. This is in fact not much surprising, since all ABIs define the alignment of the structure as the alignment of the most demanding member. And, because 64bit architectures have 8-byte registers, it is indeed expected that the size % 8 == 0. I believe that the patch below will not change the current core file notes layout, will make things consistent in our tree, and will make adding my procstat notes easier, if I use 4-byte alignment. Are you ok if I commit it before introducing my changes? Yes, I believe this is the right thing to do. Index: sys/kern/imgact_elf.c === --- sys/kern/imgact_elf.c (revision 248706) +++ sys/kern/imgact_elf.c (working copy) @@ -1538,10 +1538,10 @@ __elfN(putnote)(void *dst, size_t *off, const char *off += sizeof note; if (dst != NULL) bcopy(name, (char *)dst + *off, note.n_namesz); - *off += roundup2(note.n_namesz, sizeof(Elf_Size)); + *off += roundup2(note.n_namesz, sizeof(Elf32_Size)); if (dst != NULL) bcopy(desc, (char *)dst + *off, note.n_descsz); - *off += roundup2(note.n_descsz, sizeof(Elf_Size)); + *off += roundup2(note.n_descsz, sizeof(Elf32_Size)); } static boolean_t Also, shouldn't we update then the following comment in sys/elf_common.h? /* * Note header. The .note section contains an array of notes. Each * begins with this header, aligned to a word boundary. Immediately * following the note header is n_namesz bytes of name, padded to the * next word boundary. Then comes n_descsz bytes of descriptor, again * padded to a word boundary. The values of n_namesz and n_descsz do * not include the padding. */ -- Mikolaj Golub pgpt3ztmYjZwj.pgp Description: PGP signature
Re: how to force all packets to be ipv4 not v6
Mario Lobo l...@bsd.com.br writes: On Sun, 31 Mar 2013 01:20:17 -0400 Aryeh Friedman aryeh.fried...@gmail.com wrote: I have a host that for ISP reasons must have a ipv6 addr as well as the ipv4 but the ISP does not offer external ipv6 routing but all the commanes (ssh, ftp, etc.) default to ipv6 and need special options to use 4 is there anyway to force them to always use 4? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org A kick and dirty way would be to comment the line: options INET6 # IPv6 communications protocols from your kernel config and recompile. That breaks the must have a ipv6 addr requirement. The way to do this without completely disabling IPv6 used to be to configure ipv6_prefer, but that appears to have been superseded by ip6addrctl_policy. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: how to force all packets to be ipv4 not v6
If it's just for ssh(1) and scp(1) you can use ssh_config(5) to force the use of IPv4 based on the destination hostname. -Kimmo On Sun, Mar 31, 2013 at 10:43 PM, Lowell Gilbert freebsd-li...@be-well.ilk.org wrote: Mario Lobo l...@bsd.com.br writes: On Sun, 31 Mar 2013 01:20:17 -0400 Aryeh Friedman aryeh.fried...@gmail.com wrote: I have a host that for ISP reasons must have a ipv6 addr as well as the ipv4 but the ISP does not offer external ipv6 routing but all the commanes (ssh, ftp, etc.) default to ipv6 and need special options to use 4 is there anyway to force them to always use 4? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org A kick and dirty way would be to comment the line: options INET6 # IPv6 communications protocols from your kernel config and recompile. That breaks the must have a ipv6 addr requirement. The way to do this without completely disabling IPv6 used to be to configure ipv6_prefer, but that appears to have been superseded by ip6addrctl_policy. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
considering i386 as a tier 1 architecture
Hi, I am writing this email to discuss the i386 architecture in FreeBSD. Computers are getting faster, but also more memory intensive. I can not find a laptop with less than 4 or 8 GB of RAM. Modern browsers, such as Firefox, require a 64bit architecture and 8GB of RAM. A 32 bit platform is not enough now a days on systems with more than 4 GB of RAM. A 32 bit core now is like 640K of RAM in the 1990s. Even in the embedded world ARM is going 64 bit with ARMv8. Secondly, the i386 port is unmaintained. Very few developers run it, so it doesn't get the testing it deserves. Almost every user post or bug report I see from a x86 compatible processor is running amd64. When was the last time you booted i386 outside a virtual machine? Often times the build works for amd64 but fails for i386. Finally, others are dropping support for i386. Windows Server 2008 is 64 bit only, OSX Mountain Lion (10.8) is 64-bit only. Users and downstream vendors no longer care about preserving ancient hardware. I hope this email is enough to convince you that on this date we should drop support for the i386 architecture for 10.0 to tier 2 and replace it with the ARM architecture as Tier 1. -- Eitan Adler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
On Mon, Apr 01, 2013 at 12:48:08AM -0400, Eitan Adler wrote: Finally, others are dropping support for i386. Windows Server 2008 is 64 bit only. No, it isn't. Windows Server 2008 comes in both 32 bit and 64 bit versions. Windows Server 2008 R2 is 64 bit only however. The same goes for Windows Server 2012. -- Joel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
On Sun, Mar 31, 2013 at 9:48 PM, Eitan Adler li...@eitanadler.com wrote: Hi, I am writing this email to discuss the i386 architecture in FreeBSD. Computers are getting faster, but also more memory intensive. I can not find a laptop with less than 4 or 8 GB of RAM. Modern browsers, such as Firefox, require a 64bit architecture and 8GB of RAM. A 32 bit platform is not enough now a days on systems with more than 4 GB of RAM. A 32 bit core now is like 640K of RAM in the 1990s. Even in the embedded world ARM is going 64 bit with ARMv8. Secondly, the i386 port is unmaintained. Very few developers run it, so it doesn't get the testing it deserves. Almost every user post or bug report I see from a x86 compatible processor is running amd64. When was the last time you booted i386 outside a virtual machine? Often times the build works for amd64 but fails for i386. Finally, others are dropping support for i386. Windows Server 2008 is 64 bit only, OSX Mountain Lion (10.8) is 64-bit only. Users and downstream vendors no longer care about preserving ancient hardware. I hope this email is enough to convince you that on this date we should drop support for the i386 architecture for 10.0 to tier 2 and replace it with the ARM architecture as Tier 1. -- Eitan Adler This idea is really very good . The FreeBSD Project man power , for me , is wasted to maintain a branch that it is NOT necessary to make it a first class branch . 1 Giga Bytes , and even 2 Giga Bytes memory chips are disappearing from the computer shops slowly . At present , there is NO any processor which is ONLY 32-bits . Not only the Windows Server , if I am not remembering incorrectly , new regular Windows ( desk top , etc. ) versions will drop 32 bits branches : They only supply 64 bits versions . By concentrating on 64 bits ( amd64 ) branch and work toward distributed processing and high performance computing for super or clustered computers or graphics chips ( cards ) is much more useful than working on 32 bits version . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
I think the only ones who are going to object are the users of embedded hardware. Some of them are still using CPUs that are only i586 equivalent. Personally I support the notion. -Kimmo On Mon, Apr 1, 2013 at 7:48 AM, Eitan Adler li...@eitanadler.com wrote: Hi, I am writing this email to discuss the i386 architecture in FreeBSD. Computers are getting faster, but also more memory intensive. I can not find a laptop with less than 4 or 8 GB of RAM. Modern browsers, such as Firefox, require a 64bit architecture and 8GB of RAM. A 32 bit platform is not enough now a days on systems with more than 4 GB of RAM. A 32 bit core now is like 640K of RAM in the 1990s. Even in the embedded world ARM is going 64 bit with ARMv8. Secondly, the i386 port is unmaintained. Very few developers run it, so it doesn't get the testing it deserves. Almost every user post or bug report I see from a x86 compatible processor is running amd64. When was the last time you booted i386 outside a virtual machine? Often times the build works for amd64 but fails for i386. Finally, others are dropping support for i386. Windows Server 2008 is 64 bit only, OSX Mountain Lion (10.8) is 64-bit only. Users and downstream vendors no longer care about preserving ancient hardware. I hope this email is enough to convince you that on this date we should drop support for the i386 architecture for 10.0 to tier 2 and replace it with the ARM architecture as Tier 1. -- Eitan Adler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
On Monday, 1 April 2013 at 0:48:08 -0400, Eitan Adler wrote: Hi, I am writing this email to discuss the i386 architecture in FreeBSD. Computers are getting faster, but also more memory intensive. I can not find a laptop with less than 4 or 8 GB of RAM. Modern browsers, such as Firefox, require a 64bit architecture and 8GB of RAM. A 32 bit platform is not enough now a days on systems with more than 4 GB of RAM. A 32 bit core now is like 640K of RAM in the 1990s. Even in the embedded world ARM is going 64 bit with ARMv8. Secondly, the i386 port is unmaintained. Very few developers run it, so it doesn't get the testing it deserves. Almost every user post or bug report I see from a x86 compatible processor is running amd64. When was the last time you booted i386 outside a virtual machine? Often times the build works for amd64 but fails for i386. Finally, others are dropping support for i386. Windows Server 2008 is 64 bit only, OSX Mountain Lion (10.8) is 64-bit only. Users and downstream vendors no longer care about preserving ancient hardware. I hope this email is enough to convince you that on this date we should drop support for the i386 architecture for 10.0 to tier 2 and replace it with the ARM architecture as Tier 1. Nice one! And only 48 minutes into the day. I've seen a number of people take it seriously. Greg -- Sent from my desktop computer. Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua pgp6abC0YZd7B.pgp Description: PGP signature
Re: considering i386 as a tier 1 architecture
On Mon, Apr 1, 2013 at 8:50 AM, Greg 'groggy' Lehey g...@freebsd.org wrote: On Monday, 1 April 2013 at 0:48:08 -0400, Eitan Adler wrote: Hi, I am writing this email to discuss the i386 architecture in FreeBSD. Computers are getting faster, but also more memory intensive. I can not find a laptop with less than 4 or 8 GB of RAM. Modern browsers, such as Firefox, require a 64bit architecture and 8GB of RAM. A 32 bit platform is not enough now a days on systems with more than 4 GB of RAM. A 32 bit core now is like 640K of RAM in the 1990s. Even in the embedded world ARM is going 64 bit with ARMv8. Secondly, the i386 port is unmaintained. Very few developers run it, so it doesn't get the testing it deserves. Almost every user post or bug report I see from a x86 compatible processor is running amd64. When was the last time you booted i386 outside a virtual machine? Often times the build works for amd64 but fails for i386. Finally, others are dropping support for i386. Windows Server 2008 is 64 bit only, OSX Mountain Lion (10.8) is 64-bit only. Users and downstream vendors no longer care about preserving ancient hardware. I hope this email is enough to convince you that on this date we should drop support for the i386 architecture for 10.0 to tier 2 and replace it with the ARM architecture as Tier 1. Nice one! And only 48 minutes into the day. I've seen a number of people take it seriously. Greg -- Oh crap :P However, this discussion will not be out of place some day, may be 2 or 3 years and practicly everything will be 64-bits. -Kimmo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
