Look at the economics of the shuttle: we spend lots of money getting this 100-200 ton chunk of metal up there, with mostly non-reusable rockets one might add, and then--we bring it all down again, just to give our astronauts a nice plane-like landing (provided they don't blow up, that is). Given the per-pound cost of lifting stuff into orbit, anything that we should lift up there should contribute to some useful purpose and stay up there if at all possible. On top of all that, reentry with a "space plane" is very risky because they have lots of complicated surface geometries and need to reenter the atmosphere just right and probably with active control; with the slightest deviation, the whole thing blows up.
What we should do instead is launch with a traditional dumb rocket, and bring anything we need to bring back in a dumb, reliable, simple, and cheap Apollo/Soyuz-style return vehicle.
But, of course, none of this has anything to do with science, economics, or engineering anyway. If science, economics, and engineering were the driving factors, we'd stick to robotic probes for the next few decades. What this is really mostly about is getting money from the government to aerospace and defense contractors, and for a few politicians to build a monument to themselves.
At least some people have their heads on straight:
My idea of the most exciting exploration mission that we could do now, that NASA should be doing, is a Martian roving return vehicle. In other words, we put a vehicle down on the surface of Mars, and we direct it from Earth to drive around Mars and take samples and bring them back to Earth.
Now, that's something where I would like to see my tax-money go.
Magnetic tapes are a nuisance, and, worse, they don't last very long even if you store them well. Audio and video tapes have additional problems related to their consumer origins.
With IDE drives down to around $1/G, just go out and buy yourself a bunch of IDE drives for backup--they are a lot more reliable and a lot faster. Or, get a DVD-R: at 4.7G per side, it's not so different from a MiniDV, and they are bound to last longer than a MiniDV backup tape.
Europa is thought to be covered by an icy crust that is possibly miles deep and an ocean below that that is many more miles deep. It seems unlikely that even intense radiation on the surface would make it that far down. If anything, it might even drive the creation of chemicals near the surface that then become an energy source for life forms deeper in the ocean.
From traveling in Germany, my impression is that you are likely to be able to get DSL perhaps more easily than in the US. The computer stores also seemed to have comparable kinds of gadgets, at comparable prices, although technology still tends to be released in the US before Europe (but sometimes it's the other way around). In some technology areas, such as cell phones, Bluetooth, and wireless Internet access, it actually seems a bit better. Dial-up is also very easy, with a choice of no-subscription pay-as-you-go dial-ins and subscriber based services. Again, it seems like more choice than we get in the US.
The future is redundant, distributed systems. RAIDs are an example of this already: if you build a good RAID array out of commodity drives, you get better uptimes for less money than if you bought the most high-end, gold plated disk drive around. It also has happened with web servers already: "mission critical" web servers are now often implemented as a large collection of cheap Linux boxes with fail-over: if one goes down, a couple of customers may have to start their ordering process over again, but nobody else ever notices, and you just toss the box and plug in a new one.
The same is going to happen with databases. While there doesn't seem to be a good open source, distributed, redundant database for Linux yet, many people are already effectively building such databases out of MySQL. Yes, MySQL. You see, not only can the hardware be less than stellar in redundant, distributed systems, the software can be as well. And if you like a COTS solution for Linux, IBM already offers it.
Scalable databases will become as simple as buying a bunch of PCs with large disks, plugging them into a high-speed switch, and network-booting them. If you need more power or one breaks or goes down, you just plug in another one.
In the end, combining lots of redundant, cheap units gives you much better reliability for less money than the overly expensive and overly engineered "reliable servers". Because, no matter how reliable a single server may be, sooner or later it is going to break, even if it just because someone spills a comp of coffee into it. And the solution to that people are using right now? They are buying two very expensive high-end servers and use one as a hot standby.
I agree with that view, but perhaps a name change (UNIX to Linux) was bound to go along with that rewrite.
But perhaps Plan 9 from Bell Labs has a more direct claim on being the direct successor to UNIX. And, for better or for worse, I think Plan 9 embodies more directly a traditional clean, minimalist UNIX philosophy. That may not be as practical or comfortable to live in as Linux, but, then, neither were the traditional Bell Labs versions of UNIX.
It's a shame that the Plan 9 license is too restrictive for it to catch on much in the open source world, because it would be interesting to see how competitive it could be in the real world.
Out in the real world, rather than on Slashdot, "UNIX" is understood to be the AT&T derived systems shipped by companies like Sun, IBM, and HP. UNIX stands in contrast to Linux and other systems that may be POSIX-compliant and that you can port easily to, but that have a different lineage. If he had said "UNIX lives", refering to Linux, his IT management audience would have been very confused because that's not how they use the term "UNIX".
If it looks like UNIX, acts like UNIX and runs the source found on "legacy" UNIX systems, well, what is it?
We call that "UNIX compatible" or, possibly, "POSIX compliant".
Another question to ask, though, is: what do we do with companies that claim that their systems are "UNIX" but really are rather different beasts. For example, IBM's AIX has changed things so much that porting to it and administering it is somewhat of a headache. Linux is more UNIX-compatible than IBM's AIX. And the same is true for a number of other vendors that claim to be shipping "UNIX".
The chipset has to be different, but there is no need for the host interface to be different between b and g cards, or even differ between manufacturers. Why we still don't have a unified host interface for networking devices is beyond me.
because 802.11g doesn't officially exist yet. All those cards are prereleases based on draft standards. I don't think it's a good idea to buy those. My recommendation: wait until the standard is finalized, then wait for cards that have officially supported Linux drivers, then go buy one. You can probably still return the stuff you bought...
It does raise an interesting philosophical question, though: is it better to write a program that can easily be ported, or is it better to take advantage of the unique features of each platform?
I don't think it's a problem for Gtk+ or Qt--they are fast enough. It's only a problem when people claim that X11 needs to change because Gnome and KDE run more slowly than Windows. Unlike KDE/Qt, the Windows GUI is native and optimized only for Windows.
It is a problem with Java2D and Swing, parts of which are really too slow on Linux.
Still, while KDE and Gnome are nice for what they are, we really need a new, native X11 widget set, something that is well-optimized for X11 and takes advantage of features like multiple displays, application mobility, etc.
You're right--my bad--it does have more subwindows. It was late and I gave the wrong option to xwininfo; the actual picture is more complicated.
The point remains, though: Qt does not use X11 subwindows directly for rendering. For example, if you suspend Konqueror and wipe the contents of its window clean, almost nothing remains visible. Qt wraps a layer of classes and abstractions around X11, and there is no direct 1-1 correspondence between its model of the window system and X11. Also, its extensive use of theming and bitmaps imposes a high cost.
There is nothing wrong with doing any of that--X11 supports lots of programming styles--but it's a set of performance tradeoffs KDE/Qt choose to make, not X11.
Well, the site isn't responding, so I'm going by the summary... generally, tying a lot of drives together with LVM is not a good idea: in most cases, when any one drive fails, the entire "logical volume" that it is a part goes bad. And with 17 drives, one of them is bound to fail pretty soon.
If you need a really big file system spanning a lot of drives, use some form of RAID. Using LVM for spanninng volumes is mostly a band-aid, if you have run out of space and desparately need some additional space right now.
It must be reasonably efficient to operate on my hardware with the degree of responsiveness that I experience. [...] This is because it is more important to be able to diagnose and maintain a package over it's likely lifespan (5-10 years typically) than to save a few bytes of space or execution cycles.
I happen to agree. But apparently there are lots of people who complain that KDE and Gnome are so much slower than Windows, and they misattribute the overhead to X11. But it's KDE and Gnome that make this tradeoff, not X11.
I don't have a technical preference either, but I do have a user preference for KDE. On my machine it runs quicker, looks better, and is a rich environment to work with.
I find all available KDE themes rather ugly. For example, I find that the non-anti aliased rounded window corners clash badly with the anti-aliased drawing inside windows. Functionally, I find it's a toss-up: KDE has better "small" apps, while I find Gnome has better "big" apps.
I'm always willing to have another look.
I look at both of them periodically; Debian makes it really easy. Fortunately, they are as easy to remove as they are to install.
The consistency of the Windows environment is one of that platforms most compelling features.
Like the "most compelling anything" about Windows, that isn't saying much. Windows desktops typically use numerous different toolkits and interface conventions, it's just that people have gotten used to it.
Seems pretty damn quick on my PC. Beats Windows 2000 to the desktop by a good 2 minutes.
Yup, it's quick. That doesn't mean it's efficient, though, it just means that it is fast enough given current hardware.
30 seconds after I "startx".
Wow, given the relative speed of a Sun workstation of 1986 and the current desktops that makes it only about 100 times slower than the desktops back then.
I use both KDE and GNOME...
What's your point? I don't have a technical preference between them either.
OK, show me the app that is successful because it's not feature-rich.
The "i" applications from Apple, for example.
To argue that KDE has to become like GNOME to be more successful is quite retarded.
Yeah, so who argued that? Not me. I just find both Gnome and KDE generic, interchangeable, and dull. And that's just what they need to be in order to be successful. It's just funny to see either side argue that they are better than the other when both are so similar.
Yes it is. Simplicity is a feature too. Or are you confusing "feature" with "clickable thing" like so many people who argue against "features" do?
Petrely was talking about "clickable things", and I was simply using his terminology.
If [consistency] isn't a big deal to those people, then they won't mind if everything is consistent then, will they?
All things being equal, no, they wouldn't mind. But all things aren't equal: effort you spend on consistency won't be spent on other tasks. And you can't be consistent with everything at the same time.
Remote applications? That's something built into X, not specific to Motif.
As I was saying, KDE developers often don't even understand the issues... remote application usage isn't just about moving graphics from one screen to another, it's making configuration parameters, window management, and communications work correctly. Doing that requires toolkit and application support, but KDE and Qt don't even really try very hard.
Inter-app communication? Like DCOP and MCOP?
Yeah, that's the problem, like DCOP and MCOP.
Care to give an example?
Sure: the Konqueror window I'm looking at has about 50 distinct widgets and manipulable elements in it (buttons, menu entries, labels, scroll bars, icons, etc.), yet it only uses 7 distinct X11 subwindows. The intent of X11 was to use subwindows as a kind of structured graphics for building toolkits, but Qt and Gtk+ just do a whole lot of drawing inside big windows, and they have a whole lot of their own event processing logic. As an analogy, you can create graphics in PostScript by using its drawing commands, or you can create it by embedding a big bitmap. KDE/Qt and Gnome/Gtk+ are effectively doing the latter in a lot of cases.
And that's not necessarily a bad thing: Gnome and KDE are competing with Windows and OS X for users, so they should look and behave roughly like what common users expect.
However, some of Petrely's remarks are just silly. For example, he thinks that KDE being "more feature rich" is a good thing. Sorry, but that's not true. Having lots of features and buttons and widgets may work for some users, others may prefer something simpler, and yet others may want a different set of complex features. And while some users get all pushed out of shape about inconsistent appearances, consistency just isn't a big deal to many users either.
But what makes Gnome/Gtk+ and KDE/Qt both really lame in my book is that they don't take advantage of the really powerful and useful capabilities of X11. Motif and Xaw, for all their many and fatal faults, had better support for remote applications, customization, and inter-application communication than either Gnome or KDE. And Gtk+ and Qt both make very inefficient use of the X11 APIs, giving X11 an undeserved reputation for being slow. The Gnome and KDE developers don't even seem to understand what they are not doing, they are just complaining with some regularity that X11 is more cumbersome than Windows (which it is, if you try to program it like Windows).
As I was saying, I think both Gnome and KDE are ultimately good projects for Linux. I'm glad I have something simple and pretty to install on PCs for use by friends and family, something that, for better or for worse, works just like Windows and MacOS. But I also view them both as about equally "lame" from a technical point, and the differences between them seem minor compared to their common limitations.
At the lowest level, everything is just bitmaps, on Windows, MacOS, Fresco, Longhorn, etc. That's what the hardware supports.
Above that, there are graphics primitives. X11, GDI, and QuickDraw used to be based on pixel-oriented graphics primitives without the possibility of rescaling or anti-aliasing. Now, all of them have 2D rescaling and anti-aliasing.
Beyond that, Quartz and a few other window systems put retained structured graphics into the server. That is, you can tell the server to keep a bunch of vectors and textures and redraw it itself when needed without bothering you. That's nice to have, but it's not obvious why it should be in the display server.
On X11, that function happens to be left up to toolkits, and I think that's where it should remain. Many X11 toolkits already have excellent support for this, and with the Render extension in X11, the implementation and performance of those will improve.
However, if you really want retained structured graphics on X11, you can use the DisplayPostscript extension, which effectively gives you that (and that is very similar to what Quartz is).
Slashdot Mirror
What we should do instead is launch with a traditional dumb rocket, and bring anything we need to bring back in a dumb, reliable, simple, and cheap Apollo/Soyuz-style return vehicle.
But, of course, none of this has anything to do with science, economics, or engineering anyway. If science, economics, and engineering were the driving factors, we'd stick to robotic probes for the next few decades. What this is really mostly about is getting money from the government to aerospace and defense contractors, and for a few politicians to build a monument to themselves.
At least some people have their heads on straight:
Now, that's something where I would like to see my tax-money go.
With IDE drives down to around $1/G, just go out and buy yourself a bunch of IDE drives for backup--they are a lot more reliable and a lot faster. Or, get a DVD-R: at 4.7G per side, it's not so different from a MiniDV, and they are bound to last longer than a MiniDV backup tape.
Europa is thought to be covered by an icy crust that is possibly miles deep and an ocean below that that is many more miles deep. It seems unlikely that even intense radiation on the surface would make it that far down. If anything, it might even drive the creation of chemicals near the surface that then become an energy source for life forms deeper in the ocean.
802.1x for Linux? Use Google.
From traveling in Germany, my impression is that you are likely to be able to get DSL perhaps more easily than in the US. The computer stores also seemed to have comparable kinds of gadgets, at comparable prices, although technology still tends to be released in the US before Europe (but sometimes it's the other way around). In some technology areas, such as cell phones, Bluetooth, and wireless Internet access, it actually seems a bit better. Dial-up is also very easy, with a choice of no-subscription pay-as-you-go dial-ins and subscriber based services. Again, it seems like more choice than we get in the US.
The same is going to happen with databases. While there doesn't seem to be a good open source, distributed, redundant database for Linux yet, many people are already effectively building such databases out of MySQL. Yes, MySQL. You see, not only can the hardware be less than stellar in redundant, distributed systems, the software can be as well. And if you like a COTS solution for Linux, IBM already offers it.
Scalable databases will become as simple as buying a bunch of PCs with large disks, plugging them into a high-speed switch, and network-booting them. If you need more power or one breaks or goes down, you just plug in another one.
In the end, combining lots of redundant, cheap units gives you much better reliability for less money than the overly expensive and overly engineered "reliable servers". Because, no matter how reliable a single server may be, sooner or later it is going to break, even if it just because someone spills a comp of coffee into it. And the solution to that people are using right now? They are buying two very expensive high-end servers and use one as a hot standby.
But perhaps Plan 9 from Bell Labs has a more direct claim on being the direct successor to UNIX. And, for better or for worse, I think Plan 9 embodies more directly a traditional clean, minimalist UNIX philosophy. That may not be as practical or comfortable to live in as Linux, but, then, neither were the traditional Bell Labs versions of UNIX.
It's a shame that the Plan 9 license is too restrictive for it to catch on much in the open source world, because it would be interesting to see how competitive it could be in the real world.
If it looks like UNIX, acts like UNIX and runs the source found on "legacy" UNIX systems, well, what is it?
We call that "UNIX compatible" or, possibly, "POSIX compliant".
Another question to ask, though, is: what do we do with companies that claim that their systems are "UNIX" but really are rather different beasts. For example, IBM's AIX has changed things so much that porting to it and administering it is somewhat of a headache. Linux is more UNIX-compatible than IBM's AIX. And the same is true for a number of other vendors that claim to be shipping "UNIX".
The chipset has to be different, but there is no need for the host interface to be different between b and g cards, or even differ between manufacturers. Why we still don't have a unified host interface for networking devices is beyond me.
because 802.11g doesn't officially exist yet. All those cards are prereleases based on draft standards. I don't think it's a good idea to buy those. My recommendation: wait until the standard is finalized, then wait for cards that have officially supported Linux drivers, then go buy one. You can probably still return the stuff you bought...
...astrology. They'll probably set up a 900 number next: call in and let Lady AstraShake predict YOUR earthquake future.
Or, just get a head-mounted display and carry it with you (they are down to about $500 for VGA resolution).
Xemacs is at xemacs.org Look at the make-frame-on-device function and other functions related to frames and devices.
Yes, kind of like Xaw and Motif, just with more modern software engineering and easier extensibilty.
I don't think it's a problem for Gtk+ or Qt--they are fast enough. It's only a problem when people claim that X11 needs to change because Gnome and KDE run more slowly than Windows. Unlike KDE/Qt, the Windows GUI is native and optimized only for Windows.
It is a problem with Java2D and Swing, parts of which are really too slow on Linux.
Still, while KDE and Gnome are nice for what they are, we really need a new, native X11 widget set, something that is well-optimized for X11 and takes advantage of features like multiple displays, application mobility, etc.
The point remains, though: Qt does not use X11 subwindows directly for rendering. For example, if you suspend Konqueror and wipe the contents of its window clean, almost nothing remains visible. Qt wraps a layer of classes and abstractions around X11, and there is no direct 1-1 correspondence between its model of the window system and X11. Also, its extensive use of theming and bitmaps imposes a high cost.
There is nothing wrong with doing any of that--X11 supports lots of programming styles--but it's a set of performance tradeoffs KDE/Qt choose to make, not X11.
If you need a really big file system spanning a lot of drives, use some form of RAID. Using LVM for spanninng volumes is mostly a band-aid, if you have run out of space and desparately need some additional space right now.
I happen to agree. But apparently there are lots of people who complain that KDE and Gnome are so much slower than Windows, and they misattribute the overhead to X11. But it's KDE and Gnome that make this tradeoff, not X11.
I don't have a technical preference either, but I do have a user preference for KDE. On my machine it runs quicker, looks better, and is a rich environment to work with.
I find all available KDE themes rather ugly. For example, I find that the non-anti aliased rounded window corners clash badly with the anti-aliased drawing inside windows. Functionally, I find it's a toss-up: KDE has better "small" apps, while I find Gnome has better "big" apps.
I'm always willing to have another look.
I look at both of them periodically; Debian makes it really easy. Fortunately, they are as easy to remove as they are to install.
Like the "most compelling anything" about Windows, that isn't saying much. Windows desktops typically use numerous different toolkits and interface conventions, it's just that people have gotten used to it.
Seems pretty damn quick on my PC. Beats Windows 2000 to the desktop by a good 2 minutes.
Yup, it's quick. That doesn't mean it's efficient, though, it just means that it is fast enough given current hardware.
30 seconds after I "startx".
Wow, given the relative speed of a Sun workstation of 1986 and the current desktops that makes it only about 100 times slower than the desktops back then.
I use both KDE and GNOME...
What's your point? I don't have a technical preference between them either.
The "i" applications from Apple, for example.
To argue that KDE has to become like GNOME to be more successful is quite retarded.
Yeah, so who argued that? Not me. I just find both Gnome and KDE generic, interchangeable, and dull. And that's just what they need to be in order to be successful. It's just funny to see either side argue that they are better than the other when both are so similar.
Petrely was talking about "clickable things", and I was simply using his terminology.
If [consistency] isn't a big deal to those people, then they won't mind if everything is consistent then, will they?
All things being equal, no, they wouldn't mind. But all things aren't equal: effort you spend on consistency won't be spent on other tasks. And you can't be consistent with everything at the same time.
Remote applications? That's something built into X, not specific to Motif.
As I was saying, KDE developers often don't even understand the issues... remote application usage isn't just about moving graphics from one screen to another, it's making configuration parameters, window management, and communications work correctly. Doing that requires toolkit and application support, but KDE and Qt don't even really try very hard.
Inter-app communication? Like DCOP and MCOP?
Yeah, that's the problem, like DCOP and MCOP.
Care to give an example?
Sure: the Konqueror window I'm looking at has about 50 distinct widgets and manipulable elements in it (buttons, menu entries, labels, scroll bars, icons, etc.), yet it only uses 7 distinct X11 subwindows. The intent of X11 was to use subwindows as a kind of structured graphics for building toolkits, but Qt and Gtk+ just do a whole lot of drawing inside big windows, and they have a whole lot of their own event processing logic. As an analogy, you can create graphics in PostScript by using its drawing commands, or you can create it by embedding a big bitmap. KDE/Qt and Gnome/Gtk+ are effectively doing the latter in a lot of cases.
However, some of Petrely's remarks are just silly. For example, he thinks that KDE being "more feature rich" is a good thing. Sorry, but that's not true. Having lots of features and buttons and widgets may work for some users, others may prefer something simpler, and yet others may want a different set of complex features. And while some users get all pushed out of shape about inconsistent appearances, consistency just isn't a big deal to many users either.
But what makes Gnome/Gtk+ and KDE/Qt both really lame in my book is that they don't take advantage of the really powerful and useful capabilities of X11. Motif and Xaw, for all their many and fatal faults, had better support for remote applications, customization, and inter-application communication than either Gnome or KDE. And Gtk+ and Qt both make very inefficient use of the X11 APIs, giving X11 an undeserved reputation for being slow. The Gnome and KDE developers don't even seem to understand what they are not doing, they are just complaining with some regularity that X11 is more cumbersome than Windows (which it is, if you try to program it like Windows).
As I was saying, I think both Gnome and KDE are ultimately good projects for Linux. I'm glad I have something simple and pretty to install on PCs for use by friends and family, something that, for better or for worse, works just like Windows and MacOS. But I also view them both as about equally "lame" from a technical point, and the differences between them seem minor compared to their common limitations.
Above that, there are graphics primitives. X11, GDI, and QuickDraw used to be based on pixel-oriented graphics primitives without the possibility of rescaling or anti-aliasing. Now, all of them have 2D rescaling and anti-aliasing.
Beyond that, Quartz and a few other window systems put retained structured graphics into the server. That is, you can tell the server to keep a bunch of vectors and textures and redraw it itself when needed without bothering you. That's nice to have, but it's not obvious why it should be in the display server.
On X11, that function happens to be left up to toolkits, and I think that's where it should remain. Many X11 toolkits already have excellent support for this, and with the Render extension in X11, the implementation and performance of those will improve.
However, if you really want retained structured graphics on X11, you can use the DisplayPostscript extension, which effectively gives you that (and that is very similar to what Quartz is).