You might want to read this article. The illusion that running Linux makes you safe and that Linux machines aren't involved in spam-sending botnets is just that: an illusion.
As for firewalls protecting insecure systems: they do, to an extent. But the firewall isn't going to stop you from getting infected by, say, visiting a website with malicious code on it, opening an email attachment with such, or installing and running software with malicious code in it.
> >> Latency is the most important criteria, and reiserfs is just too complicated to deliver it'' > > Excuse me? Do you have any numbers to back up that claim? > > Because I'm having a hard time taking it on face value.
> You are the one trying to get me to switch file systems, so you are the one who has to provide the numbers. I look at > those benchmarks, and ext2 looks like the winner. If you have others, I'll be happy to take a look at them.
You misunderstand. I am not trying to get you to switch filesystems, I am asking you to back up your claims. In this case, the claim that "reiserfs is just too complicated to deliver [low latency]".
> > A filesystem that has been included in the mainline Linux kernel for several years, > > is offered as a prominent choice during installation of various distros, used to be > > the default fs on some distros, and is widely used by people who make conscious and > > informed choices about which filesystem to use. > > Most people just take the default filesystem for their distro, and I don't know of any that have reiserfs as the default.
According to Wikipedia:
``ReiserFS is the default file system on the Elive, Xandros, Linspire, GoboLinux, Kurumin Linux[citation needed], and Yoper Linux distributions. ReiserFS was the default file system in Novell's SUSE Linux Enterprise until Novell decided to move to ext3 on October 12, 2006 for future releases.''
> That would meet my definition of "fringe".
I won't argue against that.
> > Kindly point me at this compressed archive format that lets me fetch files > > (small and large) by name and other attributes more efficiently than Reiser4 > > or even ReiserFS. > > I don't know of any.
And yet, you said:
``Yup, I'd like to have efficient small file handling. But really, it is better to avoid having many small files in the first place. Use compressed archives to store such things; it's quite a bit more efficient''
If you claim that compressed archives are more efficient for storing many small files, you had better actually know at least one compressed archive format that actually is more efficient. Otherwise, you would just be making an unfounded claim. Again, I ask you to back up your claims.
> Care to write one? 'Cause I'd sure like to have it. I think you can do this with Kioslaves, but I'm > no expert there. My point is that it should exist, because it is the right solution.
I disagree. There is no reason that having many small files should be as slow as some file systems make it. Finding an alternative way to store the data may solve the performance problem, but it increases complexity and runs the risk of making standard utilities useless for your chosen storage format. Given that it _is_ possible to store and retrieve the small pieces of data efficiently, why don't we just make the filesystem do it?
> When you have many small files, > that's just bad design. They are hard to keep track of, and there is no reason for them to be individually user-visible in > the first place.
So you say. I think that claim may be true in some scenarios, but certainly not in all scenarios. I _like_ the units of data that I think about to coincide with files; this allows me to use tools that manipulate files to manipulate a lot of things on my computer: documents, programs, configuration files, messages, etc. I don't like the idea of having to use specialized tools for each of these. If anything, I would try to _extend_ the number of things I can apply my standard tools to, rather than shrink it by hiding many objects in a single unit.
> > Then please point out how I can use this as I would a filesystem: > > so that the good old Unix software can access the files. > > If you want that, you can use FUSE on a loop, but then, of course, Linux would make you mount i
``Believe it or not, the world does not revolve around huge mail servers. Some of us actually run Linux on a desktop, and so don't really care about how well an fs handles a million maildir mailboxes.''
What if I have large Maildir mailboxes on my desktop system? Or anything else that puts many files in a single directory? Just because _you_ don't need that case to be fast doesn't mean it isn't a good idea to have it be fast, anyway.
``Latency is the most important criteria, and reiserfs is just too complicated to deliver it''
Excuse me? Do you have any numbers to back up that claim? Because I'm having a hard time taking it on face value.
``as well as being a largely fringe fs''
A filesystem that has been included in the mainline Linux kernel for several years, is offered as a prominent choice during installation of various distros, used to be the default fs on some distros, and is widely used by people who make conscious and informed choices about which filesystem to use. But yes, if you want to call it a "fringe fs", go right ahead.
``Especially now with Hans gone, it would become even more fringe.''
This, unfortunately, is all too true. ReiserFS still is a great filesystem in terms of reliability and performance, from tiny files to huge ones, under a wide range of scenarios. Reiser4 was going to be even better: faster and more flexible and extensible, with fast arbitrary attributes and a lot of other goodness. But it never made it into the mainline kernel, and, with Hans Reiser in jail, the future doesn't seem bright for Reiser4. On the other hand, there are various new contenders: ZFS, btrfs, and ext4, just to name a few. None of them seem to be quite there yet, but hey, neither was Reiser4.
``Yup, I'd like to have efficient small file handling. But really, it is better to avoid having many small files in the first place. Use compressed archives to store such things; it's quite a bit more efficient''
Kindly point me at this compressed archive format that lets me fetch files (small and large) by name and other attributes more efficiently than Reiser4 or even ReiserFS. Then please point out how I can use this as I would a filesystem: so that the good old Unix software can access the files. And remember: I need random access to the file contents, and I need to be able to add, remove, write, etc. files. And if any operation is interrupted suddenly and unexpectedly, the integrity of my tree needs to be preserved. Bonus points for full data integrity preservation.
``The performance hit from journalling is simply too high to tolerate.''
Performance hit from journalling? And you're using ext2 to avoid it? Your usage patterns must be very different from mine. True, ext2 running in async mode (i.e. no consistency guarantee at all) is slower than ext3 with journalling which guarantees consistency. On the other hand, with ReiserFS, I can have journalling, guaranteed consistency of at least the filesystem structure, and better performance. Plus, for some strange reason, ext3 seems to lose a lot of files on my systems (although they can be recovered by running fsck) during normal operation. Among the 3, ReiserFS is the clear winner for me. I am not disputing that you may be seeing other data, but let's at least conclude that ext2 is _not_ faster than all journalled filesystems for everyone, and that the performance hit of journalling, if any, is not "too high to tolerate" for everyone.
``With UPS prices being as low as they are, there is no excuse for not having one, so I think that journalling will become obsolete in some near future.''
I think smart people realize that having a UPS is no guarantee that your system will never fail in the middle of a write. So a method to bring the system back to a consistent state is needed in any case. Let's also realize that journalling isn't only for recovery. It is one way to implement transactions, and transactions are useful for more than recovery alone; for example, they can be used to ensure consistency of da
``If your trivial program runs in 0.6 seconds instead of 0.01 seconds, you may not care about the difference. And if you can write your program in 1/10 the time, you may come out way ahead.''
Also, the two are not mutually exclusive. You can have a language in which it takes you little time to write the program _and_ end up with an efficient program (depending on the language implementation, of course).
I think the most important thing is that you have solved a variety of problems in a multi-paradigm language. Languages that shoehorn you into one way of solving problems don't generally give you much chance to think about what would be the best way to solve the problem. If you can suit your language to your design, instead of the other way around, you can write much more elegant code. Good multi-paradigm languages I know are Common Lisp and Ruby.
Now seems like a good time to tell you all about the book I read yesterday. It is called "Little Brother", written by Cory Doctorow, and available for free download, as well as in dead tree form. Very fascinating.
Pick a sensible version numbering scheme and stick with it.
My personal favorite is x.y.z, where x is incremented at major rewrites and when incompatible changes are introduced, y is incremented when new features are added, but backward compatibility is preserved, and z is incremented for maintenance releases that don't add features and don't break compatibility (except when caused by buggy behavior, of course).
This way, you can tell that your configuration file for version 1.1.0 will work on version 1.1.1 and version 1.2.0, but not necessarily on 2.0.1, and that if someone is running 1.1.0 when 1.1.1 is already out, they may be running into bugs that have been fixed since.
Whether you, as a user, trust a given version number to represent a reliable piece of software is, of course, entirely subjective. It is wise to remember, though, that there is software with 0.6 version numbers that is rock solid, and software with 9.0 version numbers that is junk. More or less the only thing that can reliably be deducted from version numbers is that higher numbers indicate newer versions of the software. A version number doesn't say anything about how good the product is.
In other words, they are making encryption worthless, as far as protecting you from the government goes. Sure, you can encrypt your data with a good key and cipher and they won't be able to read it. But then they can just arrest you, charge you with something, and force you to disclose your data to them. Even if there is nothing among your data that relates to what you have been charged with, the government now has access to all your data.
All that may be acceptable as long as the government is going after the people you want them to go after. But there's no guarantee that this will always be the case. Governments work for the people sometimes, but they can also work against the people. This is why some smart people have written down rules the government must play by, restrictions on what the government is allowed to do. These restrictions are there for your protection: if the government plays by the rules, they are limited in what they can do to you, should they decide to come after you. When the government breaks these rules, that's a bad sign. It means they are crossing the line between working for the people and working against the people. It means they have a problem, and they are willing to violate your rights to deal with that problem.
The defendants are right. Their encrypted data may or may not contain evidence against them. They don't have to tell the government anything about it, and they certainly don't have to give the government access to all of it. Even if the defendants are guilty of the crime they are charged with, they have rights. They are innocent until proven guilty, and they have the right to remain silent. A judge (or jury, as the case may be) has the right to make inferences as to why a defendant choses to remain silent, of course.
``But you normally have more than one in a cockpit. If one goes bad, you can use the other, not catastrophic.''
That is, unless the other one goes bad, as well. Which isn't even that unlikely, given that both of them are in the same aircraft and thus will be exposed to similar conditions - perhaps even the exact same inputs.
I think (but I haven't actually looked at the numbers) that a lot of today's aircraft incidents and accidents are caused by the pilot and the computer having different ideas about what to do. For example, a pilot trying to land a plane while the computer has decided to abort the landing.
Interesting. I've always thought that "fly-by-wire" meant that the controls and the steering of the aircraft were essentially decoupled: you use the controls to "tell" the computer how you want to fly, and the computer then flies the plane for you. The "wire" in this case refers to a virtual wire the plane flies along. For extra clarification: some fighter planes are so unstable that they need constant adjustment. A fly-by-wire system would then allow the pilot to steer smoothly, while the computer made all the micro-adjustments necessary to actually keep the plane on the expected course.
``MS set the entire computer industry back by at least half a decade by pawning that trash off on the consumer market.''
That is to say, the users set the world back because they massively went with Windows 95. They could have chosen something else...say, OS/2, SLS, or Slackware, all of which were available at the time.
FYI, there are other browsers for Linux that use WebKit as their rendering engine. From the top of my head: Epiphany and Skipstone, but there are at least two others.
Depends on the version of Linux and what software you use with it. There are a mind-boggling number of different versions of the kernel out there, in various distributions, and sometimes in custom-made operating systems...and then we aren't even getting to the applications, yet. Among all those, I am sure you will find everything from rock-solid to "crashes at the drop of a hat, or even without that".
While I don't dispute the claims you make, I would like to point out that
1. Debian does make announcements about prospective release dates. These aren't firm promises and shouldn't be interpreted as such, but it is disappointing when they miss those dates by months.
2. Releases aren't only made when the bug count drops to zero. First of all, there are bugs that aren't considered "release-critical". Secondly, sometimes (I think this happened with etch) releases are made with known issues and a promise to fix those issues Real Soon Now. Thirdly, the way the bug count is brought to zero usually includes simply throwing out packages that have known bugs. If many people want such a package, that isn't very helpful.
3. Bugs that would have been "release-critical" are often discovered after a release is made. The current stable release, etch, had more release-critical bugs pending against it than lenny (the upcoming stable release), last time I checked.
What all this means is that Debian will _not_ generalyl be released at any date that has been mentioned, and will _not_ generally be bug-free when released.
Having said all that, it's still my favorite operating system, as it takes less of my time to use and maintain than anything else I have tried (and that is quite a lot).
``If this article was about Microsoft instead of Debian, you know the tone would be substantially different.''
Yes. And that's a bit hypocritic. On the other hand, there is an important difference between Microsoft and Debian: while both produce operating systems, Microsoft mostly deals with only things they develop themselves, and doesn't package all applications for a given release of their operating systems. Debian, on the other hand, deals mostly with software they don't develop, and still manage to package an impressive chunk of that for seamless integration with their operating system. I also think their final release dates and feature sets don't tend to differ as much from the initial announcements as do Microsoft's...
"I know Dick Cheney has assured us that 'Deficits don't matter'..."
Tell that to Iceland. Not so long ago, Iceland was a rich country. Recently, the country has become unable to pay its debts, and its currency has quickly lost its value. Now, banks have stopped trading in Iceland krona, which means the money has essentially become worthless. And that means that if all you have is Icelandic kronur, you will have a very hard time paying for things. I don't think Iceland is a rich country anymore. Now, tell me again why deficits don't matter?
What's the big deal? One developer leaves the MySQL team, after MySQL has been bought by Sun. Ok. The two may or may not be related. And it may or may not indicate that something is making the developers unhappy.
MySQL has hundreds of bugs open against the upcoming release. Ok. Is that a lot? It does sound like it. On the other hand, it's hard to say what this means for quality. It means all these bugs have been _found_, which is good. Now they just need to be fixed.
In the meantime, existing versions of MySQL will continue to work as well as they have always worked. If that isn't good enough for you, there are always other databases. I prefer PostgreSQL, myself. On the other hand, if you really want to use MySQL, but some bugs are getting in your way, you can always go and fix them yourself.
I really don't see the big deal. Even _if_ something is going terribly wrong with MySQL at Sun, nothing is lost; except, perhaps, the happiness of the developers - who would have my sympathy, in that case.
``Where does the stupidity stop? When every single thing on the system has been rewritten in someones pet scripting language du jour? When every program requires its own interpreter?''
Because the perfect programming language isn't there yet. Therefore, people continue to create new ones, and others continue to find them useful.
As for your complaint about interpreter creep: I can see why that doesn't make you happy. I guess the reason many languages are interpreted rather than compiled to native executables is that it's easier to write interpreters that run on a plethora of platforms than compilers that target a plethora of platforms (something which I am trying to remedy with TurboVM, Alchemist, and an upcoming low-level platform abstraction language, but this is all still under development).
On the other hand, the interpreter is just a bit of extra code you install that provides functionality a program builds on. In many ways, interpreters are like libraries. They could have shipped the interpreter with the executable, and then you wouldn't have noticed it as a separate piece to install, but that would have prevented reuse...and reuse is a Good Thing. Speaking of which, I believe C isn't particularly good for developing reusable components, so if a large chuck of your software is written in C, you might actually have more duplicated functionality on your system than if much of your software is written in a bunch of different higher level languages.
Well, see it this way. Suppose privacy really is very important, and you try your best to retain your own privacy. Now you see many people basically destroy their own privacy, for example by using Facebook. That isn't a very smart thing to do, because privacy is important. So, clearly, you are smarter than these people at least when it comes to privacy. That has nothing to do with wanting to feel better than everyone else.
As for the "whatever that is" part, I suppose that, with a little research, one could find out. But the truth is that Facebook, and many sites like it, have introduced a lot of words in their users' vocabularies that don't mean a lot to people who have never used those sites. So, rather than coming from some sort of sense of superiority, the "whatever that is" comment could come from honest frustration with people constantly talking about things one doesn't know about.
I completely understand where the original poster is coming from, and I don't see him having an obvious case of superiority complex. Even if he does have it, I don't see what we all gain by you (and others) making personal attacks. So I would ask that you be more considerate in the future.
Slashdot Mirror
You might want to read this article. The illusion that running Linux makes you safe and that Linux machines aren't involved in spam-sending botnets is just that: an illusion.
As for firewalls protecting insecure systems: they do, to an extent. But the firewall isn't going to stop you from getting infected by, say, visiting a website with malicious code on it, opening an email attachment with such, or installing and running software with malicious code in it.
> >> Latency is the most important criteria, and reiserfs is just too complicated to deliver it''
> > Excuse me? Do you have any numbers to back up that claim?
> > Because I'm having a hard time taking it on face value.
> You are the one trying to get me to switch file systems, so you are the one who has to provide the numbers. I look at
> those benchmarks, and ext2 looks like the winner. If you have others, I'll be happy to take a look at them.
You misunderstand. I am not trying to get you to switch filesystems, I am asking you to back up your claims. In this
case, the claim that "reiserfs is just too complicated to deliver [low latency]".
> > A filesystem that has been included in the mainline Linux kernel for several years,
> > is offered as a prominent choice during installation of various distros, used to be
> > the default fs on some distros, and is widely used by people who make conscious and
> > informed choices about which filesystem to use.
>
> Most people just take the default filesystem for their distro, and I don't know of any that have reiserfs as the default.
According to Wikipedia:
``ReiserFS is the default file system on the Elive, Xandros, Linspire, GoboLinux, Kurumin Linux[citation needed], and Yoper Linux distributions. ReiserFS was the default file system in Novell's SUSE Linux Enterprise until Novell decided to move to ext3 on October 12, 2006 for future releases.''
> That would meet my definition of "fringe".
I won't argue against that.
> > Kindly point me at this compressed archive format that lets me fetch files
> > (small and large) by name and other attributes more efficiently than Reiser4
> > or even ReiserFS.
>
> I don't know of any.
And yet, you said:
``Yup, I'd like to have efficient small file handling. But really, it is better to avoid having many small files in the
first place. Use compressed archives to store such things; it's quite a bit more efficient''
If you claim that compressed archives are more efficient for storing many small files, you had better actually know
at least one compressed archive format that actually is more efficient. Otherwise, you would just be making an
unfounded claim. Again, I ask you to back up your claims.
> Care to write one? 'Cause I'd sure like to have it. I think you can do this with Kioslaves, but I'm
> no expert there. My point is that it should exist, because it is the right solution.
I disagree. There is no reason that having many small files should be as slow as some file systems make it. Finding an
alternative way to store the data may solve the performance problem, but it increases complexity and runs the risk of
making standard utilities useless for your chosen storage format. Given that it _is_ possible to store and retrieve the
small pieces of data efficiently, why don't we just make the filesystem do it?
> When you have many small files,
> that's just bad design. They are hard to keep track of, and there is no reason for them to be individually user-visible in
> the first place.
So you say. I think that claim may be true in some scenarios, but certainly not in all scenarios. I _like_ the units of
data that I think about to coincide with files; this allows me to use tools that manipulate files to manipulate a lot
of things on my computer: documents, programs, configuration files, messages, etc. I don't like the idea of having to
use specialized tools for each of these. If anything, I would try to _extend_ the number of things I can apply my
standard tools to, rather than shrink it by hiding many objects in a single unit.
> > Then please point out how I can use this as I would a filesystem:
> > so that the good old Unix software can access the files.
>
> If you want that, you can use FUSE on a loop, but then, of course, Linux would make you mount i
``Believe it or not, the world does not revolve around huge mail servers. Some of us actually run Linux on a desktop, and so don't really care about how well an fs handles a million maildir mailboxes.''
What if I have large Maildir mailboxes on my desktop system? Or anything else that puts many files in a single directory? Just because _you_ don't need that case to be fast doesn't mean it isn't a good idea to have it be fast, anyway.
``Latency is the most important criteria, and reiserfs is just too complicated to deliver it''
Excuse me? Do you have any numbers to back up that claim? Because I'm having a hard time taking it on face value.
``as well as being a largely fringe fs''
A filesystem that has been included in the mainline Linux kernel for several years, is offered as a prominent choice during installation of various distros, used to be the default fs on some distros, and is widely used by people who make conscious and informed choices about which filesystem to use. But yes, if you want to call it a "fringe fs", go right ahead.
``Especially now with Hans gone, it would become even more fringe.''
This, unfortunately, is all too true. ReiserFS still is a great filesystem in terms of reliability and performance, from tiny files to huge ones, under a wide range of scenarios. Reiser4 was going to be even better: faster and more flexible and extensible, with fast arbitrary attributes and a lot of other goodness. But it never made it into the mainline kernel, and, with Hans Reiser in jail, the future doesn't seem bright for Reiser4. On the other hand, there are various new contenders: ZFS, btrfs, and ext4, just to name a few. None of them seem to be quite there yet, but hey, neither was Reiser4.
``Yup, I'd like to have efficient small file handling. But really, it is better to avoid having many small files in the first place. Use compressed archives to store such things; it's quite a bit more efficient''
Kindly point me at this compressed archive format that lets me fetch files (small and large) by name and other attributes more efficiently than Reiser4 or even ReiserFS. Then please point out how I can use this as I would a filesystem: so that the good old Unix software can access the files. And remember: I need random access to the file contents, and I need to be able to add, remove, write, etc. files. And if any operation is interrupted suddenly and unexpectedly, the integrity of my tree needs to be preserved. Bonus points for full data integrity preservation.
``The performance hit from journalling is simply too high to tolerate.''
Performance hit from journalling? And you're using ext2 to avoid it? Your usage patterns must be very different from mine. True, ext2 running in async mode (i.e. no consistency guarantee at all) is slower than ext3 with journalling which guarantees consistency. On the other hand, with ReiserFS, I can have journalling, guaranteed consistency of at least the filesystem structure, and better performance. Plus, for some strange reason, ext3 seems to lose a lot of files on my systems (although they can be recovered by running fsck) during normal operation. Among the 3, ReiserFS is the clear winner for me. I am not disputing that you may be seeing other data, but let's at least conclude that ext2 is _not_ faster than all journalled filesystems for everyone, and that the performance hit of journalling, if any, is not "too high to tolerate" for everyone.
``With UPS prices being as low as they are, there is no excuse for not having one, so I think that journalling will become obsolete in some near future.''
I think smart people realize that having a UPS is no guarantee that your system will never fail in the middle of a write. So a method to bring the system back to a consistent state is needed in any case. Let's also realize that journalling isn't only for recovery. It is one way to implement transactions, and transactions are useful for more than recovery alone; for example, they can be used to ensure consistency of da
Aerodynamic features of the F-117, AKA the Wobblin Goblin? Now...I'm not sure that's a great idea. Maybe you should be looking at sailplanes, rather.
``If your trivial program runs in 0.6 seconds instead of 0.01 seconds, you may not care about the difference. And if you can write your program in 1/10 the time, you may come out way ahead.''
Also, the two are not mutually exclusive. You can have a language in which it takes you little time to write the program _and_ end up with an efficient program (depending on the language implementation, of course).
I think the most important thing is that you have solved a variety of problems in a multi-paradigm language. Languages that shoehorn you into one way of solving problems don't generally give you much chance to think about what would be the best way to solve the problem. If you can suit your language to your design, instead of the other way around, you can write much more elegant code. Good multi-paradigm languages I know are Common Lisp and Ruby.
Now seems like a good time to tell you all about the book I read yesterday. It is called "Little Brother", written by Cory Doctorow, and available for free download, as well as in dead tree form. Very fascinating.
* looks around his place *
I guess I'm Che Guevara.
Pick a sensible version numbering scheme and stick with it.
My personal favorite is x.y.z, where x is incremented at major rewrites and when incompatible changes are introduced, y is incremented when new features are added, but backward compatibility is preserved, and z is incremented for maintenance releases that don't add features and don't break compatibility (except when caused by buggy behavior, of course).
This way, you can tell that your configuration file for version 1.1.0 will work on version 1.1.1 and version 1.2.0, but not necessarily on 2.0.1, and that if someone is running 1.1.0 when 1.1.1 is already out, they may be running into bugs that have been fixed since.
Whether you, as a user, trust a given version number to represent a reliable piece of software is, of course, entirely subjective. It is wise to remember, though, that there is software with 0.6 version numbers that is rock solid, and software with 9.0 version numbers that is junk. More or less the only thing that can reliably be deducted from version numbers is that higher numbers indicate newer versions of the software. A version number doesn't say anything about how good the product is.
In other words, they are making encryption worthless, as far as protecting you from the government goes. Sure, you can encrypt your data with a good key and cipher and they won't be able to read it. But then they can just arrest you, charge you with something, and force you to disclose your data to them. Even if there is nothing among your data that relates to what you have been charged with, the government now has access to all your data.
All that may be acceptable as long as the government is going after the people you want them to go after. But there's no guarantee that this will always be the case. Governments work for the people sometimes, but they can also work against the people. This is why some smart people have written down rules the government must play by, restrictions on what the government is allowed to do. These restrictions are there for your protection: if the government plays by the rules, they are limited in what they can do to you, should they decide to come after you. When the government breaks these rules, that's a bad sign. It means they are crossing the line between working for the people and working against the people. It means they have a problem, and they are willing to violate your rights to deal with that problem.
The defendants are right. Their encrypted data may or may not contain evidence against them. They don't have to tell the government anything about it, and they certainly don't have to give the government access to all of it. Even if the defendants are guilty of the crime they are charged with, they have rights. They are innocent until proven guilty, and they have the right to remain silent. A judge (or jury, as the case may be) has the right to make inferences as to why a defendant choses to remain silent, of course.
Thanks for telling me about Little Brother. I'm glued to my monitor reading it. It's so real it makes me nervous. I love it.
``But you normally have more than one in a cockpit. If one goes bad, you can use the other, not catastrophic.''
That is, unless the other one goes bad, as well. Which isn't even that unlikely, given that both of them are in the same aircraft and thus will be exposed to similar conditions - perhaps even the exact same inputs.
I think (but I haven't actually looked at the numbers) that a lot of today's aircraft incidents and accidents are caused by the pilot and the computer having different ideas about what to do. For example, a pilot trying to land a plane while the computer has decided to abort the landing.
Interesting. I've always thought that "fly-by-wire" meant that the controls and the steering of the aircraft were essentially decoupled: you use the controls to "tell" the computer how you want to fly, and the computer then flies the plane for you. The "wire" in this case refers to a virtual wire the plane flies along. For extra clarification: some fighter planes are so unstable that they need constant adjustment. A fly-by-wire system would then allow the pilot to steer smoothly, while the computer made all the micro-adjustments necessary to actually keep the plane on the expected course.
``MS set the entire computer industry back by at least half a decade by pawning that trash off on the consumer market.''
That is to say, the users set the world back because they massively went with Windows 95. They could have chosen something else...say, OS/2, SLS, or Slackware, all of which were available at the time.
You are _happy_ with Windows and you ask what's wrong with you? On Slashdot? You must be new here.
FYI, there are other browsers for Linux that use WebKit as their rendering engine. From the top of my head: Epiphany and Skipstone, but there are at least two others.
Depends on the version of Linux and what software you use with it. There are a mind-boggling number of different versions of the kernel out there, in various distributions, and sometimes in custom-made operating systems...and then we aren't even getting to the applications, yet. Among all those, I am sure you will find everything from rock-solid to "crashes at the drop of a hat, or even without that".
While I don't dispute the claims you make, I would like to point out that
1. Debian does make announcements about prospective release dates. These aren't firm promises and shouldn't be interpreted as such, but it is disappointing when they miss those dates by months.
2. Releases aren't only made when the bug count drops to zero. First of all, there are bugs that aren't considered "release-critical". Secondly, sometimes (I think this happened with etch) releases are made with known issues and a promise to fix those issues Real Soon Now. Thirdly, the way the bug count is brought to zero usually includes simply throwing out packages that have known bugs. If many people want such a package, that isn't very helpful.
3. Bugs that would have been "release-critical" are often discovered after a release is made. The current stable release, etch, had more release-critical bugs pending against it than lenny (the upcoming stable release), last time I checked.
What all this means is that Debian will _not_ generalyl be released at any date that has been mentioned, and will _not_ generally be bug-free when released.
Having said all that, it's still my favorite operating system, as it takes less of my time to use and maintain than anything else I have tried (and that is quite a lot).
``If this article was about Microsoft instead of Debian, you know the tone would be substantially different.''
Yes. And that's a bit hypocritic. On the other hand, there is an important difference between Microsoft and Debian: while both produce operating systems, Microsoft mostly deals with only things they develop themselves, and doesn't package all applications for a given release of their operating systems. Debian, on the other hand, deals mostly with software they don't develop, and still manage to package an impressive chunk of that for seamless integration with their operating system. I also think their final release dates and feature sets don't tend to differ as much from the initial announcements as do Microsoft's...
"I know Dick Cheney has assured us that 'Deficits don't matter' ..."
Tell that to Iceland. Not so long ago, Iceland was a rich country. Recently, the country has become unable to pay its debts, and its currency has quickly lost its value. Now, banks have stopped trading in Iceland krona, which means the money has essentially become worthless. And that means that if all you have is Icelandic kronur, you will have a very hard time paying for things. I don't think Iceland is a rich country anymore. Now, tell me again why deficits don't matter?
The first thing I thought when I saw the picture was "That's not a moon..."
What's the big deal? One developer leaves the MySQL team, after MySQL has been bought by Sun. Ok. The two may or may not be related. And it may or may not indicate that something is making the developers unhappy.
MySQL has hundreds of bugs open against the upcoming release. Ok. Is that a lot? It does sound like it. On the other hand, it's hard to say what this means for quality. It means all these bugs have been _found_, which is good. Now they just need to be fixed.
In the meantime, existing versions of MySQL will continue to work as well as they have always worked. If that isn't good enough for you, there are always other databases. I prefer PostgreSQL, myself. On the other hand, if you really want to use MySQL, but some bugs are getting in your way, you can always go and fix them yourself.
I really don't see the big deal. Even _if_ something is going terribly wrong with MySQL at Sun, nothing is lost; except, perhaps, the happiness of the developers - who would have my sympathy, in that case.
``Where does the stupidity stop? When every single thing on the system has been rewritten in someones pet scripting language du jour? When every program requires its own interpreter?''
Because the perfect programming language isn't there yet. Therefore, people continue to create new ones, and others continue to find them useful.
As for your complaint about interpreter creep: I can see why that doesn't make you happy. I guess the reason many languages are interpreted rather than compiled to native executables is that it's easier to write interpreters that run on a plethora of platforms than compilers that target a plethora of platforms (something which I am trying to remedy with TurboVM, Alchemist, and an upcoming low-level platform abstraction language, but this is all still under development).
On the other hand, the interpreter is just a bit of extra code you install that provides functionality a program builds on. In many ways, interpreters are like libraries. They could have shipped the interpreter with the executable, and then you wouldn't have noticed it as a separate piece to install, but that would have prevented reuse...and reuse is a Good Thing. Speaking of which, I believe C isn't particularly good for developing reusable components, so if a large chuck of your software is written in C, you might actually have more duplicated functionality on your system than if much of your software is written in a bunch of different higher level languages.
Well, see it this way. Suppose privacy really is very important, and you try your best to retain your own privacy. Now you see many people basically destroy their own privacy, for example by using Facebook. That isn't a very smart thing to do, because privacy is important. So, clearly, you are smarter than these people at least when it comes to privacy. That has nothing to do with wanting to feel better than everyone else.
As for the "whatever that is" part, I suppose that, with a little research, one could find out. But the truth is that Facebook, and many sites like it, have introduced a lot of words in their users' vocabularies that don't mean a lot to people who have never used those sites. So, rather than coming from some sort of sense of superiority, the "whatever that is" comment could come from honest frustration with people constantly talking about things one doesn't know about.
I completely understand where the original poster is coming from, and I don't see him having an obvious case of superiority complex. Even if he does have it, I don't see what we all gain by you (and others) making personal attacks. So I would ask that you be more considerate in the future.