I never put my personal/business address on a commercial site, unless it's a site I use for my business. Furthermore, I use a white list. Works like a champ.
Well, how nice for you that your life is so simple and your needs are so modest. However, many other people cannot use a white list.
His complaint is legitimate: it is exceptionally rude for Slashdot editors to manually unscramble an E-mail address and put it into a story.
Pray tell me how I can change say, the Linux kernel scheduler on the fly without having to recompile from source, install and reboot with the new image.
There are lots of ways. You load a new dynamic module and, if necessary, dispatch to it. In some cases, the dispatching happens automatically, in others, you replace the first instruction of an old subroutine with a jump to the new subroutine. GDB supports that, as do many rootkits.
For kernel development, most people seem to have stopped doing that because well-defined version control, automated builds, automated testing, and remote debugging seem to work better. Keep in mind that if you set up your kernel development environment well, you can reboot faster than you can type M-x eval-buffer.
The premise of HBHG is too similar to the DVC to be happenstance.
And the problem with that would be exactly what? Almost all great art--music, theater, literature, TV, SciFi, etc. has been created by copying and improving what has come before. Where do you think Shakespeare's plays come from? Bach's music? Mozart's operas? Babylon 5 and Star Trek plots? Even the most famous artists stand on the shoulders of generations of giants.
I guess your comment demonstrates what is wrong with IP law: not only have people like you gotten it into their heads that at the beginning of the 21st century, ideas should be owned, you are also so ignorant of history that you don't actually recognize how unprecedented that notion is.
There isn't any environment that comes even close to giving the kind of access they did. You could change kernel code WHILE THE SYSTEM WAS RUNNING, if you wanted to, or any other code for that matter.
If they didn't fuck up, conceivably you won't notice...
There are hundreds of known, often fatal diseases you can catch from a transplant. If the tissue was obtained illegally, you can bet they didn't test for those, and the donors probably weren't 18 year olds that died in a motorcycle accident.
So, I assume that when people get "tested", it's for things like hepatitis, HIV, and various parasites.
Pretty much all modern CPUs need special compilers to give good performance.
If pretty much all modern CPUs need a particular feature, it's not "special" anymore. What's "special" about Cell is the features that make it different from mainstream CPUs.
To prevent pipeline stalls, you need to make sure that you have a minimum of m instructions (and ideally m) between your load and your first operation that depends on the that data.
So, in addition to having to wait for the completion of the variable time operation, which the data-dependent operation has to do anyway, the equivalen RISC instruction sequence is going to fill up the pipeline and the cache with junk. But, hey, at least the pipeline didn't stall--the CPU designers have successfully pushed the problem off their plate. Thanks for illustrating my point.
In any case, I'm not defending complex instructions at any cost, I'm saying that CPU designers have gone too far in pushing problems off onto compilers. We may not need a string edit instruction, but we do need better support for various forms of parallelism than Cell or Itanium. I expect the evolution of MMX, hyperthreading, and multicore chips is going to be much more important than architectures like Cell or Itanium.
Apple has decided. They want to be a system for creative professionals and this is their primary market.
Seems to me, scientists, engineers, academics, and students are the most creative people around.
In any case, Apple is marketing to anybody they can, and science and academia is probably their most important after home users so they need to support them better. Apple simply has a conflict: they want people to port to Cocoa, but they also want to play in this market. I think it will be a few more years before Apple will resolve the conflict one way or another. I think that if they keep (nearly) ignoring the open source GUI technologies and try to compete with proprietary stuff, it's gonna hurt them badly.
There's nothing "radical" about it--it's just a bunch of CPUs on a chip. It's about the least radical way in which you can put a bunch of CPUs on a chip, beyond multicore.
Lisp machines were dog slow and hugely expensive, even compared to the workstations around at the time. If you want that kind of environment, you can emulate it by running any of the interpreted languages so popular on Linux, Windows, and Macintosh (although you'll be hard pressed to be as slow as the Lisp machine).
As for not hiding reconfigurability: you can buy anything you desire as an add-on board, like an FPGA board or an array processor. People don't use them a lot because they are a pain to program and they don't give you good bang for the buck.
There has. Itanium is the most recent example. Most of those efforts fail because, in the real world, getting good performance only with a single compiler from a single vendor, and then usually only if the stars align right, isn't good enough.
1) Aqua's use of graphics cards for coprocessing is far beyond virtually any other OS. (Coreimage) [...] 2) Applescript. No one else has a scripting language which cuts across almost every app in the OS like this since Symbolics.
I disagree with both of those points, but it's not worth debating that.
3) Objective C is basically an apple technology
No, Objective C and its core libraries were developed by Stepstone, borrowing heavily from Xerox's Smalltalk-80 system. NeXT took Stepstone's system (and my impression is that the term "rip off" might apply), and Apple got the whole thing as part of the NeXT acquisition.
4) Adaptive dimming
You mean of the laptop screen? You must be kidding--consumer displays have been doing that for a long time.
5) Xgrid compiles
Do you mean distributed compilation? That's been around for at least two decades.
6) ACL technology in a mainstream OS.
Do you mean "access control lists"? Windows NT has had those for a long time, as have most UNIX systems. Linux has had them for half a dozen years as well. The reason you don't hear about them is because they don't work.
Even if your list of "innovations" were actually Apple innovations, you're really reaching for the bottom of the barrel--I mean, screen dimming? Come on. Compared to the massive amounts of innovation that have gone into Linux, UNIX, and Windows, at the kernel, library, UI, and application level, Macintosh is pretty dull technologically.
Again, that's not wrong or bad--Macs are decent, well-designed machines, but that's all.
Everybody's X came from MIT. What is means to write an X is to implement MIT's code for your platform. That is the definition and its been the definition of 20 years.
You don't know what you're talking about. X11 is a protocol, not a piece of software. The definition of X11 is the protocol, nothing else. There are probably dozens of implementations by now, many of which share little more than the definitions of data structures, and some of which don't share a line of code with any of the others.
The concept of a window system standard independent of an implementation may be hard to grasp for people like you, who have grown up at the mercy of a vendor that changes interfaces and codebases every couple of years, but it's a good concept and it works. It's why X11 is still going strong, while Apple and Microsoft have had to throw out their window systems several times, and will probably have to do so again in the next few years.
First off I and most other OSX users never change resolutions.
You aren't giving any presentations then.
To make it really work well, as you said above Apple would have to do a lot of work.
They could probably do it with the FTE's that are wasting their time on DarwinPorts.
Further using your definition they would have to abandon the HUGs. Which means it can't as long as the Macintosh is anything like it is today.
You mean their interface guidelines? Apple isn't following their own guidelines anyway; Macintosh consistency is a sham--it's been abandoned long ago, and supporting X11 properly doesn't make it any worse.
X11 works fine for experienced Unix users. You can ship software to a Unix user customer base which uses X11. You cannot ship software which uses X technology to the general Mac user base and Apple doesn't want you to. That's policy not a bug.
Apple needs to decide: do they want to be a professional system for scientists and engineers or do they want to be a hobbyist system. In the first case, they must support X11 better. It's not a question of whether scientists or engineers are too dumb to install and set up X11, it's that it's too much work. If people have to invest that much work in getting Macs to run, they might as well set up a Linux machine.
If a CPU needs a special compiler in order to give good performance, it's basically dead; there are simply too many different applications that do binary code generation.
Also, the division into "expert programmer" and "regular programmer" is silly. Most coding is done by people who aren't experts in the cell architecture (or any other architecture). That's not because people are too stupid to do this sort of thing, it's because it's not worth the investment.
If Cell can't deliver top-notch performance with a simple compiler back-end and regular programmers who know how to write decent imperative code, then Cell is going to lose. Hardware designers really need to get over the notion that they can push off all the hard stuff into software. People want hardware that works reliably, predictably,and with a minimum of software complexity.
Maybe CISC wasn't such a bad idea after all--you may get less bang for the buck, but at least you get a predictable bang for the buck.
Nobody has any idea of how well any kind of encasement technology holds up under those conditions or whether things you put there stay there. And once you put it there, you can't get it back out.
What's just as irresponsible is that fissile material is a scarce resource and without using breeder reactors, you are only using a tiny fraction of the energy you could potentially get from it.
As I'm reading what you want that's not "becoming a little more open" its a full change in the development direction of their OS
It's not about "being open", it's about producing a reasonably usable X11 server for their OS.
You conveniently skirted around the real biggies: the fact that screen resolutions and keymaps just don't work makes X11 almost completely unusable for day-to-day work.
I'm not sure if you are nitpicking or just poorly informed. MITX11 -> X consortium X11 (old X.org) -> Xfree86 -> XDarwin -> Apple X11.
Neither. I'm pointing out that your claim that Apple "wrote a custom X11" is wrong--Apple didn't "write" an X11 implementation, they modified the MIT X11 implementation. Like a lot of "their" stuff, it's someone else's stuff that's been hacked a bit.
They have to replicate that work on both Carbon and Cocoa in both directions. Then they would have to keep it working through changes in both platforms. What you are asking for is a lot of work for apple. In particular it would mean coordinating their GUI development with open source GUIs.
Yes, that's what it would mean.
That seems deliberate to me, probably designed to stop virus and the like.
It probably is deliberate--it probably is to maintain non-Macintosh applications as foreign objects. Apple wants to tie developers and application writers to their platform.
Just change your startup scripts.
And how do I ship applications (open source or proprietary) that way? Am I supposed to give users a page of instructions on how to enable X11 and install Fink?
Well try fink. I've gotten to work fine.
Fink works a little better than DarwinPorts, but it's still unusable for mainstream use. Any mainstream Linux distribution is easier to install, more consistent, and easier to use than Fink on OS X.
If I want my X apps to really work well I'm using a Linux.
My point exactly: X11 doesn't reall work well on Macintosh, even though it could. X11 is a marketing gimmick for Apple right now, something that is intended to induce people to switch but that doesn't work well enough for heavy-duty use and that you can't ship software for.
Which brings me back to my original point: Apple doesn't really have any brilliant new technology. What they have is branding and single-source hardware/software. If Apple started shipping OS X as a layer on top of Windows, Apple would have nothing left to support such a huge company. Apple knows that, which is why they will continue shipping the software/hardware combo that they are shipping, and why they will keep crippling the open source compatiblity of their system.
which can share a clipboard, is Aqua aware, integrates with the Dock, has a Mac like Window manager.....
Have you ever tried USING X11 for anything non-trivial on the Mac? Try running OpenOffice 2.0 on OS X, it shows some of the blatant shortcomings pretty easily. For example, X11 doesn't pick up the Mac international keybindings, even though it should. Native X11 keyboard rebinding doesn't work properly so that you can't even have consistent key bindings between X11 and native apps. X11 doesn't change resolution when Quartz does, making it impossible to use Impress for presentations. Dragging from the finder doesn't work. Most cut-and-paste operations other than plain text don't work. All X11 apps are a single group. You can't start X11 apps by double clicking (everybody gets around that by having special startup scripts). X11 isn't even preinstalled out of the box, or started up automatically.
Apple knows about these problems, they just don't fix them--deliberately.
2) Apple has paid FTE's working on the DarwinPorts project. Their gnome support seems pretty good.
DarwinPorts is unusable: installing packages takes forever, and that's assuming they even compile. A large proportion (I'd guess about 1/3-1/2) packages fail to compile altogether (among other things, I have never been able to get a working Gnome or Gtk+ out of DarwinPorts).
3) I assume you mean GTK on an equal footing since Gnome::GTK, OSX::Cocoa/Carbon see diagram. But in that case it isn't the Gnome GUI so I don't know what you mean.
It means fixing the above problems with X11, preinstalling and automatically starting X11, preinstalling the Gnome and Gtk+ libraries, automatically starting the Gnome servers at startup, and doing whatever is necessary behind the scenes to make the Finder integrate with Gnome apps like the native Gnome file manager. It probably means a few other things, but that would be a good start.
In the end, Apple doesn't care about the underlying OS. Mach was handy, they only need a substrate to run their desktop environment atop. [...] Sooner or later Steve will swollow his pride and create a subsystem consisting of a modernized POSIX and NextStep and that will be OS XI. It will also ship with all of the Vista subsystem. That will allow all the device installers to run and gain the ability to run all Windows apps besides. Which also solves the Microsoft Office availibility problem.
That would reduce Apple to an application vendor. How long do you think Apple is going to last as a vendor of iApplications and Cocoa libraries? They'd be competing with software companies having a few dozen employees and (in the case of Cocoa) better libraries and better IDEs.
Apple has no unique technology, they have almost no research, and they don't really innovate. What Apple has going for them is branding, style, and an all-in-one solution. That's enough to be successful in this market (many other companies survive on branding and style alone), but if they try to take on Windows software houses or PC hardware vendors head-on on price and functionality, they're going to lose.
The one thing Apple could and should do is become a little more open to open source technologies. In particular, Apple should make X11 and Gnome a GUI environment on equal footing with Carbon and Cocoa. Right now, Gnome is a cumbersome third party install, and their X11 integration sucks.
It's irresponsible to keep using nuclear energy before we have solved the question of waste disposal.
In fact, technically, waste disposal is not such a big problem: using breeder reactors, nuclear power could be generated without large amounts of high-level waste. Unfortunately, breeder reactors can theoretically be used to produce weapons-grade material, so the US government prefers accumulating lots of hard-to-dispose of high-level waste rather than building breeder reactors.
The "Get Info > Open With..." functionality in the finder is worse than nothing at all because it doesn't work reliably (probably because the Mac can't decide whether it wants to use file extensions, codes, or content for determining file types). It's another example of how inconsistent the Mac actually has become.
The only thing that works reasonably well is to get the "Default Apps" plugin for System Preferences.
OS X is based on Mach with a BSD emulation layer on top of it, some BSD command line tools, and NeXTStep libraries.
Furthermore, the point of running BSD or Linux on the Mac is to get rid of a lot of the bloat that Apple has added, and instead run a pure, consistent X11 desktop; less is more in this case.
Well, you list a few smaller items, there are lots more. I'd collected about a hundred different problems that I noticed over time before I stopped. Some that come to mind are:
-- green button does something unpredictable -- bindings of files to applications change haphazardly and incomprehensibly -- there's no built-in mechanism for fixing unwanted file associations -- can't drag file items from dock -- application menus make menu tools disappear -- applications are inconsistent in what they do when the last window closes -- key binding mechanisms are inconsistent between Carbon, Cocoa -- desktop links don't work from the shell -- MS Office uses ":" as path separator in dialog boxes -- X11 claims to use Mac keybindings but doesn't -- X11 doesn't support RANDR -- You can select "use SSL" in Mail.app, but it doesn't work; it does TLS instead
At this point, Gnome and KDE are far more consistent than the OS X GUI. That's not to say that the OS X GUI is bad--it's one of the better GUIs around, but it is hardly the best, most consistent, and/or most advanced GUI around.
The "Java enterprise" platform is ambiguous today, unless you're talking strictly of Sun J2EE components. If you find the J2EE components to be bloated and unwieldy, there are now plenty of lightweight alternatives.
You're missing the point: Sun has produced a hugely bloated platform, for the same reason that Shuttleworth's developers have--too much money, too much time on their hands, and little push to actually deliver something. The fact that desparate Java developers happen to have developed alternatives doesn't change that.
Fact is, Java has the best quality Open Source tools available today for developing business applications.
I think you should join Shuttleworth's software developers--you represent the same sort of gadget-happy idiocy that got them fired. Fortunately, people like you are easy enough to spot during interviews.
Java is the premiere Open Source language today and it is the rallying point behind the most successful commercial Open Source efforts.
Most of Java's open source activities can only be described as masturbatory--they don't contribute to anything other than more Java development. For real-world open source usage, Java has become largely irrelevant; on many Linux and BSD installations, it's not even installed anymore.
As any language, Java still has flaws but they are being fixed rapidly. Open Source developers need to collectively realize this and get with the program. The alternative is a world where.NET is the only relevant platform for anything beyond forums, blogs and CMS tools.
Slashdot Mirror
apparently the designers of Verizon's email system forgot some basic computing
Unlike "root" or "postmaster", the address "null" has no special meaning in an E-mail system.
I never put my personal/business address on a commercial site, unless it's a site I use for my business. Furthermore, I use a white list. Works like a champ.
Well, how nice for you that your life is so simple and your needs are so modest. However, many other people cannot use a white list.
His complaint is legitimate: it is exceptionally rude for Slashdot editors to manually unscramble an E-mail address and put it into a story.
Pray tell me how I can change say, the Linux kernel scheduler on the fly without having to recompile from source, install and reboot with the new image.
There are lots of ways. You load a new dynamic module and, if necessary, dispatch to it. In some cases, the dispatching happens automatically, in others, you replace the first instruction of an old subroutine with a jump to the new subroutine. GDB supports that, as do many rootkits.
For kernel development, most people seem to have stopped doing that because well-defined version control, automated builds, automated testing, and remote debugging seem to work better. Keep in mind that if you set up your kernel development environment well, you can reboot faster than you can type M-x eval-buffer.
The premise of HBHG is too similar to the DVC to be happenstance.
And the problem with that would be exactly what? Almost all great art--music, theater, literature, TV, SciFi, etc. has been created by copying and improving what has come before. Where do you think Shakespeare's plays come from? Bach's music? Mozart's operas? Babylon 5 and Star Trek plots? Even the most famous artists stand on the shoulders of generations of giants.
I guess your comment demonstrates what is wrong with IP law: not only have people like you gotten it into their heads that at the beginning of the 21st century, ideas should be owned, you are also so ignorant of history that you don't actually recognize how unprecedented that notion is.
There isn't any environment that comes even close to giving the kind of access they did. You could change kernel code WHILE THE SYSTEM WAS RUNNING, if you wanted to, or any other code for that matter.
You can do the same with UNIX or Linux.
If they didn't fuck up, conceivably you won't notice...
There are hundreds of known, often fatal diseases you can catch from a transplant. If the tissue was obtained illegally, you can bet they didn't test for those, and the donors probably weren't 18 year olds that died in a motorcycle accident.
So, I assume that when people get "tested", it's for things like hepatitis, HIV, and various parasites.
Pretty much all modern CPUs need special compilers to give good performance.
If pretty much all modern CPUs need a particular feature, it's not "special" anymore. What's "special" about Cell is the features that make it different from mainstream CPUs.
To prevent pipeline stalls, you need to make sure that you have a minimum of m instructions (and ideally m) between your load and your first operation that depends on the that data.
So, in addition to having to wait for the completion of the variable time operation, which the data-dependent operation has to do anyway, the equivalen RISC instruction sequence is going to fill up the pipeline and the cache with junk. But, hey, at least the pipeline didn't stall--the CPU designers have successfully pushed the problem off their plate. Thanks for illustrating my point.
In any case, I'm not defending complex instructions at any cost, I'm saying that CPU designers have gone too far in pushing problems off onto compilers. We may not need a string edit instruction, but we do need better support for various forms of parallelism than Cell or Itanium. I expect the evolution of MMX, hyperthreading, and multicore chips is going to be much more important than architectures like Cell or Itanium.
Apple has decided. They want to be a system for creative professionals and this is their primary market.
Seems to me, scientists, engineers, academics, and students are the most creative people around.
In any case, Apple is marketing to anybody they can, and science and academia is probably their most important after home users so they need to support them better. Apple simply has a conflict: they want people to port to Cocoa, but they also want to play in this market. I think it will be a few more years before Apple will resolve the conflict one way or another. I think that if they keep (nearly) ignoring the open source GUI technologies and try to compete with proprietary stuff, it's gonna hurt them badly.
This radical of a change in architecture
There's nothing "radical" about it--it's just a bunch of CPUs on a chip. It's about the least radical way in which you can put a bunch of CPUs on a chip, beyond multicore.
Lisp machines were dog slow and hugely expensive, even compared to the workstations around at the time. If you want that kind of environment, you can emulate it by running any of the interpreted languages so popular on Linux, Windows, and Macintosh (although you'll be hard pressed to be as slow as the Lisp machine).
As for not hiding reconfigurability: you can buy anything you desire as an add-on board, like an FPGA board or an array processor. People don't use them a lot because they are a pain to program and they don't give you good bang for the buck.
There has. Itanium is the most recent example. Most of those efforts fail because, in the real world, getting good performance only with a single compiler from a single vendor, and then usually only if the stars align right, isn't good enough.
1) Aqua's use of graphics cards for coprocessing is far beyond virtually any other OS. (Coreimage) [...] 2) Applescript. No one else has a scripting language which cuts across almost every app in the OS like this since Symbolics.
I disagree with both of those points, but it's not worth debating that.
3) Objective C is basically an apple technology
No, Objective C and its core libraries were developed by Stepstone, borrowing heavily from Xerox's Smalltalk-80 system. NeXT took Stepstone's system (and my impression is that the term "rip off" might apply), and Apple got the whole thing as part of the NeXT acquisition.
4) Adaptive dimming
You mean of the laptop screen? You must be kidding--consumer displays have been doing that for a long time.
5) Xgrid compiles
Do you mean distributed compilation? That's been around for at least two decades.
6) ACL technology in a mainstream OS.
Do you mean "access control lists"? Windows NT has had those for a long time, as have most UNIX systems. Linux has had them for half a dozen years as well. The reason you don't hear about them is because they don't work.
Even if your list of "innovations" were actually Apple innovations, you're really reaching for the bottom of the barrel--I mean, screen dimming? Come on. Compared to the massive amounts of innovation that have gone into Linux, UNIX, and Windows, at the kernel, library, UI, and application level, Macintosh is pretty dull technologically.
Again, that's not wrong or bad--Macs are decent, well-designed machines, but that's all.
Everybody's X came from MIT. What is means to write an X is to implement MIT's code for your platform. That is the definition and its been the definition of 20 years.
You don't know what you're talking about. X11 is a protocol, not a piece of software. The definition of X11 is the protocol, nothing else. There are probably dozens of implementations by now, many of which share little more than the definitions of data structures, and some of which don't share a line of code with any of the others.
The concept of a window system standard independent of an implementation may be hard to grasp for people like you, who have grown up at the mercy of a vendor that changes interfaces and codebases every couple of years, but it's a good concept and it works. It's why X11 is still going strong, while Apple and Microsoft have had to throw out their window systems several times, and will probably have to do so again in the next few years.
First off I and most other OSX users never change resolutions.
You aren't giving any presentations then.
To make it really work well, as you said above Apple would have to do a lot of work.
They could probably do it with the FTE's that are wasting their time on DarwinPorts.
Further using your definition they would have to abandon the HUGs. Which means it can't as long as the Macintosh is anything like it is today.
You mean their interface guidelines? Apple isn't following their own guidelines anyway; Macintosh consistency is a sham--it's been abandoned long ago, and supporting X11 properly doesn't make it any worse.
X11 works fine for experienced Unix users. You can ship software to a Unix user customer base which uses X11. You cannot ship software which uses X technology to the general Mac user base and Apple doesn't want you to. That's policy not a bug.
Apple needs to decide: do they want to be a professional system for scientists and engineers or do they want to be a hobbyist system. In the first case, they must support X11 better. It's not a question of whether scientists or engineers are too dumb to install and set up X11, it's that it's too much work. If people have to invest that much work in getting Macs to run, they might as well set up a Linux machine.
If a CPU needs a special compiler in order to give good performance, it's basically dead; there are simply too many different applications that do binary code generation.
Also, the division into "expert programmer" and "regular programmer" is silly. Most coding is done by people who aren't experts in the cell architecture (or any other architecture). That's not because people are too stupid to do this sort of thing, it's because it's not worth the investment.
If Cell can't deliver top-notch performance with a simple compiler back-end and regular programmers who know how to write decent imperative code, then Cell is going to lose. Hardware designers really need to get over the notion that they can push off all the hard stuff into software. People want hardware that works reliably, predictably,and with a minimum of software complexity.
Maybe CISC wasn't such a bad idea after all--you may get less bang for the buck, but at least you get a predictable bang for the buck.
Nobody has any idea of how well any kind of encasement technology holds up under those conditions or whether things you put there stay there. And once you put it there, you can't get it back out.
What's just as irresponsible is that fissile material is a scarce resource and without using breeder reactors, you are only using a tiny fraction of the energy you could potentially get from it.
As I'm reading what you want that's not "becoming a little more open" its a full change in the development direction of their OS
It's not about "being open", it's about producing a reasonably usable X11 server for their OS.
You conveniently skirted around the real biggies: the fact that screen resolutions and keymaps just don't work makes X11 almost completely unusable for day-to-day work.
I'm not sure if you are nitpicking or just poorly informed.
MITX11 -> X consortium X11 (old X.org) -> Xfree86 -> XDarwin -> Apple X11.
Neither. I'm pointing out that your claim that Apple "wrote a custom X11" is wrong--Apple didn't "write" an X11 implementation, they modified the MIT X11 implementation. Like a lot of "their" stuff, it's someone else's stuff that's been hacked a bit.
They have to replicate that work on both Carbon and Cocoa in both directions. Then they would have to keep it working through changes in both platforms. What you are asking for is a lot of work for apple. In particular it would mean coordinating their GUI development with open source GUIs.
Yes, that's what it would mean.
That seems deliberate to me, probably designed to stop virus and the like.
It probably is deliberate--it probably is to maintain non-Macintosh applications as foreign objects. Apple wants to tie developers and application writers to their platform.
Just change your startup scripts.
And how do I ship applications (open source or proprietary) that way? Am I supposed to give users a page of instructions on how to enable X11 and install Fink?
Well try fink. I've gotten to work fine.
Fink works a little better than DarwinPorts, but it's still unusable for mainstream use. Any mainstream Linux distribution is easier to install, more consistent, and easier to use than Fink on OS X.
If I want my X apps to really work well I'm using a Linux.
My point exactly: X11 doesn't reall work well on Macintosh, even though it could. X11 is a marketing gimmick for Apple right now, something that is intended to induce people to switch but that doesn't work well enough for heavy-duty use and that you can't ship software for.
Which brings me back to my original point: Apple doesn't really have any brilliant new technology. What they have is branding and single-source hardware/software. If Apple started shipping OS X as a layer on top of Windows, Apple would have nothing left to support such a huge company. Apple knows that, which is why they will continue shipping the software/hardware combo that they are shipping, and why they will keep crippling the open source compatiblity of their system.
1) X11 integration is great.
No, it's not.
Apple wrote a custom X11
No, they didn't. They modified MIT X11.
which can share a clipboard, is Aqua aware, integrates with the Dock, has a Mac like Window manager.....
Have you ever tried USING X11 for anything non-trivial on the Mac? Try running OpenOffice 2.0 on OS X, it shows some of the blatant shortcomings pretty easily. For example, X11 doesn't pick up the Mac international keybindings, even though it should. Native X11 keyboard rebinding doesn't work properly so that you can't even have consistent key bindings between X11 and native apps. X11 doesn't change resolution when Quartz does, making it impossible to use Impress for presentations. Dragging from the finder doesn't work. Most cut-and-paste operations other than plain text don't work. All X11 apps are a single group. You can't start X11 apps by double clicking (everybody gets around that by having special startup scripts). X11 isn't even preinstalled out of the box, or started up automatically.
Apple knows about these problems, they just don't fix them--deliberately.
2) Apple has paid FTE's working on the DarwinPorts project. Their gnome support seems pretty good.
DarwinPorts is unusable: installing packages takes forever, and that's assuming they even compile. A large proportion (I'd guess about 1/3-1/2) packages fail to compile altogether (among other things, I have never been able to get a working Gnome or Gtk+ out of DarwinPorts).
3) I assume you mean GTK on an equal footing since Gnome::GTK, OSX::Cocoa/Carbon see diagram. But in that case it isn't the Gnome GUI so I don't know what you mean.
It means fixing the above problems with X11, preinstalling and automatically starting X11, preinstalling the Gnome and Gtk+ libraries, automatically starting the Gnome servers at startup, and doing whatever is necessary behind the scenes to make the Finder integrate with Gnome apps like the native Gnome file manager. It probably means a few other things, but that would be a good start.
In the end, Apple doesn't care about the underlying OS. Mach was handy, they only need a substrate to run their desktop environment atop. [...] Sooner or later Steve will swollow his pride and create a subsystem consisting of a modernized POSIX and NextStep and that will be OS XI. It will also ship with all of the Vista subsystem. That will allow all the device installers to run and gain the ability to run all Windows apps besides. Which also solves the Microsoft Office availibility problem.
That would reduce Apple to an application vendor. How long do you think Apple is going to last as a vendor of iApplications and Cocoa libraries? They'd be competing with software companies having a few dozen employees and (in the case of Cocoa) better libraries and better IDEs.
Apple has no unique technology, they have almost no research, and they don't really innovate. What Apple has going for them is branding, style, and an all-in-one solution. That's enough to be successful in this market (many other companies survive on branding and style alone), but if they try to take on Windows software houses or PC hardware vendors head-on on price and functionality, they're going to lose.
The one thing Apple could and should do is become a little more open to open source technologies. In particular, Apple should make X11 and Gnome a GUI environment on equal footing with Carbon and Cocoa. Right now, Gnome is a cumbersome third party install, and their X11 integration sucks.
If other sites pirate P10's images and those sites misrepresent the images as being theirs, then those sites should be held responsible, not Google.
It's irresponsible to keep using nuclear energy before we have solved the question of waste disposal.
In fact, technically, waste disposal is not such a big problem: using breeder reactors, nuclear power could be generated without large amounts of high-level waste. Unfortunately, breeder reactors can theoretically be used to produce weapons-grade material, so the US government prefers accumulating lots of hard-to-dispose of high-level waste rather than building breeder reactors.
The "Get Info > Open With..." functionality in the finder is worse than nothing at all because it doesn't work reliably (probably because the Mac can't decide whether it wants to use file extensions, codes, or content for determining file types). It's another example of how inconsistent the Mac actually has become.
The only thing that works reasonably well is to get the "Default Apps" plugin for System Preferences.
OS X is based on Mach with a BSD emulation layer on top of it, some BSD command line tools, and NeXTStep libraries.
Furthermore, the point of running BSD or Linux on the Mac is to get rid of a lot of the bloat that Apple has added, and instead run a pure, consistent X11 desktop; less is more in this case.
Well, you list a few smaller items, there are lots more. I'd collected about a hundred different problems that I noticed over time before I stopped. Some that come to mind are:
-- green button does something unpredictable
-- bindings of files to applications change haphazardly and incomprehensibly
-- there's no built-in mechanism for fixing unwanted file associations
-- can't drag file items from dock
-- application menus make menu tools disappear
-- applications are inconsistent in what they do when the last window closes
-- key binding mechanisms are inconsistent between Carbon, Cocoa
-- desktop links don't work from the shell
-- MS Office uses ":" as path separator in dialog boxes
-- X11 claims to use Mac keybindings but doesn't
-- X11 doesn't support RANDR
-- You can select "use SSL" in Mail.app, but it doesn't work; it does TLS instead
At this point, Gnome and KDE are far more consistent than the OS X GUI. That's not to say that the OS X GUI is bad--it's one of the better GUIs around, but it is hardly the best, most consistent, and/or most advanced GUI around.
The "Java enterprise" platform is ambiguous today, unless you're talking strictly of Sun J2EE components. If you find the J2EE components to be bloated and unwieldy, there are now plenty of lightweight alternatives.
.NET is the only relevant platform for anything beyond forums, blogs and CMS tools.
You're missing the point: Sun has produced a hugely bloated platform, for the same reason that Shuttleworth's developers have--too much money, too much time on their hands, and little push to actually deliver something. The fact that desparate Java developers happen to have developed alternatives doesn't change that.
Fact is, Java has the best quality Open Source tools available today for developing business applications.
I think you should join Shuttleworth's software developers--you represent the same sort of gadget-happy idiocy that got them fired. Fortunately, people like you are easy enough to spot during interviews.
Java is the premiere Open Source language today and it is the rallying point behind the most successful commercial Open Source efforts.
Most of Java's open source activities can only be described as masturbatory--they don't contribute to anything other than more Java development. For real-world open source usage, Java has become largely irrelevant; on many Linux and BSD installations, it's not even installed anymore.
As any language, Java still has flaws but they are being fixed rapidly. Open Source developers need to collectively realize this and get with the program. The alternative is a world where
The sooner the better as far as I'm concerned.