Yeah! Just like all the worms recently; until they showed up, Microsoft didn't release... oh, right, they did.
While not technically a worm, the current trojan horse that will redirect web users to other pages with lots of porn ads uses the object-bug in IE, for which there is indeed no working patch. It's likely that others exploit it as well.
As far as I know, even Microsoft has never made it impossible to replace a random executable with another one that serves the same purpose. init is just that (hence the possibility to get root on a linux box when you have access to the boot loader by passing "init=/bin/sh"), on every unix I ever heard of - it is not tied to any other part of the OS, except by some open, well known interfaces, mostly how it is started and how it reacts to some signals.
So, the only way for a proprietary software company to screw anyone using or offering an init replacement would be to remove modularity, which kind of proves my point...
SysV init is stupid, but that doesn't mean that you have to adopt this bogus proposal. There are lots of other inits, like those used by the BSDs, minit, or tons of others - some even work well. Writing an init isn't rocket science, and replacing it is trivial. The only tedious thing is writing the neccessary scripts, and I would expect it to be easier to write most of them as shell scripts than in python.
<rant>
How about "All POSIX-compatible systems come with a bourne-compatible shell"? I don't see any reason why a developer of an init system, which is so not tied to a specific kernel, should restrict himself to a non-standard embrace-and-extend version when he can also follow open standards, and create something more useful to more people instead.
</rant>
That's the strength of open source development: every little component has the potential of being made more efficient at any given time by any given party of developers.
No, it is not. It's the strength of modular software, like Unix-like operating systems. Replacing the init mechanism is not any harder on Solaris that it is on Linux.
It's not a general purpose mechanism built using the thinnest layer with the least dependencies possible (like init is)
I completely agree on the dependencies issue, but isn't calling the SysV init mess "thin" a little bit off? Honestly, how many runlevels exept "multi-user", "single-user" and "turned off" do you really need? Do you collect symlinks as a hobby?
Don't hold your breath. The current estimated release date for 5.3, which will become RELENG_5, is march 2004.
Personally, I plan to switch when 5.2 is released, though. Mostly for the filesystem snapshots and background fsck. I too use FBSD 5 on my personal workstation and have scince 5.0-RELEASE, without any problems, so I don't worry too much.
Virtualization rocks for that kind of things. I happily use FreeBSD jails for that. They work on a different level and have different goals, but giving each (group of) user(s) their own sandbox to play with is definitly a really cool thing, both for admins and for the users themselves.
It is still at least 1.5 months until 4.9 is released, according to the release schedule, and generally the FreeBSD team will accept delays in the interest of stability and not rush out something half-baked. 5.0 has been delayed more than one year, IIRC. During such a timeframe, certain other free Unix-like OSes change half of your supposedly stable kernel under your back and accidentally eat your file systems three times without bumping the minor version number.
The right spelling and pronunciation is "Neandertal".
Bullsh*t
Just more evidence for my theory that the german habit of frequently changing orthography rules is just meant to confuse the heck out of everybody, and then have fun watch the resulting flamewars. Basically, a giant trolling.
MS engineers are specifically prohibited from accessing much open-source software (in specific GPL'ed code), without first obtaining permission from the legal department.
What a contrast to all the other, non-evil companies where developers are encouraged to reuse third-party code willy-nilly without having to care about the legal consequences.
And people might find that the impossibility of travelling faster than light is also nothing more than a common belief, based on faulty logic or invalid assumptions. You can never prove that something is impossible, only that it is possible or existent by showing/doing it (and there is plenty room for error even then).
At least, that is how we think about science today. It may of course be that the assuptions behind this science are false themselves. Try proving the validity of logic itself:-)
Face it, science is a social phenomenon like ethics or fashion - all working completly different, of course, and on dramatically different time scales. Our current way of thinking about absolute truth and scientific proofs will probably look as laughable and inherently flawed in 1000 years as the way of thinking usual 1000 years ago looks to us now. There is no absolute truth. At least, it is not recognizable by humans.
Huge parts of the windows source have been available for interested parties for quite some time, as usual with commercial software. Simply sign some NDAs and pay loads of money. If the chinese government or anybody else would want to find some interesting holes, they could as well pay someone to break their NDA. Never mind the rumors of intruders having access to the internal MS network, including source code. If I would plan to exploit a certain piece of software, I would not issue a press release about my plans to review it before.
When people say that security through obscurity doesn't work so well, they really mean it. You always have to assume that a potential attacker knows exactly how your software works, the trick is making it secure nevertheless.
Not only compiler-generated random stuff, but most likely also build dates and timestamps. The FreeBSD binary update project had to deal with these kinds of issues and have written a nice paper that discusses them (51k PDF, Google HTML version).
At least Lindows isn't a public company this time, so his investors should understand the risk he is taking better than the public did with MP3.com
This time he distributes the risk among his customers and the internet community by selling a linux distribution that beats windows in being insecure for convenience reasons.
Linux just like Beos can use binary closed source drivers.
Linux has two problems with binary closed source drivers BeOS doesn't have: Binary compatibility is frequently broken, and the legal status of it is rather unclear (yeah, Linus may say it's OK, but his opinion doesn't matter a bit. He isn't the only copyright owner.)
Third party developers are welcome to create and ship frameworks, but their use is discouraged. Disk space and RAM are cheaper than the labor involved in maintaining shared code.
Finding and patching all users of a library/framework/whatever that needs to be updated due to this weeks buffer overflow is still expensive, though.
I have been thinking that what Linux needs is a good free CDE clone based on Lesstif
Um, why? CDE is not exactly widely loved for its look and feel, and I don't know of any free software that would require it (as opposed to plain motif), so porting wouldn't be an issue either. And if you'd need a proprietary CDE app, why wouldn't be a proprietary CDE for Linux (which is $49.95 at Xi Graphics) do?
Slashdot Mirror
So, the only way for a proprietary software company to screw anyone using or offering an init replacement would be to remove modularity, which kind of proves my point...
SysV init is stupid, but that doesn't mean that you have to adopt this bogus proposal. There are lots of other inits, like those used by the BSDs, minit, or tons of others - some even work well. Writing an init isn't rocket science, and replacing it is trivial. The only tedious thing is writing the neccessary scripts, and I would expect it to be easier to write most of them as shell scripts than in python.
How about "All POSIX-compatible systems come with a bourne-compatible shell"? I don't see any reason why a developer of an init system, which is so not tied to a specific kernel, should restrict himself to a non-standard embrace-and-extend version when he can also follow open standards, and create something more useful to more people instead.
</rant>
Personally, I plan to switch when 5.2 is released, though. Mostly for the filesystem snapshots and background fsck. I too use FBSD 5 on my personal workstation and have scince 5.0-RELEASE, without any problems, so I don't worry too much.
Virtualization rocks for that kind of things. I happily use FreeBSD jails for that. They work on a different level and have different goals, but giving each (group of) user(s) their own sandbox to play with is definitly a really cool thing, both for admins and for the users themselves.
It is still at least 1.5 months until 4.9 is released, according to the release schedule, and generally the FreeBSD team will accept delays in the interest of stability and not rush out something half-baked. 5.0 has been delayed more than one year, IIRC. During such a timeframe, certain other free Unix-like OSes change half of your supposedly stable kernel under your back and accidentally eat your file systems three times without bumping the minor version number.
I had to use VBA in Excel, and I can confirm that not everything he does is that good...
At least, that is how we think about science today. It may of course be that the assuptions behind this science are false themselves. Try proving the validity of logic itself :-)
Face it, science is a social phenomenon like ethics or fashion - all working completly different, of course, and on dramatically different time scales. Our current way of thinking about absolute truth and scientific proofs will probably look as laughable and inherently flawed in 1000 years as the way of thinking usual 1000 years ago looks to us now. There is no absolute truth. At least, it is not recognizable by humans.
With the data uri scheme, I can include the whole internet in my URIs!
When people say that security through obscurity doesn't work so well, they really mean it. You always have to assume that a potential attacker knows exactly how your software works, the trick is making it secure nevertheless.
Except that it wasn't in GCC. Of course, given the recent r00ting of ftp.gnu.org, who knows what is in GCC...
Not only compiler-generated random stuff, but most likely also build dates and timestamps. The FreeBSD binary update project had to deal with these kinds of issues and have written a nice paper that discusses them (51k PDF, Google HTML version).
But the real question is: Will the next Windows CD come with mp3s and stickers?
That won't help you much if the app happens to be compiled for Windows/x86.