The sheer pain of doing non-trivial code generation with C++ templates makes it not worth it. Even something relatively simple like Boost.Lambda, which doesn't generate all that much code when you think of it, is nearly unusable because of how much it shows down compilation and how throughly it messes up any error messages for errors made in the vicinity of a template call. It would be a massive PITA to use an API that generated a non-trivial amount of marshaling code using the template mechanism.
Since "4.0" in a computer often means something like 3.99999, as computers cannot in general represent real number precisely, they definitely should not be equal.
The QPL was not GPL compatible, and it was being linked against (L)GPL'ed code. It was a blatant license conflict, and it took three years to resolve.
And of course, with GNOME 2.0, your point is moot anyway. GNOME now distinguishes itself from KDE by having a GUI that isn't a complete and utter clusterfuck.
There are lots of links. For example, there are lots of connections between the development of syntax and grammers in linguistics and the work on syntax and grammer in computer languages.
I don't think the Carnot cycle is applicable to fuel cells directly. However, I think the Carnot efficiency would be applicable to any system that did work based on the energy provided by a fuel cell.
My math is not so good. I thought the integers modulo n formed a field, but apparently its only a field if n is prime. So what's the correct term for the set of integers modulo 2^n where n = 32 or 64?
There is nothing to explain. Not all mechanisms of converting chemical energy to more useful forms are governed by the Carnot efficiency. Fuel cells are one example of energy conversion systems that aren't. As I said, I don't know if the metabolic processes within a person are so-governed.
I'm not trying to make a comment about the efficiency of humans versus car engines one way or the other. What I'm saying is that just because human beings have had millions of years of evolution it does not mean that they are necessarily more efficient than a car engine. Humans have to operate within the constraints of what is suitable for living cells, which is an environment that is not particularly suitable for efficient power generation. Power generation through thermal cycles is just an example of that.
Its a basic principle of thermodynamics that the efficiency of an engine is proportional to the temperature gradient within the engine cycle. While this principle is specific to Carnot and Brayton cycles, and I don't know enough about biology to know whether you could model a human being that way, I wouldn't be at all surprised if the high combustion temperature within a car engine made it a lot more efficient at extracting energy from a given mass of fuel than a human being.
The improvement from FORTRAN to a modern Lisp (circa 1985) is not incremental at all. Relative to assembly, FORTRAN abtracts registers into variables, and branches into loops and functions. Additionally, it automates static storage layout. Relative to FORTRAN, Lisp additionally abstracts memory into objects, machine arithmetic into actual arithmetic*, and simple functions into higher-order, polymorphic functions**. Moreover, it automates dynamic storage management, and abstracts large-scale code patterns with macros. Add all those together, and the delta betweeen Lisp and FORTRAN is easily as large as the delta between FORTRAN and assembly.
*) Ie: the integer type in FORTRAN or C isn't an integer in the mathematical sense, but a finite field. Addition of integers isn't real addition, but modulo addition. Division over integers isn't real division, its truncation.
**) In FORTRAN functions are primitives, while in Lisp functions are first-class values. Moreover, until FORTRAN 90 functions could not be recursive.
At the end of the day, open source developers do stuff for the community, for free. It's important never to forget that. If the developers want to build a successful project, then he'll obviously have to take user input, but if the "user" isn't respectful enough to offer criticism constructively, then honestly he's not worth anybody's time. If the problem he poses is important, then somebody polite will probably bring it up anyway, there is no reason to reward assholes by paying attention to them.
My aero engineer friend has really never done any of that, so he's an engineer who doesn't know what "empiricism" means. Is this also a failing by our educational system? Isn't such education necessary to be a good researcher?
It's not necessary for being a good researcher. You don't need anything to do aerospace engineering other than a knack for differential equations, and these days the ability to bend Matlab to your will.
On the other hand, I'd argue that having an understanding of philosophy and history is probably a prerequisite from being a good citizen. However, and perhaps this is exposing my biases as an engineer, in my experience engineers tend to have a better knowledge of the humanities than humanities majors have of science and engineering. A philosophy major or literature major will never have to take physics, but at most universities an engineering major will have to take several semesters of history, english, and a social science or two.
I'm going to be the last one to defend Haliburton, but exactly where do "American wages for American employees" fit in here? If 90% of their business is in the Middle East, doesn't it make sense to hire local employees?
On a larger scale, what's with the idea that a company owes Americans jobs just because they're American? What happened to land of the free and all that jazz?
The fucking populists are overrunning this country, and I don't like it one bit...
My question is why would anybody run MacOS X as a UNIX distribution when there are other UNIXes out there that are a lot cheaper to buy, such as BSD, Solaris, and Linux.
That really wasn't the point of the original post. The original poster complained, in so many words, that OS X was isolationist and did everything its own way. That's wrong. Whenever possible, OS X does things how other modern *NIXs do things. Aside from Quartz, Cocoa, and Carbon, most everything in OS X is built off open technologies. OpenGL, LDAP, CUPS, NFS, SSH, etc are all part of the core platform.
Not to mention that running UNIX programs in OS X is more trouble at first as OS X doesn't natively use X11 and it will include none of the standard Qt or GTK libraries, X11, or GCC in a standard installation.
X11 and GCC are on every OS X installation CD. Yeah, it doesn't install them by default, but then again, Ubuntu doesn't install GCC by default either!
I bet that any CIO worth their Mountain Dew ration will feel the same way.
Again, we're not talking about buying OS X to get a UNIX, but buying OS X and getting a UNIX as part of the bargain. You don't need to have OS X to get a machine that uses UNIX standards, but if you do buy OS X machines, they can integrate into your environment much like any other UNIX.
Oh, and Linux does not necessarily have its own disk format like Solaris, OS X, or Windows do. Linux will install on ext2, ext3, ReiserFS 3, XFS, and JFS.
Of those, only XFS and JFS weren't especially designed for Linux. And it took several years to port XFS to Linux, reinforcing my point that filesystems are by and large closely tied to their host OS. Also, ext3 is the de-facto standard Linux filesystem. Every major distribution ships ext3 as the default, and its the first one to get improvements like the low-latency work and fine-grained locking.
And to be fair, OS X installs on UFS just fine, though some apps don't like the case-sensitivity.
And with the exception of ReiserFS and ext4, all of the Linux filesystems are fully read-write in at least one other OS. For example, Windows can read-write ext2 and ext3 via the IFS driver.
And both Linux and Windows can read-write HFS+. However, Windows won't install on ext2 or UFS, Linux won't install on NTFS, UFS, or HFS+, so why is it a surprise that OS X won't install on NTFS or ext3? The original poster asked "why does OS X use its own disk format", and the answer is: "almost every OS uses its own, preferred disk format". There are exceptions, and Linux is particularly flexible in this regard, but even on Linux there is a de-facto standard that is the most well-supported.
All the ones you mentioned (ext, reiser) are Linux-specific. XFS and JFS aren't, but they are very rarely used. No distro ships either as the default FS. And yes, you can mount ext filesystems on Windows, but then again you can mount HFS+ on Linux and Windows, and NTFS in Linux and OS X. However, despite this capability, these OSs still all use their native filesystems as their primary ones. OS X is really no different than Linux or Windows in that regard.
Its a really stupid idea to compare different configurations with different prices. It's like complaining that tires cost more than milk. If you want to say, "Apple has a limited range of choices", then fine, just say that, its perfectly clear what that means. But if you say "Apple is more expensive", be prepared to back up how an Apple machine costs more than a comparable PC.
Ever since the Intel transition, Macs have been really competitively priced within their market segments, its just that Apple doesn't target a full range of markets.
1) Apple also would have to be a team player. Where is AIX blended with OS X running on IBM servers to make things go fast forward?
Blending things with AIX doesn't make much sense, given that Apple is now on x86 and AIX is for PowerPC. Moreover, why would you want to? If you need a serious, heavy-duty server, run AIX or Linux, OS X will inter-operate perfectly via standard UNIX technologies (NFS, LDAP, etc). If you need an easy-to-admin small server, run OS X server, and all your Linux and Windows clients will be able to use it just fine.
2) Apple also would have to actively integrate other software. Actively, Apple will support Windows and Linux integration on Macintosh computers.
It does. OS X uses standard UNIX tools extensively. Underneath the GUI, it's all GCC, Samba, NFS, Apache, CUPS, etc, etc.
5) Standardized software interfaces. Why does Apple have to use their own disk format? Why does Apple have to do all kinds of things "their own way"?
Apple supports the major standardized UNIX software interfaces. OS X 10.5 will be officially SUSv3 compliant (though at this point, trying to be Linux-compatible is probably more useful). It supports standard protocols like LDAP, NFS, SSH, etc. It does use its own disk format, but then again almost every OS uses its own disk format. Disk formats are not standardized, invariably poorly documented (or in the case of NTFS, undocumented), and usually very closely-tied to the kernel implementation. That's why Linux uses EXT3, AIX uses JFS2, Windows uses NTFS, BSD uses UFS, Solaris uses ZFS, etc.
That's the kind of requirements you have to meet for aerospace/chemical/nuclear/mechanical engineering. The standards for software "engineering" are nowhere close to being as rigorous.
Eh, cut me a break;) They just shipped it in Herd 5, which came out a few days ago. Before that, they had planned to defer shipping it at all. They still don't enable it by default (and neither does Fedora Core 6), which implies its still not fully ready for prime-time.
I look at Safari, frontend is written in Carbon while the backend is written in C -- You can't really do much complicated programs it seems in Carbon or Cocoa from what I've seen in Mac software, you end up getting into horrible issues if you attempt todo so. I don't really see those languages being superior to others that have GTK+ or even QT bindings.
What the hell are you talking about you can't do complicated programs in Carbon/Cocoa? Examples? And yes, I agree that C and Obj-C aren't great languages, but its very easy to bind to Carbon from Lisp (a hell of a lot easier than binding to Qt, and I know that from first-hand experience!), and OpenMCL even has Cocoa bindings. There are also Cocoa bindings to Python, if you don't do the sexprs thing.
Well, they seem to be doing more OS releases in less time, but they stop supporting older systems a lot faster than Microsoft does and Microsoft definitely stops supporting older software than the Linux communities do. I can't really say Apple is gaining speed on Linux because of this.
What does dropping support for older systems have to do with the rate of progress?
Sorry, I can't see this as a bad thing.
I'm not saying its a bad thing. Carbon would be a lot cleaner if it didn't have decades of Mac baggage behind it. But to be fair, Carbon is getting cleaner, and GTK+ is picking up baggage of its own. The transition to Cairo from GDK is only partially complete, for example, so you have the same kind of overlap you do in Carbon between Quartz and QuickDraw. At least OS X 10.5 deprecates QuickDraw, and its getting to the point where you can safely ignore a lot of the archaic stuff and stick to the new APIs.
I think Linux distributions will be catching up a lot faster with OS X's graphical effect engines a lot sooner than your prediction (which personally I couldn't really care for -- Nor understand why pointless effects make a desktop so technically superior).
It's not the effects, its the technical capabilities of the stack underneath. It's the ability to do resolution-independent drawing, compositing, synchronized move/resize, etc. These are the features that make a desktop technically superior, like zero-copy networking or fine-grained locking might make a kernel technically superior.
I don't see redesigns being a issue on Linux. It's not like it would have to break compatability with older applications.
The stack just moved to XRender relatively recently. Moving to something else is going to be... painful.
By the way, which features are you referring to?
The basic problem is that XRender abstracts the GPU too much. Basically, it gives you composited trapezoid drawing, without exposing any programmability capabilities. It turns out that if you want to use the GPU to accelerate the vector graphics library, it helps to have much more access to the features of the GPU than XRender gives you (see some of Zack Rusin's work on Qt on OpenGL, Loop and Blinn's work on vector textures, and Apple's APIs like CoreImage). This basically leaves you in the position of bypassing XRender and using OpenGL directly, which is not feasible because it has lots of bad consequences in the rest of the stack. My guess is that they'll solve this GLX, giving the X server a single GL context and having all applications render indirectly. AIGLX sets up the infrastructure for doing this, but its still very far away.
I see they have it installed by default, but still not enabled by default. Which is a sensible solution. In my experience Compiz is somewhat adequate on a system suited for it (eg: the GMA950 in my MacBook runs Compiz in Fedora Core 6 just fine), but it doesn't work well on a lot of other machines.
Of course, even when it works, its still not even at OS X 10.0 levels. It's pretty fast it doesn't support critical things like synchronized buffer swapping. What's the point of spending all that memory on a compositor and double-buffering if you don't synchronize the buffer swap, and thus still get tearing during resize and move operations?
You might think I'm nitpicking, but the tearing during window reconfigure is really a major sign of the immaturity of the infrastructure. Doing proper double-buffered resize and move is a complex operation, involving synchronization of the toolkit, compositing/window manager, X server, and graphics driver. The fact that its not there yet suggests that there is a lot of work to go before the stack is even at OS X 10.0 levels of maturity.
What carefully prepared comparison? I picked the D620 off Dell's website and just matched the major specs (CPU/GPU/RAM/HDD). I didn't even bother to match things like firewire or the webcam, which would have made the Dell even less attractive. And I picked the D620 because: a) it was similar in size unlike the E1505, and b) because I've owned Inspirons and they're pieces of shit.
The E1505 is a completely different class of machine. It's a full pound heaver, a third of an inch thicker, an inch and a quarter wider, and an inch and a half deeper.
In the laptop market, the price of the machine isn't just proportional to the specifications, but to the size, weight, and build materials. Smaller machines cost more to build, and they sell for more. The E1505 is bigger, heavier, and (from direct experience), more cheaply built. No surprise that its cheaper. Indeed, its no surprise that its cheaper than Dell's own Latitude, which is more expensive than the E1505 precisely because its smaller and better-built.
The MacBook's closest competitors, from the point of view of specifications and form-factor, are the Vaio C series, ThinkPad T 14.1", the Latitude D620, and Asus's 13.3" model. Relative to the Vaio, the MacBook has more features for the same price and similar build quality. Relative to the ThinkPad, it is heavier and a bit less sturdy, but with a better screen and more features at a slightly lower price. Relative to the D620 its better built and has a better screen for a slightly higher price. And its almost identical to the Asus model at the same price.
When I bought my MacBook, I did some comparison shopping. In its size/weight category, its really hard to find a better notebook at the price. You can get bigger features by going to a bigger form-factor, but lugging around a 15" laptop is a PITA. You can also save money by going with less performance (in particular, dropping the dual core or going to an AMD chip will save you a lot of money). However, if you want a fast dual-core machine in a mid-sized form-factor, the MB is a great choice.
I question any kind of technical superiority below the window dressing
As a desktop system, I'd say OS X is technically superior to Linux. As far as UNIX's go, Darwin state of the art circa 1995, but its perfectly adequate for a desktop machine that doesn't need to saturate a 400 MB/sec RAID array or handle a server with a thousand concurrent threads.
On the other hand, the graphical infrastructure is really superior. Quartz is a couple of years ahead of Cairo in maturity and performance, which is not so surprising given that its several years older. The compositing infrastructure is really mature in OS X, while its immature enough in Linux that Ubuntu still doesn't see fit to ship a compositing manger by default in Feisty Fawn. And HIView/HIToolbox (the view/control framework that's been slotted underneath Carbon and Cocoa) is miles ahead of GTK+, although the latter has a much cleaner API with less historical baggage. And DRI is just now getting some crucial features (management of GPU memory, virtualization of GPU resources) that OS X's GL stack has had for a while now.
As for slowing down, there is really no indication that Apple is moving more slowly than Linux. It'll still be a couple of years yet before the DRI/X.org/GTK+ stack catch up with OS X 10.4, much less what's in 10.5. And there are some really fundamental problems with XRender that would keep it, without a significant redesign, from being able to support features past what Apple introduced in OS X 10.2.
Slashdot Mirror
The sheer pain of doing non-trivial code generation with C++ templates makes it not worth it. Even something relatively simple like Boost.Lambda, which doesn't generate all that much code when you think of it, is nearly unusable because of how much it shows down compilation and how throughly it messes up any error messages for errors made in the vicinity of a template call. It would be a massive PITA to use an API that generated a non-trivial amount of marshaling code using the template mechanism.
Rich people (especially smart rich people) are more important than everyone else. What's so hard about that to understand?
Since "4.0" in a computer often means something like 3.99999, as computers cannot in general represent real number precisely, they definitely should not be equal.
The QPL was not GPL compatible, and it was being linked against (L)GPL'ed code. It was a blatant license conflict, and it took three years to resolve.
And of course, with GNOME 2.0, your point is moot anyway. GNOME now distinguishes itself from KDE by having a GUI that isn't a complete and utter clusterfuck.
There are lots of links. For example, there are lots of connections between the development of syntax and grammers in linguistics and the work on syntax and grammer in computer languages.
Thanks. That's why I'm an engineer and not a mathematician ;)
I don't think the Carnot cycle is applicable to fuel cells directly. However, I think the Carnot efficiency would be applicable to any system that did work based on the energy provided by a fuel cell.
My math is not so good. I thought the integers modulo n formed a field, but apparently its only a field if n is prime. So what's the correct term for the set of integers modulo 2^n where n = 32 or 64?
There is nothing to explain. Not all mechanisms of converting chemical energy to more useful forms are governed by the Carnot efficiency. Fuel cells are one example of energy conversion systems that aren't. As I said, I don't know if the metabolic processes within a person are so-governed.
I'm not trying to make a comment about the efficiency of humans versus car engines one way or the other. What I'm saying is that just because human beings have had millions of years of evolution it does not mean that they are necessarily more efficient than a car engine. Humans have to operate within the constraints of what is suitable for living cells, which is an environment that is not particularly suitable for efficient power generation. Power generation through thermal cycles is just an example of that.
Its a basic principle of thermodynamics that the efficiency of an engine is proportional to the temperature gradient within the engine cycle. While this principle is specific to Carnot and Brayton cycles, and I don't know enough about biology to know whether you could model a human being that way, I wouldn't be at all surprised if the high combustion temperature within a car engine made it a lot more efficient at extracting energy from a given mass of fuel than a human being.
The improvement from FORTRAN to a modern Lisp (circa 1985) is not incremental at all. Relative to assembly, FORTRAN abtracts registers into variables, and branches into loops and functions. Additionally, it automates static storage layout. Relative to FORTRAN, Lisp additionally abstracts memory into objects, machine arithmetic into actual arithmetic*, and simple functions into higher-order, polymorphic functions**. Moreover, it automates dynamic storage management, and abstracts large-scale code patterns with macros. Add all those together, and the delta betweeen Lisp and FORTRAN is easily as large as the delta between FORTRAN and assembly.
*) Ie: the integer type in FORTRAN or C isn't an integer in the mathematical sense, but a finite field. Addition of integers isn't real addition, but modulo addition. Division over integers isn't real division, its truncation.
**) In FORTRAN functions are primitives, while in Lisp functions are first-class values. Moreover, until FORTRAN 90 functions could not be recursive.
At the end of the day, open source developers do stuff for the community, for free. It's important never to forget that. If the developers want to build a successful project, then he'll obviously have to take user input, but if the "user" isn't respectful enough to offer criticism constructively, then honestly he's not worth anybody's time. If the problem he poses is important, then somebody polite will probably bring it up anyway, there is no reason to reward assholes by paying attention to them.
My aero engineer friend has really never done any of that, so he's an engineer who doesn't know what "empiricism" means. Is this also a failing by our educational system? Isn't such education necessary to be a good researcher?
It's not necessary for being a good researcher. You don't need anything to do aerospace engineering other than a knack for differential equations, and these days the ability to bend Matlab to your will.
On the other hand, I'd argue that having an understanding of philosophy and history is probably a prerequisite from being a good citizen. However, and perhaps this is exposing my biases as an engineer, in my experience engineers tend to have a better knowledge of the humanities than humanities majors have of science and engineering. A philosophy major or literature major will never have to take physics, but at most universities an engineering major will have to take several semesters of history, english, and a social science or two.
I'm going to be the last one to defend Haliburton, but exactly where do "American wages for American employees" fit in here? If 90% of their business is in the Middle East, doesn't it make sense to hire local employees?
On a larger scale, what's with the idea that a company owes Americans jobs just because they're American? What happened to land of the free and all that jazz?
The fucking populists are overrunning this country, and I don't like it one bit...
My question is why would anybody run MacOS X as a UNIX distribution when there are other UNIXes out there that are a lot cheaper to buy, such as BSD, Solaris, and Linux.
That really wasn't the point of the original post. The original poster complained, in so many words, that OS X was isolationist and did everything its own way. That's wrong. Whenever possible, OS X does things how other modern *NIXs do things. Aside from Quartz, Cocoa, and Carbon, most everything in OS X is built off open technologies. OpenGL, LDAP, CUPS, NFS, SSH, etc are all part of the core platform.
Not to mention that running UNIX programs in OS X is more trouble at first as OS X doesn't natively use X11 and it will include none of the standard Qt or GTK libraries, X11, or GCC in a standard installation.
X11 and GCC are on every OS X installation CD. Yeah, it doesn't install them by default, but then again, Ubuntu doesn't install GCC by default either!
I bet that any CIO worth their Mountain Dew ration will feel the same way.
Again, we're not talking about buying OS X to get a UNIX, but buying OS X and getting a UNIX as part of the bargain. You don't need to have OS X to get a machine that uses UNIX standards, but if you do buy OS X machines, they can integrate into your environment much like any other UNIX.
Oh, and Linux does not necessarily have its own disk format like Solaris, OS X, or Windows do. Linux will install on ext2, ext3, ReiserFS 3, XFS, and JFS.
Of those, only XFS and JFS weren't especially designed for Linux. And it took several years to port XFS to Linux, reinforcing my point that filesystems are by and large closely tied to their host OS. Also, ext3 is the de-facto standard Linux filesystem. Every major distribution ships ext3 as the default, and its the first one to get improvements like the low-latency work and fine-grained locking.
And to be fair, OS X installs on UFS just fine, though some apps don't like the case-sensitivity.
And with the exception of ReiserFS and ext4, all of the Linux filesystems are fully read-write in at least one other OS. For example, Windows can read-write ext2 and ext3 via the IFS driver.
And both Linux and Windows can read-write HFS+. However, Windows won't install on ext2 or UFS, Linux won't install on NTFS, UFS, or HFS+, so why is it a surprise that OS X won't install on NTFS or ext3? The original poster asked "why does OS X use its own disk format", and the answer is: "almost every OS uses its own, preferred disk format". There are exceptions, and Linux is particularly flexible in this regard, but even on Linux there is a de-facto standard that is the most well-supported.
All the ones you mentioned (ext, reiser) are Linux-specific. XFS and JFS aren't, but they are very rarely used. No distro ships either as the default FS. And yes, you can mount ext filesystems on Windows, but then again you can mount HFS+ on Linux and Windows, and NTFS in Linux and OS X. However, despite this capability, these OSs still all use their native filesystems as their primary ones. OS X is really no different than Linux or Windows in that regard.
All the filesystems you mentioned are Linux-specific. It can use XFS and JFS, but that's done very rarely.
Its a really stupid idea to compare different configurations with different prices. It's like complaining that tires cost more than milk. If you want to say, "Apple has a limited range of choices", then fine, just say that, its perfectly clear what that means. But if you say "Apple is more expensive", be prepared to back up how an Apple machine costs more than a comparable PC.
Ever since the Intel transition, Macs have been really competitively priced within their market segments, its just that Apple doesn't target a full range of markets.
1) Apple also would have to be a team player. Where is AIX blended with OS X running on IBM servers to make things go fast forward?
Blending things with AIX doesn't make much sense, given that Apple is now on x86 and AIX is for PowerPC. Moreover, why would you want to? If you need a serious, heavy-duty server, run AIX or Linux, OS X will inter-operate perfectly via standard UNIX technologies (NFS, LDAP, etc). If you need an easy-to-admin small server, run OS X server, and all your Linux and Windows clients will be able to use it just fine.
2) Apple also would have to actively integrate other software. Actively, Apple will support Windows and Linux integration on Macintosh computers.
It does. OS X uses standard UNIX tools extensively. Underneath the GUI, it's all GCC, Samba, NFS, Apache, CUPS, etc, etc.
5) Standardized software interfaces. Why does Apple have to use their own disk format? Why does Apple have to do all kinds of things "their own way"?
Apple supports the major standardized UNIX software interfaces. OS X 10.5 will be officially SUSv3 compliant (though at this point, trying to be Linux-compatible is probably more useful). It supports standard protocols like LDAP, NFS, SSH, etc. It does use its own disk format, but then again almost every OS uses its own disk format. Disk formats are not standardized, invariably poorly documented (or in the case of NTFS, undocumented), and usually very closely-tied to the kernel implementation. That's why Linux uses EXT3, AIX uses JFS2, Windows uses NTFS, BSD uses UFS, Solaris uses ZFS, etc.
That's the kind of requirements you have to meet for aerospace/chemical/nuclear/mechanical engineering. The standards for software "engineering" are nowhere close to being as rigorous.
Wrong.
;) They just shipped it in Herd 5, which came out a few days ago. Before that, they had planned to defer shipping it at all. They still don't enable it by default (and neither does Fedora Core 6), which implies its still not fully ready for prime-time.
Eh, cut me a break
I look at Safari, frontend is written in Carbon while the backend is written in C -- You can't really do much complicated programs it seems in Carbon or Cocoa from what I've seen in Mac software, you end up getting into horrible issues if you attempt todo so. I don't really see those languages being superior to others that have GTK+ or even QT bindings.
What the hell are you talking about you can't do complicated programs in Carbon/Cocoa? Examples? And yes, I agree that C and Obj-C aren't great languages, but its very easy to bind to Carbon from Lisp (a hell of a lot easier than binding to Qt, and I know that from first-hand experience!), and OpenMCL even has Cocoa bindings. There are also Cocoa bindings to Python, if you don't do the sexprs thing.
Well, they seem to be doing more OS releases in less time, but they stop supporting older systems a lot faster than Microsoft does and Microsoft definitely stops supporting older software than the Linux communities do. I can't really say Apple is gaining speed on Linux because of this.
What does dropping support for older systems have to do with the rate of progress?
Sorry, I can't see this as a bad thing.
I'm not saying its a bad thing. Carbon would be a lot cleaner if it didn't have decades of Mac baggage behind it. But to be fair, Carbon is getting cleaner, and GTK+ is picking up baggage of its own. The transition to Cairo from GDK is only partially complete, for example, so you have the same kind of overlap you do in Carbon between Quartz and QuickDraw. At least OS X 10.5 deprecates QuickDraw, and its getting to the point where you can safely ignore a lot of the archaic stuff and stick to the new APIs.
I think Linux distributions will be catching up a lot faster with OS X's graphical effect engines a lot sooner than your prediction (which personally I couldn't really care for -- Nor understand why pointless effects make a desktop so technically superior).
It's not the effects, its the technical capabilities of the stack underneath. It's the ability to do resolution-independent drawing, compositing, synchronized move/resize, etc. These are the features that make a desktop technically superior, like zero-copy networking or fine-grained locking might make a kernel technically superior.
I don't see redesigns being a issue on Linux. It's not like it would have to break compatability with older applications.
The stack just moved to XRender relatively recently. Moving to something else is going to be... painful.
By the way, which features are you referring to?
The basic problem is that XRender abstracts the GPU too much. Basically, it gives you composited trapezoid drawing, without exposing any programmability capabilities. It turns out that if you want to use the GPU to accelerate the vector graphics library, it helps to have much more access to the features of the GPU than XRender gives you (see some of Zack Rusin's work on Qt on OpenGL, Loop and Blinn's work on vector textures, and Apple's APIs like CoreImage). This basically leaves you in the position of bypassing XRender and using OpenGL directly, which is not feasible because it has lots of bad consequences in the rest of the stack. My guess is that they'll solve this GLX, giving the X server a single GL context and having all applications render indirectly. AIGLX sets up the infrastructure for doing this, but its still very far away.
I see they have it installed by default, but still not enabled by default. Which is a sensible solution. In my experience Compiz is somewhat adequate on a system suited for it (eg: the GMA950 in my MacBook runs Compiz in Fedora Core 6 just fine), but it doesn't work well on a lot of other machines.
Of course, even when it works, its still not even at OS X 10.0 levels. It's pretty fast it doesn't support critical things like synchronized buffer swapping. What's the point of spending all that memory on a compositor and double-buffering if you don't synchronize the buffer swap, and thus still get tearing during resize and move operations?
You might think I'm nitpicking, but the tearing during window reconfigure is really a major sign of the immaturity of the infrastructure. Doing proper double-buffered resize and move is a complex operation, involving synchronization of the toolkit, compositing/window manager, X server, and graphics driver. The fact that its not there yet suggests that there is a lot of work to go before the stack is even at OS X 10.0 levels of maturity.
What carefully prepared comparison? I picked the D620 off Dell's website and just matched the major specs (CPU/GPU/RAM/HDD). I didn't even bother to match things like firewire or the webcam, which would have made the Dell even less attractive. And I picked the D620 because: a) it was similar in size unlike the E1505, and b) because I've owned Inspirons and they're pieces of shit.
The E1505 is a completely different class of machine. It's a full pound heaver, a third of an inch thicker, an inch and a quarter wider, and an inch and a half deeper.
In the laptop market, the price of the machine isn't just proportional to the specifications, but to the size, weight, and build materials. Smaller machines cost more to build, and they sell for more. The E1505 is bigger, heavier, and (from direct experience), more cheaply built. No surprise that its cheaper. Indeed, its no surprise that its cheaper than Dell's own Latitude, which is more expensive than the E1505 precisely because its smaller and better-built.
The MacBook's closest competitors, from the point of view of specifications and form-factor, are the Vaio C series, ThinkPad T 14.1", the Latitude D620, and Asus's 13.3" model. Relative to the Vaio, the MacBook has more features for the same price and similar build quality. Relative to the ThinkPad, it is heavier and a bit less sturdy, but with a better screen and more features at a slightly lower price. Relative to the D620 its better built and has a better screen for a slightly higher price. And its almost identical to the Asus model at the same price.
When I bought my MacBook, I did some comparison shopping. In its size/weight category, its really hard to find a better notebook at the price. You can get bigger features by going to a bigger form-factor, but lugging around a 15" laptop is a PITA. You can also save money by going with less performance (in particular, dropping the dual core or going to an AMD chip will save you a lot of money). However, if you want a fast dual-core machine in a mid-sized form-factor, the MB is a great choice.
I question any kind of technical superiority below the window dressing
As a desktop system, I'd say OS X is technically superior to Linux. As far as UNIX's go, Darwin state of the art circa 1995, but its perfectly adequate for a desktop machine that doesn't need to saturate a 400 MB/sec RAID array or handle a server with a thousand concurrent threads.
On the other hand, the graphical infrastructure is really superior. Quartz is a couple of years ahead of Cairo in maturity and performance, which is not so surprising given that its several years older. The compositing infrastructure is really mature in OS X, while its immature enough in Linux that Ubuntu still doesn't see fit to ship a compositing manger by default in Feisty Fawn. And HIView/HIToolbox (the view/control framework that's been slotted underneath Carbon and Cocoa) is miles ahead of GTK+, although the latter has a much cleaner API with less historical baggage. And DRI is just now getting some crucial features (management of GPU memory, virtualization of GPU resources) that OS X's GL stack has had for a while now.
As for slowing down, there is really no indication that Apple is moving more slowly than Linux. It'll still be a couple of years yet before the DRI/X.org/GTK+ stack catch up with OS X 10.4, much less what's in 10.5. And there are some really fundamental problems with XRender that would keep it, without a significant redesign, from being able to support features past what Apple introduced in OS X 10.2.