I don't believe they make changelogs for current builds. For a general overview of new features, and possibly some insight as to how much work this will be, look at the NetBSD guide, specifically section 2. You may also want to browse the mailing list archives for gotchas.
I'd go with -current anyway, there are more features in it, and it's generally more widely-used by the community.
PS: I believe the next NetBSD formal release will be 2.0. It will have kernel threads, SMP, ACPI, and all that other good stuff. (:
-Bruce
Re:Mac68K build-from-scratch in emulation?
on
NetBSD 1.6.2 Released
·
· Score: 5, Informative
Alright, I've got a hankering to build 1.6.2 from scratch for my Mac Quadra (25MHz 68040), but I KNOW building the whole thing would take weeks.
Is there an emulator for my x86 box that would allow me to get this done faster? BasiliskII can emulate my Mac much faster than it really is.
I'm sure this is a problem on a lot of the 40 architectures, some of them are way old and limited to the sub-100MHz range. Cross-compiling seems like a hairy mess.
You should be able to cross-compile the entire distribuiton from your x86 box using the build.sh frontend. It seems like it would be messy to build it and copy it over, but it's actually quite easy. The alternative would be to *not* build it yourself and instead just install the binary distribution---there really aren't many benefits of compiling it unless you need a custom kernel or -current sources.
Also, is there a way to build the whole distribution via gcc-3.3.x? I'd like to see how well it performs against the gcc2-built system I used a while ago.
The 1.6.x releases use gcc-2.95 for the basis of the toolchain. If you want to try gcc-3.3.x, this may be another reason to look at -current (just yesterday they updated gcc to v3.3.3). Current may be a better choice anyway: its faster, more feature-rich (think native threads), and more widely-used by the community.
All the BSDs use the GNU toolchain (binutils, gcc, gdb,...) and whatever else they don't have a BSD-licensed alternative for. They copy the sources and modify them in their own cvs tree. This explains why dialog may have modifications to it.
I agree totally. While forking does contribute to a slight sparsity of developers, think of all the projects that have had a fork and are still going strong in parallel to what forked (NetBSD and OpenBSD). Sometimes, the forked project becomes the one from which it forked (Python's IDLE). Sometimes, the originator will die off (Linux Router Project), and sometimes, the fork will die (does anyone really care about Zynot?), but more often than not, they will coexist (think {e,x,a}mule).
Forking really isn't all that bad, anyway. Given enough information, users will actually appreciate the wide array of choices.
Apple's G5 probably is the fastest personal computer around. An Opteron box may be faster, but it isn't any more a `personal computer' than [insert some Japanese supercomputer here] is. Until manufacturers start using the Opteron in systems, the G5 is still king for people who don't know how to build their own.
Build a system that a fool can use, and only a fool will want to use it.
BTW, I'm not calling Mac users fools, but there probably are more idiots running them than there are running tricked-out Opteron boxes:)
Slashdot Mirror
... Hyphen, rather ...
Yet another troll gone awry.
Yeah, and there should be a comma between standards and compliant ... No one cares, dude.
I don't believe they make changelogs for current builds. For a general overview of new features, and possibly some insight as to how much work this will be, look at the NetBSD guide, specifically section 2. You may also want to browse the mailing list archives for gotchas.
-current is usually very reliable. I would suggest that you install a binary snapshot from ftp://releng.netbsd.org first, just to be sure
-Bruce
I'd go with -current anyway, there are more features in it, and it's generally more widely-used by the community.
PS: I believe the next NetBSD formal release will be 2.0. It will have kernel threads, SMP, ACPI, and all that other good stuff. (:
-Bruce
-Bruce
All the BSDs use the GNU toolchain (binutils, gcc, gdb, ...) and whatever else they don't have a BSD-licensed alternative for. They copy the sources and modify them in their own cvs tree. This explains why dialog may have modifications to it.
This is not true: Virtutech Simics is capable of emulating the Opteron and the PowerPC (among others).
The class is a state requirement (South Dakota of all places)
I agree totally. While forking does contribute to a slight sparsity of developers, think of all the projects that have had a fork and are still going strong in parallel to what forked (NetBSD and OpenBSD). Sometimes, the forked project becomes the one from which it forked (Python's IDLE). Sometimes, the originator will die off (Linux Router Project), and sometimes, the fork will die (does anyone really care about Zynot?), but more often than not, they will coexist (think {e,x,a}mule). Forking really isn't all that bad, anyway. Given enough information, users will actually appreciate the wide array of choices.
Apple's G5 probably is the fastest personal computer around. An Opteron box may be faster, but it isn't any more a `personal computer' than [insert some Japanese supercomputer here] is. Until manufacturers start using the Opteron in systems, the G5 is still king for people who don't know how to build their own.
Build a system that a fool can use, and only a fool will want to use it.
BTW, I'm not calling Mac users fools, but there probably are more idiots running them than there are running tricked-out Opteron boxesNot to mention the SysRq key still in use on Linux for debugging---if you enable CONFIG_MAGIC_SYSRQ (Linux 2.4) or CONFIG_SYSRQ (Linux 2.6).
I really doubt that ``it's days are numbered.''