Interesting point, but where in the hell do you see courts ordering open source code? Yes, they order it in drastic cases and the party reviewiong the code is really constrained in what they are allowed to do, you make it sound like courts are mandating Open Source projects for companies.
Secondly, as far as OS Wars being over, nothing has really changed that much. The market changes the same way it did a few years ago. Systems come and go, just because MS is dominant on the desktop doesn't mean there is little change in the market. If you would qualify the market before as a war, it still is, but I would say any supposed OS "war" is a misnomer in any time..
Yes the bitrate of MPEG-1 is variable, and yes you can have the same bitrate, and yes you can have the same quality as real, *but* you can't have both the same quality and MPEG-1 video, MPEG-1 at typical realmedia bitrates is complete and utter crap, MPEG-2 is designed for high bitrates, and MPEG-4 based video codecs might well do as good or better, but availability of those is rather strange right now. Real is the best cross-platform low-bandwidth video choice out there today..
Because MPEG would be a bandwidth hog compared to Real, and Real *is* accessible by most people. Mac, Win, Linux, Sparc Solaris all have working players, though real.com seems to treat them like their bastard children, hiding them in an unimaginable maze of links to get to the linux versions. I keep a realplay8 and the alpha realone player for linux around, because realone supports XVideo extension, but sometimes it breaks and you need realplayer8...
I don't understand why people think shared libraries couldn't work under such a system. Though it is a collection of Python modules rather than libraries, ROX-Lib provides a proof of concept for libraries as AppDirs. Of course you could get similar behvor by having/usr/local/Lib (for example) as a library appdir, with each library having it's own subdirectory, having a name like mylib.so in each, with whatever else the library needs in the same directory. The linker could probably be patched to understand this jsut a tad slower than current...
Additionally, who says you can't mix and match? Dynamic libraries as files in a directory and applications as folders? Kinda like windows does (except have a command interpreter that would parse those AppDir in the path and execute automatically AppRun programs in them to avoid large PATH variables)
Well, I think the choice of name is appropriate, storage of user "Choices", but Preferences might be a better name... The Idea behind a generic name is that is isn't supposed to be a necessarily ROX-only standard, so.ROX would be a bad name, you would be heading back to the dotdirectory mess we have now. It may seem trivial to say that 'ls -a' looks cluttered (If it hurts, don't do it), but It makes a lot more sense to have a relatively generic subdirectory dedicated to all package configuration data. Not only does ROX use the Choices directory (though they did lead the way and set the example in a way accessible to Linux), a few other apps (i.e. PythonTheater) use the structure too, and it works well.
Re:They support MacOS X style app wrappers!
on
ROX Desktop Update
·
· Score: 2
Actually, if you overhauled the linking tools you could have libraries operate under the same principles, and AppDirs could depend upon other AppDirs just as packages depend on other packages. Check out ROX-Lib as an example of how a library can be done in AppDir style and be usable. Granted that it is Python-exclusive, but it is highly functional in what it does and can serve as a proof of concept for non-python ideas.
There is your median. Of course, you have to have some sort of central store of dependency information if you want to warn users they are going to screw over apps by removing those AppDirs, but the amount of overhead involved with managing well-behaved AppDirs would be *much* less compared to the common methodolgy of scattering files all over the place and hoping the package manager can sort it all out in the end...
What you say is true about ROX needing per-directory prefs, but I would say that isn't too far off.
The thing about the shell is true too, but ROX is so much closer to shell flexibility than any file manager I have seen.
Every action can quickly and easily be assigned a single key shortcut. And those actions range from opening up a terminal in the current directory, to filemask based file selections, to running arbitrary command lines in current directory, to navigation through typing paths with tab completion. Granted, you can't do the fancy things
like while and for loops with really fancy stuff, but with well written apps that can accept multiple drops, this becomes less of an issue. Now for applications such as highly configurable completion that extends beyond filenames into arbitrary sets, zsh is the command line shell of choice to complement ROX-Filer. Never been so satisfied with a User Interface design in my life.
What I like so much about the ROX-Filer is that is acheives the useful functionality of Gnome/KDE without the cruft, so it goes unbelievably fast.
And Python programmers should take a look at ROX-Lib. The primary bit that is really cool is the really simple API for creating, accessing and modifying xml configuration files that follow the same ~/Choices/ convention that ROX-Filer follows, which seems infinitely better than the standard of polluting your home directory with dotfiles and dotdirectories... Not only that, but also will generate a nice, usable GUI to manipulate those files without the programmer having to build it by hand (though the programmer has to provide a well hinted sample xml file, but this is *far* more trivial than writing the gui out by hand). Not only does this make things easy on the developer, but also enforces consistency among apps that choose to use it.
Also, the entire concept of AppDirs is very very nice. Installing an application simply involves dragging it wherever you want, and it doesn't scatter files all over the file system, making package management a moot point. The de-facto standard has been to scatter files all over the damn place right next to other packages and this creates a huge problem package managers have been trying to solve effectively, but it is never perfect (packages occasionally make modifications not tracked by these managers). AppDir as ROX is designed around and specifies keeps package files well separated, in its own AppDir, own subdir of a system Choices directory, or per-user Choices directories. Nothing stops a bad developer from breaking this convention, but there rarely is a need, at most placing a wrapper script in/usr/local/bin for command-line support. Removing a package is as simple as removing those three folders. Of course, the AppDirs don't run as cleanly under command lines and library tools, but there is a patch to bash to support AppDirs and ROX-Lib demonstrates well how libraries can work in this system. In the meantime scripts that wrap AppRun calls are easy enough to place in the path.. I have PythonTheater (a media player designed with ROX in mind) configured in this manner (http://xtheater.sourceforge.net/)
Only issue with ROX-Lib is that it is python specific, so all that cool stuff is only for python developers, but I like python too:)
Though far from alleviating your troubles with the many many many many applications that like to put.files and.directories right in your home directory, I thought you might find this interesting.
The LOX Desktop (http://rox.sourceforge.net/) is a litttle project to bring an Risc-OS like environment to X desktops. Mostly a file manager (but a bit more), but one huge thing about it is the recommeded AppDir packaging. Basically, every package is almost entirely self-contained, except for preferences. For system-wide prefs, something like '/usr/local/Choices/' is used and for personal, ~/Choices/. That way all config info is in a separate location and it is *very* easy to uninstall packages. They provide ROX-Lib for Python writers to *very* easily use this structure. Although it diverges from the path significantly, and provides a Python-Centric API, it has some really good ideas. I know a lot of little utilities exist including a media player (PythonTheater, http://xtheater.sourceforge.net/) that obey this little standard.
But the problem there is that you can only change the speed through which you move through time. You can't, for example, roll back the clock, which is really the only really interesting thing about time travel, going to the future is no problem, getting back is the problem. You can go really fast or you can go into some sort of suspended animation. Getting back, as far as I know, isn't possible even by relativity.
I think this comment is pretty obviously a fabrication. The single DVD is a dead giveaway, it couldn't possibly store a feature-length film at the resolutions required for good use of digital screens.
And the comment even contradicts itself, first the moovies are running from fibre hrd drives then from DVDs, which is it?
Oh, mine will never forget. From the day I gave out my root password, my drives have always been at about 99% capacity....or 100% sometimes... Meaniwhile my files are content to cram into their little corner of the disk...
Well, part of the whole thing about corp edition is to reduce installation time and hassle on large corporate installs on machines that do not have internet connectivity, so in answer to the question about it needing to contact MS anyway, it doesn't *need* to. However, when I first had to roll out an XP install on our corp. edition, I decided to make it into an experiment. I took the host's MAC address and assigned it a static IP in the DHCP server. Then, when I went to install the system, I blocked and logged all traffic from the host trying to get to the outside. And guess what, the install did indeed still try to contact MS server about 3 or 4 times throughout the install (before Windows Update stuff). I think one of the attempts seemed to have something to do with the MEdia player (?), but at least two of them where MS hosts I had no idea what they would do (they were definitely not windows update hosts). With the packets dropped, the install did in fact complete, albeit it slowed down while waiting for responses from MS that never came. Has anyone done a more thorough experiment? I only logged source port, and destination address/port, no payload and since I dropped the packets I didn't see a full dialog as MS would have intended to occur. I didn't even bother to keep the log beyond the standard month, so that is gone too...
Two things:
Network capability
and
Hardware limitations.
Typically, hardware cards don't do more thon 3 or four sound channels at once. Sure, more than we can usually listen two, but still, a lot more limited than these programs.
Besides, though alsa supported it first, I can have multiple applications directly use dsp without software daemons, though it is an sb live..
Alsa is far more advanced and we finally get to see it coming mainstream (first it was going to be in 2.1, then put off to 2.3, and finally, and 2.5 we see it. Of course, the OSS is less and less important as more of the sound modules lie outside the OSS every release... (EMU10k1, VIA audio, etc...)
In any case, *BSD lacks a great deal of the Hardware support Linux has. Not necessarily *BSD's fault, but it is true. For example, I don't see drivers for my dxr2 decoder board under *BSD. If you have an nVidia chipset for graphics... well...
Re:In 10 years you'll be glad your Mac runs Linux
on
Linux on the iMac G4
·
· Score: 5, Insightful
Good point, however the argument really only applies to open-source applications, which tend to get ported to anything with a compiler anyway. Binary applications in Linux tend to be even shorter lived than other platforms (i.e. running a libc5/kernel 1.2.x binary application on modern equipment?)
As far as Apple goes, I would dare say they dragged on the m68k support as long as it was feasible, beyond a certain point the market has shrunk too much. Of Desktop/Workstation systems, I would say that Mac has either the longest or second longest lifespan of m68k products. (Sun ditched them way early after Sun3 hardware, and depending on how you count Amiga, Amiga might be considered longer support for m68k, since 3.9 was released in 2k, but then again, Amiga's support over the last few years has been rather tenuous at best.
Mac hardware tends to enjoy a much longer period of being up-to-date than, say, the PC market..
What comes to my mind is embedded applications that don't need the more advanced features of the modern trees but are so space deprived that the smaller the better.
Pretty good response, though I would note that even for video decoders writing to a raw framebuffer isn't desired... Writing directly to an allocated overlay in a colorspace natural to the decoding is better (that way, X provides a surface to write to that takes care of both colorspace conversion and scaling in hardware, two *Very* expensive video rendering tasks.). There are very few applications in which direct, unmediated framebuffer access is that beneficial... For example some apps support all sorts of targets from standard Xlib, to XShm, to DGA, to GL. The DGA is probably the closes to direct access, and, no surprise, it isn't that impressive....
Of course, I think the poster didn't really mean direct framebuffer access, but rather trimming Xlib where possible to not do things that increase latency locally, which, as many have pointed out Xshm does that very thing..
Of course mounting drives read-only, operating out of a ramdisk is still not as secure as this approach if you can afford a very static set of firewall rules.
In this state, the system is incapable of even offering a shell without a full reboot. Once you give it the ability to offer a running process to hijack and potentially have a shell open, the read-only mount only lasts until the equivalent of mount -o remount rw is executed, and then all bets are off. Same of a ramdisk (unless the ramdisk has no ide driver or whatever). But in any case a danger in having it so that you can change firewalling rules is that if they get in, *they* can change rules too.... So, at least in theory, a halted firewall is more secure than even the most anal tactics along the lines you describe. Of course, the chances of an exploit being so severe as to offer root shell is remote, but you can never be too paranoid in some cases.
All this being said, if you have a system dedicated to firewalling by itself, and you are worth your salt as a network administrator, setting up a tight firewall is child's play. If it is coming down the input chain and it is not coming from a specific address range over the correct interface, drop. Maybe allow ssh if you critically need remote admin capabilities, but if something goes wrong with your firewall, you probably need to be there in person anyway.
And if someone untrusted can get into your network and come over the trusted interface into your firewall, well, your network has a lot more problems than a less than perfect firewall...
It's true that Linux will likely never dominate the desktop market. I see a lot of responses varying from this sort of reality would mean the end of Linux, or otherwise, if we accept it, then why bother with desktop oriented packages (i.e. Gnome and KDE).
However, for my, as well as a lot of computer savvy people, not so much the common users, purposes, Gnome and KDE have a lot to offer for us. *Our* desktops can be Linux based and we want our desktop OS to be just as functional. Just because it will never be able to offer the same market that MS can offer, doesn't mean that the desktop market is pointless. Take for example the process of building your our computer. The average person wouldn't touch this with a ten foot pole, they would rather go down and get the whole package ready to go. However, some people recognize they can get better deals/better control by building it themselves, carefully examining and selecting each component for just the right end result. There are businesses that thrive by catering to this minority. Linux is in the same sort of category. Though never quite dominant, there is still enough of an interested market to support enough companies on the desktop to provide the most interesting features. And what companies refuse to bring, open source developers will eventually provide, even if it is slow, simply to make their system nicer.
Sure, OpenDivX is open, but that's dead. Seems that they opened DivX for a while, milked open source for all they felt they could, and then losed and is taking it further commercially, trying to get a patent and probably getting together with Fraunhoffer because they lack the resources to take it further.
It would be one thing if it was a good, closed from the beginning project. However, they essentially exploited open source developers whose work may soon be packaged for sale with no compensation whatsoever...
Of course, XVid (http://www.videocoding.de/) has branched the OpenDivx code since its death, but if the "creators" of OpenDivx get the patent, XVid could be shut out through this. In a sane world they couldn't possibly get a patent on this (since they really didn't build the codec themselves), but in this world...
I don't think this is a bad thing, really. People have conflicted ideas so two forks form. Each fork is evaluated in the eyes of the hardcore users and in the eyes of distributors such as RedHat. Sure, we look now and think that things will get ugly as all these trees evolve, but as the past has shown, the trees that work better, or are closer to the pre-exsiting "standard" given a tie, dominate and often extinguishes less succeful trees whose ideas didn't pan out, usually folding in the improvements the other tree made succcessful.
The process of having these trees sprout up and played with by businesses and advanced users provide a sort of natural selection for improved evolution of the system. While all this complicated mess plays itself out among the bleeding edge people, the common users have the stock redhat or what have you kernel to play it safe with.
Slashdot Mirror
Interesting point, but where in the hell do you see courts ordering open source code? Yes, they order it in drastic cases and the party reviewiong the code is really constrained in what they are allowed to do, you make it sound like courts are mandating Open Source projects for companies.
Secondly, as far as OS Wars being over, nothing has really changed that much. The market changes the same way it did a few years ago. Systems come and go, just because MS is dominant on the desktop doesn't mean there is little change in the market. If you would qualify the market before as a war, it still is, but I would say any supposed OS "war" is a misnomer in any time..
Yes the bitrate of MPEG-1 is variable, and yes you can have the same bitrate, and yes you can have the same quality as real, *but* you can't have both the same quality and MPEG-1 video, MPEG-1 at typical realmedia bitrates is complete and utter crap, MPEG-2 is designed for high bitrates, and MPEG-4 based video codecs might well do as good or better, but availability of those is rather strange right now. Real is the best cross-platform low-bandwidth video choice out there today..
Because MPEG would be a bandwidth hog compared to Real, and Real *is* accessible by most people. Mac, Win, Linux, Sparc Solaris all have working players, though real.com seems to treat them like their bastard children, hiding them in an unimaginable maze of links to get to the linux versions. I keep a realplay8 and the alpha realone player for linux around, because realone supports XVideo extension, but sometimes it breaks and you need realplayer8...
I don't understand why people think shared libraries couldn't work under such a system. Though it is a collection of Python modules rather than libraries, ROX-Lib provides a proof of concept for libraries as AppDirs. Of course you could get similar behvor by having /usr/local/Lib (for example) as a library appdir, with each library having it's own subdirectory, having a name like mylib.so in each, with whatever else the library needs in the same directory. The linker could probably be patched to understand this jsut a tad slower than current...
Additionally, who says you can't mix and match? Dynamic libraries as files in a directory and applications as folders? Kinda like windows does (except have a command interpreter that would parse those AppDir in the path and execute automatically AppRun programs in them to avoid large PATH variables)
Well, I think the choice of name is appropriate, storage of user "Choices", but Preferences might be a better name... The Idea behind a generic name is that is isn't supposed to be a necessarily ROX-only standard, so .ROX would be a bad name, you would be heading back to the dotdirectory mess we have now. It may seem trivial to say that 'ls -a' looks cluttered (If it hurts, don't do it), but It makes a lot more sense to have a relatively generic subdirectory dedicated to all package configuration data. Not only does ROX use the Choices directory (though they did lead the way and set the example in a way accessible to Linux), a few other apps (i.e. PythonTheater) use the structure too, and it works well.
Actually, if you overhauled the linking tools you could have libraries operate under the same principles, and AppDirs could depend upon other AppDirs just as packages depend on other packages. Check out ROX-Lib as an example of how a library can be done in AppDir style and be usable. Granted that it is Python-exclusive, but it is highly functional in what it does and can serve as a proof of concept for non-python ideas.
There is your median. Of course, you have to have some sort of central store of dependency information if you want to warn users they are going to screw over apps by removing those AppDirs, but the amount of overhead involved with managing well-behaved AppDirs would be *much* less compared to the common methodolgy of scattering files all over the place and hoping the package manager can sort it all out in the end...
What you say is true about ROX needing per-directory prefs, but I would say that isn't too far off.
The thing about the shell is true too, but ROX is so much closer to shell flexibility than any file manager I have seen.
Every action can quickly and easily be assigned a single key shortcut. And those actions range from opening up a terminal in the current directory, to filemask based file selections, to running arbitrary command lines in current directory, to navigation through typing paths with tab completion. Granted, you can't do the fancy things
like while and for loops with really fancy stuff, but with well written apps that can accept multiple drops, this becomes less of an issue. Now for applications such as highly configurable completion that extends beyond filenames into arbitrary sets, zsh is the command line shell of choice to complement ROX-Filer. Never been so satisfied with a User Interface design in my life.
What I like so much about the ROX-Filer is that is acheives the useful functionality of Gnome/KDE without the cruft, so it goes unbelievably fast.
/usr/local/bin for command-line support. Removing a package is as simple as removing those three folders. Of course, the AppDirs don't run as cleanly under command lines and library tools, but there is a patch to bash to support AppDirs and ROX-Lib demonstrates well how libraries can work in this system. In the meantime scripts that wrap AppRun calls are easy enough to place in the path.. I have PythonTheater (a media player designed with ROX in mind) configured in this manner (http://xtheater.sourceforge.net/)
:)
And Python programmers should take a look at ROX-Lib. The primary bit that is really cool is the really simple API for creating, accessing and modifying xml configuration files that follow the same ~/Choices/ convention that ROX-Filer follows, which seems infinitely better than the standard of polluting your home directory with dotfiles and dotdirectories... Not only that, but also will generate a nice, usable GUI to manipulate those files without the programmer having to build it by hand (though the programmer has to provide a well hinted sample xml file, but this is *far* more trivial than writing the gui out by hand). Not only does this make things easy on the developer, but also enforces consistency among apps that choose to use it.
Also, the entire concept of AppDirs is very very nice. Installing an application simply involves dragging it wherever you want, and it doesn't scatter files all over the file system, making package management a moot point. The de-facto standard has been to scatter files all over the damn place right next to other packages and this creates a huge problem package managers have been trying to solve effectively, but it is never perfect (packages occasionally make modifications not tracked by these managers). AppDir as ROX is designed around and specifies keeps package files well separated, in its own AppDir, own subdir of a system Choices directory, or per-user Choices directories. Nothing stops a bad developer from breaking this convention, but there rarely is a need, at most placing a wrapper script in
Only issue with ROX-Lib is that it is python specific, so all that cool stuff is only for python developers, but I like python too
Though far from alleviating your troubles with the many many many many applications that like to put .files and .directories right in your home directory, I thought you might find this interesting.
The LOX Desktop (http://rox.sourceforge.net/) is a litttle project to bring an Risc-OS like environment to X desktops. Mostly a file manager (but a bit more), but one huge thing about it is the recommeded AppDir packaging. Basically, every package is almost entirely self-contained, except for preferences. For system-wide prefs, something like '/usr/local/Choices/' is used and for personal, ~/Choices/. That way all config info is in a separate location and it is *very* easy to uninstall packages. They provide ROX-Lib for Python writers to *very* easily use this structure. Although it diverges from the path significantly, and provides a Python-Centric API, it has some really good ideas. I know a lot of little utilities exist including a media player (PythonTheater, http://xtheater.sourceforge.net/) that obey this little standard.
But the problem there is that you can only change the speed through which you move through time. You can't, for example, roll back the clock, which is really the only really interesting thing about time travel, going to the future is no problem, getting back is the problem. You can go really fast or you can go into some sort of suspended animation. Getting back, as far as I know, isn't possible even by relativity.
Of course, I am not a physicist...
I think this comment is pretty obviously a fabrication. The single DVD is a dead giveaway, it couldn't possibly store a feature-length film at the resolutions required for good use of digital screens.
And the comment even contradicts itself, first the moovies are running from fibre hrd drives then from DVDs, which is it?
Oh, mine will never forget. From the day I gave out my root password, my drives have always been at about 99% capacity....or 100% sometimes... Meaniwhile my files are content to cram into their little corner of the disk...
Well, part of the whole thing about corp edition is to reduce installation time and hassle on large corporate installs on machines that do not have internet connectivity, so in answer to the question about it needing to contact MS anyway, it doesn't *need* to. However, when I first had to roll out an XP install on our corp. edition, I decided to make it into an experiment. I took the host's MAC address and assigned it a static IP in the DHCP server. Then, when I went to install the system, I blocked and logged all traffic from the host trying to get to the outside. And guess what, the install did indeed still try to contact MS server about 3 or 4 times throughout the install (before Windows Update stuff). I think one of the attempts seemed to have something to do with the MEdia player (?), but at least two of them where MS hosts I had no idea what they would do (they were definitely not windows update hosts). With the packets dropped, the install did in fact complete, albeit it slowed down while waiting for responses from MS that never came. Has anyone done a more thorough experiment? I only logged source port, and destination address/port, no payload and since I dropped the packets I didn't see a full dialog as MS would have intended to occur. I didn't even bother to keep the log beyond the standard month, so that is gone too...
Two things:
Network capability
and
Hardware limitations.
Typically, hardware cards don't do more thon 3 or four sound channels at once. Sure, more than we can usually listen two, but still, a lot more limited than these programs.
Besides, though alsa supported it first, I can have multiple applications directly use dsp without software daemons, though it is an sb live..
Alsa is far more advanced and we finally get to see it coming mainstream (first it was going to be in 2.1, then put off to 2.3, and finally, and 2.5 we see it. Of course, the OSS is less and less important as more of the sound modules lie outside the OSS every release... (EMU10k1, VIA audio, etc...)
Well, WP has pretty good *nix applications...
In any case, *BSD lacks a great deal of the Hardware support Linux has. Not necessarily *BSD's fault, but it is true. For example, I don't see drivers for my dxr2 decoder board under *BSD. If you have an nVidia chipset for graphics... well...
Good point, however the argument really only applies to open-source applications, which tend to get ported to anything with a compiler anyway. Binary applications in Linux tend to be even shorter lived than other platforms (i.e. running a libc5/kernel 1.2.x binary application on modern equipment?)
As far as Apple goes, I would dare say they dragged on the m68k support as long as it was feasible, beyond a certain point the market has shrunk too much. Of Desktop/Workstation systems, I would say that Mac has either the longest or second longest lifespan of m68k products. (Sun ditched them way early after Sun3 hardware, and depending on how you count Amiga, Amiga might be considered longer support for m68k, since 3.9 was released in 2k, but then again, Amiga's support over the last few years has been rather tenuous at best.
Mac hardware tends to enjoy a much longer period of being up-to-date than, say, the PC market..
What comes to my mind is embedded applications that don't need the more advanced features of the modern trees but are so space deprived that the smaller the better.
Today there is a release of some sort in 4 kernel trees (see freshmeat.net):
2.0.40-rc2
2.2.21-pre2
2.4.18-pre7-ac3
And, of course, 2.5.4.
Granted, only one was a full revision bump, but to see updates in so many trees is neat.
Pretty good response, though I would note that even for video decoders writing to a raw framebuffer isn't desired... Writing directly to an allocated overlay in a colorspace natural to the decoding is better (that way, X provides a surface to write to that takes care of both colorspace conversion and scaling in hardware, two *Very* expensive video rendering tasks.). There are very few applications in which direct, unmediated framebuffer access is that beneficial... For example some apps support all sorts of targets from standard Xlib, to XShm, to DGA, to GL. The DGA is probably the closes to direct access, and, no surprise, it isn't that impressive....
Of course, I think the poster didn't really mean direct framebuffer access, but rather trimming Xlib where possible to not do things that increase latency locally, which, as many have pointed out Xshm does that very thing..
Pretty good, except change those 'anys' to 'all'
Of course mounting drives read-only, operating out of a ramdisk is still not as secure as this approach if you can afford a very static set of firewall rules.
In this state, the system is incapable of even offering a shell without a full reboot. Once you give it the ability to offer a running process to hijack and potentially have a shell open, the read-only mount only lasts until the equivalent of mount -o remount rw is executed, and then all bets are off. Same of a ramdisk (unless the ramdisk has no ide driver or whatever). But in any case a danger in having it so that you can change firewalling rules is that if they get in, *they* can change rules too.... So, at least in theory, a halted firewall is more secure than even the most anal tactics along the lines you describe. Of course, the chances of an exploit being so severe as to offer root shell is remote, but you can never be too paranoid in some cases.
All this being said, if you have a system dedicated to firewalling by itself, and you are worth your salt as a network administrator, setting up a tight firewall is child's play. If it is coming down the input chain and it is not coming from a specific address range over the correct interface, drop. Maybe allow ssh if you critically need remote admin capabilities, but if something goes wrong with your firewall, you probably need to be there in person anyway.
And if someone untrusted can get into your network and come over the trusted interface into your firewall, well, your network has a lot more problems than a less than perfect firewall...
Very small program actually, but one that will drastically improve google's popularity:
Mature content *only* in image search.
To further enhance this with a lot of space, cache high quality versions of the images.
It's true that Linux will likely never dominate the desktop market. I see a lot of responses varying from this sort of reality would mean the end of Linux, or otherwise, if we accept it, then why bother with desktop oriented packages (i.e. Gnome and KDE).
However, for my, as well as a lot of computer savvy people, not so much the common users, purposes, Gnome and KDE have a lot to offer for us. *Our* desktops can be Linux based and we want our desktop OS to be just as functional. Just because it will never be able to offer the same market that MS can offer, doesn't mean that the desktop market is pointless. Take for example the process of building your our computer. The average person wouldn't touch this with a ten foot pole, they would rather go down and get the whole package ready to go. However, some people recognize they can get better deals/better control by building it themselves, carefully examining and selecting each component for just the right end result. There are businesses that thrive by catering to this minority. Linux is in the same sort of category. Though never quite dominant, there is still enough of an interested market to support enough companies on the desktop to provide the most interesting features. And what companies refuse to bring, open source developers will eventually provide, even if it is slow, simply to make their system nicer.
Sure, OpenDivX is open, but that's dead. Seems that they opened DivX for a while, milked open source for all they felt they could, and then losed and is taking it further commercially, trying to get a patent and probably getting together with Fraunhoffer because they lack the resources to take it further.
It would be one thing if it was a good, closed from the beginning project. However, they essentially exploited open source developers whose work may soon be packaged for sale with no compensation whatsoever...
Of course, XVid (http://www.videocoding.de/) has branched the OpenDivx code since its death, but if the "creators" of OpenDivx get the patent, XVid could be shut out through this. In a sane world they couldn't possibly get a patent on this (since they really didn't build the codec themselves), but in this world...
I don't think this is a bad thing, really. People have conflicted ideas so two forks form. Each fork is evaluated in the eyes of the hardcore users and in the eyes of distributors such as RedHat. Sure, we look now and think that things will get ugly as all these trees evolve, but as the past has shown, the trees that work better, or are closer to the pre-exsiting "standard" given a tie, dominate and often extinguishes less succeful trees whose ideas didn't pan out, usually folding in the improvements the other tree made succcessful.
The process of having these trees sprout up and played with by businesses and advanced users provide a sort of natural selection for improved evolution of the system. While all this complicated mess plays itself out among the bleeding edge people, the common users have the stock redhat or what have you kernel to play it safe with.