That's a fair accessment. To be honest, BSD is mostly a hobby system.
You better go and tell that to Yahoo! and all those ISP's who have server farms running nothing but FreeBSD. You better tell all those embedded companies who have mistakenly chosen NetBSD over some less well featured, closed source alternative. And all those people running critical edge systems (firewalls, routers, etc.) on OpenBSD - better tell them to switch as well. And those amateurs at Apple, what the hell are they doing running a BSD based operating system?
Your post is the most ill informed rubbish I've seen in oh, a couple of hours. Well, since I last checked SplashSnot anyway.
The next generation of Rosegarden is shaping up quite nicely. I only use it as a MIDI sequencer, but it has support for JACK and LADSPA giving it interesting audio capabilities. The only machine I own that runs Linux does so simply because of Rosegarden (anyone working on an ALSA compatability layer for the BSD's?).
http://www.all-day-breakfast.com/rosegarden/
BEAST/BSE is also good fun, but I would hesitate to recommend it to anyone for serious use as it's still pretty raw.
Windows CE is not big nor bug ridden. Windows CE 3.0 is about 1 MB
1MB? Bloody hell. You obviously don't have the same expectations from an embedded OS as I do. But then I use NetBSD with a custom built kernel which weighs in at less than half that. As for being buggy, does it still grind to a halt after 10 - 12 hours of reasonably continuous use? That's what happened when I used it at a former job. Considerable effort was expended on memory checking code but to no avail. Other WinCE developers told us that this was a familiar problem.
Microsoft makes money off of licensing Pocket PC and SmartPhone, and doesn't make as much off of Windows CE itself
I stand corrected on this point, their licensing fees will no doubt be astronomic enough to produce a healthy profit. Again, coming from a NetBSD background, paying any licesing fees is a bit of a shock:-).
As this cuts out the main revenue from WinCE, I can only see them doing this as a spoiling tactic. In other words, once WinCE has wiped out linux as a viable competitor in the embedded sphere, they'll release a new encumbered upgrade.
Of course this is unlikely to happen, as cost isn't what stops many companis using WinCE. The fact it's too big and bug ridden is.
Slashdot's usual bunch of Linux fanboys are missing the point of these articles. So SGI might move to Linux and might drop IRIX. They might port there apps to Linux (their developers are certainly experienced enough). However, SGI's future operating system strategy has little bearing on NetBSD.
NetBSD has a strong following in the academic world (I'm talking about researchers and postgrads here, not undergrads running Linux file sharing apps in their dorm). The BSD license, along with clear and well documented source make Net an ideal choice for academic work. However, a lot of cutting edge work takes place outside academia, often in companies like Sun and SGI. Often this work is not publicly documented.
Reverse engineering things like IRIX's kernel can give valuable insights into advancements made by SGI. These can then suggest new avenues for research that may have been overlooked otherwise.
So those questioning the utility of IRIX binary compatability, are missing the primary motivation for such work. Of course someone may find the ability to run IRIX apps useful one day - after all, who would have thought that NetBSD's emulation of a niche operating system like Linux would have proved so useful;-).
Linux SPARC support has been borked for most of the 2.4 series, as well as 2.5. This is mainly due to key SPARC gurus like David Miller concentrating exclusively on SPARC64 support. Last I heard (several months ago), SPARC32 was without a maintainer. The Aurora Linux guys are trying to keep the 2.4 kernel working on 32bit SPARC's, but the 1.0 release of their distribution was extremely flaky during installation and then failed to boot on a SparcStation 5.
You have some proof of "moving to finer grained locking"
I assume that was a question or accusation rather than a simple statement. Well, the proof is on the tech-smp mailing list where Paul Kranenburg and Frank van der Linden have both posted recent commments on locking improvements. Some subsystems are still not guaranteed to be OK with these finer grained locks, but the fact that testing is being carried out by switching the BKL off entirely is encouraging.
As for open source developers doing things at the their own pace and priority, I get the impression that Frank van der Linden is working to some sort of Wasabi schedule. Not that it means we'll see enterprise class SMP in a stable NetBSD release anytime soon, but it suggests someone is being paid to expend a fair proportion of their time on it.
Last I heard, NetBSD didn't do SMP though that may have changed since the last time I played with it
The SMP support is shaping up nicely. I have it running on a dual processor SparcStation 20 which recent versions of the Linux kernel wont even compile on, let alone boot. Both my i386 machines are uniprocessor (laptops), so I can't comment on the performance on commodity hardware.
Yes, for several years now. Initially it relied on one big kernel lock, just like pre 2.4 Linux did, but it's moving to finer grained locking. The great thing is NetBSD's dedication to portability, and it runs on MP i386, SPARC, Alpha, and Vax(!) systems that I'm aware of.
For the lowdown, see: http://mail-index.netbsd.org/tech-smp/
The GTK 1.2 documentation is still in that state, & GTK 2.0's documentation doesn't appear to be much better.
I like the ambiguity of your using the word "appear" - shows that you know GTK+ 2.0's documentation is in fact much better than 1.2's, but don't want to admit it. Yes, Qt does have nice documentation, but it still uses that poxy slot and signal mechanism along with a daft preprocessor.
Another legacy of fighting on the Eastern Front in World War II is the RPG. Simple and effective, it's an updated version of the German "Panzerfaust", a one shot bazooka that was simple to make, simple to operate and destroyed thousands of Allied tanks.
While it isn't as sophisticated and doesn't have the range or accuracy of the infantry missiles used by the coalition forces, it's very useful. The Russians found out the hard way how good it was, when the Afghans started using captured RPG's against tanks and other vehicles.
Iraqis do not have vast territory to retreat from.
Coalition combat troops only number 100,000 (the remainder are support personnel), which in a country the size of Iraq is a very small number. Don't forget that the Axis and Soviet armies that fought on the Eastern front numbered many millions.
They don't have cold winter to try to freeze unprepared enemys.
The desert drops to below freezing every night, while the late Spring, Summer and early Autumn are too hot for conventional forces to operate in.
They don't have woods to hide partisans in.
Which is why they are drawing the coalition forces into urban fighting, as it's incredibly costly for the attacker. This is something the Russian forces found out in Stalingrad, Budapest and Berlin, but judging by the assault on Grozny they failed to learn the lesson.
Lines of supply are fine to target, but coalition have transport aviation to resupply remote troops.
Open desert is no place to land large transport planes, and helicopters simply don't have the capacity to supply even the meagre coalition forces. With small mobile groups of Iraqi irregulars roaming the deserts, even if transport planes could land there the coalition would be taking a huge risk. Transport planes make an easy target for even the most primitive surface to air missile.
The native Mozilla in NetBSD's pkgsrc has also been updated to 1.3 - I've been running it without any problems for a couple of days now on 1.6. Locks up occasionally on -current, but that's because the new scheduler activations are not entirely happy with it.
One area where ruggedised laptops are usefull is on stage with a band. The Sisters of Mercy use several military grade laptops (aging 80386 based beasts) for sequencing - totally obsolete by most peoples standards, but ideal for the Sisters purpose. I've tried using a similar setup, laptop with a USB MIDI interface and the rosegarden sequencer, which worked quite well.
The German NetBSD birthday party will end up at the OperationMindfuck event on the 22nd of March. Check out http://www.operationmindfuck.net/. Plenty of girls, alcohol and loud industrial music.
I have to disagree. Most people can use Linux once it is installed, especially Mandrake and the like
True, but to exploit the full potential of a Unix like operating system then you need to learn the command line. I agree that people who just want web surfing, word processing and e-mailing capabilities would find Linux no harder than Windows. What's harder is for former Windows programmers to grasp concepts like pipes, "everything's a file" and the single rooted filesystem (amongst other things). Once they've got their heads around these concepts though, then things go swimmingly.
That's not exactly the fault of the language, now is it?
Well, there have been a number of posts on BugTraq describing holes in PHP itself, but it seems like a new hole in apps like PHPNuke appear every week.
PHP and Linux look a lot like the things that DIDN'T go on the heap. Simple to understand, easy to use, powerful.
For PHP, add to that: resource hungry and many of the apps written with it are notoriously insecure. For Linux, add: increasingly over engineered and poorly documented. It is simple to use and powerful, but the learning curve's steep for Joe Sixpack.
If a non-programmer can grasp it easily, it usually doesn't go on the heap.
Your implication being that if it can be understood by the great unwashed, then it must be good. Where does that leave Unix versus Windows then? What about COBOL and VB? The majority of well informed people would argue that Windows, COBOL and VB are dubious technologies... yet they prosper because they are relatively simple to use.
Frankly, if I interviewd you for a job at my firm and you trotted out the "real programmer" and "great new things are shit" mantra I'd show you the door double quick.
How does Intel currently kludge around the 4Gb memory limit on 32bit processors? The article alludes to a feature in the Xeon line that does this, but a quick Google didn't turn anything up. I assume it's some virtual memory style hack, where the pointer indexes into a table rather than directly into memory.
If there's a NetBSD mirror site for your country, then replace the "xx" in the FTP server address with your country code. Failing that,
the canonical ftp.netbsd.org server is pretty nippy.
Then burn the ISO to a CD-ROM, straightforward enough, although if you need extra instructions they can be found here:
Finally, grab the extremely good NetBSD Guide from:
http://www.netbsd.org/Documentation/
Installation should take little more than 20 minutes on modern hardware. Configure the system (little more than editing/etc/rc.conf) and reboot. Then read up on pkgsrc, which is described in the NetBSD guide. This will allow you to install loads of extra software.
FreeBSD and OpenBSD are equally worth a look, but I find Net just that little bit easier to install and configure.
SunOS was originally taken from BSD if I'm correct
The original SunOS yes, but the modern day Solaris SunOS is actually SVR4 based. Sun have made a lot of changes to their original SVR4 codebase over the years, adding amongst other things, a lot of the best bits from the BSD SunOS.
I'm a little bit unsure of the licensing that surrounds Java ports, but could NetBSD (and Open perhaps) base a native port on this work? Do Sun hold the reins when it comes to Java ports by only releasing the TCK under restrictive terms?
Currently I develop Java stuff on NetBSD using the official Sun JDK and the Linux emulation layer. If I could get a native version of the JDK then it would be quite nice to lose the need for the emulation stuff from my kernel, along with the Linux bits from SuSE.
Slashdot Mirror
That's a fair accessment. To be honest, BSD is mostly a hobby system.
You better go and tell that to Yahoo! and all those ISP's who have server farms running nothing but FreeBSD. You better tell all those embedded companies who have mistakenly chosen NetBSD over some less well featured, closed source alternative. And all those people running critical edge systems (firewalls, routers, etc.) on OpenBSD - better tell them to switch as well. And those amateurs at Apple, what the hell are they doing running a BSD based operating system?
Your post is the most ill informed rubbish I've seen in oh, a couple of hours. Well, since I last checked SplashSnot anyway.
Chris
The next generation of Rosegarden is shaping up quite nicely. I only use it as a MIDI sequencer, but it has support for JACK and LADSPA giving it interesting audio capabilities. The only machine I own that runs Linux does so simply because of Rosegarden (anyone working on an ALSA compatability layer for the BSD's?).
http://www.all-day-breakfast.com/rosegarden/
BEAST/BSE is also good fun, but I would hesitate to recommend it to anyone for serious use as it's still pretty raw.
http://beast.gtk.org/
Chris
Windows CE is not big nor bug ridden. Windows CE 3.0 is about 1 MB
1MB? Bloody hell. You obviously don't have the same expectations from an embedded OS as I do. But then I use NetBSD with a custom built kernel which weighs in at less than half that. As for being buggy, does it still grind to a halt after 10 - 12 hours of reasonably continuous use? That's what happened when I used it at a former job. Considerable effort was expended on memory checking code but to no avail. Other WinCE developers told us that this was a familiar problem.
Microsoft makes money off of licensing Pocket PC and SmartPhone, and doesn't make as much off of Windows CE itself
I stand corrected on this point, their licensing fees will no doubt be astronomic enough to produce a healthy profit. Again, coming from a NetBSD background, paying any licesing fees is a bit of a shock :-).
Chris
As this cuts out the main revenue from WinCE, I can only see them doing this as a spoiling tactic. In other words, once WinCE has wiped out linux as a viable competitor in the embedded sphere, they'll release a new encumbered upgrade.
Of course this is unlikely to happen, as cost isn't what stops many companis using WinCE. The fact it's too big and bug ridden is.
Chris
hopefully it will let some other people cut their teeth on IRIX apps. that might not have access to an actual IRIX machine.
Note that this effectively maps IRIX system calls to NetBSD ones, but you're still going to have to run this on a suitable MIPS machine.
Chris
Slashdot's usual bunch of Linux fanboys are missing the point of these articles. So SGI might move to Linux and might drop IRIX. They might port there apps to Linux (their developers are certainly experienced enough). However, SGI's future operating system strategy has little bearing on NetBSD.
;-).
NetBSD has a strong following in the academic world (I'm talking about researchers and postgrads here, not undergrads running Linux file sharing apps in their dorm). The BSD license, along with clear and well documented source make Net an ideal choice for academic work. However, a lot of cutting edge work takes place outside academia, often in companies like Sun and SGI. Often this work is not publicly documented.
Reverse engineering things like IRIX's kernel can give valuable insights into advancements made by SGI. These can then suggest new avenues for research that may have been overlooked otherwise.
So those questioning the utility of IRIX binary compatability, are missing the primary motivation for such work. Of course someone may find the ability to run IRIX apps useful one day - after all, who would have thought that NetBSD's emulation of a niche operating system like Linux would have proved so useful
Chris
Linux SPARC support has been borked for most of the 2.4 series, as well as 2.5. This is mainly due to key SPARC gurus like David Miller concentrating exclusively on SPARC64 support. Last I heard (several months ago), SPARC32 was without a maintainer. The Aurora Linux guys are trying to keep the 2.4 kernel working on 32bit SPARC's, but the 1.0 release of their distribution was extremely flaky during installation and then failed to boot on a SparcStation 5.
Chris
You have some proof of "moving to finer grained locking"
I assume that was a question or accusation rather than a simple statement. Well, the proof is on the tech-smp mailing list where Paul Kranenburg and Frank van der Linden have both posted recent commments on locking improvements. Some subsystems are still not guaranteed to be OK with these finer grained locks, but the fact that testing is being carried out by switching the BKL off entirely is encouraging.
As for open source developers doing things at the their own pace and priority, I get the impression that Frank van der Linden is working to some sort of Wasabi schedule. Not that it means we'll see enterprise class SMP in a stable NetBSD release anytime soon, but it suggests someone is being paid to expend a fair proportion of their time on it.
Chris
Last I heard, NetBSD didn't do SMP though that may have changed since the last time I played with it
The SMP support is shaping up nicely. I have it running on a dual processor SparcStation 20 which recent versions of the Linux kernel wont even compile on, let alone boot. Both my i386 machines are uniprocessor (laptops), so I can't comment on the performance on commodity hardware.
Chris
Does NetBSD support multiple processors?
Yes, for several years now. Initially it relied on one big kernel lock, just like pre 2.4 Linux did, but it's moving to finer grained locking. The great thing is NetBSD's dedication to portability, and it runs on MP i386, SPARC, Alpha, and Vax(!) systems that I'm aware of.
For the lowdown, see: http://mail-index.netbsd.org/tech-smp/
Chris
This is the most obvious April Fools yet :-)
The GTK 1.2 documentation is still in that state, & GTK 2.0's documentation doesn't appear to be much better.
I like the ambiguity of your using the word "appear" - shows that you know GTK+ 2.0's documentation is in fact much better than 1.2's, but don't want to admit it. Yes, Qt does have nice documentation, but it still uses that poxy slot and signal mechanism along with a daft preprocessor.
Chris
Another legacy of fighting on the Eastern Front in World War II is the RPG. Simple and effective, it's an updated version of the German "Panzerfaust", a one shot bazooka that was simple to make, simple to operate and destroyed thousands of Allied tanks.
While it isn't as sophisticated and doesn't have the range or accuracy of the infantry missiles used by the coalition forces, it's very useful. The Russians found out the hard way how good it was, when the Afghans started using captured RPG's against tanks and other vehicles.
Chris
Looks like they read those russian books wrong ;)
Iraqis do not have vast territory to retreat from.
Coalition combat troops only number 100,000 (the remainder are support personnel), which in a country the size of Iraq is a very small number. Don't forget that the Axis and Soviet armies that fought on the Eastern front numbered many millions.
They don't have cold winter to try to freeze unprepared enemys.
The desert drops to below freezing every night, while the late Spring, Summer and early Autumn are too hot for conventional forces to operate in.
They don't have woods to hide partisans in.
Which is why they are drawing the coalition forces into urban fighting, as it's incredibly costly for the attacker. This is something the Russian forces found out in Stalingrad, Budapest and Berlin, but judging by the assault on Grozny they failed to learn the lesson.
Lines of supply are fine to target, but coalition have transport aviation to resupply remote troops.
Open desert is no place to land large transport planes, and helicopters simply don't have the capacity to supply even the meagre coalition forces. With small mobile groups of Iraqi irregulars roaming the deserts, even if transport planes could land there the coalition would be taking a huge risk. Transport planes make an easy target for even the most primitive surface to air missile.
Chris
The native Mozilla in NetBSD's pkgsrc has also been updated to 1.3 - I've been running it without any problems for a couple of days now on 1.6. Locks up occasionally on -current, but that's because the new scheduler activations are not entirely happy with it.
Chris
One area where ruggedised laptops are usefull is on stage with a band. The Sisters of Mercy use several military grade laptops (aging 80386 based beasts) for sequencing - totally obsolete by most peoples standards, but ideal for the Sisters purpose. I've tried using a similar setup, laptop with a USB MIDI interface and the rosegarden sequencer, which worked quite well.
Chris
"set -o emacs" in NetBSD's standard Bourne shell will give you command line history. Nect time RTFM.
Chris
The German NetBSD birthday party will end up at the OperationMindfuck event on the 22nd of March. Check out http://www.operationmindfuck.net/. Plenty of girls, alcohol and loud industrial music.
Chris
I have to disagree. Most people can use Linux once it is installed, especially Mandrake and the like
True, but to exploit the full potential of a Unix like operating system then you need to learn the command line. I agree that people who just want web surfing, word processing and e-mailing capabilities would find Linux no harder than Windows. What's harder is for former Windows programmers to grasp concepts like pipes, "everything's a file" and the single rooted filesystem (amongst other things). Once they've got their heads around these concepts though, then things go swimmingly.
Chris
That's not exactly the fault of the language, now is it?
Well, there have been a number of posts on BugTraq describing holes in PHP itself, but it seems like a new hole in apps like PHPNuke appear every week.
Chris
PHP and Linux look a lot like the things that DIDN'T go on the heap. Simple to understand, easy to use, powerful.
For PHP, add to that: resource hungry and many of the apps written with it are notoriously insecure. For Linux, add: increasingly over engineered and poorly documented. It is simple to use and powerful, but the learning curve's steep for Joe Sixpack.
If a non-programmer can grasp it easily, it usually doesn't go on the heap.
Your implication being that if it can be understood by the great unwashed, then it must be good. Where does that leave Unix versus Windows then? What about COBOL and VB? The majority of well informed people would argue that Windows, COBOL and VB are dubious technologies ... yet they prosper because they are relatively simple to use.
Frankly, if I interviewd you for a job at my firm and you trotted out the "real programmer" and "great new things are shit" mantra I'd show you the door double quick.
Chris
How does Intel currently kludge around the 4Gb memory limit on 32bit processors? The article alludes to a feature in the Xeon line that does this, but a quick Google didn't turn anything up. I assume it's some virtual memory style hack, where the pointer indexes into a table rather than directly into memory.
Chris
If I wanted to get started on BSD where is a good place to begin?
If you want to try NetBSD, then download the ISO image from:
ftp://ftp.xx.netbsd.org/pub/NetBSD/iso/1.6/i386c d.iso
If there's a NetBSD mirror site for your country, then replace the "xx" in the FTP server address with your country code. Failing that, the canonical ftp.netbsd.org server is pretty nippy.
Then burn the ISO to a CD-ROM, straightforward enough, although if you need extra instructions they can be found here:
http://www.netbsd.org/Documentation/bootcd.html# cdrecord
Finally, grab the extremely good NetBSD Guide from:
http://www.netbsd.org/Documentation/
Installation should take little more than 20 minutes on modern hardware. Configure the system (little more than editing /etc/rc.conf) and reboot. Then read up on pkgsrc, which is described in the NetBSD guide. This will allow you to install loads of extra software.
FreeBSD and OpenBSD are equally worth a look, but I find Net just that little bit easier to install and configure.
Chris
SunOS was originally taken from BSD if I'm correct
The original SunOS yes, but the modern day Solaris SunOS is actually SVR4 based. Sun have made a lot of changes to their original SVR4 codebase over the years, adding amongst other things, a lot of the best bits from the BSD SunOS.
Chris
I'm a little bit unsure of the licensing that surrounds Java ports, but could NetBSD (and Open perhaps) base a native port on this work? Do Sun hold the reins when it comes to Java ports by only releasing the TCK under restrictive terms?
Currently I develop Java stuff on NetBSD using the official Sun JDK and the Linux emulation layer. If I could get a native version of the JDK then it would be quite nice to lose the need for the emulation stuff from my kernel, along with the Linux bits from SuSE.
Chris