It isn't quite true that v4 is not running out of addresses. It only has four billion, and even with totally efficient allocation there obviously wouldn't be enough for everyone on the planet to get onto the internet. Given that allocation can at best be a few percent efficient, you have a problem.
No, it isn't random. Its what's known as a "link local" address. It is synthesized automatically from the universal link local prefix and your interface's MAC address. This allows all the usual "who am I anyway" protocols from IPv4 to be done over IPv6 directly instead of over raw link layer protocols. Its rather cool, actually.
I doubt that this means OpenBSD will support the iMac. The kernel has bears little in common with NetBSDs any more. They may be working on their own iMac support, of course, but NetBSD's working on a platform tells you nothing about whether OpenBSD will run.
By the way: I know the OpenBSD people will claim otherwise, but NetBSD is more or less as secure as OpenBSD. We generally just aren't as loud about it. They sometimes have bugs we don't have, we sometimes have bugs they don't have. In general, NetBSD is very secure.
The eMate is a strongarm based system, and NetBSD has been ported to lots of ARM based systems. I'd suggest the only real problem would be the lack of mass storage.
It is quite true -- most of the kernel of OS X comes from Mach (although as I noted the networking code has been taken from NetBSD, has has the userland). However, accuracy is rarely/.'s strongpoint. Reporters are supposed to always make sure they get the details right, but unfortunately,/. often skimps a bit too much in this regard. Fact checking would help a lot.
The OS X userland and TCP stack come from NETBSD, not FREEBSD.
If you don't believe me, look at the Darwin source code yourself. We've been working with folks from Apple for a long time, and we've been importing most of the improvements and bug fixes they've made so the source bases stay in sync.
It doesn't matter that FreeBSD runs on x86s. The point is that NCI has an operating system they sell, NC/OS, and it is NetBSD. I'm sure they *could* use FreeBSD if they wanted to use a different system on different platforms, but I don't think that is their goal.
In any case, the system that they use, really and not theoretically, is NetBSD. FreeBSD is used for their server platform. Why the split? I don't know.
This is not a "problem" -- this is intentional. One of the reasons I hack on NetBSD is that I want people to be able to use my code, even for proprietary projects.
In general, most companies have been remarkably good at contributing back fixes.
The folks at Digital contributed back virtually every bit of their reference port of NetBSD to their ARM32 based NC. The folks at Apple, who use NetBSD's userland and TCP/IP stack in Darwin/OS-X have contributed back virtually all the code they fixed or changed to us. A number of people from NC participate on NetBSD technical mailing lists and contribute back fixes, too.
NCI uses FreeBSD based servers, but the network computers themselves run a derivative of NetBSD. I happen to have a Genuine DNARD (Digital Network Appliance Reference Design) network computer sitting right here, complete with NC logo painted on the front. It was built to run NetBSD. (Runs it beautifully, btw -- the boxes are fully supported by recent NetBSD releases.)
This should be obvious to people, of course. NCs are mostly not Intel based -- they tend to run on processors like ARMs and MIPS, and FreeBSD runs mostly on the i386. (They have an Alpha port but it isn't stable yet -- they certainly have no ARM or MIPS ports).
STUPID engineers produce 10 lines of code a day. Brilliant ones can do orders of magnitude more than that. I've heard this idiotic statistic for years -- I've never believed it, largely because it does not in any way match experience with smart and educated programmers.
My suggestion: DONT buy a top of the line machine with the $5000. Buy a $1250 machine every year you are in college. In four years, even the best alpha will seem pathetic. Better to have a "pretty damn good" computer every year than a horribly obsolete one. You pay a huge premium for being ahead of the curve -- a $5000 system is not five times better than a $1000 system.
Slashdot Mirror
It isn't quite true that v4 is not running out of addresses. It only has four billion, and even with totally efficient allocation there obviously wouldn't be enough for everyone on the planet to get onto the internet. Given that allocation can at best be a few percent efficient, you have a problem.
IPv6 of course solves all this.
No, it isn't random. Its what's known as a "link local" address. It is synthesized automatically from the universal link local prefix and your interface's MAC address. This allows all the usual "who am I anyway" protocols from IPv4 to be done over IPv6 directly instead of over raw link layer protocols. Its rather cool, actually.
Microsoft Research has a v6 stack for windows, and so does Trumpet Winsock. Windows users can run v6 any time they like.
See www.ipv6.org if you want to track down versions for your favorite OS.
I doubt that this means OpenBSD will support the iMac. The kernel has bears little in common with NetBSDs any more. They may be working on their own iMac support, of course, but NetBSD's working on a platform tells you nothing about whether OpenBSD will run.
By the way: I know the OpenBSD people will claim otherwise, but NetBSD is more or less as secure as OpenBSD. We generally just aren't as loud about it. They sometimes have bugs we don't have, we sometimes have bugs they don't have. In general, NetBSD is very secure.
NetBSD has also run on the PowerPC for years.
The eMate is a strongarm based system, and NetBSD has been ported to lots of ARM based systems. I'd suggest the only real problem would be the lack of mass storage.
The iMac at Usenix was running just fine.
I'd suggest asking for help on the proper NetBSD mailing list, not here.
I haven't heard any such thing. They mostly use NetBSD userland code, so it would probably be an immense pain for them to yank it all out.
As for the API, well, we all follow nearly the same API.
HFS file system support could probably be done pretty straightforwardly -- its a matter of someone having the energy to do so.
Ditto on COMPAT_MACOSX -- we support enough compatibility modes in NetBSD that it wouldn't be such a big deal if someone took the time on it.
Volunteers to help are always welcome!
Maybe they thought the userland was good. I tend to think so, but I'm biased.
It is quite true -- most of the kernel of OS X comes from Mach (although as I noted the networking code has been taken from NetBSD, has has the userland). However, accuracy is rarely /.'s strongpoint. Reporters are supposed to always make sure they get the details right, but unfortunately, /. often skimps a bit too much in this regard. Fact checking would help a lot.
The OS X userland and TCP stack come from NETBSD, not FREEBSD.
If you don't believe me, look at the Darwin source code yourself. We've been working with folks from Apple for a long time, and we've been importing most of the improvements and bug fixes they've made so the source bases stay in sync.
It doesn't matter that FreeBSD runs on x86s. The point is that NCI has an operating system they sell, NC/OS, and it is NetBSD. I'm sure they *could* use FreeBSD if they wanted to use a different system on different platforms, but I don't think that is their goal.
In any case, the system that they use, really and not theoretically, is NetBSD. FreeBSD is used for their server platform. Why the split? I don't know.
This is not a "problem" -- this is intentional. One of the reasons I hack on NetBSD is that I want people to be able to use my code, even for proprietary projects.
In general, most companies have been remarkably good at contributing back fixes.
The folks at Digital contributed back virtually every bit of their reference port of NetBSD to their ARM32 based NC. The folks at Apple, who use NetBSD's userland and TCP/IP stack in Darwin/OS-X have contributed back virtually all the code they fixed or changed to us. A number of people from NC participate on NetBSD technical mailing lists and contribute back fixes, too.
NCI uses FreeBSD based servers, but the network computers themselves run a derivative of NetBSD. I happen to have a Genuine DNARD (Digital Network Appliance Reference Design) network computer sitting right here, complete with NC logo painted on the front. It was built to run NetBSD. (Runs it beautifully, btw -- the boxes are fully supported by recent NetBSD releases.)
This should be obvious to people, of course. NCs are mostly not Intel based -- they tend to run on processors like ARMs and MIPS, and FreeBSD runs mostly on the i386. (They have an Alpha port but it isn't stable yet -- they certainly have no ARM or MIPS ports).
Gee.. hardware autodetection... like BSD has had since the early 1980s?
Wow... I'm impressed...
Perry
STUPID engineers produce 10 lines of code a day.
Brilliant ones can do orders of magnitude more
than that. I've heard this idiotic statistic
for years -- I've never believed it, largely
because it does not in any way match experience
with smart and educated programmers.
The protocol in question is crud. The IETF
wouldn't even agree to standardize it.
My suggestion: DONT buy a top of the line machine with the $5000. Buy a $1250 machine every year you are in college. In four years, even the best alpha will seem pathetic. Better to have a "pretty damn good" computer every year than a horribly obsolete one. You pay a huge premium for being ahead of the curve -- a $5000 system is not five times better than a $1000 system.
Is there a reason that every NetBSD story gets a "FreeBSD News" Icon on it?
What an invention! Serial to video! Why, they've reinvented the terminal! Now where did I put that vt100....