Hmm... The shell-equivalent in hardware would be a large hammer I guess. Or a fire axe.
Similarities: 1) Government doesn't like when you use it too much 2) You can threaten people with it 3) It may get you a job, and it might loose you one 4) It is an immense help for re-configuring almost anyting else
Now what would the software-equivalent of a plastic screwdriver be ? (I already have a candidate;)
That's what you have the second beer for: To open the first one. Then you put the (uh, missing a word here, pls. insert the name of the metal thingy on top of the closed bottle) back on top of the first bottle, and open the second one with that.
Ever tried updating more than a few machines ? Well that's why you don't want to click it. You could ofcourse. I'm sure that tools like gRPM (GNOME RPM) and others will, in time if not already, give you the option of running the equivalent of the --freshen. You can already point-and-click upgrade packages, which is sufficient for upgrading packages you know needs upgrading.
I don't know about the 120 exploits you mention. If you look at the updates directory for RH6, there's far from 120 packages to upgrade. So there might be 120 holes, but they're all fixed by applying a far smaller number of upgrades (so either 120 is a little optimistic on someone's part, or some packages just have a lot of holes (I'd doubt that so many packages had so many holes though)).
Really, redhat has the erratta page, and you can already point'n'click upgrade. In the security updates that redhat release, they even give you an entire command-line you can just cut'n'paste into a root-shell, to have the upgrade retrieved from the 'net and applied. I'm having a hard time seeing what you think the problem is.
PostgreSQL database formats changes only between some (usually major) version numbers.
It would be very bad indeed if RH released an update package that would break data when applied. Haven't seen that yet. They're usually (probably for the reasons you state) very careful about warning you of any implications an update might have. Usually the're no implications except for the fix of the hole.
I guess the main reason why GNU/Linux systems ship numerous small updates, whereas NT has huge single service-packs is, that any normal program (a package) under GNU/Linux consists of a well-defined set of files. None of which are *system* libraries (DLLs).
On Windows a typical application ships its own version of some of the *system* DLLs, thereby rendering the whole platform insecure if one of it's libraries has a flaw.
Thus the need for a huge service pack on NT. You need to re-ship updated versions of all libraries, and you need to re-install the service pack after each installation of a (seemingly unrelated) program, because NT DLLs are touched by *applications*.
Because of open source, we can re-compile an application that doesn't work with the system libraries we may have, thereby avoiding having to overwrite system libraries whenever we install an application. Therefore we can have small packages that update nothing but the problem. And therefore GNU/Linux will, unlike some other OS, have a massive share of the total server installations for many years to come.
I can think of: *) ssh (using.shosts for root) *) rpm --freshen ftp:// and eventually *) at
There you have your shink-wrapped enterprise management patch package distribution scheduling parallel system [feel free to add more buzzwords]
Really, with rpm (and I'm sure with dpkg too) it's really _so_ easy. You need a very small amount of imagination, and then you have your management system that you can customize in anyway you please (hell, you just wrote the main routine of the application yourself - even though it's a one-liner).
That is, if rpm --freshen * is too hard to type, they shouldn't be running computers at all.
Hire someone with a clue, and go back to writing articles.
Seriously though, if you tried applying NT service packs, and tried rpm --freshen, you know who's got the lead (and for those who haven't tried, here's a hint: it's not the redmond guys).
With NT, you apply one huge service-pack that (somewhat) fixes the problems known at the time of the release of the service pack. Whenever you install a new piece of software, you have to re-install the service pack if you want to be sure it's effective.
With rpm you do the --freshen trick, once. If you install another piece of software, well fine, no worries. If another fix becomes available, just get them all and do --freshen, or get the one fix and --freshen. It's as simple as it gets.
I think it's much too common for clueless people to assume that it's hard to maintain a system they don't know (and haven't even tried to grasp), and assuming that the system with the most aggressive PR backing is necessarily much easier.
The only reason why we don't see more remote attacks on NT is because ``networking'' is somewhat alien to NT. Networking has always been an integral part of UN*X and Linux, so naturally a buggy networked application is almost bound to compromise the system in a cracker-friendly way.
Consider the incredible amount of local attacks on NT being posted weekly (almost daily) on Bugtraq, and you see why NT people should be really happy that NT is not a network operating system.
But he wasn't talking about Linux. He was talking about CUPS, an application. The most stable kernel in the world won't make a difference for a crappy application running on it. He didn't say the system went down, just the print-system, the application, there's a difference.
Besides, I fail to see how CUPS is much different from the rhs_printfilters shipped with every RedHat, or the similar filters Debian use. You can print almost anything directly, if you don't care about having some control with how eg. a TIFF is put on your paper (functionality which the Gimp will easily provide).
LPRng is nice though. It's much more fault tolerant than the standard lpr package. It puts a lot of effort into working with printers that aren't exactly acting as the RFC suggests. Too bad about the crappy licence.
Deep though / deep blue consisten of a very large number of very bad chess players (they only knew the rules and how good/bad one move would be). But the were organized so that a good number of moves could be considered (including possible moves from Kasparov - by guessing), and the best move picked.
This is not democracy. The move with the most backing (the move to be chosen) was not the one which most of the ``chess-players'' wanted, but the one that looked best considering the whole set of moves and possible moves.
You can't find an optimal move by distributing the search for single moves to dumb players, and then voting in a democratic way. Maybe this could have worked if the human voters' moves had been considered by a computer (or a human with too much time on his hands). But then again, studpid computer chess-players can produce a much larger number of moves than smarter human ones.
Stupidity parallelizes well, and that can be exploited if it is just reckoned that it _is_ stupidity. Parallelizing intelligence is different. A large number of intelligent thoughts cannot be parallelized only by considering their outcome. You must consider the reasoning behind them too. I'll leave that as an exercise to the reader:)
I once participated in setting up a box to play MP3s in a bar. It was supposed to be operated by drunk clueless people, and it ran Linux. Why ? Because when it booted, it booted up an X server with a nice background image and an MP3 player. No window manager, no logins, no start buttons, no nonsense.
By the way, it also booted from the network, so there was no need to fsck if people power-cycled it.
In fact, it worked really well. There was no way people could minimize/close the MP3 player, and even if they managed to do so, a simple power-cycle would bring the box back up and functional in less than a minute.
You don't need notepad to surf the web, especially not in a cab. I'd go with an OSS anytime, if I had to set up such a system again.
I'm stunned... That was absolutely the most vague article I've read for quite some time, and given the usual vagueness of popular press, that's something ! Do they pay tax on publishing facts ? Or are they heading for a Guiness record ?
So some well known people are somewhat involved in some project that has a three-letter-acronym for Linux [buzzword] Cluster [buzzword] Cabal [you need three words to make a TLA].
What are they aiming for ? Is development going on at all ? Do they have _any_ goals yet, except to make this cluster stuff and put the rest of the cluster stuff projects to sleep ?
If anyone knows more than was put in that [cough] ``article'', I'd be delighted to know about it.
Or, perhaps it will get posted once they get their record...
They could release their nonGPL software under nonGPL license, and have it come along with the distribution. To the user it would seem as the Corel distribution included the nonGPL software, but to the rest of us it would seem that Corel had a ``real'' distribution with an optional nonGPL package.
Caldera does this, and RedHat did back in the old days (with MetroX).
If the distribution (except for some nonGPL packages) isn't GPL, it means that not anyone can just download it, which in turn means that a lot of people won't even try it out, which in turn...
Corel are shooting themselves in their feet with an eight barreled Vulcan (HE+AP ammo), twice, at close range, and for some reason they don't seem too bothered about it. I don't get it...
Even if they change the license tomorrow, it's a week late. But I do hope they change it. Corel could still be seen in a good light. But they must act.
Corel would truely impress me, if they fixed their license by just sticking a GPL on the distribution.
After all, it's the easiest thing to do, and it shouldn't take a genious to figure that the community would be happiest with this. Corel would even stand as an insightful company that knows when the time is for a new license and when the time is to support and benefit from an existing one.
However, that would require actual insight. Not a lot, but some. I'd be as surprised as I would be happy.
The main problem with the media (and therefore the general public) believing that Linus wrote GNU/Linux is, as I see it, that Linus getting hit by a bus will scare the sh*t out of people.
_If_ Linus decides to stop working on Linux, or he gets hit by the famous bus, the general public will think that the sole person who is developing this great ``new'' promising system is gone, and therefore any further development is stalled.
We all know that this is not the way things are. But if the general public, believes it really is so, we may see companies abandoning Linux, ultimately making Linus _the_ central person of GNU/Linux (or open source in general) development.
The power if PR should not be underestimated. Now that the media already has the wrong picture of how open source works, we're in a hurry to seek to rectify that view.
This may be a good reason to insist on calling a Linux system a GNU/Linux system. To emphasize that it is not just the system written by some crazed Finnish communist student with too much spare time on his hand, or whatever it is the media seems to believe.
Stallman may be more justified in his insistance on the GNU/Linux labelling that we would normally agree he is.
However, I wouldn't worry about the govt. giving back fixes.
You can argue, that the US government probably some way or the other is immune to copyright law (at least US copyright law). So they don't _have_ to give back the fixes.
But it's a matter of common interest. It's in their best interest to see that the stock distributions are as secure as possible, in order to minimize the hazzle they go thru when maintaining their installations. Therefore the government _will_ be interested in giving back any fixes, even though they don't have to.
Still, I wouldn't be surprised if some brown nosed idiot would suggest they they shouldn't give back the fixes, because of national security reasons or whatever. Like the crypto restrictions. But I'm confident that such measures would be short-term, and that we will definitely see contributions from the government, should they decide to use the more secure platform.
Ironically, the government may some day be part of a community:) Wonder how they'll tackle that one.
That was about time that some government took off the sunglasses and had a look at the real world.
I can't believe they haven't thought of this earlier (or at least thought of it in public). Linux is far from the only open-source OS, simply using the proprietary UN*Xes they've been running for long, with open-source daemons and tools would have gotten them a long way.
I remember the swedish government discovering that the proprietary e-mail tool they used had a backdoor in the encryption service they relied upon for security reasons. The backdoor was there for the US government (NSA probably).
This was so funny, or rather tragic, because they simply didn't think about before someone pointed it out to them. They honestly believed, that because the shrink-wrapped package said ``encryption'', they'd be safe.
Amazing it is, that the US government has been just as naive, believing that a closed source product only did what the package said it would do. I wonder how much insight MS/Sun/Oracle/others have into what's going on behind those closed doors.
Never underestimate the power of human stupidity.
Well, I'm looking forward to seeing new OSS daemons from the white-house, and mails from randomuser@whitehouse.gov on LKML:)
From webster's: Fail \Fail\v. i.... 1. To be wanting; to fall short;
Linux doesn't want to dominate anyting, and therefore cannot fail in this task.
Java was hyped out to dominate the world, and for now it has failed.
It's incredible how reporters and others just can't seem to grasp that Linux doesn't have any need or desire to dominate, and therefore cannot fail in trying to do so.
``Total world domination'' was meant as a joke, but it's a lot more real that any of the hype surrounding Java. That is just a coincidence, not a goal.
> No, because C++ is a hybrid language, whereas Java is a pure OO language.
Exactly. And the world just isn't pure OO.
> Yes you can, with RMI.
Didn't know about that. Thanks.
> I don't see why this would be a bad thing?
Try writing a guidance system for a missile.
And try sleeping for two seconds while waiting for the GC to do it's job.
> No, it is not useless. It quarantees that machine X doesn't suddenly have 10 bits less in its floating points than machine Y. Also, there is also java.math which has classes for arbitrary-precision integer and decimal arithmetic.
You just don't have 10 bits of difference in the real world. The difference (between machines that would be likely to be on the same network) you usually see around one bit or so, and perhaps different rounding/truncation of numbers.
Numerical algorithms work because they know that they work with finite precision. Unifying the finite precision is outright dumb. You would get just as far, faster, by knowing your worst precision and using that as the unified precision.
Arbitrary precision floating point is nice, but it's something that can be in a library (or class if you like) just as well as in the language. I'm pretty indifferent to that. I guess there are plenty of libraries out there just for that, for almost any language one could imagine.
Another thing about Java is, that IMHO it is not at all such a nice language.
The concept of running on a virtual machine is nice, but there are problems.
Good features: 1) Threads in the language 2) Sockets in the language 3) Garbage collection 4) Homogenous environment on heterogenous architectures
Bad features: 0) It is not object oriented like C++, where you can choose to use object orientation when it fits the task at hand. You are _forced_ to use object orientation, always, everywhere. 2) You can easily communicate datastructures over the network. But you cannot (AFAIK) communicate the code. Why not ?? It's a virtual machine, distributing code over the network should be trivial. 3) You have garbage collection always, everywhere. Not just when it's a benefit, but again you're locked into it. 4) Floating point calculations are guaranteed to have same machine precision on all architectures. However, this is completely useless since numerical computations per definition are inaccurate, so all we have is an overhead from a feature with no use.
Sun invested an incredible amount of money and effort into marketing Java. Still, it is not the language that most people use when they need real work done. It's IMO a niche language. It has it's forces, but it's not a general purpose language.
To quote Bjarne Stroustrup: Java is... ... a marketing phenomenon.
That is, in my oppinion where Sun failed. If only Java had been a general purpose language, boy we'd be coding it today.
I hear it pretty often from people, that the Linux distributions are hard to install. Especially some feel that the lack of a GUI install makes it really hard.
I'm not understanding a bit of that. RedHat Linux (which I use) has the easiest install I've ever seen. And other distributions (Debian and Slack which I've also run) are good as well. The procedure is: Put in the boot floppy, answer the questions, and reboot.
You can install most Linux distributions using one or two floppies, and a network connection or a CD. Now why is that said to be hard ?
Especially in sharp contrast to the NT install, which I've also been thru quite a few times... To install NT, you need the right kind of hardware (meaning ATAPI CD-rom and a motherboard that doesn't have controllers NT choke on (like NOT Asus P2B-DS)), you need DOS running and able to access the CD drive, and _then_ you can maybe start the GUI install. Wow!
I'm sure one can boot an NT install from CD, if one has the right hardware again, but still, the problems with unsupported devices and crap like that remain.
Besides, if you're an experienced Linux user, you can do a lot of clever tricks during the install, by using the shell which is available in most installers. You can never become experienced enough to do that under NT.
It's been some time since I installed Win95. In fact I've only really done it once. That one was fairly easy, given that I had the hard-drive partitioned correctly and all the right hardware.
Ever tried installing Win9X/NT on a disk that had a non-DOS partition ? Well, if you have you already know what I'm talking about.
Come on people. Entering the right IP address is no easier in a GUI than it is in ncurses.
I'm not pissed off about Caldera making a GUI install. I think it's nice. I'm just pissed off by the ignorance and unfounded accusations posed by lusers with too thick sunglasses.
I guess this proves that no matter how secure your platform is, the people who write the apps still need to have a clue about security.
It doesn't matter that UN*X or Linux are secure, when the apps that run on them aren't.
Except from removing sprintf/sscanf and friends from the C library, does anyone have any good ideas about what could possibly be done to increase the probability of some daemon being secure ?
Buffer overflows are a frequent coding error, but other exploits also happen (like much of the Java disasters in browsers previously). Also, simple design errors in an authentication sequence can cause the wrong people to get access, even if the code implements the intended algorithms perfectly.
One can write an insecure program in any language using any tools. But how can we seek to increase the probability that developers don't fall into these pits of insecure code writing ?
We still need C, we still need string handling, and since every system has it's own way of authenticating users, it seems there is little to be done at all.
Mount the/home/httpd filesystem with the noatime mount option, then there will be no writes generated from read-accesses, and your ext2fs will effectively work as a ram-disk, if you have enough memory. Only, it's a helluwalot easier to just change stuff where it resides, and know it will be written to disk, instead of back-forth-copying tar images...
Second benefit: if you really get low on memory, you're fucked with a 1 Gig RAM disk, whereas the disk-cache will quickly be thrown away and used for whatever memory hog you have running.
ram-disks are good for booting over-modularized kernels _only_.
Slashdot Mirror
Hmm... The shell-equivalent in hardware would be a large hammer I guess. Or a fire axe.
;)
Similarities:
1) Government doesn't like when you use it too much
2) You can threaten people with it
3) It may get you a job, and it might loose you one
4) It is an immense help for re-configuring almost anyting else
Now what would the software-equivalent of a plastic screwdriver be ? (I already have a candidate
I'd use the corkscrew to drill an Ethernet port in .. oh. no never mind.
What ?
:)
That's what you have the second beer for: To open the first one. Then you put the (uh, missing a word here, pls. insert the name of the metal thingy on top of the closed bottle) back on top of the first bottle, and open the second one with that.
I live in Denmark, trust me !
This is redundant, that's all they got right.
Remember people, ``Hardware'' is all the kickable parts of a computer system, let's not forget that.
Now I gotta go now, 'have a few machines to ``boot'', or, that'll be ``sneak'' (what else would you call it when wearing sneakers?)
Ever tried updating more than a few machines ? Well that's why you don't want to click it. You could ofcourse. I'm sure that tools like gRPM (GNOME RPM) and others will, in time if not already, give you the option of running the equivalent of the --freshen. You can already point-and-click upgrade packages, which is sufficient for upgrading packages you know needs upgrading.
I don't know about the 120 exploits you mention. If you look at the updates directory for RH6, there's far from 120 packages to upgrade. So there might be 120 holes, but they're all fixed by applying a far smaller number of upgrades (so either 120 is a little optimistic on someone's part, or some packages just have a lot of holes (I'd doubt that so many packages had so many holes though)).
Really, redhat has the erratta page, and you can already point'n'click upgrade. In the security updates that redhat release, they even give you an entire command-line you can just cut'n'paste into a root-shell, to have the upgrade retrieved from the 'net and applied. I'm having a hard time seeing what you think the problem is.
PostgreSQL database formats changes only between some (usually major) version numbers.
It would be very bad indeed if RH released an update package that would break data when applied. Haven't seen that yet. They're usually (probably for the reasons you state) very careful about warning you of any implications an update might have. Usually the're no implications except for the fix of the hole.
I guess the main reason why GNU/Linux systems ship numerous small updates, whereas NT has huge single service-packs is, that any normal program (a package) under GNU/Linux consists of a well-defined set of files. None of which are *system* libraries (DLLs).
On Windows a typical application ships its own version of some of the *system* DLLs, thereby rendering the whole platform insecure if one of it's libraries has a flaw.
Thus the need for a huge service pack on NT. You need to re-ship updated versions of all libraries, and you need to re-install the service pack after each installation of a (seemingly unrelated) program, because NT DLLs are touched by *applications*.
Because of open source, we can re-compile an application that doesn't work with the system libraries we may have, thereby avoiding having to overwrite system libraries whenever we install an application. Therefore we can have small packages that update nothing but the problem. And therefore GNU/Linux will, unlike some other OS, have a massive share of the total server installations for many years to come.
I can think of: .shosts for root)
*) ssh (using
*) rpm --freshen ftp://
and eventually
*) at
There you have your shink-wrapped enterprise management patch package distribution scheduling parallel system [feel free to add more buzzwords]
Really, with rpm (and I'm sure with dpkg too) it's really _so_ easy. You need a very small amount of imagination, and then you have your management system that you can customize in anyway you please (hell, you just wrote the main routine of the application yourself - even though it's a one-liner).
That is, if rpm --freshen * is too hard to type, they shouldn't be running computers at all.
Hire someone with a clue, and go back to writing articles.
Seriously though, if you tried applying NT service packs, and tried rpm --freshen, you know who's got the lead (and for those who haven't tried, here's a hint: it's not the redmond guys).
With NT, you apply one huge service-pack that (somewhat) fixes the problems known at the time of the release of the service pack. Whenever you install a new piece of software, you have to re-install the service pack if you want to be sure it's effective.
With rpm you do the --freshen trick, once. If you install another piece of software, well fine, no worries. If another fix becomes available, just get them all and do --freshen, or get the one fix and --freshen. It's as simple as it gets.
I think it's much too common for clueless people to assume that it's hard to maintain a system they don't know (and haven't even tried to grasp), and assuming that the system with the most aggressive PR backing is necessarily much easier.
The only reason why we don't see more remote attacks on NT is because ``networking'' is somewhat alien to NT. Networking has always been an integral part of UN*X and Linux, so naturally a buggy networked application is almost bound to compromise the system in a cracker-friendly way.
Consider the incredible amount of local attacks on NT being posted weekly (almost daily) on Bugtraq, and you see why NT people should be really happy that NT is not a network operating system.
But he wasn't talking about Linux. He was talking about CUPS, an application. The most stable kernel in the world won't make a difference for a crappy application running on it. He didn't say the system went down, just the print-system, the application, there's a difference.
Besides, I fail to see how CUPS is much different from the rhs_printfilters shipped with every RedHat, or the similar filters Debian use. You can print almost anything directly, if you don't care about having some control with how eg. a TIFF is put on your paper (functionality which the Gimp will easily provide).
LPRng is nice though. It's much more fault tolerant than the standard lpr package. It puts a lot of effort into working with printers that aren't exactly acting as the RFC suggests. Too bad about the crappy licence.
Deep though / deep blue consisten of a very large number of very bad chess players (they only knew the rules and how good/bad one move would be). But the were organized so that a good number of moves could be considered (including possible moves from Kasparov - by guessing), and the best move picked.
:)
This is not democracy. The move with the most backing (the move to be chosen) was not the one which most of the ``chess-players'' wanted, but the one that looked best considering the whole set of moves and possible moves.
You can't find an optimal move by distributing the search for single moves to dumb players, and then voting in a democratic way. Maybe this could have worked if the human voters' moves had been considered by a computer (or a human with too much time on his hands). But then again, studpid computer chess-players can produce a much larger number of moves than smarter human ones.
Stupidity parallelizes well, and that can be exploited if it is just reckoned that it _is_ stupidity. Parallelizing intelligence is different. A large number of intelligent thoughts cannot be parallelized only by considering their outcome. You must consider the reasoning behind them too. I'll leave that as an exercise to the reader
I once participated in setting up a box to play MP3s in a bar. It was supposed to be operated by drunk clueless people, and it ran Linux. Why ? Because when it booted, it booted up an X server with a nice background image and an MP3 player. No window manager, no logins, no start buttons, no nonsense.
By the way, it also booted from the network, so there was no need to fsck if people power-cycled it.
In fact, it worked really well. There was no way people could minimize/close the MP3 player, and even if they managed to do so, a simple power-cycle would bring the box back up and functional in less than a minute.
You don't need notepad to surf the web, especially not in a cab. I'd go with an OSS anytime, if I had to set up such a system again.
I'm stunned... That was absolutely the most vague article I've read for quite some time, and given the usual vagueness of popular press, that's something ! Do they pay tax on publishing facts ? Or are they heading for a Guiness record ?
So some well known people are somewhat involved in some project that has a three-letter-acronym for Linux [buzzword] Cluster [buzzword] Cabal [you need three words to make a TLA].
What are they aiming for ? Is development going on at all ? Do they have _any_ goals yet, except to make this cluster stuff and put the rest of the cluster stuff projects to sleep ?
If anyone knows more than was put in that [cough] ``article'', I'd be delighted to know about it.
Or, perhaps it will get posted once they get their record...
They could release their nonGPL software under nonGPL license, and have it come along with the distribution. To the user it would seem as the Corel distribution included the nonGPL software, but to the rest of us it would seem that Corel had a ``real'' distribution with an optional nonGPL package.
Caldera does this, and RedHat did back in the old days (with MetroX).
If the distribution (except for some nonGPL packages) isn't GPL, it means that not anyone can just download it, which in turn means that a lot of people won't even try it out, which in turn...
Corel are shooting themselves in their feet with an eight barreled Vulcan (HE+AP ammo), twice, at close range, and for some reason they don't seem too bothered about it. I don't get it...
Even if they change the license tomorrow, it's a week late. But I do hope they change it. Corel could still be seen in a good light. But they must act.
Corel would truely impress me, if they fixed their license by just sticking a GPL on the distribution.
After all, it's the easiest thing to do, and it shouldn't take a genious to figure that the community would be happiest with this. Corel would even stand as an insightful company that knows when the time is for a new license and when the time is to support and benefit from an existing one.
However, that would require actual insight. Not a lot, but some. I'd be as surprised as I would be happy.
The main problem with the media (and therefore the general public) believing that Linus wrote GNU/Linux is, as I see it, that Linus getting hit by a bus will scare the sh*t out of people.
_If_ Linus decides to stop working on Linux, or he gets hit by the famous bus, the general public will think that the sole person who is developing this great ``new'' promising system is gone, and therefore any further development is stalled.
We all know that this is not the way things are. But if the general public, believes it really is so, we may see companies abandoning Linux, ultimately making Linus _the_ central person of GNU/Linux (or open source in general) development.
The power if PR should not be underestimated. Now that the media already has the wrong picture of how open source works, we're in a hurry to seek to rectify that view.
This may be a good reason to insist on calling a Linux system a GNU/Linux system. To emphasize that it is not just the system written by some crazed Finnish communist student with too much spare time on his hand, or whatever it is the media seems to believe.
Stallman may be more justified in his insistance on the GNU/Linux labelling that we would normally agree he is.
Good point.
:) Wonder how they'll tackle that one.
However, I wouldn't worry about the govt. giving back fixes.
You can argue, that the US government probably some way or the other is immune to copyright law (at least US copyright law). So they don't _have_ to give back the fixes.
But it's a matter of common interest. It's in their best interest to see that the stock distributions are as secure as possible, in order to minimize the hazzle they go thru when maintaining their installations. Therefore the government _will_ be interested in giving back any fixes, even though they don't have to.
Still, I wouldn't be surprised if some brown nosed idiot would suggest they they shouldn't give back the fixes, because of national security reasons or whatever. Like the crypto restrictions. But I'm confident that such measures would be short-term, and that we will definitely see contributions from the government, should they decide to use the more secure platform.
Ironically, the government may some day be part of a community
That was about time that some government took off the sunglasses and had a look at the real world.
:)
I can't believe they haven't thought of this earlier (or at least thought of it in public). Linux is far from the only open-source OS, simply using the proprietary UN*Xes they've been running for long, with open-source daemons and tools would have gotten them a long way.
I remember the swedish government discovering that the proprietary e-mail tool they used had a backdoor in the encryption service they relied upon for security reasons. The backdoor was there for the US government (NSA probably).
This was so funny, or rather tragic, because they simply didn't think about before someone pointed it out to them. They honestly believed, that because the shrink-wrapped package said ``encryption'', they'd be safe.
Amazing it is, that the US government has been just as naive, believing that a closed source product only did what the package said it would do. I wonder how much insight MS/Sun/Oracle/others have into what's going on behind those closed doors.
Never underestimate the power of human stupidity.
Well, I'm looking forward to seeing new OSS daemons from the white-house, and mails from randomuser@whitehouse.gov on LKML
From webster's: ...
Fail \Fail\v. i.
1. To be wanting; to fall short;
Linux doesn't want to dominate anyting, and therefore cannot fail in this task.
Java was hyped out to dominate the world, and for now it has failed.
It's incredible how reporters and others just can't seem to grasp that Linux doesn't have any need or desire to dominate, and therefore cannot fail in trying to do so.
``Total world domination'' was meant as a joke, but it's a lot more real that any of the hype surrounding Java. That is just a coincidence, not a goal.
> No, because C++ is a hybrid language, whereas Java is a pure OO language.
Exactly. And the world just isn't pure OO.
> Yes you can, with RMI.
Didn't know about that. Thanks.
> I don't see why this would be a bad thing?
Try writing a guidance system for a missile.
And try sleeping for two seconds while waiting for the GC to do it's job.
> No, it is not useless. It quarantees that machine X doesn't suddenly have 10 bits less in its floating points than machine Y. Also, there is also java.math which has classes for arbitrary-precision integer and decimal arithmetic.
You just don't have 10 bits of difference in the real world. The difference (between machines that would be likely to be on the same network) you usually see around one bit or so, and perhaps different rounding/truncation of numbers.
Numerical algorithms work because they know that they work with finite precision. Unifying the finite precision is outright dumb. You would get just as far, faster, by knowing your worst precision and using that as the unified precision.
Arbitrary precision floating point is nice, but it's something that can be in a library (or class if you like) just as well as in the language. I'm pretty indifferent to that. I guess there are plenty of libraries out there just for that, for almost any language one could imagine.
Another thing about Java is, that IMHO it is not at all such a nice language.
...
... a marketing phenomenon.
The concept of running on a virtual machine is nice, but there are problems.
Good features:
1) Threads in the language
2) Sockets in the language
3) Garbage collection
4) Homogenous environment on heterogenous architectures
Bad features:
0) It is not object oriented like C++, where you can choose to use object orientation when it fits the task at hand. You are _forced_ to use object orientation, always, everywhere.
2) You can easily communicate datastructures over the network. But you cannot (AFAIK) communicate the code. Why not ?? It's a virtual machine, distributing code over the network should be trivial.
3) You have garbage collection always, everywhere. Not just when it's a benefit, but again you're locked into it.
4) Floating point calculations are guaranteed to have same machine precision on all architectures. However, this is completely useless since numerical computations per definition are inaccurate, so all we have is an overhead from a feature with no use.
Sun invested an incredible amount of money and effort into marketing Java. Still, it is not the language that most people use when they need real work done. It's IMO a niche language. It has it's forces, but it's not a general purpose language.
To quote Bjarne Stroustrup:
Java is
That is, in my oppinion where Sun failed. If only Java had been a general purpose language, boy we'd be coding it today.
I hear it pretty often from people, that the Linux distributions are hard to install. Especially some feel that the lack of a GUI install makes it really hard.
I'm not understanding a bit of that. RedHat Linux (which I use) has the easiest install I've ever seen. And other distributions (Debian and Slack which I've also run) are good as well. The procedure is: Put in the boot floppy, answer the questions, and reboot.
You can install most Linux distributions using one or two floppies, and a network connection or a CD. Now why is that said to be hard ?
Especially in sharp contrast to the NT install, which I've also been thru quite a few times...
To install NT, you need the right kind of hardware (meaning ATAPI CD-rom and a motherboard that doesn't have controllers NT choke on (like NOT Asus P2B-DS)), you need DOS running and able to access the CD drive, and _then_ you can maybe start the GUI install. Wow!
I'm sure one can boot an NT install from CD, if one has the right hardware again, but still, the problems with unsupported devices and crap like that remain.
Besides, if you're an experienced Linux user, you can do a lot of clever tricks during the install, by using the shell which is available in most installers. You can never become experienced enough to do that under NT.
It's been some time since I installed Win95. In fact I've only really done it once. That one was fairly easy, given that I had the hard-drive partitioned correctly and all the right hardware.
Ever tried installing Win9X/NT on a disk that had a non-DOS partition ? Well, if you have you already know what I'm talking about.
Come on people. Entering the right IP address is no easier in a GUI than it is in ncurses.
I'm not pissed off about Caldera making a GUI install. I think it's nice. I'm just pissed off by the ignorance and unfounded accusations posed by lusers with too thick sunglasses.
'guess I'd better stop now...
I guess this proves that no matter how secure your platform is, the people who write the apps still need to have a clue about security.
It doesn't matter that UN*X or Linux are secure, when the apps that run on them aren't.
Except from removing sprintf/sscanf and friends from the C library, does anyone have any good ideas about what could possibly be done to increase the probability of some daemon being secure ?
Buffer overflows are a frequent coding error, but other exploits also happen (like much of the Java disasters in browsers previously). Also, simple design errors in an authentication sequence can cause the wrong people to get access, even if the code implements the intended algorithms perfectly.
One can write an insecure program in any language using any tools. But how can we seek to increase the probability that developers don't fall into these pits of insecure code writing ?
We still need C, we still need string handling, and since every system has it's own way of authenticating users, it seems there is little to be done at all.
Software RAID is usually faster than hardware RAID.
:)
It's also more flexible (think RAID of RAID of network block-devices).
It's also cheaper.
It has features that some hardware controllers don't even have (like background initialization).
What kind of idiot talks about software RAID without knowing jack about it ?
Mount the /home/httpd filesystem with the noatime mount option, then there will be no writes generated from read-accesses, and your ext2fs will effectively work as a ram-disk, if you have enough memory. Only, it's a helluwalot easier to just change stuff where it resides, and know it will be written to disk, instead of back-forth-copying tar images...
Second benefit: if you really get low on memory, you're fucked with a 1 Gig RAM disk, whereas the disk-cache will quickly be thrown away and used for whatever memory hog you have running.
ram-disks are good for booting over-modularized kernels _only_.