Wow. Really? You're going to ignore Apple until they clean up their act? Wow. Once Steve Jobs hears that metatruk is ignoring Apple, he'll undoubtedly re-release all of Apple's products under the GPL. Being ignored by the righteous metatruk would, after all, simply be too much to bear.
READ THE THREAD ALREADY. APPLE HAS GIVEN BACK BSD AND GCC BUGFIXES, UPDATES, AND A COUPLE OF LARGE-SCALE PROJECTS, INCLUDING THEIR CORE OS. THEY ARE UNDER NO OBLIGATION TO DO ANY OF THIS, BY THE BSD LICENSE. GET A CLUE.
So, what specifically about Mac OS X "sucks?" Does it not sufficiently resemble GNOME or KDE running on Linux for you? Seriously, tell us, in your own words, what "sucks" so much about Mac OS X?
You obviously haven't been paying attention here, or you would know that Apple has given a great deal back to the BSD world, and will continue to do so.
"In another couple of years, the average Slashdot reader will graduate from high school."
I live, apparently, less than 500 feet too far from my CO for DSL service. I'm supposed to pick up and move so I can play Q3? Get real.
Back in the day, I kicked LPB ass all over the map in Quakeworld over my crappy 300 msec 28.8 modem connection. The only people who could consistently own me were excellent players on the same local network as the QW server. What is really so much more bandwidth/latency intensive in Q3 that I can't still do the same thing?
Admittedly, I have given up on first-person shooters, period. The rewards are too small for the hardware and bandwidth requirements. I'm happy for id that they can make money off this crap, but really, who's buying? These games will be nothing but a disappointment to 80 percent of the people who buy them. Diablo II plays well on low bandwidth/high latency, although it is still a local resource hog.
The ppc kernel source is, let's see, *years* older than reiserfs. Mackerass and company have made considerable efforts to integrate smoothly. A mainstreaming of ppc kernel code was anticipated by 2.2 release. Yeah, right.
Again, it really doesn't matter much for those of us who actually *use* ppc linux, but the simple fact is, Linux is written for x86. That's not going to change until x86 stops being the majority architecture. x86 people generally do not care about any other architectures, and Linus is definitely an x86 person. People who care about platform-independent code should look at NetBSD. Platform independence is not going to come from Linus.
I fail to see why this is so surprising. It became clear after the first year or so of ppc kernel development that Linus has no interest in the PowerPC platform. He has even stated publically that he has no such interest, and that x86 is the only architecture that matters to him.
Blaming this on the port maintainers shows how little you understand the PowerPC port. Traditionally, PowerPC port patches consist of either several small pieces, as you describe, or major chunks of code, or a combination of both. This is not because the maintainers are somehow stubborn or lazy. The size of a patch is only as large as it needs to be, which in some cases can be fairly large. Since Linus approves all source for the official tree, it's clear that PowerPC has, for the most part, escaped his notice. Again, he has stated in the past that he's not particularly interested in non-x86 architectures. Some might say this is because ppc is a marginal platform, but it is certainly less so than, say, Alpha...
There are a lot of people around now saying, "I'll try a Mac if it'll run Linux," which often translates to "I'll try it if it someone else does the work to make it run, and only then if I can grab the official source, specify a PowerPC target, and have a useful kernel." This has been possible only a handful of times in the history of the kernel, for some loose definition of useful.
Bottom line: Linux is open source, but it's far from being a portable kernel. If you need portability, use NetBSD. If you just gotta have that GPL... oh well. If there has to be a fork to support Linux on other hardware, who really cares? It doesn't matter. Certainly, the gap between a fork of Linux to support hardware is nothing compared to the gulf between, I don't know, MacOS and Windows. BSD can run most of the same software as Linux and vice versa. I don't understand the fuss over forking Linux.
Get a Mac and thumb your nose at the world. The Hebrew support is excellent. I would never give mine up in a million years, it's the only thing that's not completely brain-dead when it comes to non-Roman languages. Linux/BSD just can't hold a candle to the Mac's multilingual support.
...if you think you need a leak detector, what you probably need is a language with real garbage collection. There are lots to choose from nowadays, most of which can either be compiled natively or translated to some dialect of C and complied, so you can use good ol' gcc if that's your heart's desire.
C is great for writing kernels and drivers. Java is okay for JSPs and the like. Other choices exist that are far, far better for one-person or large-scale projects. Eiffel, Dylan, Lisp, and ML dialects can work well for big projects and provide very good runtime performance. Python, Ruby, and Smalltalk are great for individual use and are usually fast enough for a given purpose.
Thanks for mentioning this... fellow Squeakers, untie!;-)
Squeak was Apple's open source Smalltalk before it was Disney's. It's not really fair to say it's Disney's, since the licensing still refers back to Apple. The license is actually quite liberal, even more so than BSD. GPL aficionados won't like that... too bad.
Perhaps you haven't been keeping up-to-date on Squeak, since the imminent next release is supposed to be event-based, no longer polling. Squeak already contains some dandy pen-input components and some folks are using palm-top devices with it routinely.
There are working Linux ports of Squeak already, sure, but the sensible thing to do on a palm-top device is just run it on bare hardware. It's already been ported to the various CE-running hardware architectures and a couple of others.
Apps, like a to-do list, web-browser, email, IRC, telnet, even text-to-speech, and so on also already exist in the Squeak base image. If you need more, Squeak is fun and relatively easy to program.
Hear, hear re: LinuxPPC. Those guys are great kernel hackers, but they don't have the big-picture skills to put out a decent distro.
SuSE is, IMO, the most competent distro on the PPC as of this moment. Debian/PPC has great potential, but it is not for the faint of heart, and you can't just go get CDs, run the install script, and be on your way. Debian/PPC won't be mature until at least Debian 2.4.
For those who like BSD-style packaging, there is always NetBSD/PPC.:-)
Actually, OpenBSD has had a functional PowerPC port for quite some time now; longer than than the more-mainstream NetBSD, which has really improved its PPC support in recent months.
OpenBSD has not borrowed so much from NetBSD/PPC development lately, however, and is rather behind the NetBSD port at this time.
It's the normal, expected code-sharing lag that happens with BSD ports.
Agreed, NetBSD is a nice way to go if you want Unix on PPC. SuSE would be the first Linux distro for PPC not to suck out of the box, so there is now a choice for those who want a PPC *nix that actually works.
Aqua -- not much more than a term for the watery, bubbly appearance of the developer-stage Mac OS X interface skin.
Quartz -- a PDF-based system-level imaging model. This is the Mac OS X component corresponding most closely to X11.
Carbon -- a forwards-compatibility library to ease the pain of classic Mac OS developers in porting existing Mac OS applications to Mac OS X.
Cocoa -- the "native" API for Mac OS X development.
"Choosing a GUI" is not going to be as hard as you seem to think. Carbon and Cocoa are the APIs, and Quartz provides display services to the entire system. They are separate entities.
It's important not to underestimate the number of people who are equally appreciative of and comfortable with Mac OS and Unix. Why? Lots of us were first exposed to Macs and Unix simultaneously in the mid-80's, at university.
There are lot of combination Mac/Unix fans, and OS X should be warmly welcomed by us.
Since when does Unix have lower hardware and software costs than Mac OS?
Free operating systems != Unix. When you say Unix, I start thinking of Solaris, AT&T, SCO, Irix, and so on. Hardware and software costs are much higher in that world. If you mean that free Unix and Unix-like operating systems have lower hardware and software costs than MacOS, then that has pretty much always been true and pretty much always will be. No commercial enterprise can hope to compete with free software for dollar value.
Undoubtedly, there will be some push in both directions, development-wise. Many current OS X developers are companies that built NeXTStep applications or have Mac/Unix products, like Tenon. Mac OS X is already a respectable server platform precisely because it runs unadulterated Apache, among other things. For server applications, the OS X's BSD heritage is a clear selling point, and OS X is already a pretty good BSD flavor.
For the near future, end-user applications will primarily run in the classic Mac OS compatibility environment, until more are converted to use CarbonLib (which is happening already). Most of the work being done in the better Cocoa API is by NeXTStep developers; mainstream Mac developers will probably not move on to Cocoa until they've successfully Carbonized their current applications.
It's going to be a bumpy ride, but hopefully the end result will be worth it. Mac people have been waiting for a real OS that would handle their beloved GUI for years. With Mac OS X, it could finally come to fruition.
Not everyone likes OO, but much of its muddy reputation results directly from "Frankenstein" languages like Java and C++, where OO was grafted on almost as an afterthought.
Objective C is (arguably) more appealing as a complied OO language. For "real" OO, one must go to high-level languages like Smalltalk and Lisp. Of course, even fewer people seem to like these languages than do C++. The ones who do like them generally like them a lot.
We have yet to see the emergence of an OO language that those weaned on procedural languages will easily feel comfortable with (myself included). Smalltalk comes very close, but it's very difficult to translate Smalltalk's advantages into a worthy compiler, because typing is dynamic. Someone once made a "typed Smalltalk" which could probably be compiled, but it would probably break a lot of favored Smalltalk idioms.
Loglan is still around hasn't been supplanted in any way by Lojban. The Loglan/Lojban split arose out of copyright disputes. Lojban probably has larger community around it today than does Loglan, simply because the use of Lojban is much less restricted.
There are considerably more native speakers of Mandarin and Cantonese than any other language in the world, and a growing number of non-native speakers.
English may be our latter-day lingua franca, but Chinese languages, especially as written, are more of a world language than any other based on sheer numbers, and written Chinese has long been a sort of lingua franca throughout Asia.
It's incredibly arrogant to underestimate the significance of the Chinese language.
Basic English is an extreme reaction to the excessively adjectival and vague tendencies present in natural English.
The expressive power of Basic English is so feeble as to render it useless for all but the most "basic" uses: simple warnings, directives, the type of thing you might see on road signs.
Babelfish could certainly be made to translate, so far as it is able to translate anything at all, using Basic English. However, the root dictionary of Basic English is so small that most texts would lose almost all of their meaning.
>one would have to be reasonably intelligent and mature to have the Latin skills to read them
You're kidding, right?
Clearly, you weren't one of the kids sitting next to me in high school Latin 3. We were no doubt reasonably intelligent, but the level of maturity was about what you'd expect of the most stereotypically puerile high school student.
Latin would require so many word-imports it would end up looking much like net-English anyway.
Slashdot Mirror
Wow. Really? You're going to ignore Apple until they clean up their act? Wow. Once Steve Jobs hears that metatruk is ignoring Apple, he'll undoubtedly re-release all of Apple's products under the GPL. Being ignored by the righteous metatruk would, after all, simply be too much to bear.
READ THE THREAD ALREADY. APPLE HAS GIVEN BACK BSD AND GCC BUGFIXES, UPDATES, AND A COUPLE OF LARGE-SCALE PROJECTS, INCLUDING THEIR CORE OS. THEY ARE UNDER NO OBLIGATION TO DO ANY OF THIS, BY THE BSD LICENSE. GET A CLUE.
So, what specifically about Mac OS X "sucks?" Does it not sufficiently resemble GNOME or KDE running on Linux for you? Seriously, tell us, in your own words, what "sucks" so much about Mac OS X?
You obviously haven't been paying attention here, or you would know that Apple has given a great deal back to the BSD world, and will continue to do so.
"In another couple of years, the average Slashdot reader will graduate from high school."
I live, apparently, less than 500 feet too far from my CO for DSL service. I'm supposed to pick up and move so I can play Q3? Get real.
Back in the day, I kicked LPB ass all over the map in Quakeworld over my crappy 300 msec 28.8 modem connection. The only people who could consistently own me were excellent players on the same local network as the QW server. What is really so much more bandwidth/latency intensive in Q3 that I can't still do the same thing?
Admittedly, I have given up on first-person shooters, period. The rewards are too small for the hardware and bandwidth requirements. I'm happy for id that they can make money off this crap, but really, who's buying? These games will be nothing but a disappointment to 80 percent of the people who buy them. Diablo II plays well on low bandwidth/high latency, although it is still a local resource hog.
Gonna go flip on my Playstation...
The ppc kernel source is, let's see, *years* older than reiserfs. Mackerass and company have made considerable efforts to integrate smoothly. A mainstreaming of ppc kernel code was anticipated by 2.2 release. Yeah, right.
Again, it really doesn't matter much for those of us who actually *use* ppc linux, but the simple fact is, Linux is written for x86. That's not going to change until x86 stops being the majority architecture. x86 people generally do not care about any other architectures, and Linus is definitely an x86 person. People who care about platform-independent code should look at NetBSD. Platform independence is not going to come from Linus.
I fail to see why this is so surprising. It became clear after the first year or so of ppc kernel development that Linus has no interest in the PowerPC platform. He has even stated publically that he has no such interest, and that x86 is the only architecture that matters to him.
Blaming this on the port maintainers shows how little you understand the PowerPC port. Traditionally, PowerPC port patches consist of either several small pieces, as you describe, or major chunks of code, or a combination of both. This is not because the maintainers are somehow stubborn or lazy. The size of a patch is only as large as it needs to be, which in some cases can be fairly large. Since Linus approves all source for the official tree, it's clear that PowerPC has, for the most part, escaped his notice. Again, he has stated in the past that he's not particularly interested in non-x86 architectures. Some might say this is because ppc is a marginal platform, but it is certainly less so than, say, Alpha...
There are a lot of people around now saying, "I'll try a Mac if it'll run Linux," which often translates to "I'll try it if it someone else does the work to make it run, and only then if I can grab the official source, specify a PowerPC target, and have a useful kernel." This has been possible only a handful of times in the history of the kernel, for some loose definition of useful.
Bottom line: Linux is open source, but it's far from being a portable kernel. If you need portability, use NetBSD. If you just gotta have that GPL... oh well. If there has to be a fork to support Linux on other hardware, who really cares? It doesn't matter. Certainly, the gap between a fork of Linux to support hardware is nothing compared to the gulf between, I don't know, MacOS and Windows. BSD can run most of the same software as Linux and vice versa. I don't understand the fuss over forking Linux.
Get a Mac and thumb your nose at the world. The Hebrew support is excellent. I would never give mine up in a million years, it's the only thing that's not completely brain-dead when it comes to non-Roman languages. Linux/BSD just can't hold a candle to the Mac's multilingual support.
Once MacOS X goes final, it'll be bye-bye forever to Linux at our place.
...if you think you need a leak detector, what you probably need is a language with real garbage collection. There are lots to choose from nowadays, most of which can either be compiled natively or translated to some dialect of C and complied, so you can use good ol' gcc if that's your heart's desire.
C is great for writing kernels and drivers. Java is okay for JSPs and the like. Other choices exist that are far, far better for one-person or large-scale projects. Eiffel, Dylan, Lisp, and ML dialects can work well for big projects and provide very good runtime performance. Python, Ruby, and Smalltalk are great for individual use and are usually fast enough for a given purpose.
Thanks for mentioning this... fellow Squeakers, untie! ;-)
Squeak was Apple's open source Smalltalk before it was Disney's. It's not really fair to say it's Disney's, since the licensing still refers back to Apple. The license is actually quite liberal, even more so than BSD. GPL aficionados won't like that... too bad.
Perhaps you haven't been keeping up-to-date on Squeak, since the imminent next release is supposed to be event-based, no longer polling. Squeak already contains some dandy pen-input components and some folks are using palm-top devices with it routinely.
There are working Linux ports of Squeak already, sure, but the sensible thing to do on a palm-top device is just run it on bare hardware. It's already been ported to the various CE-running hardware architectures and a couple of others.
Apps, like a to-do list, web-browser, email, IRC, telnet, even text-to-speech, and so on also already exist in the Squeak base image. If you need more, Squeak is fun and relatively easy to program.
URL: http://www.squeak.org/
>It's [was] a x86 world.
You said it, friend.
x86 has been useful, but it's going away.
1. All translation engines suck.
2. The examples above of word order are neither German, English, nor any other language I'm competent in. I'm curious. Where did they come from?
You might as well go to a junkyard and find a 386 you can run Linux on as run it under emulation.
PPC stuff isn't standard... Intel stuff is... I want some of whatever that was you were smoking, just now. ;-)
LinuxPPC is pretty much like Intel Linux of two or three years ago. Why not give SuSE or NetBSD a try?
Um, yeah... there's Debian on PPC. A bit premature with this post, wouldn't you say?
There is also SuSE. There is also NetBSD.
Hear, hear re: LinuxPPC. Those guys are great kernel hackers, but they don't have the big-picture skills to put out a decent distro.
:-)
SuSE is, IMO, the most competent distro on the PPC as of this moment. Debian/PPC has great potential, but it is not for the faint of heart, and you can't just go get CDs, run the install script, and be on your way. Debian/PPC won't be mature until at least Debian 2.4.
For those who like BSD-style packaging, there is always NetBSD/PPC.
Actually, OpenBSD has had a functional PowerPC port for quite some time now; longer than than the more-mainstream NetBSD, which has really improved its PPC support in recent months.
OpenBSD has not borrowed so much from NetBSD/PPC development lately, however, and is rather behind the NetBSD port at this time.
It's the normal, expected code-sharing lag that happens with BSD ports.
Agreed, NetBSD is a nice way to go if you want Unix on PPC. SuSE would be the first Linux distro for PPC not to suck out of the box, so there is now a choice for those who want a PPC *nix that actually works.
Aqua -- not much more than a term for the watery, bubbly appearance of the developer-stage Mac OS X interface skin.
Quartz -- a PDF-based system-level imaging model. This is the Mac OS X component corresponding most closely to X11.
Carbon -- a forwards-compatibility library to ease the pain of classic Mac OS developers in porting existing Mac OS applications to Mac OS X.
Cocoa -- the "native" API for Mac OS X development.
"Choosing a GUI" is not going to be as hard as you seem to think. Carbon and Cocoa are the APIs, and Quartz provides display services to the entire system. They are separate entities.
It's important not to underestimate the number of people who are equally appreciative of and comfortable with Mac OS and Unix. Why? Lots of us were first exposed to Macs and Unix simultaneously in the mid-80's, at university.
There are lot of combination Mac/Unix fans, and OS X should be warmly welcomed by us.
Since when does Unix have lower hardware and software costs than Mac OS?
Free operating systems != Unix. When you say Unix, I start thinking of Solaris, AT&T, SCO, Irix, and so on. Hardware and software costs are much higher in that world. If you mean that free Unix and Unix-like operating systems have lower hardware and software costs than MacOS, then that has pretty much always been true and pretty much always will be. No commercial enterprise can hope to compete with free software for dollar value.
Undoubtedly, there will be some push in both directions, development-wise. Many current OS X developers are companies that built NeXTStep applications or have Mac/Unix products, like Tenon. Mac OS X is already a respectable server platform precisely because it runs unadulterated Apache, among other things. For server applications, the OS X's BSD heritage is a clear selling point, and OS X is already a pretty good BSD flavor.
For the near future, end-user applications will primarily run in the classic Mac OS compatibility environment, until more are converted to use CarbonLib (which is happening already). Most of the work being done in the better Cocoa API is by NeXTStep developers; mainstream Mac developers will probably not move on to Cocoa until they've successfully Carbonized their current applications.
It's going to be a bumpy ride, but hopefully the end result will be worth it. Mac people have been waiting for a real OS that would handle their beloved GUI for years. With Mac OS X, it could finally come to fruition.
Not everyone likes OO, but much of its muddy reputation results directly from "Frankenstein" languages like Java and C++, where OO was grafted on almost as an afterthought.
Objective C is (arguably) more appealing as a complied OO language. For "real" OO, one must go to high-level languages like Smalltalk and Lisp. Of course, even fewer people seem to like these languages than do C++. The ones who do like them generally like them a lot.
We have yet to see the emergence of an OO language that those weaned on procedural languages will easily feel comfortable with (myself included). Smalltalk comes very close, but it's very difficult to translate Smalltalk's advantages into a worthy compiler, because typing is dynamic. Someone once made a "typed Smalltalk" which could probably be compiled, but it would probably break a lot of favored Smalltalk idioms.
Loglan is still around hasn't been supplanted in any way by Lojban. The Loglan/Lojban split arose out of copyright disputes. Lojban probably has larger community around it today than does Loglan, simply because the use of Lojban is much less restricted.
There is more about this at the lojban.org site.
There are considerably more native speakers of Mandarin and Cantonese than any other language in the world, and a growing number of non-native speakers.
English may be our latter-day lingua franca, but Chinese languages, especially as written, are more of a world language than any other based on sheer numbers, and written Chinese has long been a sort of lingua franca throughout Asia.
It's incredibly arrogant to underestimate the significance of the Chinese language.
Basic English is an extreme reaction to the excessively adjectival and vague tendencies present in natural English.
The expressive power of Basic English is so feeble as to render it useless for all but the most "basic" uses: simple warnings, directives, the type of thing you might see on road signs.
Babelfish could certainly be made to translate, so far as it is able to translate anything at all, using Basic English. However, the root dictionary of Basic English is so small that most texts would lose almost all of their meaning.
George Bernard Shaw came up with a splendid orthography for English.
http://www.shavian.f9.co.uk/
Really, it's incredibly nifty. Not practical for systems limited to character-based I/O, though.
>one would have to be reasonably intelligent and mature to have the Latin skills to read them
You're kidding, right?
Clearly, you weren't one of the kids sitting next to me in high school Latin 3. We were no doubt reasonably intelligent, but the level of maturity was about what you'd expect of the most stereotypically puerile high school student.
Latin would require so many word-imports it would end up looking much like net-English anyway.