The part about licensing IP from third parties is true - their licenses may legally prohibit them from releasing the trade secrets (or whatever is protected). The best you can get in pure 'free' form is a driver which is effectively crippled in functionality or performance because it can't use a good algorithm. It's humiliating that actual human beings not only created such a legal system, but enforce and support it, even build economies based on it. Next thing you know it'll be often illegal to use certain short combinations of letters without proper legal wrapping. Oh wait...
You must be joking when you say "As much as I'd like to see everyone forced to use Linux for a kernel". Linux is fantastic for a lot of things, but it's still infinitely far from being ideal for *every* use case. There are many many things for which other systems (yes, even Windows, as long as proprietary software is locked to that platform) are much better.
So if you seriously believe Linux is what everyone should be forced to use, you're ignoring the collective human wisdom surrounding freedom of choice and *platform* standardization (rather than *implementation* standardization).
I'd much rather "force" every OS to provide a decent POSIX *platform* than a specific implementation like GNU/Linux. Some would argue it's too buggy to be an exact implementation anyway, but that's another matter. Windows, on the other hand, has such a small and broken subset of POSIX it's barely usable.
Even having said that, it's still absurd to make every embedded device support the full POSIX, because they're never going to use it and it's prohibitively extensive. The point is that any platform that wants to be supported by a wide software selection should support an appropriate set of standards, and Microsoft make a deliberate and calculated effort to do the exact opposite, to the detriment of all mankind. My rage is boundless.
It's a bonus (malus?) cost of proprietary software. Part of the "genuine advantage", of course. You're screwed either way. FOSS remains the only way to go. I'd much rather have to license one proprietary package on an open system than the entire system, and all the compromises that inherently accompany proprietary software.
Or Theora (video) + Vorbis (audio) in OGG (container). All unencumbered and open. Investigate 'ffmpeg2theora' for a one-liner to convert any reasonably open video to the much more open combination mentioned. The codecs are very good in compression and quality. Any platform which can run VLC or MPlayer can handle this combination, but admittedly mobile phones are pressed for processing speed. Media Player Classic (http://sourceforge.net/projects/guliverkli/) is another fine choice if you're stuck in Windows and want a decent, sane media player.
There's no good way to look at it. The "problem" that you missed is not that the hardware requires firmware (which is perfectly fine), but that the firmware is extremely restricted and virtually impossible to replace. Theo wants at least the freedom to distribute the firmware blobs with free operating systems without additional restrictions on the users, and even that is being denied by many vendors, continuing to require accepting a license on a web page and forbidding redistributing the blob you receive.
The common situation is that to use your wireless card, you need to go to the vendor website and accept a license agreement to download it (very, very few distributions accept restrictions to bundle even the "more" liberal firmware like Intel PRO Wireless blobs, and those that do are frequently beaten up for doing so). You can't do this without your wireless card working, so you try to find the driver CD (if there is one at all) and then tear off the firmware which is not guaranteed to match the kernel driver's expected interface anyway. If the dark lords have mercy on you, you may proceed to accept the license and install the newer, less broken firmware. Maybe.
Unix is a trademark - you can't name things Unix (not even UNIX as it should be) willy-nilly. We just need a new term, and Linux seems to have become a blanket term for "libre Unix workalike or derivative" which is offensive to those who dislike Linux but, really, doesn't make even a tiny difference to the masses of clueless users who wouldn't even be able to tell the systems apart, as long as they're not Windows or OSX which everyone knows.
In fact, the end users wouldn't even care what base system it's on, with things like KDE and GNOME appearing and being nothing like real Unix, just happening to run on compatible systems. And a lot of the "Linux software" is being ported to even run on Windows, which is about as compatible with Linux and glibc as day and 1. Even MPlayer, originally called "The Media Player for Linux", now runs on practically everything (and crawls on everything else).
The absurd size of these drivers (even compared to other 'abstracted' drivers like in X.Org) means there's a LOT of redundancy or sheer failure of engineering. No, nVidia sucks and should be overthrown by force if necessary. Binary drivers are an inexcusable evil, giving us a quick workaround to a permanent problem, which is not guaranteed to work with the combination of old cards and new kernels/XOrgs, or at all with custom configs or patchings, let alone allow porting to other systems with any practical ease. Oh, and want to check them for stability and security? Nope, pack up and go home, you won't win this one. We need more Theos fighting binary crimes and less moron end users encouraging their vendors to give out these terrible hacks.
You can't be serious. *Anything* which somebody would rather pay to have done than do themself, will get paid to get done. If you take away money incentives, then people will start selling items where they can, or assistance where they can't (I don't know WoW so I don't know what can't be sold). A less scalable but entirely possible scheme would be for people for a service of building your character for you while you're doing more useful things (like working, resting or watching paint dry) at a rate not unlike a day job. It'd be like a boss hiring an employee to organize things in the office, except that it's completely stupid because nobody should be playing WoW anyway.
Apologies, I misunderstood. Shouldn't the kernel somehow deny access to that page from another process when it's 'owned' by the server? Actually I didn't think the server would get the same page anyway (unless it requested a new page instead of writing to an existing one). What you describe sounds like shared memory, where both processes agree that the memory involved is not exclusively theirs, and if vmsplice() is meant to do something similar between processes (not just user-kernel) then it'll be quite a problem.
You're right, I should have considered the possibility of card->user page, I only considered kernel->user page (which may as well be a copy, heck they're very fast with MMX anyway). My issue with this is that the card would have to wait until it's asked to write to the user page, otherwise it will have to write to a kernel page anyway, because you can't quite synchronize the same as with writes.
I don't favor zero-copy in either COW or splice implementations. The extra sophistication required (either in kernel or userland) and ALWAYS requiring over-allocating is pretty insignificant when you can just do a memcpy, which becomes an almost 'free' operation when you bring in the processor's cache. The tiny potential kernel memory savings of zero-copy are completely nerfed by having to allocate multiple buffers in the user program anyway, so that can't be used as an argument either. Not to mention working with more memory in a single schedule of the processor time offers less chance to utilize the cache properly.
A better optimization would be to reduce the syscall overhead by buffering the operations themselves in userland until a certain amount of time has passed (something reasonable in the milliseconds), and balancing this out to reduce the overall latency of the IO. With reads this is even better since there's no *extra* latency, but with reads the program should be smart enough to buffer ahead anyway.
You *definitely* can't have zero-copy into a 'read', simply because the page is already defined for the data to be written to - you can't simply 'swap' it with the page with the right data (any such hack should be made illegal). Even so, a memcpy isn't going to kill anyone.
A server should never assume the *client* did sanity checking on the data it's sending anyway. The kernel can't do this either, since it doesn't know what 'sane' is - bits are bits. Grandparent has forgotten to take his medication.
If you want a good measure of how efficient your kernel is with pure socket IO, netperf localhost via UDP. Network card/driver overhead is eliminated, so is application logic. The closer it is to pure memory bandwidth, the more awesome your kernel is. SMP really helps here, so it's a bit unfair for UP systems and giant-locked network stacks, though in practice the effect on real network throughput (we're talking multi-client combined throughput) is even better.
As we move more of our lives into computers - multimedia, information, communication - they have to be able to keep up. I suppose you're on a 486 running FreeDOS and Telnetting to Slashdot? No.
Technology has to evolve. We phase out old designs for ovens, for chrissakes, why should something as important as a computer NOT be upgraded? The manufacturing costs are fantastically low. If only the components were to be disassembled and utilized in cheaper hardware, it'd be useful recycling, without the full procedure required for material recycling.
By the way, if you don't want to sound stupid, get "its"/"it's" right, and it's "would have", not "would of". But this is moot compared to how stupid the message itself is.
And don't even joke about Slashdot being a power user base. If 'power' is being able to create shortcuts in Windows, sure, but really, we're looking at a mass of people who wouldn't know a Von Neumann architecture from their own ass with a detailed diagram. There are very few people who actually know anything useful at all, and they usually have better things to do.
Speaking of being clueless, ICMP and UDP are connectionless. TCP is the only one of the three protocols you mentioned which *does* maintain a bidirectional state on the protocol layer. So while it's nice that you think you've got it all worked out by using the pitiful filtering capacity you get out of the box... you still fail at the internet.
Human: your mother
ALICE: Actually I do not have a mother.
Human: yes you do
ALICE: Hmm. When do I do it?
Human: right now
ALICE: Oh. I am glad we agree.
I think this is even worse than the original ALICE. But then Parry's the cool one.
That was a single-process multi-thread setup, which NetBSD doesn't seem to handle very well (or it wasn't set up properly for that bench, which is also a popular claim).
See how NetBSD 3.0 and DragonFly BSD 1.4 do compared to FreeBSD 6 and post some good benches. That'll be interesting.
Sure, except that cgd works on memory block devices (useless) and file-backed block devices (pretty useful). And on any disk. And on any platform. And on USB bars and floppy diskettes.
Nice to hear Seagate is offering a specialty product, but you can have much more versatile encryption for free, and it's easier to administer. How would the Seagate drive get its password? Would you type it in while booting? Or have to use a Windows-specific driver? Or would it memorise it, completely defeating the point of encryption?
Performance isn't everything. 'Slow' doesn't mean 'decidedly inferior'. By that token you may as well take a plane to work instead of driving a car.
NetBSD's code paths would be severely extended if it was to add in hooks for DRI, etc. Sure, it wouldn't be all bad, in fact most wouldn't notice. I do believe it's a "we don't care enough about it" issue, not even a "we can't do it" issue (they've done much more remarkable things).
But why would you even need DRI on a 'workstation'? NetBSD runs all of the bleeding-edge workstation software like aterm and vim. If you're really daring you can even use one of those graphically intensive CAD applications like TGif.
My point: Unix people are used to having under-impressive 'workstations'. It's about getting things done. If taking a year to implement DRI for every major card and resulting in a slightly reduced latency for MPlayer is your idea of a good pursuit for a functionality-oriented OS, good for you.
Relax. Linux' large developer base is the reason for its mess and increasing bureaucracy. It's getting to the stage where code being too clean for the rest of the kernel is a reason to not include it in mainline (this was an argument against Reiser4).
Working on more minor projects with less random hacker interest and less pressure to keep up is the only way to result in a clean product. Rushing to compete rarely achieves anything. Not many people care about the quality of the code until it affects the quality of the product. And every Linux 'oops, my last commit broke everything, sorry' changelog entry speaks for itself.
This is why the BSDs survive despite having several orders of magnitude less developer resources. Less to manage, low pressure, good work done. FreeBSD is falling to Linux' disease of over-coding under-thinking, in particular the new complexity in 5/6 which is making it much harder to develop. They have recovered from the brutal side effects of the new SMP stack but how DragonFly's competes has yet to be seen, and the latter was done with much less mucking about, less segfaults, and much less in the way of resources.
However, Linux' incredibly large developer base means it can do just about anything (except, strangely, proper jails), and also run on just about anything too. However, not everything is done cleanly. In *one*day* (as per my reading of KernelPlanet, NOT by post time), these two posts on KernelPlanet made me break into a cold sweat:
The first outlines how failure to plan ahead lead to a hacky solution to what should have been a simple problem. The latter is an example of how some kernel developers just go and do something really stupid and people don't notice until it's too late.
Sure, these things happen in other systems, but they're easier to notice when there's only 20 developers, compared to 20,000. When you can afford to track every commit, you can easily notice if something stupid is happening. Add to this that Linux committers are fine with accepting small *anonymous* commits, and you have a clear path to utter failure.
So don't worry about your project. Sure few people will even know it exists, but at least you can sleep at night knowing it's as clean as you can make it.
Or use your talent to empower DragonFly BSD, which still has the potential to usurp Linux with its SMP stack, one of the most popular reasons to use Linux instead of (say) NetBSD.
The basic problem is that most people leave on memory caching, which is a default that is not changable other than hand-hacking the config or accessing about:config
This has a few tangible consequences. Firstly, memory consumption grows for everything you download. It's kept in memory. And on disk. Defeating the point of both at the same time. This is stupid, but that's Mozilla.org for you, worst fucking coders to ever be recognized as a high-ranking.
Secondly, scalability drops. I hope they're using something sensible like a hash table, but chances are, no they're not.
Lastly (that I can care about), it will eventually run out of memory and freak out. This is rare because any extension at all has a high chance of crashing it, and also its own JavaScript interpreter, and probably a dozen other things.
It is a steaming pile of shit that I can't believe ranks higher than Tiger (a surprisingly good system I've never used but hear good things about, basically a FreeBSD for suckers^Wartists) and countless other GOOD products.
The security vulnerability list is fantastically long. And for each minor update (containing a few patches), you have to download the entire tree again. It's not as bad on binary-based package managers of course. It's not hard to write secure code. Thinking before you act helps.
#1 thing I hate about Firefox more than any other of its problems: it assigns favicons to bookmarks based on the time frame in which they were downloaded, not their source. So if you are browsing multiple sites in parallel or even close enough in time, and bookmark them, you have a disturbingly high chance of your bookmarks having favicons from other sites entirely, and others having none at all. This is fucking pathetic and I can't believe that, with problems like this, the rest of the browser works at all.
On that note, there was that laughable 'crypto' of adding a number to every byte of a 'secure' config file which really nailed the coffin as far as good ideas are concerned.
It would help you to know that, although the DragonFly BSD code is cleaner, they still haven't actually lifted the giant lock from most subsystems, so in actual fact a DFly system is probably WORSE in terms of raw parallelism than a FreeBSD 6 system, which has had at the very least many more drivers lifted. But then Linux 2.6 is probably even better in this regard.
However, in terms of cleanliness of the system and the code, and the guarantee of a better future, yes DragonFly BSD is a terrific choice, however you will still need to do frequent rebuilds of everything as system calls and structures are still being added or changed (see http://www.shiningsilence.com/dbsdlog/ for heads up). DFly will be still undergoing years of restructuring and there is no reason to believe that at any point will it become properly 'stable' in terms of development (though in my experience it is remarkably stable for actual usage), but if you're a BSDophile you're already used to rebuilds and tracking mailing lists or at least blogs like the above.
One final mention is that software availability for DragonFly BSD is still lower than for FreeBSD, which is still slightly lower than for Linux. This situation is greatly improving, but I still haven't heard of anyone running a native Java environment on DFly, which may be a problem for some people (heck I know I would love a JDK/JRE on DFly, I quite like Java as a language). However it's possible that one of the 'Java for Linux' projects (there are at least 10) has bothered being portable. Whether or not it goes so far as to use kqueue for SelectorProviders and so on I can't even begin to guess.
If you're talking about the threading library, it's inherently N:M but linking with a different threading library makes it 1:1. Performance has been shown to be inferior to NPTL and NetBSD's SA, but maybe that's improved by now.
If you're talking about the thread/process scheduler, it's ULE, based on the old O(1) scheduler in Linux. It has nices and processor affinity so it could only be called M:N, which is not the right terminology (is ANY modern scheduler 1:1 anyway?!).
Packet scheduler? I doubt you're talking about that. Same for IO scheduler.
Does he intend to update those and add DragonFly and NetBSD? DragonFly in particular has had a lot of work done which should be very interesting. I'm not sure if it has been micro-optimised like some of the efforts done for FreeBSD and Linux, but on the macro scale it looks good. -PREVIEW should be slipped Real Soon Now and contains numerous improvements over the last slip, some of which may be relevant to the topic.
Slashdot Mirror
The part about licensing IP from third parties is true - their licenses may legally prohibit them from releasing the trade secrets (or whatever is protected). The best you can get in pure 'free' form is a driver which is effectively crippled in functionality or performance because it can't use a good algorithm. It's humiliating that actual human beings not only created such a legal system, but enforce and support it, even build economies based on it. Next thing you know it'll be often illegal to use certain short combinations of letters without proper legal wrapping. Oh wait...
You must be joking when you say "As much as I'd like to see everyone forced to use Linux for a kernel". Linux is fantastic for a lot of things, but it's still infinitely far from being ideal for *every* use case. There are many many things for which other systems (yes, even Windows, as long as proprietary software is locked to that platform) are much better.
So if you seriously believe Linux is what everyone should be forced to use, you're ignoring the collective human wisdom surrounding freedom of choice and *platform* standardization (rather than *implementation* standardization).
I'd much rather "force" every OS to provide a decent POSIX *platform* than a specific implementation like GNU/Linux. Some would argue it's too buggy to be an exact implementation anyway, but that's another matter. Windows, on the other hand, has such a small and broken subset of POSIX it's barely usable.
Even having said that, it's still absurd to make every embedded device support the full POSIX, because they're never going to use it and it's prohibitively extensive. The point is that any platform that wants to be supported by a wide software selection should support an appropriate set of standards, and Microsoft make a deliberate and calculated effort to do the exact opposite, to the detriment of all mankind. My rage is boundless.
It's a bonus (malus?) cost of proprietary software. Part of the "genuine advantage", of course. You're screwed either way. FOSS remains the only way to go. I'd much rather have to license one proprietary package on an open system than the entire system, and all the compromises that inherently accompany proprietary software.
So now we have a way to link snowflakes and cryptography.
Or Theora (video) + Vorbis (audio) in OGG (container). All unencumbered and open. Investigate 'ffmpeg2theora' for a one-liner to convert any reasonably open video to the much more open combination mentioned. The codecs are very good in compression and quality. Any platform which can run VLC or MPlayer can handle this combination, but admittedly mobile phones are pressed for processing speed. Media Player Classic (http://sourceforge.net/projects/guliverkli/) is another fine choice if you're stuck in Windows and want a decent, sane media player.
There's no good way to look at it. The "problem" that you missed is not that the hardware requires firmware (which is perfectly fine), but that the firmware is extremely restricted and virtually impossible to replace. Theo wants at least the freedom to distribute the firmware blobs with free operating systems without additional restrictions on the users, and even that is being denied by many vendors, continuing to require accepting a license on a web page and forbidding redistributing the blob you receive. The common situation is that to use your wireless card, you need to go to the vendor website and accept a license agreement to download it (very, very few distributions accept restrictions to bundle even the "more" liberal firmware like Intel PRO Wireless blobs, and those that do are frequently beaten up for doing so). You can't do this without your wireless card working, so you try to find the driver CD (if there is one at all) and then tear off the firmware which is not guaranteed to match the kernel driver's expected interface anyway. If the dark lords have mercy on you, you may proceed to accept the license and install the newer, less broken firmware. Maybe.
Unix is a trademark - you can't name things Unix (not even UNIX as it should be) willy-nilly. We just need a new term, and Linux seems to have become a blanket term for "libre Unix workalike or derivative" which is offensive to those who dislike Linux but, really, doesn't make even a tiny difference to the masses of clueless users who wouldn't even be able to tell the systems apart, as long as they're not Windows or OSX which everyone knows.
In fact, the end users wouldn't even care what base system it's on, with things like KDE and GNOME appearing and being nothing like real Unix, just happening to run on compatible systems. And a lot of the "Linux software" is being ported to even run on Windows, which is about as compatible with Linux and glibc as day and 1. Even MPlayer, originally called "The Media Player for Linux", now runs on practically everything (and crawls on everything else).
The absurd size of these drivers (even compared to other 'abstracted' drivers like in X.Org) means there's a LOT of redundancy or sheer failure of engineering. No, nVidia sucks and should be overthrown by force if necessary. Binary drivers are an inexcusable evil, giving us a quick workaround to a permanent problem, which is not guaranteed to work with the combination of old cards and new kernels/XOrgs, or at all with custom configs or patchings, let alone allow porting to other systems with any practical ease. Oh, and want to check them for stability and security? Nope, pack up and go home, you won't win this one. We need more Theos fighting binary crimes and less moron end users encouraging their vendors to give out these terrible hacks.
You can't be serious. *Anything* which somebody would rather pay to have done than do themself, will get paid to get done. If you take away money incentives, then people will start selling items where they can, or assistance where they can't (I don't know WoW so I don't know what can't be sold). A less scalable but entirely possible scheme would be for people for a service of building your character for you while you're doing more useful things (like working, resting or watching paint dry) at a rate not unlike a day job. It'd be like a boss hiring an employee to organize things in the office, except that it's completely stupid because nobody should be playing WoW anyway.
Apologies, I misunderstood. Shouldn't the kernel somehow deny access to that page from another process when it's 'owned' by the server? Actually I didn't think the server would get the same page anyway (unless it requested a new page instead of writing to an existing one). What you describe sounds like shared memory, where both processes agree that the memory involved is not exclusively theirs, and if vmsplice() is meant to do something similar between processes (not just user-kernel) then it'll be quite a problem.
You're right, I should have considered the possibility of card->user page, I only considered kernel->user page (which may as well be a copy, heck they're very fast with MMX anyway). My issue with this is that the card would have to wait until it's asked to write to the user page, otherwise it will have to write to a kernel page anyway, because you can't quite synchronize the same as with writes.
I don't favor zero-copy in either COW or splice implementations. The extra sophistication required (either in kernel or userland) and ALWAYS requiring over-allocating is pretty insignificant when you can just do a memcpy, which becomes an almost 'free' operation when you bring in the processor's cache. The tiny potential kernel memory savings of zero-copy are completely nerfed by having to allocate multiple buffers in the user program anyway, so that can't be used as an argument either. Not to mention working with more memory in a single schedule of the processor time offers less chance to utilize the cache properly.
A better optimization would be to reduce the syscall overhead by buffering the operations themselves in userland until a certain amount of time has passed (something reasonable in the milliseconds), and balancing this out to reduce the overall latency of the IO. With reads this is even better since there's no *extra* latency, but with reads the program should be smart enough to buffer ahead anyway.
You *definitely* can't have zero-copy into a 'read', simply because the page is already defined for the data to be written to - you can't simply 'swap' it with the page with the right data (any such hack should be made illegal). Even so, a memcpy isn't going to kill anyone.
A server should never assume the *client* did sanity checking on the data it's sending anyway. The kernel can't do this either, since it doesn't know what 'sane' is - bits are bits. Grandparent has forgotten to take his medication.
If you want a good measure of how efficient your kernel is with pure socket IO, netperf localhost via UDP. Network card/driver overhead is eliminated, so is application logic. The closer it is to pure memory bandwidth, the more awesome your kernel is. SMP really helps here, so it's a bit unfair for UP systems and giant-locked network stacks, though in practice the effect on real network throughput (we're talking multi-client combined throughput) is even better.
As we move more of our lives into computers - multimedia, information, communication - they have to be able to keep up. I suppose you're on a 486 running FreeDOS and Telnetting to Slashdot? No.
Technology has to evolve. We phase out old designs for ovens, for chrissakes, why should something as important as a computer NOT be upgraded? The manufacturing costs are fantastically low. If only the components were to be disassembled and utilized in cheaper hardware, it'd be useful recycling, without the full procedure required for material recycling.
By the way, if you don't want to sound stupid, get "its"/"it's" right, and it's "would have", not "would of". But this is moot compared to how stupid the message itself is.
And don't even joke about Slashdot being a power user base. If 'power' is being able to create shortcuts in Windows, sure, but really, we're looking at a mass of people who wouldn't know a Von Neumann architecture from their own ass with a detailed diagram. There are very few people who actually know anything useful at all, and they usually have better things to do.
http://www.netbsd.org/
Linux kernel is one of the worst examples of open source code. NetBSD is one of the best. Enjoy.
DragonFly BSD is turning out some really great progress too, but there's still a lot of FreeBSDism left.
Speaking of being clueless, ICMP and UDP are connectionless. TCP is the only one of the three protocols you mentioned which *does* maintain a bidirectional state on the protocol layer. So while it's nice that you think you've got it all worked out by using the pitiful filtering capacity you get out of the box... you still fail at the internet.
Human: your mother ALICE: Actually I do not have a mother. Human: yes you do ALICE: Hmm. When do I do it? Human: right now ALICE: Oh. I am glad we agree. I think this is even worse than the original ALICE. But then Parry's the cool one.
That was a single-process multi-thread setup, which NetBSD doesn't seem to handle very well (or it wasn't set up properly for that bench, which is also a popular claim).
See how NetBSD 3.0 and DragonFly BSD 1.4 do compared to FreeBSD 6 and post some good benches. That'll be interesting.
Sure, except that cgd works on memory block devices (useless) and file-backed block devices (pretty useful). And on any disk. And on any platform. And on USB bars and floppy diskettes.
Nice to hear Seagate is offering a specialty product, but you can have much more versatile encryption for free, and it's easier to administer. How would the Seagate drive get its password? Would you type it in while booting? Or have to use a Windows-specific driver? Or would it memorise it, completely defeating the point of encryption?
Performance isn't everything. 'Slow' doesn't mean 'decidedly inferior'. By that token you may as well take a plane to work instead of driving a car.
Because these features can require compromises.
NetBSD's code paths would be severely extended if it was to add in hooks for DRI, etc.
Sure, it wouldn't be all bad, in fact most wouldn't notice. I do believe it's a "we don't care enough about it" issue, not even a "we can't do it" issue (they've done much more remarkable things).
But why would you even need DRI on a 'workstation'? NetBSD runs all of the bleeding-edge workstation software like aterm and vim. If you're really daring you can even use one of those graphically intensive CAD applications like TGif.
My point: Unix people are used to having under-impressive 'workstations'. It's about getting things done. If taking a year to implement DRI for every major card and resulting in a slightly reduced latency for MPlayer is your idea of a good pursuit for a functionality-oriented OS, good for you.
Relax. Linux' large developer base is the reason for its mess and increasing bureaucracy. It's getting to the stage where code being too clean for the rest of the kernel is a reason to not include it in mainline (this was an argument against Reiser4).
m l1 2/06/#20051206-libusb
Working on more minor projects with less random hacker interest and less pressure to keep up is the only way to result in a clean product. Rushing to compete rarely achieves anything. Not many people care about the quality of the code until it affects the quality of the product. And every Linux 'oops, my last commit broke everything, sorry' changelog entry speaks for itself.
This is why the BSDs survive despite having several orders of magnitude less developer resources. Less to manage, low pressure, good work done. FreeBSD is falling to Linux' disease of over-coding under-thinking, in particular the new complexity in 5/6 which is making it much harder to develop. They have recovered from the brutal side effects of the new SMP stack but how DragonFly's competes has yet to be seen, and the latter was done with much less mucking about, less segfaults, and much less in the way of resources.
However, Linux' incredibly large developer base means it can do just about anything (except, strangely, proper jails), and also run on just about anything too. However, not everything is done cleanly. In *one*day* (as per my reading of KernelPlanet, NOT by post time), these two posts on KernelPlanet made me break into a cold sweat:
http://www.livejournal.com/users/zaitcev/43337.ht
http://ganesha.gnumonks.org/~laforge/weblog/2005/
The first outlines how failure to plan ahead lead to a hacky solution to what should have been a simple problem. The latter is an example of how some kernel developers just go and do something really stupid and people don't notice until it's too late.
Sure, these things happen in other systems, but they're easier to notice when there's only 20 developers, compared to 20,000. When you can afford to track every commit, you can easily notice if something stupid is happening. Add to this that Linux committers are fine with accepting small *anonymous* commits, and you have a clear path to utter failure.
So don't worry about your project. Sure few people will even know it exists, but at least you can sleep at night knowing it's as clean as you can make it.
Or use your talent to empower DragonFly BSD, which still has the potential to usurp Linux with its SMP stack, one of the most popular reasons to use Linux instead of (say) NetBSD.
The basic problem is that most people leave on memory caching, which is a default that is not changable other than hand-hacking the config or accessing about:config
This has a few tangible consequences. Firstly, memory consumption grows for everything you download. It's kept in memory. And on disk. Defeating the point of both at the same time. This is stupid, but that's Mozilla.org for you, worst fucking coders to ever be recognized as a high-ranking.
Secondly, scalability drops. I hope they're using something sensible like a hash table, but chances are, no they're not.
Lastly (that I can care about), it will eventually run out of memory and freak out. This is rare because any extension at all has a high chance of crashing it, and also its own JavaScript interpreter, and probably a dozen other things.
It is a steaming pile of shit that I can't believe ranks higher than Tiger (a surprisingly good system I've never used but hear good things about, basically a FreeBSD for suckers^Wartists) and countless other GOOD products.
The security vulnerability list is fantastically long. And for each minor update (containing a few patches), you have to download the entire tree again. It's not as bad on binary-based package managers of course. It's not hard to write secure code. Thinking before you act helps.
#1 thing I hate about Firefox more than any other of its problems: it assigns favicons to bookmarks based on the time frame in which they were downloaded, not their source. So if you are browsing multiple sites in parallel or even close enough in time, and bookmark them, you have a disturbingly high chance of your bookmarks having favicons from other sites entirely, and others having none at all. This is fucking pathetic and I can't believe that, with problems like this, the rest of the browser works at all.
On that note, there was that laughable 'crypto' of adding a number to every byte of a 'secure' config file which really nailed the coffin as far as good ideas are concerned.
It would help you to know that, although the DragonFly BSD code is cleaner, they still haven't actually lifted the giant lock from most subsystems, so in actual fact a DFly system is probably WORSE in terms of raw parallelism than a FreeBSD 6 system, which has had at the very least many more drivers lifted. But then Linux 2.6 is probably even better in this regard.
However, in terms of cleanliness of the system and the code, and the guarantee of a better future, yes DragonFly BSD is a terrific choice, however you will still need to do frequent rebuilds of everything as system calls and structures are still being added or changed (see http://www.shiningsilence.com/dbsdlog/ for heads up). DFly will be still undergoing years of restructuring and there is no reason to believe that at any point will it become properly 'stable' in terms of development (though in my experience it is remarkably stable for actual usage), but if you're a BSDophile you're already used to rebuilds and tracking mailing lists or at least blogs like the above.
One final mention is that software availability for DragonFly BSD is still lower than for FreeBSD, which is still slightly lower than for Linux. This situation is greatly improving, but I still haven't heard of anyone running a native Java environment on DFly, which may be a problem for some people (heck I know I would love a JDK/JRE on DFly, I quite like Java as a language). However it's possible that one of the 'Java for Linux' projects (there are at least 10) has bothered being portable. Whether or not it goes so far as to use kqueue for SelectorProviders and so on I can't even begin to guess.
Well, actually, they did show their configuration and installation tools. Stop trolling. Don't just assume that every 'Screenshots' page is the same.
If you're talking about the threading library, it's inherently N:M but linking with a different threading library makes it 1:1. Performance has been shown to be inferior to NPTL and NetBSD's SA, but maybe that's improved by now.
If you're talking about the thread/process scheduler, it's ULE, based on the old O(1) scheduler in Linux. It has nices and processor affinity so it could only be called M:N, which is not the right terminology (is ANY modern scheduler 1:1 anyway?!).
Packet scheduler? I doubt you're talking about that. Same for IO scheduler.
Does he intend to update those and add DragonFly and NetBSD? DragonFly in particular has had a lot of work done which should be very interesting. I'm not sure if it has been micro-optimised like some of the efforts done for FreeBSD and Linux, but on the macro scale it looks good. -PREVIEW should be slipped Real Soon Now and contains numerous improvements over the last slip, some of which may be relevant to the topic.