Keith Packard's transparency server will attempt to notify windows when they need to redraw because a window underneath has changed (this isn't normally communicated because when the protocol was developed, it was assumed to be redundant).
There are two choices for dealing with transparency: either applications redraw their layers when any layer changes, or the server keeps bitmaps or vectors around and does the drawing compositing itself. Those are the same choices you have for any kind of redrawing.
X11 has always offered both choices, and it will likely also offer both for transparency. That is, if you tell the server to keep the bitmaps around for window contents, it won't ask applications to redraw--it will just do the compositing itself. If you tell the server not to eat up resources by keeping bitmaps around, it will ask applications to redraw.
Berlin simplifies its world by only giving you the simpler version of the two, where the server does the work. That's nice for many uses, but it isn't always the best choice.
Berlin also abstracts the pixels on the screen and lets developers deal with sizes in plain distance measurements. An icon that is one inch tall will always be one inch tall (it may be x or y pixels high though). SVG icon support will go into KDE, but XFree86 will still be pixel-based.
Again, you are confusing levels. At some level, Berlin has to deal with pixels as well: that's what the hardware has. At a slightly higher level, it provides rescaling and anti-aliasing. Those two levels are what X11 provides. Beyond that, it's not X11's business, it's the toolkits business. Some X11 toolkits provide resolution independence, although it hasn't been very popular because screens still aren't high resolution enough to make it work well.
Applications and toolkits are supposed to support moving windows between displays, and a few do (XEmacs is one of them).
X toolkits were going in that direction, but all of that was short circuited by the invasion of cross-platform toolkits like Qt, wxWindows, FLTK, and others, as well as X toolkits that might as well be cross-platform, like Gtk+ and Tcl/Tk. Those toolkits barely have a notion of remote applications, let alone multiple displays or moving between displays.
However, until then, there are workarounds. In particular, there is something called "xmove"; look for it on the web. It's a bit tricky to set up initially, but once you have figured it out, it works quite well. There are also X11 servers that have a built-in notion of moving applications between displays.
In the long run, we really need a modern, well-designed X11 toolkit that takes full advantage of X11's capabilities, including application mobility; the current crop of pretty-but-simplistic toolkits just don't fit the bill. I think efforts in that direction have started.
Re:Windows/OS X architecture is similar to X11
on
XFree86 4.3.0 Released
·
· Score: 3, Insightful
I haven't much experience with OSX, but with Windows... KDE/Gnome/Windowmaker
all feel klunky with dealing with any type of object (window, icon, pointer). [...] And even with the (older and) newer Xfree86'es, I STILL have the "page tear effect" in many applications. Even in Mozilla. I'm sure I'm not the only one (and if I am, how do I fix that)?
So, KDE/Gnome/Mozilla are clunky. Let's add Java to the mix, too. You won't get any argument from me there. Those toolkits rely heavily and unnecessarily on bitmaps. They are effectively written with a local direct drawing model in mind. They fail to use the X11 APIs properly in many ways. And that's not really so surprising: KDE, Mozilla, and Java all use cross-platform toolkits, and they have been designed primarily around Microsoft's APIs and Microsoft's performance characteristics, with X11 support kind of as an afterthought.
I also know
that X wastes a bunch on bandwidth that Tight VNX saves. Try that
"oh-so-nice-network-transparency" over a modem. I have, and it sucks compared to
how snappy a 640x480 8bit black background screen transfers over EVEN regular
VNC.
The default X11 protocol is optimized for minimizing CPU usage and latencies assuming LAN-speed connections. That's the environment people are using it in, and that's the environment it has been successful in for 20 years.
X11 does not try to minimize network traffic. If you want to run X11 over slow connections, you need an X protocol compressor. One comes built into your X11 server, but you need to enable it (lbx).
And there is nothing wrong with using VNC--it's a great system. It simply isn't a network transparent window system, it's a remote display--different function and different application.
still stand by what I said. Go get a copy of WIn98, and a feature-equilavalent copy of Linux with X and managers.
Well, and I say: you are wrong. I have run X11 and Windows 95 on the same hardware, I have run X11 and Windows 98 on the same hardware, and I'm running X11 and Windows XP on the same hardware. X11 has always been competitive with Windows, and usually beat it, in actual measurements as well as "feel".
Still, why didnt you approach the 3-D issue? 3-d's dog slow, even on supported
hardware (eg: nVidia).
What's there to address? 3D games under X11 don't involve the X11 protocol, they use DRI (the equivalent of Direct3D). If that is slow, it's a problem with the 3D drivers or the game, it has nothing to do with X11. Basically, this claim is characteristic of your reasoning: something doesn't work, and you blame X11. I have to say, I have run all versions of Quake on Linux and have had comparable frame rates to running it under Windows.
But to what you accuse me of, it's MY fault X runs slow....
It's your fault to make bogus comparisons. Face it, Linux is still largely unsupported, and it is certainly unsupported on Windows 98-style hardware. It's not suprising that you might configure your machine less than optimally or that your drivers aren't very good. Most people aren't bothered by that, since it runs fast enough, but if you are going to nit-pick about performance, you have to nit-pick about your own installation as well.
Likewise, a lot of GUI developers (KDE, Gnome, etc.) come to X11 without knowing much about X11 or understanding how it works. It isn't surprising that they produce inefficient or sluggish code.
But we know X11 can run fast. You said so yourself: you found it responsive on a 120MHz SPARC, hardware that it is actually supported on.
If you want X11 to run fast under Linux, either figure out how to configure it properly and buy the right hardware for it, or go out and pay the money for a commercially supported version with drivers that were written with access to closed hardware specs.
Are you sure it's not your KVM? Most good KVMs emulate the keyboard and mouse to the computer so that the computer never even sees any switch. If anything changes from the point of view of your computer, then the KVM screwed up and there is nothing the X server can do.
What does Berlin give me that I don't get with X11? I mean, you may or may not think that its architecture is better (I think it's considerably worse), but architecture doesn't interest the user. You may also think that, in theory, its performance might end up being better, but the proof is in the pudding. In terms of functionality, I don't see any new and exciting capabilities. Until a couple of years ago, Berlin promised transparency, but X11 has that now.
I think anything to replace X11 will have to offer some really exciting new capabilities that can't be added to X11. And I see nothing on the horizon that does that.
Maybe you need to update your copy of Quake 3. I have run Quake 3 with several different XFree86 servers and never had a problem.
Windows/OS X architecture is similar to X11
on
XFree86 4.3.0 Released
·
· Score: 4, Insightful
My overall performance isnt worth "network transparency".
Well, so tell us: in what way are Windows or Macintosh OS X supposed to be more efficient? Where are these great gains in efficiency in their architecture supposed to come from? I mean, it can't be the use of IPC or system calls for the application to communicate with a graphics server: Windows and Macintosh have that as well.
In reality, there is no fundamental difference in the client/server window system architecture between OS X and Linux. For NT, there is a difference: large chunks of the windowing code have moved into the kernel ad some point, but you still need system calls to talk to it. Of course, there is nothing to stop anybody from moving X11 into the kernel.
Overall, the idea that network transparency is some sort of special feature that one pays a high price for is nonsense: all major desktop operating systems run in protected mode, and most GUI applications run in a different context from the window system. X11 simply has been designed that way from the ground up, while Windows and Macintosh have evolved there from "direct mode" graphics. Network transparency in X11 is not so much an issue of IPC or how it does graphics--it uses IPC like all desktop windowing systems--but in having well-defined network transparent support for features like window management and configuration information. It's lack of those features in Windows and OS X that means that Windows and OS X are not network transparent.
In practice, XFree86 is a damned efficient window system that, when it has comparable drivers for the graphics cards, beats OS X handily in terms of performance and memory usage, and usually even beats Windows.
You need screen on another computer, use TightVNC.
TightVNC gives you a "screen on another computer". It does not give you network transparent windowing. If you are running a well-designed X11 desktop, you can run applications on any machine, and they will behave as if run locally. You can also move individual windows between machines and displays. Of course, Gnome and KDE both break this behavior, but that's not X11's fault.
MSWindows 98 is snappy, even on quite old hardware. XFree runs like shit. It feels klunky and laggy.
That's a ludicrous claim. X11 worked reasonably well on 1988 hardware already. X11 servers obviously can run like a charm on 1998 hardware, hardware that's more than an order of magnitude faster.
And that's also what one finds in practice: Windows 98 requires much more hardware (memory, CPU power) to run than Linux/XFree86. If you claim were having a problem with Linux/XFree86, either you are making it up, or you had a bad driver, or you misconfigured something.
This actually makes a great Beowulf cluster machine: it's small, it's cheap, and it takes standard components. Just about the only thing that's extraneous is the keyboard, but that's kind of nice for maintenance.
So get over it. Not only is Mac OS X a real, true, complete Unix,
You are arguing semantics. I'm arguing functionality. Porting UNIX programs to OS X can be a lot of work, much more than to just about any other platform that claims to be UNIX-compatible. A UNIX kernel hacker coming to Darwin has to start learning from scratch because its architecture is so different. X11 on OS X is rather inefficient. Multimedia works differently. Etc. Etc. OS X just doesn't function like a "true, complete Unix". It's a good approximation, but no more.
I especially like your idea that X11 is bolted on to OS X. Damn, dude, X11 is "bolted on" to every Unix!
On OS X, X11 runs on top of, and in parallel with, the existing Mac window system. Normally, X11 has sole and complete control of the frame buffer, graphics hardware, and accelerator.
due to its incredible shipping volume, it is now THE UNIX.
Oh? Do you have any numbers to back that up that claim?
Given the realities of the market and who ends up paying for drugs, it turns out to be cheaper for drugs to be developed through government research and then manufactured generically. If private companies develop the drugs, the public doesn't need to pay for drug development directly, but the public ends up paying many times over in terms of higher drug prices.
Another problem with private development of drugs is that market forces cause the development of the wrong kinds of drugs: you get dozens of redundant designer anti-allergy drugs, but less common diseases don't get addressed.
Research is something the government has demonstrated they are good and efficient at. And, in fact, a lot of private drug research is still partially supported by the government anyway.
Disclosing the source code to the US government hurts national security, disclosing the source code to the Chinese government improves it.
You see, being exposed to Windows source code gives programmers a killer headache, and after having seen it, they'll never be able to write a secure piece of code themselves.
It takes a lot of bookkeeping in the background to assign different tasks to different CPUs. Not to mention programs need to be written multi-threaded to take advantage of another processor.
There are lots of ways of using multiple processors for computations; threads is only one of them, and probably among the most cumbersome.
One Fast CPU is always going to have an advantage over multiple slower CPUs.
If that were true, the fastest computers would be like the supercomputers of the past. But multi-processor designs and compute clusters have pretty much killed the supercomputers of the past.
You are still missing the point. The point isn't whether these things can be safe--they obviously can be. The question is whether NASA can be trusted to make them safe. All it takes is a single screw-up, like using the wrong kind of weld or material, for the thing to blow up. This is an organization under stress, under budgetary constraints, and that just scattered a space shuttle across half a dozen states.
And that's why I'm glad that organizations like Greenpeace are holding NASA's feet to the fire, just as much as I'm going to be glad when the Kuiper express is on its way to Pluto with its--very thoroughly scrutinized--RTG.
In which scientific report did you read that stated several kilograms of plutonium in an RTG could kill thousands of people??? Before replying (if you reply) check out this site [nasa.gov]. Here's a direct quote on its safety design:
Look, you are satisfied with the safety of a NASA design based on a NASA and DOE press release. Come on, doesn't that strike you as silly?
What I'm saying is: neither of us is qualified to determine whether these designs are safe. And given NASA's recent track record, I simply do not trust them to make the call by themselves--they have screwed up too much. I'm glad that Greenpeace and lots of other organizations scrutinize, pressure, and protest: it will hopefully get NASA to take more precautions than they seem to be capable of by themselves.
As for the general question of plutonium toxicity, don't take my word for it, look at the CDC site. Or, even take the plutonium-friendly LLNL report, which, in whatever way you look at it, ultimately does argue that there can be around a thousand deaths per kilogram of plutonium released over, say, Munich. But it, like you, assumes that if the additional risk is small compared to other risks, the additional deaths just don't count.
Well, for scientific users the debate about which platform to use has *significantly* been mitigated by the presence of a true UNIX with OS X allowing for the easy porting and running of code already written for other *nix distros.
While UNIX compatibility in OS X is great, calling it a "true UNIX" is really rather misleading. First of all, the kernel isn't a UNIX kernel, it's a hacked Mach kernel with a BSD compatibility layer. Furthermore, there are very significant differences in userland, including things like a case-insensitive file system, huge changes in system administration, lack of device nodes for things like audio and video, multiple views of the file system (from Carbon/UNIX), etc. Also, the standard UNIX window system, X11, is at best bolted onto OS X.
Now, you may think all these things are improvements to UNIX, and you might be right. However, they make OS X pretty significantly different from UNIX. And while some applications port with no problems to OS X, others require incorporating Cocoa or Carbon code for porting, which can be a lot of effort.
It simply comes down to this: a 1GHz G4 is roughly comparable to a 1GHz P3 on the SPEC benchmarks, which are actually pretty representative of real-world applications. So, ask yourself: would you still be running a 1GHz P3? Would you consider that fast? I wouldn't.
Apple is way behind in terms of performance. That doesn't matter for desktop use. But don't buy a 1GHz G4 (or a dual 1GHz G4) and expect to get a lot of bang for the buck.
Did Newton owners choose wrong or were they simply ahead of the curve?
Read about the history of pen based computing here. Basically, the Newton seems in part an attempt to commecialize aspects of Alan Kay's vision of the Dynabook, and most of the technology had been previously explored, going back to the 1960's.
Heat shields are incredibly simple devices as well, yet NASA managed to construct a space shuttle around them that had so many different modes of disintegrating on re-entry that we still don't know which one to pick.
(as someone pointed out, about 26 people consumed a "lethal" dose of plutonium during the Manhattan Project and yet virtually all of them lived to see old age (above the statistical average in fact)).
That is not inconsistent with the fact that plutonium is a very dangerous poison. If it causes one death in a thousand, you would expect that a group of physicists would live longer than average, while in a city of 10 million, 10000 additional people would die from the exposure. (Also, it's inhaling plutonium that you have to worry about.) If an RTG disintegrates on re-entry, it will almost certainly not kill you or me or anybody else in particular; I'm more likely to be killed by a speeding truck. But it will probably kill lots of people nonetheless.
Basically, you seem to subscribe to the notion that it's perfectly fine to kill thousands or tens of thousands of people as long as nobody knows that you did--otu of sight out of mind. I worry that NASA does the same. Of course, we already know that the DOE and the US military subscribe to that notion and act accordingly. But why add to the problem?
They are sort of like the black boxes in airplanes that can survive virtually any impact/heat/etc (they're designed to withstand orbit re-entries, explosions, etc.).
Yes, if they are designed correctly. The question is whether NASA and their contractors are capable of designing something like that correctly.
Even if that's not enough for you, they don't actually carry that much radiation. I read a report a long time ago that if a RTG vaporized directly over a large city, it would be the equivalent of everyone outside getting a tan.
Well, let's say that that is true. If everybody went outside and got a tan, then that would probably result in dozens of additional deaths. Just because it's hard to attribute those deaths to a specific action doesn't mean that they don't happen.
But that's not even true. The total dose of radiation may be low, but the problem is that you receive in places like the inside of your lung.
Dispersing Plutonium in the atmosphere does not cause instant death, and it does not empty whole city blocks. It's probably not much different from atmospheric nuclear tests. If an accident were to happen, nobody would notice. In fact, military RTGs may have blown up left and right and nobody would know. What it will do is increase cancer rates slightly and over a long period of time. But why do people have this twisted notion that if you kill thousands of people through something invisible that takes years to kill, it is any better than lining up the people against a wall and shooting them?
As I was saying: RTGs can be made safe, but I have little confidence that NASA knows how to make them safe or really cares much. In fact, I have strong suspicions that NASA's attitude towards the issue is as irrational and cavalier as yours. And that's why I hope that their designs will be carefully reviewed by others.
Matlab and Mathematica are widely used, but they probably are "worst of breed". Both are based on haphazardly designed languages with flaky implementations. And when you graduate, you'll discover that in the real world, those packages are also hugely expensive.
Pick up some better tools than that. For numerical stuff, consider Numerical Python. For symbolic math, Maxima is probably still better, although it has a very steep learning curve; but I have rarely found symbolic math program useful at all--usually, a good change of variables makes the derivation simple.
At issue is not whether RTGs can be made safe in principle--they can. But after the spectacular failures of NASA over the last couple of decades, as well as getting more insight into the kinds of stupid safety and engineering decisions NASA and their contractors seem to be making, I am not convinced that NASA can put together a reasonably safe RTG. A scenario where the probe blows up some time during launch and a poorly designed RTG just vaporizes seems quite possible given NASA's other failures. I hope NASA's designs will be very carefully reviewed and audited by outsiders because this is a matter that affects everybody.
If you want to talk about priorities, let's talk about the US defense budget: hundreds of billions of dollars per year, and it doesn't make the world a safer place. Or take the S/L bailout. Or take the corporate tax breaks for Microsoft. Or...
If you are looking for general purpose tools for numerical computing, Numerical Python and Scientific Python are excellent choices, possibly with VTK for visualization (search on Google; the projects are on Sourceforge). Octave is a Matlab clone, although, like Matlab itself, rather limited. The R system (www.r-project.org) is probably the best statistical system around and produces great plots. And for interactive symbolic math, Maxima is still very good (and you can use "texmacs" as a nicer interface to it).
Don't underestimate the power of C++: with type checking and overloading, C++ may actually be more convenient to use for many numerical applications that even something like Numerical Python or Octave/Matlab.
Beyond that, yes, obviously, all those libraries are in use by someone if they are maintained. If you have the need to use one of them, you will know. If not, don't worry about it.
Well, if the poor graphics of a game is the special thing it can't loose, the game surely isn't for me.
Yes, in roughly the same way that the poor graphics of, oh, say Ulysses or the Iliad are the "special thing" those works can't easily lose. That doesn't stop people from making the movie version--light on content but heavy on graphics. And you already have that for NetHack--just get Diablo.
Slashdot Mirror
There are two choices for dealing with transparency: either applications redraw their layers when any layer changes, or the server keeps bitmaps or vectors around and does the drawing compositing itself. Those are the same choices you have for any kind of redrawing.
X11 has always offered both choices, and it will likely also offer both for transparency. That is, if you tell the server to keep the bitmaps around for window contents, it won't ask applications to redraw--it will just do the compositing itself. If you tell the server not to eat up resources by keeping bitmaps around, it will ask applications to redraw.
Berlin simplifies its world by only giving you the simpler version of the two, where the server does the work. That's nice for many uses, but it isn't always the best choice.
Berlin also abstracts the pixels on the screen and lets developers deal with sizes in plain distance measurements. An icon that is one inch tall will always be one inch tall (it may be x or y pixels high though). SVG icon support will go into KDE, but XFree86 will still be pixel-based.
Again, you are confusing levels. At some level, Berlin has to deal with pixels as well: that's what the hardware has. At a slightly higher level, it provides rescaling and anti-aliasing. Those two levels are what X11 provides. Beyond that, it's not X11's business, it's the toolkits business. Some X11 toolkits provide resolution independence, although it hasn't been very popular because screens still aren't high resolution enough to make it work well.
X toolkits were going in that direction, but all of that was short circuited by the invasion of cross-platform toolkits like Qt, wxWindows, FLTK, and others, as well as X toolkits that might as well be cross-platform, like Gtk+ and Tcl/Tk. Those toolkits barely have a notion of remote applications, let alone multiple displays or moving between displays.
However, until then, there are workarounds. In particular, there is something called "xmove"; look for it on the web. It's a bit tricky to set up initially, but once you have figured it out, it works quite well. There are also X11 servers that have a built-in notion of moving applications between displays.
In the long run, we really need a modern, well-designed X11 toolkit that takes full advantage of X11's capabilities, including application mobility; the current crop of pretty-but-simplistic toolkits just don't fit the bill. I think efforts in that direction have started.
So, KDE/Gnome/Mozilla are clunky. Let's add Java to the mix, too. You won't get any argument from me there. Those toolkits rely heavily and unnecessarily on bitmaps. They are effectively written with a local direct drawing model in mind. They fail to use the X11 APIs properly in many ways. And that's not really so surprising: KDE, Mozilla, and Java all use cross-platform toolkits, and they have been designed primarily around Microsoft's APIs and Microsoft's performance characteristics, with X11 support kind of as an afterthought.
I also know that X wastes a bunch on bandwidth that Tight VNX saves. Try that "oh-so-nice-network-transparency" over a modem. I have, and it sucks compared to how snappy a 640x480 8bit black background screen transfers over EVEN regular VNC.
The default X11 protocol is optimized for minimizing CPU usage and latencies assuming LAN-speed connections. That's the environment people are using it in, and that's the environment it has been successful in for 20 years.
X11 does not try to minimize network traffic. If you want to run X11 over slow connections, you need an X protocol compressor. One comes built into your X11 server, but you need to enable it (lbx).
And there is nothing wrong with using VNC--it's a great system. It simply isn't a network transparent window system, it's a remote display--different function and different application.
still stand by what I said. Go get a copy of WIn98, and a feature-equilavalent copy of Linux with X and managers.
Well, and I say: you are wrong. I have run X11 and Windows 95 on the same hardware, I have run X11 and Windows 98 on the same hardware, and I'm running X11 and Windows XP on the same hardware. X11 has always been competitive with Windows, and usually beat it, in actual measurements as well as "feel".
Still, why didnt you approach the 3-D issue? 3-d's dog slow, even on supported hardware (eg: nVidia).
What's there to address? 3D games under X11 don't involve the X11 protocol, they use DRI (the equivalent of Direct3D). If that is slow, it's a problem with the 3D drivers or the game, it has nothing to do with X11. Basically, this claim is characteristic of your reasoning: something doesn't work, and you blame X11. I have to say, I have run all versions of Quake on Linux and have had comparable frame rates to running it under Windows.
But to what you accuse me of, it's MY fault X runs slow....
It's your fault to make bogus comparisons. Face it, Linux is still largely unsupported, and it is certainly unsupported on Windows 98-style hardware. It's not suprising that you might configure your machine less than optimally or that your drivers aren't very good. Most people aren't bothered by that, since it runs fast enough, but if you are going to nit-pick about performance, you have to nit-pick about your own installation as well.
Likewise, a lot of GUI developers (KDE, Gnome, etc.) come to X11 without knowing much about X11 or understanding how it works. It isn't surprising that they produce inefficient or sluggish code.
But we know X11 can run fast. You said so yourself: you found it responsive on a 120MHz SPARC, hardware that it is actually supported on.
If you want X11 to run fast under Linux, either figure out how to configure it properly and buy the right hardware for it, or go out and pay the money for a commercially supported version with drivers that were written with access to closed hardware specs.
Are you sure it's not your KVM? Most good KVMs emulate the keyboard and mouse to the computer so that the computer never even sees any switch. If anything changes from the point of view of your computer, then the KVM screwed up and there is nothing the X server can do.
I think anything to replace X11 will have to offer some really exciting new capabilities that can't be added to X11. And I see nothing on the horizon that does that.
Maybe you need to update your copy of Quake 3. I have run Quake 3 with several different XFree86 servers and never had a problem.
Well, so tell us: in what way are Windows or Macintosh OS X supposed to be more efficient? Where are these great gains in efficiency in their architecture supposed to come from? I mean, it can't be the use of IPC or system calls for the application to communicate with a graphics server: Windows and Macintosh have that as well.
In reality, there is no fundamental difference in the client/server window system architecture between OS X and Linux. For NT, there is a difference: large chunks of the windowing code have moved into the kernel ad some point, but you still need system calls to talk to it. Of course, there is nothing to stop anybody from moving X11 into the kernel.
Overall, the idea that network transparency is some sort of special feature that one pays a high price for is nonsense: all major desktop operating systems run in protected mode, and most GUI applications run in a different context from the window system. X11 simply has been designed that way from the ground up, while Windows and Macintosh have evolved there from "direct mode" graphics. Network transparency in X11 is not so much an issue of IPC or how it does graphics--it uses IPC like all desktop windowing systems--but in having well-defined network transparent support for features like window management and configuration information. It's lack of those features in Windows and OS X that means that Windows and OS X are not network transparent.
In practice, XFree86 is a damned efficient window system that, when it has comparable drivers for the graphics cards, beats OS X handily in terms of performance and memory usage, and usually even beats Windows.
You need screen on another computer, use TightVNC.
TightVNC gives you a "screen on another computer". It does not give you network transparent windowing. If you are running a well-designed X11 desktop, you can run applications on any machine, and they will behave as if run locally. You can also move individual windows between machines and displays. Of course, Gnome and KDE both break this behavior, but that's not X11's fault.
MSWindows 98 is snappy, even on quite old hardware. XFree runs like shit. It feels klunky and laggy.
That's a ludicrous claim. X11 worked reasonably well on 1988 hardware already. X11 servers obviously can run like a charm on 1998 hardware, hardware that's more than an order of magnitude faster.
And that's also what one finds in practice: Windows 98 requires much more hardware (memory, CPU power) to run than Linux/XFree86. If you claim were having a problem with Linux/XFree86, either you are making it up, or you had a bad driver, or you misconfigured something.
This actually makes a great Beowulf cluster machine: it's small, it's cheap, and it takes standard components. Just about the only thing that's extraneous is the keyboard, but that's kind of nice for maintenance.
Think of it as the Commodore-64 with a Pentium 4: low-cost, built into the keyboard, and no screen.
You are arguing semantics. I'm arguing functionality. Porting UNIX programs to OS X can be a lot of work, much more than to just about any other platform that claims to be UNIX-compatible. A UNIX kernel hacker coming to Darwin has to start learning from scratch because its architecture is so different. X11 on OS X is rather inefficient. Multimedia works differently. Etc. Etc. OS X just doesn't function like a "true, complete Unix". It's a good approximation, but no more.
I especially like your idea that X11 is bolted on to OS X. Damn, dude, X11 is "bolted on" to every Unix!
On OS X, X11 runs on top of, and in parallel with, the existing Mac window system. Normally, X11 has sole and complete control of the frame buffer, graphics hardware, and accelerator.
due to its incredible shipping volume, it is now THE UNIX.
Oh? Do you have any numbers to back that up that claim?
Another problem with private development of drugs is that market forces cause the development of the wrong kinds of drugs: you get dozens of redundant designer anti-allergy drugs, but less common diseases don't get addressed.
Research is something the government has demonstrated they are good and efficient at. And, in fact, a lot of private drug research is still partially supported by the government anyway.
You see, being exposed to Windows source code gives programmers a killer headache, and after having seen it, they'll never be able to write a secure piece of code themselves.
There are lots of ways of using multiple processors for computations; threads is only one of them, and probably among the most cumbersome.
One Fast CPU is always going to have an advantage over multiple slower CPUs.
If that were true, the fastest computers would be like the supercomputers of the past. But multi-processor designs and compute clusters have pretty much killed the supercomputers of the past.
And that's why I'm glad that organizations like Greenpeace are holding NASA's feet to the fire, just as much as I'm going to be glad when the Kuiper express is on its way to Pluto with its--very thoroughly scrutinized--RTG.
Look, you are satisfied with the safety of a NASA design based on a NASA and DOE press release. Come on, doesn't that strike you as silly?
What I'm saying is: neither of us is qualified to determine whether these designs are safe. And given NASA's recent track record, I simply do not trust them to make the call by themselves--they have screwed up too much. I'm glad that Greenpeace and lots of other organizations scrutinize, pressure, and protest: it will hopefully get NASA to take more precautions than they seem to be capable of by themselves.
As for the general question of plutonium toxicity, don't take my word for it, look at the CDC site. Or, even take the plutonium-friendly LLNL report, which, in whatever way you look at it, ultimately does argue that there can be around a thousand deaths per kilogram of plutonium released over, say, Munich. But it, like you, assumes that if the additional risk is small compared to other risks, the additional deaths just don't count.
While UNIX compatibility in OS X is great, calling it a "true UNIX" is really rather misleading. First of all, the kernel isn't a UNIX kernel, it's a hacked Mach kernel with a BSD compatibility layer. Furthermore, there are very significant differences in userland, including things like a case-insensitive file system, huge changes in system administration, lack of device nodes for things like audio and video, multiple views of the file system (from Carbon/UNIX), etc. Also, the standard UNIX window system, X11, is at best bolted onto OS X.
Now, you may think all these things are improvements to UNIX, and you might be right. However, they make OS X pretty significantly different from UNIX. And while some applications port with no problems to OS X, others require incorporating Cocoa or Carbon code for porting, which can be a lot of effort.
Apple is way behind in terms of performance. That doesn't matter for desktop use. But don't buy a 1GHz G4 (or a dual 1GHz G4) and expect to get a lot of bang for the buck.
Read about the history of pen based computing here. Basically, the Newton seems in part an attempt to commecialize aspects of Alan Kay's vision of the Dynabook, and most of the technology had been previously explored, going back to the 1960's.
Heat shields are incredibly simple devices as well, yet NASA managed to construct a space shuttle around them that had so many different modes of disintegrating on re-entry that we still don't know which one to pick.
(as someone pointed out, about 26 people consumed a "lethal" dose of plutonium during the Manhattan Project and yet virtually all of them lived to see old age (above the statistical average in fact)).
That is not inconsistent with the fact that plutonium is a very dangerous poison. If it causes one death in a thousand, you would expect that a group of physicists would live longer than average, while in a city of 10 million, 10000 additional people would die from the exposure. (Also, it's inhaling plutonium that you have to worry about.) If an RTG disintegrates on re-entry, it will almost certainly not kill you or me or anybody else in particular; I'm more likely to be killed by a speeding truck. But it will probably kill lots of people nonetheless.
Basically, you seem to subscribe to the notion that it's perfectly fine to kill thousands or tens of thousands of people as long as nobody knows that you did--otu of sight out of mind. I worry that NASA does the same. Of course, we already know that the DOE and the US military subscribe to that notion and act accordingly. But why add to the problem?
Yes, if they are designed correctly. The question is whether NASA and their contractors are capable of designing something like that correctly.
Even if that's not enough for you, they don't actually carry that much radiation. I read a report a long time ago that if a RTG vaporized directly over a large city, it would be the equivalent of everyone outside getting a tan.
Well, let's say that that is true. If everybody went outside and got a tan, then that would probably result in dozens of additional deaths. Just because it's hard to attribute those deaths to a specific action doesn't mean that they don't happen.
But that's not even true. The total dose of radiation may be low, but the problem is that you receive in places like the inside of your lung.
Dispersing Plutonium in the atmosphere does not cause instant death, and it does not empty whole city blocks. It's probably not much different from atmospheric nuclear tests. If an accident were to happen, nobody would notice. In fact, military RTGs may have blown up left and right and nobody would know. What it will do is increase cancer rates slightly and over a long period of time. But why do people have this twisted notion that if you kill thousands of people through something invisible that takes years to kill, it is any better than lining up the people against a wall and shooting them?
As I was saying: RTGs can be made safe, but I have little confidence that NASA knows how to make them safe or really cares much. In fact, I have strong suspicions that NASA's attitude towards the issue is as irrational and cavalier as yours. And that's why I hope that their designs will be carefully reviewed by others.
Pick up some better tools than that. For numerical stuff, consider Numerical Python. For symbolic math, Maxima is probably still better, although it has a very steep learning curve; but I have rarely found symbolic math program useful at all--usually, a good change of variables makes the derivation simple.
At issue is not whether RTGs can be made safe in principle--they can. But after the spectacular failures of NASA over the last couple of decades, as well as getting more insight into the kinds of stupid safety and engineering decisions NASA and their contractors seem to be making, I am not convinced that NASA can put together a reasonably safe RTG. A scenario where the probe blows up some time during launch and a poorly designed RTG just vaporizes seems quite possible given NASA's other failures. I hope NASA's designs will be very carefully reviewed and audited by outsiders because this is a matter that affects everybody.
If you want to talk about priorities, let's talk about the US defense budget: hundreds of billions of dollars per year, and it doesn't make the world a safer place. Or take the S/L bailout. Or take the corporate tax breaks for Microsoft. Or...
Don't underestimate the power of C++: with type checking and overloading, C++ may actually be more convenient to use for many numerical applications that even something like Numerical Python or Octave/Matlab.
Beyond that, yes, obviously, all those libraries are in use by someone if they are maintained. If you have the need to use one of them, you will know. If not, don't worry about it.
Yes, in roughly the same way that the poor graphics of, oh, say Ulysses or the Iliad are the "special thing" those works can't easily lose. That doesn't stop people from making the movie version--light on content but heavy on graphics. And you already have that for NetHack--just get Diablo.