On windows I just run setup and the system configs itself. I never have to recompile any kernel, because 1) I don't have the sourcecode (;)) but 2) I don't have to: WinXP will config itself and will work no matter what hw card I jam into the pci slots: install the driver (or better: xp has the driver already) and off you go. There is no need for compilation of a certain subsystem into the 'kernel'.
Yes, kernel modules work better on Windows and Macintosh OS X. That's the kind of kernel configurability Linux should aim for.
That, my friend, is a result of the true error in the whole picture: there is no consistency. People are doing what they think is right, but there is no big, guideline which will bring the whole system to a certain level because it's all worked out.
Windows and Macintosh had to make dynamic kernel configuration work because recompilation just wasn't an option in their markets.
Your analogy to GUIs misses the point. Hardware vendors on Windows or Macintosh don't make their drivers work because of some consistent guidelines, they make they work because otherwise they couldn't sell their products. Hardware vendors did this long before DOS/Windows even had a kernel or guidelines. Linux kernel configuration is, if anything, more consistent and standardized than Windows, it just happens to be more cumbersome for end users, too.
Or maybe we should just always have to have a kernel and a copy of the full binary module tree for every possible hardware platform the kernel supports?
We should do what we do with every other piece of software on Linux: have separate packages. You have a GeeWhiz audio card? Install the GeeWhiz audio package. Want ReiserFS? Install the ReiserFS package. Want networking? Install the networking package. Kernel modules are a start, but they need a lot more work.
It'll be a sad day for linux when you can't customize your kernel.
I do want to be able to customize the kernel. In fact, I want to be able to do so much more and much more easily than I can now. I want to be able to add functionality to the kernel as easily as I can add a new command line command. We stopped recompiling our command line interpreters to add new commands some time in the 1960's--and Linux should stop requiring recompiling the kernel to add new functionality.
Sheesh. It's people like you that give laziness a bad name.
Don't get me wrong, OSX is good. In some UI areas, they really are better: dialog boxes are designed better, getting rid of MDI is a good idea, and getting rid of the gray is also good (I never understood why toolkits became so enamored with gray--now if we could only get rid of pseudo-3D...).
Here are just three observations that come to mind:
The single menu bar is a pain on large screens. Worse, it is confusing to many users: when they start an application, they expect an application to appear, not just some subtle change in the appearance of the menubar.
Packaging applications in a single directory is good, but drag-and-drop installation is not. When I download the latest version of Mozilla, I don't want to have to hunt down the old version and delete it by hand. Nor do I want to have to hunt down the shortcuts to the old version and replace them with new ones. Upgrading application software should be automatic and centralized. The answer is a real packaging system, not Windows installers, and not drag-and-drop installation.
Apple wants consistency among Macintosh applications, so they want developers to use standard shortcuts. That's great for their business--it turns all Mac users into Mac zealots who wouldn't consider using anything else. But as a user who uses different platforms, I want consistency among my different work environments. It makes no difference to me whether my desktop is consistent with yours, what matters to me is that my different desktops are as consistent as possible. That means that platforms need to be configurable.
There are other problems with the Aqua UI. But the most basic one is perhaps that it is just another toolkit-based GUI--a system in which people produce the same kind of inflexible applications that people produce in the other major toolkits on the other major platforms. The fact that Aqua looks a little prettier and crashes a little less does not get around this basic fact.
Overall, I think what makes Aqua most useful is a desire to keep applications simple. Unlike Windows, Gnome, or KDE, it comes with useful applications are not overburdened with zillions of options; developers of those desktops should take notice.
I'm sorry, but tinkering around with another graphical configuration app isn't going to fix the fundamental problems with Linux kernel configuration. (In fact, if anything, I find a single window application with a tree widget worse than xconfig.)
We shouldn't have to decide for hundreds of packages whether we want them or what options they should be pre-configured with in the first place. Almost everything should always be dynamically loadable and should always be dynamically loaded. Modules should be independent between minor kernel versions. There should be very few options, and those that are there should be configurable at runtime. The few remaining compile-time options shouldn't require some complicated interface. If we want single-file kernel distribution, we should be able to create a single file archive of the kernel and the required modules in a way that the bootstrap loader understands.
While parts of the Linux kernel are great--the variety of kernels and file systems, for example--I think overall kernel architecture and configuration is by far the weakest part of the Linux operating system. It's not the GUI that inhibits Linux adoption by the masses--Linux GUIs are up to par with other platforms--it's the fact that a large number of people end up having to recompile the kernel to get things like audio, FireWire, power management, cameras, and USB working, even with the modularized kernels in some distributions.
Quite plausible--assuming the car carries a little nuclear thermoelectric generator, crawls along fairly slowly, and doesn't bother with too much shielding:-)
Trying to impose digital rights management through a consortium is bound to fail. Even if Intel, Dell, Compaq, IBM, Microsoft, and Apple collude fully to control digital content, there are thousands of chips out there thay any small and innovative company can turn into a computing platform, using Linux or BSD as the OS. The only thing Microsoft achieves by crippling their OS is to give open source a leg up.
The only serious threat is legislation or legal precedent: if running your favorite OS on an embedded chip becomes defined as "circumvention" under the DMCA, then there is real trouble. But then we'd be heading for the technological dark ages anyway: a DRM world simply cannot support a rapid pace of technological innovation.
There is nothing insane about the BSD license, nor is it necessarily unfriendly to developers.
Yes, BSD-licensed code may end up in commercial products. But that often beats the alternative. I'd much rather see Microsoft use a piece of software with a BSD license than have them hack their own--I already know that whatever they come up with themselves is going to be less compatible with the rest of the world and usually technically worse.
Most companies who use BSD code and try to keep it closed sooner or later realize the futility of their endeavor and publish it--there is just no point on keeping software closed when other people have very similar software already for free.
The GPL relies on a contractual obligation to ensure source availability. BSD relies on something much simpler: laziness.
The LGPL and GPL both are very useful, and I use them for my software too. But BSD isn't "insane"--it's a valid license and a good approach to open source software. And sometimes, giving commercial users more than they "deserve" is a good idea because it helps get the APIs and architecture of free software systems into commercial and proprietary products.
So, here is how I see good licensing choices that promote free software:
GPL: use for software for which there is no substitute and for which it is desirable that feedback comes back to the community. Also use for software where incorporation into another product doesn't help free software much. Application like office suites and scientific applications fall into this category.
LGPL: use for libraries or software for which substitutes are available and where it is desirable that the free software gets adopted by commercial users but that their changes get published back to allow others to interoperate. Libraries like GUI toolkits, office suite file readers/writers, password authentication libraries, Java runtimes, etc. fall into this category.
BSD (or MIT or public domain): use for libraries or software for which substitutes are very easily available and where feeding changes back to the community doesn't matter that much. Examples are commodity software like command line FTP and telnet clients, command line utilities, libraries for HTTP or XML, etc. For such software, the free software community benefits most if commercial companies just adopt whatever small or large part of the free and open standard as they like, and you want to minimize their reluctance to do so.
For software like kernels and command line tools, the GPL/LGPL often isn't very strong anyway because most commercial uses would not involve linking with the code. Note again that the GPL (or some even more restrictive license) isn't always the best choice for promoting free software. Imagine where Linux and free software would be today if the Linux kernel only allowed the execution of free software applications, or if the X11 window system only allowed the display of GPL'ed GUI apps.
So, in short, all of the *GPL and BSD licenses have their purpose. Which one is best for the promotion of free software depends on the software and the potential users.
It seems to me the actual invention ot television, the idea of translating an image into a sequential electrical signal by scanning and converting it back at the receiver, dates back to Nipkow in the 19th century. Baird, Farnsworth, and Zworykin's are elaborations on this basic idea, using early 20th century technology.
I agree with you, but not for the reason you give. The main advantage OSX has over Linux is that Apple ships it preinstalled and makes sure it works on all their hardware. Also, there are some drivers available for OSX that aren't available for Linux. You lose that if you run OSX under Linux on Macintosh hardware.
Technically, I don't think either OSX or Linux is preferable over the other. While basic command line stuff ports pretty easily to OSX, there is a lot of stuff that's hard to port and where the OSX APIs are just enormously cumbersome compared to what Linux offers. In short, neither OSX nor Linux is clearly better than the other--they are different OSes for different user communities. But if you spend the money for a Mac, it makes sense to run OSX--for Linux, PCs are more cost effective platforms.
I'm not sure what you mean by "the standard way". Most modern applications put Cut/Paste entries into their menus (almost all Gnome and KDE applications have it) and they work as expected. Note that they also handle selections, so "middle button" or its equivalent will paste the selection, while Paste will paste the clipboard. If the selection pasting bothers you, just don't use it (you can even rebind the button to do something you find useful).
A small number of old applications (most notably, xterm) are still in use and don't have any menu entries corresponding to clipboard operations. I can't think of any such old application that is still needed. For example, instead of xterm, just use gnome-terminal, which behaves like you probably expect it to.
I think it's a tribute to the design of X11 that things like xterm still work and are still useful to many people, even if they don't support a few features. Imagine, in comparison, how a 16bit real-mode graphical DOS application runs under today's Windows XP operating system.
Others have asserted, and I believe, that when you give the user two mechanisms for accomplishing the same thing, the user wastes more time deciding which to use than he would have spent using the either of the two methods.
That result refers to GUIs like what you get in Visual C++--GUIs that put up zillions of buttons, menus, and entry widgets, many of which do the same thing.
That result does not apply to configurable systems. You don't waste any time thinking about options you either don't know are there in the first place (your situation with cut-and-paste under X11), or have already decided not to use.
I agree that consistency is good. And it is configurability that allows users to make their systems more consistent. I frankly don't care at all whether you find that the way I have configured my Macintosh is consistent with the way you have configured yours. What I care about is that my Macintosh is consistent with the other machines I use and with the way I'm used to using computers. In order to achieve that, I need to change the behavior of my Macintosh to deviate substantially from Apple's guidelines. We aren't all little clones of each other--our needs and experiences differ.
The notion that you achieve a consistent user experience by imposing a single standard on a platform only works if there is only a single platform. That may be Gates's and Jobs's pipe dream and master plan, but it is profoundly user-hostile. And users will work around such attempts at imposing "consistency", as the numerous tuning and modification programs for the Windows and Macintosh GUIs show.
That's a separate application and a workaround; Windows, X11, and other desktops have that, too, but nobody uses it. In day-to-day usage, the paste-selection mechanism always shows you clearly what you are pasting, automatically and in its original context.
In any case, as I was saying, X11 gives you both, so take your pick. Most X11 users prefer paste-selection, and for good reason, I believe.
The biggest problem with this survey is that Unix usage has gone through the roof in the last two years with the advent of Mac OS X.
Do you have any figures to back up that claim? It seems pretty implausible to me, even if we look at desktop usage. On the server, of course, it is clearly false, given the miniscule usage of Macintosh for servers.
Besides, what is your point? Most Macintosh users don't use or see much of the UNIX functionality. UNIX applications still require quite a bit of porting to become native Macintosh applications. And Macintosh applications aren't portable to non-Macintosh UNIX systems. And Macintosh users still use Microsoft Office and IE, like good little Bill Gates clones.
You are confusing cut-and-paste with paste-the-selection. The two are different mechanisms and X11 supports both (as do most toolkits and many applications).
From a usability point of view, the selection-based mechanism is arguably better since you always see what you are about to paste; with the clipboard, there is no visual indication at all. It's mostly switching back and forth that makes it confusing.
I was really hoping to see more comparisons of OS X versus other Linux flavors,
I'm glad that such comparisons weren't made. Most Macintosh users can't figure out why people might prefer Linux, and Linux users can't figure out how Macintosh users can put up with the Macintosh.
The article told you much of what you needed to know to draw your own conclusions; I think that's the way articles like that should be written.
The main point here is that a. anyone who wants X11 can figure it out easily, and b. almost no one wants X11. If Apple bundled it, that wouldn't change. People don't want X11 because X11 sucks. People only use it when they have to use it, to get at specialized software. People would rather use an inferior IRC client in Cocoa or Carbon than a better one in X11, even if X11 is installed and configured, because X11 inherently sucks a lot more.
Then Apple's smart engineers can figure out how to make it suck less and add value to it; XFree86 on OS X doesn't cut it. Given that there are a huge number of X11 users out there (almost certainly more than OS X users), it's a market opportunity that Apple would be foolish to miss.
Like every other implementation of X11, you mean. So?
X11 implementations exist that run in less than 1Mbyte of RAM. Applications for X11 run on 16bit embedded systems and can be implemented in binaries a few kilobytes large.
Look at the processes on your Mac to see how huge even the simplest applications are. Terminal on X11 uses 1/6th the memory and is 80 times faster at displaying text than Terminal.app on my Mac (1GHz Athlon vs. 600MHz PPC), and that's true for many other applications as well.
There is no need to set DISPLAY settings, and there is no need for it to start automatically.
When a user installs X11, there are no links to X11 applications anywhere to be found in the Finder. When they manage to find the "xterm" executable (or almost any other X11 executable), it doesn't run when they double click on it. If they switch to the shell and try to run it from the command line, it won't run either because they need to set a DISPLAY environment variable. Maybe they figure out how to install OroborusX, but that's a limited set of applications, not usually what the user wants to run.
This is not a "well supported" X11 installation, and the user experience is much worse than on a UNIX workstation or preconfigured Linux machine. Apple needs to improve this.
Because the premium-priced Mac already comes with a far superior windowing system,
Too bad it doesn't run most of the scienctific and engineering software people use. Heck, it doesn't even run Matlab--for that you need X11.
You're right, it's not. You have to type in your password (one would hope one would know this), select a language (one would really hope one would know this), then click Next a few times, before clicking Install. My bad. Excuse me while I snicker.
Yup, a gearhead like you would snicker. Most people find the idea of downloading a 53Mbyte package, installing it, setting it up to auto-start at startup, figuring out DISPLAY settings, and all that daunting. And when you are done, you end up with a flickering, sluggish, and bloated implementation of X11.
If Apple wants to make MacOSX an easy-to-use UNIX workstation alternative, they need to make X11 applications as easy to start up as double-clicking on an icon--just like Carbon or Cocoa apps--with nothing to download, install, or configure.
very few people will ever use X11 on a Mac.
We agree on that point. And that makes the Mac a minor player when it comes to the UNIX workstation market. Apple should stop marketing it as such until they actually support a standard suite of workstation software out of the box.
Yes, it does invalidate the point you made. Your point was that "Einstein showed something". But he didn't. One can show (=prove) that pi must be irrational, but one can't show that objects can't accelerate faster than light (even if it seems plausible and likely). The distinction is particularly important for physicists to keep in mind; too bad that it is lost on many of them.
Einstein didn't "show" that. Einstein developed a mathematical theory that makes certain experimental predictions. Whether those predictions are correct or not needs to be verified experimentally. Just because a few predictions have been verified doesn't mean that the whole theory is true. In fact, we already know that the whole theory cannot be true--at best, it can be an approximation.
If the experiment
is successful it will provide a new independent test of general
relativity in the solar system.
If the experiment showed infinite propagation velocity, it would invalidate GR. But it is a common fallacy among physicists to claim that conducting an experiment that can invalidate a theory "tests" that theory. The problem with that view is that there are many other possible theories of gravity that differ substantially from GR but still have finite speeds of gravitational interactions. In fact, merely imposing finite speed on Newtonian gravity (and doing some fixing up to make the result consistent) gives you an interesting theory that is quite similar to the experimental predictions of GR in many ways.
I don't know where you're getting your "fiddling around dozens of megabytes of stuff and going into the command line", 'coz it doesn't apply in this case.
I have had to help too many people to get a working X11 environment on OSX: it doesn't "just work". Maybe the server starts up with a couple of clicks, if you are lucky, but there is more to do. A well-integrated version of X11 would allow people to just double click on any X11 application and run it just like a Carbon application on an out-of-the-box Mac, with standard OSX window management, transparency support, and hardware acceleration.
However, on setting up X on Jaguar, I disagree. Download two pkgs and double-click 'em - how easy can it get?
It can get as easy as not having to think about it at every upgrade, not having to download 53Mbytes, like I don't have to on other UNIX workstations. It can get as easy as making the differences between X11 and Cocoa as small as those between Carbon and Cocoa from the user's point of view.
If Apple wants to be in the scientific and engineering workstation market, they have to make it as easy as that, because otherwise OSX is a lot more hassle than a UNIX workstation.
To be supported is not the same as to be included. X11 is supported on Mac OS X.
To me it is. You obviously understood what I meant. Redefining terms doesn't change the fact.
# If a scientific or engineering user can't download XFree86 and click "Install", then perhaps they shouldn't be using computers.
It's not that simple. Even if it were that simple, it's a headache. I don't have to download and install the window system for my UNIX or Linux workstation--why should I have to do it for my premium-priced Mac?
Altogether, my MacOSX machines are a lot more work to maintain than my Linux machines. That's not the way to get and keep professional users for Apple.
Slashdot Mirror
Yes, kernel modules work better on Windows and Macintosh OS X. That's the kind of kernel configurability Linux should aim for.
That, my friend, is a result of the true error in the whole picture: there is no consistency. People are doing what they think is right, but there is no big, guideline which will bring the whole system to a certain level because it's all worked out.
Windows and Macintosh had to make dynamic kernel configuration work because recompilation just wasn't an option in their markets.
Your analogy to GUIs misses the point. Hardware vendors on Windows or Macintosh don't make their drivers work because of some consistent guidelines, they make they work because otherwise they couldn't sell their products. Hardware vendors did this long before DOS/Windows even had a kernel or guidelines. Linux kernel configuration is, if anything, more consistent and standardized than Windows, it just happens to be more cumbersome for end users, too.
We should do what we do with every other piece of software on Linux: have separate packages. You have a GeeWhiz audio card? Install the GeeWhiz audio package. Want ReiserFS? Install the ReiserFS package. Want networking? Install the networking package. Kernel modules are a start, but they need a lot more work.
It'll be a sad day for linux when you can't customize your kernel.
I do want to be able to customize the kernel. In fact, I want to be able to do so much more and much more easily than I can now. I want to be able to add functionality to the kernel as easily as I can add a new command line command. We stopped recompiling our command line interpreters to add new commands some time in the 1960's--and Linux should stop requiring recompiling the kernel to add new functionality.
Sheesh. It's people like you that give laziness a bad name.
It's people like you that give Linux a bad name.
Here are just three observations that come to mind:
There are other problems with the Aqua UI. But the most basic one is perhaps that it is just another toolkit-based GUI--a system in which people produce the same kind of inflexible applications that people produce in the other major toolkits on the other major platforms. The fact that Aqua looks a little prettier and crashes a little less does not get around this basic fact.
Overall, I think what makes Aqua most useful is a desire to keep applications simple. Unlike Windows, Gnome, or KDE, it comes with useful applications are not overburdened with zillions of options; developers of those desktops should take notice.
We shouldn't have to decide for hundreds of packages whether we want them or what options they should be pre-configured with in the first place. Almost everything should always be dynamically loadable and should always be dynamically loaded. Modules should be independent between minor kernel versions. There should be very few options, and those that are there should be configurable at runtime. The few remaining compile-time options shouldn't require some complicated interface. If we want single-file kernel distribution, we should be able to create a single file archive of the kernel and the required modules in a way that the bootstrap loader understands.
While parts of the Linux kernel are great--the variety of kernels and file systems, for example--I think overall kernel architecture and configuration is by far the weakest part of the Linux operating system. It's not the GUI that inhibits Linux adoption by the masses--Linux GUIs are up to par with other platforms--it's the fact that a large number of people end up having to recompile the kernel to get things like audio, FireWire, power management, cameras, and USB working, even with the modularized kernels in some distributions.
Quite plausible--assuming the car carries a little nuclear thermoelectric generator, crawls along fairly slowly, and doesn't bother with too much shielding :-)
The only serious threat is legislation or legal precedent: if running your favorite OS on an embedded chip becomes defined as "circumvention" under the DMCA, then there is real trouble. But then we'd be heading for the technological dark ages anyway: a DRM world simply cannot support a rapid pace of technological innovation.
This is what the article says:
See the difference?
Yes, BSD-licensed code may end up in commercial products. But that often beats the alternative. I'd much rather see Microsoft use a piece of software with a BSD license than have them hack their own--I already know that whatever they come up with themselves is going to be less compatible with the rest of the world and usually technically worse.
Most companies who use BSD code and try to keep it closed sooner or later realize the futility of their endeavor and publish it--there is just no point on keeping software closed when other people have very similar software already for free.
The GPL relies on a contractual obligation to ensure source availability. BSD relies on something much simpler: laziness.
The LGPL and GPL both are very useful, and I use them for my software too. But BSD isn't "insane"--it's a valid license and a good approach to open source software. And sometimes, giving commercial users more than they "deserve" is a good idea because it helps get the APIs and architecture of free software systems into commercial and proprietary products.
So, here is how I see good licensing choices that promote free software:
For software like kernels and command line tools, the GPL/LGPL often isn't very strong anyway because most commercial uses would not involve linking with the code. Note again that the GPL (or some even more restrictive license) isn't always the best choice for promoting free software. Imagine where Linux and free software would be today if the Linux kernel only allowed the execution of free software applications, or if the X11 window system only allowed the display of GPL'ed GUI apps.
So, in short, all of the *GPL and BSD licenses have their purpose. Which one is best for the promotion of free software depends on the software and the potential users.
It seems to me the actual invention ot television, the idea of translating an image into a sequential electrical signal by scanning and converting it back at the receiver, dates back to Nipkow in the 19th century. Baird, Farnsworth, and Zworykin's are elaborations on this basic idea, using early 20th century technology.
Technically, I don't think either OSX or Linux is preferable over the other. While basic command line stuff ports pretty easily to OSX, there is a lot of stuff that's hard to port and where the OSX APIs are just enormously cumbersome compared to what Linux offers. In short, neither OSX nor Linux is clearly better than the other--they are different OSes for different user communities. But if you spend the money for a Mac, it makes sense to run OSX--for Linux, PCs are more cost effective platforms.
A small number of old applications (most notably, xterm) are still in use and don't have any menu entries corresponding to clipboard operations. I can't think of any such old application that is still needed. For example, instead of xterm, just use gnome-terminal, which behaves like you probably expect it to.
I think it's a tribute to the design of X11 that things like xterm still work and are still useful to many people, even if they don't support a few features. Imagine, in comparison, how a 16bit real-mode graphical DOS application runs under today's Windows XP operating system.
That result refers to GUIs like what you get in Visual C++--GUIs that put up zillions of buttons, menus, and entry widgets, many of which do the same thing.
That result does not apply to configurable systems. You don't waste any time thinking about options you either don't know are there in the first place (your situation with cut-and-paste under X11), or have already decided not to use.
I agree that consistency is good. And it is configurability that allows users to make their systems more consistent. I frankly don't care at all whether you find that the way I have configured my Macintosh is consistent with the way you have configured yours. What I care about is that my Macintosh is consistent with the other machines I use and with the way I'm used to using computers. In order to achieve that, I need to change the behavior of my Macintosh to deviate substantially from Apple's guidelines. We aren't all little clones of each other--our needs and experiences differ.
The notion that you achieve a consistent user experience by imposing a single standard on a platform only works if there is only a single platform. That may be Gates's and Jobs's pipe dream and master plan, but it is profoundly user-hostile. And users will work around such attempts at imposing "consistency", as the numerous tuning and modification programs for the Windows and Macintosh GUIs show.
In any case, as I was saying, X11 gives you both, so take your pick. Most X11 users prefer paste-selection, and for good reason, I believe.
Do you have any figures to back up that claim? It seems pretty implausible to me, even if we look at desktop usage. On the server, of course, it is clearly false, given the miniscule usage of Macintosh for servers.
Besides, what is your point? Most Macintosh users don't use or see much of the UNIX functionality. UNIX applications still require quite a bit of porting to become native Macintosh applications. And Macintosh applications aren't portable to non-Macintosh UNIX systems. And Macintosh users still use Microsoft Office and IE, like good little Bill Gates clones.
From a usability point of view, the selection-based mechanism is arguably better since you always see what you are about to paste; with the clipboard, there is no visual indication at all. It's mostly switching back and forth that makes it confusing.
I'm glad that such comparisons weren't made. Most Macintosh users can't figure out why people might prefer Linux, and Linux users can't figure out how Macintosh users can put up with the Macintosh.
The article told you much of what you needed to know to draw your own conclusions; I think that's the way articles like that should be written.
Then Apple's smart engineers can figure out how to make it suck less and add value to it; XFree86 on OS X doesn't cut it. Given that there are a huge number of X11 users out there (almost certainly more than OS X users), it's a market opportunity that Apple would be foolish to miss.
X11 implementations exist that run in less than 1Mbyte of RAM. Applications for X11 run on 16bit embedded systems and can be implemented in binaries a few kilobytes large.
Look at the processes on your Mac to see how huge even the simplest applications are. Terminal on X11 uses 1/6th the memory and is 80 times faster at displaying text than Terminal.app on my Mac (1GHz Athlon vs. 600MHz PPC), and that's true for many other applications as well.
There is no need to set DISPLAY settings, and there is no need for it to start automatically.
When a user installs X11, there are no links to X11 applications anywhere to be found in the Finder. When they manage to find the "xterm" executable (or almost any other X11 executable), it doesn't run when they double click on it. If they switch to the shell and try to run it from the command line, it won't run either because they need to set a DISPLAY environment variable. Maybe they figure out how to install OroborusX, but that's a limited set of applications, not usually what the user wants to run.
This is not a "well supported" X11 installation, and the user experience is much worse than on a UNIX workstation or preconfigured Linux machine. Apple needs to improve this.
Too bad it doesn't run most of the scienctific and engineering software people use. Heck, it doesn't even run Matlab--for that you need X11.
You're right, it's not. You have to type in your password (one would hope one would know this), select a language (one would really hope one would know this), then click Next a few times, before clicking Install. My bad. Excuse me while I snicker.
Yup, a gearhead like you would snicker. Most people find the idea of downloading a 53Mbyte package, installing it, setting it up to auto-start at startup, figuring out DISPLAY settings, and all that daunting. And when you are done, you end up with a flickering, sluggish, and bloated implementation of X11.
If Apple wants to make MacOSX an easy-to-use UNIX workstation alternative, they need to make X11 applications as easy to start up as double-clicking on an icon--just like Carbon or Cocoa apps--with nothing to download, install, or configure.
very few people will ever use X11 on a Mac.
We agree on that point. And that makes the Mac a minor player when it comes to the UNIX workstation market. Apple should stop marketing it as such until they actually support a standard suite of workstation software out of the box.
Yes, it does invalidate the point you made. Your point was that "Einstein showed something". But he didn't. One can show (=prove) that pi must be irrational, but one can't show that objects can't accelerate faster than light (even if it seems plausible and likely). The distinction is particularly important for physicists to keep in mind; too bad that it is lost on many of them.
Einstein didn't "show" that. Einstein developed a mathematical theory that makes certain experimental predictions. Whether those predictions are correct or not needs to be verified experimentally. Just because a few predictions have been verified doesn't mean that the whole theory is true. In fact, we already know that the whole theory cannot be true--at best, it can be an approximation.
If the experiment showed infinite propagation velocity, it would invalidate GR. But it is a common fallacy among physicists to claim that conducting an experiment that can invalidate a theory "tests" that theory. The problem with that view is that there are many other possible theories of gravity that differ substantially from GR but still have finite speeds of gravitational interactions. In fact, merely imposing finite speed on Newtonian gravity (and doing some fixing up to make the result consistent) gives you an interesting theory that is quite similar to the experimental predictions of GR in many ways.
The USENET sci.physics FAQ has a pretty readable explanation of some of the speculation surrounding the speed of gravity.
I have had to help too many people to get a working X11 environment on OSX: it doesn't "just work". Maybe the server starts up with a couple of clicks, if you are lucky, but there is more to do. A well-integrated version of X11 would allow people to just double click on any X11 application and run it just like a Carbon application on an out-of-the-box Mac, with standard OSX window management, transparency support, and hardware acceleration.
However, on setting up X on Jaguar, I disagree. Download two pkgs and double-click 'em - how easy can it get?
It can get as easy as not having to think about it at every upgrade, not having to download 53Mbytes, like I don't have to on other UNIX workstations. It can get as easy as making the differences between X11 and Cocoa as small as those between Carbon and Cocoa from the user's point of view.
If Apple wants to be in the scientific and engineering workstation market, they have to make it as easy as that, because otherwise OSX is a lot more hassle than a UNIX workstation.
To me it is. You obviously understood what I meant. Redefining terms doesn't change the fact.
# If a scientific or engineering user can't download XFree86 and click "Install", then perhaps they shouldn't be using computers.
It's not that simple. Even if it were that simple, it's a headache. I don't have to download and install the window system for my UNIX or Linux workstation--why should I have to do it for my premium-priced Mac?
Altogether, my MacOSX machines are a lot more work to maintain than my Linux machines. That's not the way to get and keep professional users for Apple.