Slashdot Mirror
NetBSD released for iMacs and G3s
ChristianC writes "The latest release of NetBSD, 1.4, now supports iMacs and G3s. This is particulary interesting, as OS X is based on various BSD distributions, so NetBSD and OS X will be very similar under the hood. "
at least in theory. They're relatively easy to program and understand, and in an emergency the hand-editability becomes a great asset.
But programmers forget one problem: the average person. The average person is not a programmer. They get no masochistic joy from hunting through cryptically-named directories to find the file, change it, and then restart the program, especially a big one like X.
This wouldn't be a problem is most programmers provided other means of configuring the program. But in the *nix crowds, they don't tend to do that (it's getting more popular but is still relatively rare). That's why things like iceconf, e-conf, and wmakerconf are getting so popular; I don't want to have to hunt down, for example, each of the config files WindowMaker uses (~/GNUstep/Defaults/WindowMaker, ~/GNUstep/Defaults/WMWindowAttributes, ~GNUstep/Library/WindowMaker/Menu, and so forth), learn the different syntaxes on each file, and hand-edit them. And the hell of it is, I do know what I'm doing with those files; I've done it before.
(By the way, WM fans, please don't flame me for this one; I use WindowMaker every day; I'm just using its multiplicity of config files as an example).
Having multiple config files is a Good Thing; certainly better than having them in a Registry. But it needs to be done right; put them all in a consistent, well-defined place, like the Preferences folder in MacOS, so you at least know where to look for them (if you have lots of them; make a subdirectory of this place and put them in there to keep it organized; but at least get them in one good spot). And to all the coders out there, add a somewhat more convenient way of configuring programs to supplement the config files; your users will thank you for it.
Or they just don't want to support the couple of engineers needed to get any of the specs they could possibly need from the LinuxPPC, NetBSD, or Darwin source code and keep it legal to make their software proprietary (still a possibility, but it involves cleanroom techniques, which means sacrificing several engineers since they have to document the specs but then cannot code).
The NetBSD project demo'd NetBSD on the iMac last week at USENIX. They had a booth over in the vendors area where they were showing this spiffy iMac along with an old VaxStation or somesuch -- this iMac probably outperformed that VAX 20:1... hehe.
Nice guys too.
I'd be looking more at what you want to do - AFAIK, the *BSD's have more emphasis on network throughput (ref: ftp.cdrom.com), whilst linux supports everything under the sun 8-)
:-)
:-)
The NetBSD project doesn't state "Of course it runs NetBSD" for nothing. That OS is about the most portable *BSD around, and this is their primary objective (along with "correctness", whatever that means). I'd say NetBSD probably runs on more hardware platforms than Linux, though it's pretty close race.
NetBSD is a great OS. I run it on my Sun 3/80's because nothing else will , reliably anyway. Who wants to run SunOS 4.1.1?
I'd say the primary difference between Linux and the *BSD's is not technical, because they're both pretty damn good, but one of licensing terms. The BSD's allow one to take the source and rework it into a completely commercial project, thus allowing re-distribution without releasing source. This is in stark contrast to Linux, released under the GPL, which requires those who both derive from from a GPL'd source tree AND distribute a new product based on said derivative, must also release the new source tree.
I'm not a licensing zealot, so I think there's a place for both licensing schemes. For example, I suspect the *BSD's would make a better OS than Linux for commercial embedded devices simply because of their licensing terms. However, as an end user who prefers keeping a code base to my OS free and open, I prefer using an OS released under the GPL for my day to day work... so I run Linux on my PC's -- unless I don't have a choice (like with my 3/80's), then I'll run whatever's available. Just a personal preference which says nothing about the quality of the BSD codebase. Those who hack BSD because they prefer the additional freedom of the BSD license have every justification to do so. In fact, the success of BSD in attracting quality developers is in and of itself a validation of their licensing and development model, just as is the success of Linux.
There. That's about as Politically Correct as I can get.
A few questions.. Why are the datestamps on all the files May 11?
/usr/mdec/ofwboot.elf as the actual bootloader (That's kinda useful, having the network loader packaged up inside the install. Sigh) - BUT, it's not there. Not at all. There's a file there that's called 'ofwboot', which I thought would be the one, but it seems like the Mac's OF doesn't like it as it says 'unrecognized Client Program format' (case exactly as displayed). I had a quick search through altavista and found precisely zero hits on 'ofwboot.elf' and zero on the message above.
Am I looking in the wrong spot? I went happily to my usual mirror (ftp2.au.netbsd.org), thought there was some NetBSD secret that files are hidden for 2 months before being put on show? Anyway....
I have an iMAC (as mentioned above), and I'm trying to get the bastard to boot. Not being at all new to bootp, and extremely comfortable with it, I've fired it up, and set up a root filesystem, etc. This is where the clues are needed.
The page here hints slightly that I need the file
Help?
--Rob
Comics:
Sluggy.com - It rocks my nads.
Schlock Mercenary.
This also mens that the next OpenBSD 2.6 will likely support the iMac. FYI: OpenBSD is a security focused BSD that broke off from the NetBSD team in 1995.
xm@GeekMafia.dynip.com [http://GeekMafia.dynip.com/]
If your brother happens to have an ALi 15xx chipset, the support's in 2.3.x, and there are patches for 2.2.x. (Probably in Alan Cox's 2.2.x patch tree, before they were moved out and into 2.3.x). Obviously, 2.3.x is the development branch, and the support is labelled as being in development, but they seem to work pretty well by now, and the Mandrake 6.0 distro includes a 2.2.9 Kernel RPM with the ALi 15xx support patch backfolded in.
Choice of masters is not freedom.
The NetBSD 1.4 release uses egcs on all platforms. NetBSD -current has been using egcs for some significant time :)
:)
The Mach VM system is a general purpose system, not designed specificcally for unix.
FreeBSD took turned it into a high quality, performant system, and by all accounts it took one hell of a lot of work.
Chuck Craynor specifically designed UVM for unix VM needs; it has some optimisations and extra features which are not feasible in a Mach derived system.
FreeBSD has a UBC (Unified Buffer Cache), which is still under development for UVM, which gives FreeBSD a significant advantage in filesystem caching.
By all accounts they are both very good systems,
and both work very well, but I believe the underlying design of UVM is cleaner and better suited to unix. (The NetBSD way
'Linux' runs on more different platforms than NetBSD, but what is 'linux'?
The linux that runs on the palm pilot is a totally different product/source tree that just happens to be called 'linux'. Even the sparc and ultrasparc linux sports have split the source tree (though they are working on merging them back).
The different linux source trees can release at different times. This makes it much easier for each platform to develop at its own pace, but makes extra work synchronising between source trees.
NetBSD has one central source tree, and has to synchronise all platforms to release at the same time (sixteen architectures as of 1.4). The fact it can do this is a credit to the almost fanatical desire for clean code, particuarly given the massive developer base available to linux.
I dont believe _any_ OS supports anything like the number of platforms as NetBSD out of the same source tree.