Carbon will not be 64bit in Leopard. “At last year’s keynote, Apple had claimed that both Carbon and Cocoa would be 64-bit, adding to the 64-bit fundamentals that Tiger had laid. However, according to the latest on Apple’s website, Leopard’s 64-bit frameworks will include the POSIX and math libraries found in Tiger, Cocoa, Quartz, OpenGL, and X11 GUI framework. In addition, Apple confirms that Carbon will not be 64-bit on the Carbon Developer mailing list.” In addition, the readme file included with Leopard’s developer preview says G3 support will be dropped from Leopard.
What about my B&W G3? It still makes a decent home server, running 10.4 right now.
Then it will stay a decent home server running 10.4
Or when Apple drops support for 10.4, you can switch to NetBSD or Linux.
If it’s working fine for you now with 10.4 as a server why would you upgrade to the new OS anyways?? If it ain’t broke…
Because eventually Apple will stop supporting 10.4. That means no more security patches or bug fixes.
I’m kind of in the same boat as parent. I have a 17″ LCD iMac, 800 GHz G4 processor, circa 2002. I’m thinking that it won’t see another OS upgrade from Apple, because it really isn’t worth it. When Apple drops support for either the G4 processor, or switches to 64-bit only, I will have to evaluate whether it is “safe” to continue to run OS X on that machine, or whether I will shift it over to Linux or one of the *BSD’s.
Apple still releases security patches for 10.3, so your 10.4 will be supported for a couple of years – at least.
Apple would at least have to wait until 10.6 before going 64-bit, and that is probably not relased until late 2009 at the earliest.
That means that your iMac will be 7 or 8 years old at that time.
I think we’re going for Apple’s Vista. My gut feeling is that Apple is reaching their peak and Leopard or Leopard+1 is going to be like Vista. The signs are starting, delays (6 month delay so far), dropping features (ZFS, this), rushing (severe stability problems currently, even in released Safari beta), etc… I think Apple is just putting to much under their belt, and they just aren’t ready for it yet. If they ever are (its harder to produce quality products as your company gets bigger and has more products)
I know this is getting rated -5, but thats just my opinion on this subject.
How is not having ZFS by default dropping features? AFAIK Apple simply never mentionned anything publicly about ZFS. All I heard about ZFS on Leopard was from external sources.
Also really… running a G3 on Tiger is already a pain. I don’t want to know what it’s like with Leopard.
If you want to use your old machine for a server then there’s always a good linux distribution suited for it.
> Also really… running a G3 on Tiger is already a pain.
Not true.
1.) There are 900MHz G3 iBooks out there.
2.) Tiger on a G3 is as fast as Panther on a G3 which is MUCH faster than 10.2 on a G3, which was the preinstalled OS on those iBooks. So if you claim that running Tiger on these machines is a pain, you’ll have to argue that using these machines was an even bigger pain when they were brand-new.
Apple has only so much it can support.
Keeping older hardware supported
1. Means you can’t effectively use the features of the newer hardware
2. You strain your development/support teams beyond what is possible.
I feel Tiger slow on my iBook G4 800… much slower than XP on a 800 MHz Pentium III. I don’t believe they can make Leopard faster than Tiger in any appreciable way, so I’m not going to upgrade this machine.
Back in the days, there were a lot of people who wanted to switch back to OS9 exactly for this reason!
You have to remember the G4 was pretty much a G3+Altivec. A 900Mhz G3 ought to be faster in day to day use than a G4 800Mhz.
Now, 10.1 and 10.3 were definitely faster than Tiger on my flat panel iMac. In fact, so bad I bought a Intel iMac. Tiger was a hog. Since they’ve ported dtrace, they may be able to do the tuning magic Sun did with Solaris 10 which really made a fantastic difference (really, go use good old Slowaris 8, then switch to 10).
So I will be peeved if my Intel iMac runs Leopard like a dog!
If I could mod you straight up to 5, I would. Heck, if I could mod you way beyond 5, I would.
You nailed it.
OTOH, Thom (or Jeremy, I dunno, but it’s still Thom’s job to dig deeper into the story!) *so* cherry-picked the email in that thread that he found news-worthy.
Check these out (both by the very same Eric Schlegel):
http://lists.apple.com/archives/carbon-dev/2007/Jun/msg00316.html
http://lists.apple.com/archives/carbon-dev/2007/Jun/msg00322.html
There’s hardly a lack of care for the current developer situation. Specially when there are sessions *dedicated* to the subject on WWDC itself!
Mass hysteria seems to abound, though.
Anyway, I still pretty much doubt that Leopard can’t be shoehorned into quite a number of G3’s at all.
My Performa 6360, running 9.2.2, can attest this. Manual ResEdit intervention was necessary, but it works like a charm.
Same as my iMac Rev D, running the very latest release of Tiger. XPostFacto to the rescue.
But we’ll know the *real deal* in due time.
(Sidenote: who in a right mindset would run Vista, or even XP, on a processor that tops at 900MHz (and those are few and far between), especially processors lacking any kind of SIMD extensions? Not to mention how most G3 motherboards can’t support more than 640MB of RAM. Really, wake up and smell the coffee. And those rare, fastest-ever-produced G3s were discontinued in 2003. 4 years already!
Now, how about unreasonable expectations that Apple itself will continue supporting machines after they EOLd? Try Ubuntu PPC for a change! Or Xubuntu if you machine is lacking RAM and a larger hard disk.)
Anyway, my souped-up iMac 333 won’t cry missing out on Leopard until I’m pretty sure XPostFacto won’t do its magic; and it’s not like it feels any zippy on Tiger already.
And it will take a couple years for Leopard-exclusive apps to become the norm. Until then, Apple will continue releasing security updates for Tiger, as it currently does for Panther.
So really, what’s the big deal? You can’t run the glitz already. A hardware failure might be on the verge of happening (specially the HDs, those tend to fail quite frequently!).
What about saving some money or getting yourself an el-cheapo G4 on eBay?
(Sidenote: who in a right mindset would run Vista, or even XP, on a processor that tops at 900MHz (and those are few and far between), especially processors lacking any kind of SIMD extensions? Not to mention how most G3 motherboards can’t support more than 640MB of RAM.
XP Pro runs quite well on my Dell Dimension 4100 (933Mhz PIII, 512MB RAM).
XP came out when 600Mhz PIII’s were the norm, and it ran decently once SP1 came out.
You do realise however that Pentium IIIs have SSE extensions, in addition to MMX, right? And how much RAM do these motherboards support, again?
Re-read my post, please.
You do realise however that Pentium IIIs have SSE extensions, in addition to MMX, right? And how much RAM do these motherboards support, again?
Re-read my post, please.
I did. I was addressing this comment:
(Sidenote: who in a right mindset would run Vista, or even XP, on a processor that tops at 900MHz (and those are few and far between), especially processors lacking any kind of SIMD extensions?
I realize they have SSE extensions. But in the particular case of the 4100, it only supports up to 512MB of RAM, yet still runs XP just fine.
Try not to sound so condescending next time.
I’m not intentionally being condescending, but I can’t help if it happens unconsciously.
You’re giving me a hard time, because the way you phrase things make it seem like you’re implying that SSE extensions are not SIMD.
Specially when you re-quote the part where I specifically said the G3 processors Apple got to sell (i.e., excluding aftermarket upgrades, which topped at 1.1GHz and are rarer still!!) TOP at 900MHz (*not* that 900MHz was the norm, but the exception, and the average speed of the G3 installed base happens to be around 450MHz, half of that!!) and sports NO SIMD extensions at all (nothing similar to even MMX)!
And I also mentioned the motherboards TOP at 640MB, again, not that it’s the norm. Topping my iMac rev D to 512MB requires finding a couple of low-density 256MB PC-100 SO-DIMMs. I can’t find those anymore on my country. I’d have to import one from OWC were I to top it. Currently it sports 384MB, a new HD and a DVD-ROM/CDRW combo. But I’m not upgrading this machine any further, it’s a waste of money better invested on buying either a 2nd-hand G4 or a Intel-based Mac. Or a PC. Or a car. Anything other than attempting to give a G3 some extra spare hours to live.
The G3 only got a decent lifetime because the base architecture was sound enough to live without SIMD extensions for quite some time. But try to imagine how XP or Vista would run on a first-generation Pentium overclocked to 450MHz. 900MHz even. No matter how much RAM.
In any circumstances, it was NO reason for you to mod me down a point.
Edit: “else that” != “other than”. “to life” != “to live”. Grr.
Edited 2007-06-14 19:02
EDIT
Not worth it. Clearly you’re not understanding where I am going with this.
Edited 2007-06-14 19:06
not to flame or anything… But My grandmothers pc is a p3-600 with 512mb of ram running xp sp2 just fine.
A pc I just dismantled and sold the pieces off to friends was a p1-233mmx running at 250mhz with a 100mhz fsb running 512mb of pc133. it ran xp pro sp2 perfectly fine.
but thats about the slowest I’d dare go really. 300+ mhz is the best bet with windows XP. After that, its mostly ram and hdd access times slowing you down.
Vista is slow on 2ghz machines I’ve messed with. heh. That could just be me though
Apple sold G3s until 2003 if I remember correctly. That’s only 4 years ago. Vista claims to run on 800 MHz processors, which are about 7 years old. Also XP, in 2001, claimed to run on 133 MHz processors, which were almost 6 years old.
The fact is that most people just doesn’t want to trash a 5 years old computer.
OK, Leopard is six months late. But ZFS in Mac OS X wasn’t dropped, because it has never been officially announced. And the policy regarding ZFS seems much like resolution-independence in Tiger: It’s part of the OS, but it’s not turned on. But developers/hackers who want to test/play with the feature can unlock it.
And I bet that there’ll be ZFS implementations and hacks for Leopard as soon as the OS is released.
Just wondering cause I am unsure…..but how long does it take to take source code that is already written by someone else (ZFS by Sun) and sticking it into a *NIX OS (OS X by Apple) compared to a written from scratch filesystem (WinFS by MS)…if I am not mistaken, most of the ZFS should be plumbing code to make it work with OS X?
This is not trying to start a flame war or anything I am just tryng to understand. I have a feeling Apple spent more time with the Iphone since that will probably bring them more revenue and hence the delays with OS X. Also they figure people are gonna wait anyway for Penryn based workstations and Santa Rosa based laptops to come out full strength which is around the time when Leopard will be released. Just a thought.
Just wondering cause I am unsure…..but how long does it take to take source code that is already written by someone else (ZFS by Sun) and sticking it into a *NIX OS (OS X by Apple) compared to a written from scratch filesystem (WinFS by MS)…if I am not mistaken, most of the ZFS should be plumbing code to make it work with OS X?
“It depends”.
(I know, great answer) Note: I know no specifics of ZFS or Darwin, I’m just generalizing why this may be a tougher job than you think.
It depends on how ZFS is written, and how similar the kernel APIs are. Sun may have kernel API available that do -something- that Apple doesn’t have an analogus function. In that case, Apple has to create a function that takes the input ZFS wants to give the Sun API and translate it into a series of Darwin calls. On top of that, Sun’s kernel is still fairly monolithic, so a ZFS can go root around directly in the kernel structures, which may not be allowed in Darwin’s more protective environment. I know it took SGI’s engineers *years* to get XFS working properly with the Linux kernel.
But, it seems like ZFS *does* work with Darwin as of now. My gut feeling is that some of the goofy HFS+ semantics (resource forks, etc) are causing compatibility issues with some apps, probably the 3rd-party ones. A friend of mine tried to run his G4 cube on UFS (which was ‘supported’, IIRC) in the OS X 10.0-10.1 timeframe, and while the system ‘worked’, lots of applications acted strangely.
The signs are starting, delays (6 month delay so far)
Actually, iPhone is a good reason for the leopard delay. Vista delays had no other reason than crappy management.
dropping features (ZFS, this)
Apple never said that they’d include ZFS. Plus, ZFS is not a critical feature – it’s just a better filesystem, but still a filesystem. Why people cares so much about it is a mistery for me.
And 64-bit Carbon is not a “feature”. Carbon is a library for legacy apps. Not many apps use it, and the ones that use it don’t need 64 bit. Nobody cares about 64-bit carbon, nobody is going to notice it. Actually, I think that the “feature here” is not making it 64-bit capable – Carbon has to die, is just old compatibility crap.
(severe stability problems currently, even in released Safari beta)
Which is why they’re not shipping leopard until october.
Edited 2007-06-14 16:38
“And 64-bit Carbon is not a “feature”. Carbon is a library for legacy apps.”
It would be like Microsoft shipping Vista x64 with only a 32 bit Win32 API and requiring anyone who wants to write native 64 bit apps to use .Net x64. If that were the case, it’d be a huge deal, but of course since this is Apple no one gets up in arms.
Apple’s user base lets them get away with bloody murder without holding anyone accountable for actions like this.
Edited 2007-06-14 16:43
Programming on Mac OS X is not akin to Windows. Try programming something first before going off on how it compares to Microsoft and their .NET.
Carbon is a procedural API designed for C use and backwards compatibility. It would be more like MS dropping VB6 support, or MFC or any of the other archaic APIs in Windows.
Even Microsoft are not comfortable enough in their own language, they tried doing Explorer in managed code, and then had to end up dumping the whole thing. At least on OS X, large portions are written in Cocoa – and this announcement means that hopefully those few Carbon apps left might finally convert to Cocoa for Leopard
Admittedly I’m not a Mac developer, but have been writing production applications on Windows for 7 years now so I think I’m more than qualified to make comparisons.
“Carbon is a procedural API designed for C use and backwards compatibility.”
Sounds eerily similar to what Win32 does on Windows…it’s a native C/C++ wrapper around the core OS API’s. In this case, WinFX would be the Windows equivalent to a more “modern” wrapper around the core OS API’s (ala Cocoa). The comparison is from a very high level, not actual implementation details.
“Even Microsoft are not comfortable enough in their own language, they tried doing Explorer in managed code, and then had to end up dumping the whole thing.”
I’ve never seen this mentioned anywhere, though I’d love to be proven wrong. Managed code would not be suited for something as low level as an OS shell as the amount of indirection involved would hinder performance so it would make no sense for MS to attempt to do something like that.
If they aren’t comfortable enough with their own language, how is it that we’re close to v3.5 of the .Net framework? Why are they actively working on Singularity (a managed kernel for Windows)? et al.
Again, Win32 is not the correct analogy in this case; Win32s is.
“s”.
Remember, there was a set of Carbon libraries available to Mac OS 8.1/9.x as well. Apple was clearly not trying to extend their longevity.
So was the case with Win32s under Windows 3.1x. Microsoft had *no* interest in blowing an extra breath of life into Windows 3.1x. But they had interest in not leaving the current developer base in the dark.
Just look how great it was for Microsoft, having to support to this day an API that just turned 12. Look how difficult it is for them to convince key soft houses to just let go of Win32 and use .Net.
Apple was just risking going down the same route. And skipping 64-bit Carbon while having full and transparent 32-bit compatibility is just as good as it gets, IMHO.
Edit: clarified the Win32s analogy, if people missed part of the history
Edited 2007-06-14 17:26
What is the native API for XP? I was under the impression that the native API for XP is Win32 while the .Net is more like a virtual machine similar to the one used for Java. So the developers stuck to the native API (Win32).
While for the OSX case it is different (I think), the Cocoa is the API for the OSX and Carbon was the API for MacOS. So Carbon is still supported to enable one to run old MacOS apps. So the developers for OSX chose Cocoa, the native API here.
That’s not quite the way it works. You can’t take pre-OSX binaries and run it natively, that’s what the infamous “Classic Mode” was for. Carbon is about bringing the classic API into OSX to make it easier to *port* old Mac apps. So that companies like Adobe won’t abandon the Mac platform altogether.
BTW, .Net is not a virtual machine. It really is a development platform. The intermediate byte code is compiled into native code and stored in a “warehouse” so it only has to be done once.
I second that…
Actually it’s to my best belief that Carbon both gave us Photoshop 7 for Mac OS X and complicated Adobe’s move to Intel by not motivating a move away from Metrowerks Codewarrior and on to XCode at an earlier point.
I’d be happy to see Mac OS X be Cocoa only!
No, it would be like deprecating Win32s, a temporary API that has *always* been announced as so, whose only purpose was to ease the transition of legacy applications to current modern APIs while not losing the currently installed user base which *at the time* comprised most of the users. Oh wait, that happened for how long now, half a decade?
Carbon is but a compatibility layer between the Mac Toolbox from 15 years ago, forced to play along with the reality of needing preemptive multitasking (i.e., they rewrote parts to enable reentrancy).
Apple has been preaching the death of “plain” Carbon for 3 years now. Objective-C++ hasn’t been invented for nothing. Cocoa bindings for *several* languages haven’t been invented for nothing. And people still writing CodeWarrior apps in Pascal should really find better ways to spend their time.
And now, how unsurmountable an effort would it be to compile only the GUI using [Carbon] and write the backend in, say, Objective-C++?
I guess I should refrain from commenting further until today’s WWDC sessions are over. Plenty of questions will be answered then.
How again are YOU being affected by it as a Mac developer? Or a user? Oh, way to “authoritatively” talk about something that you really can’t state anything about…
Edit: [Carbon], 4 paragraphs back.
Edited 2007-06-14 17:15
No, it would be like deprecating Win32s, a temporary API that has *always* been announced as so, whose only purpose was to ease the transition of legacy applications to current modern APIs while not losing the currently installed user base which *at the time* comprised most of the users. Oh wait, that happened for how long now, half a decade?
Not sure what you’re trying to say there, but you don’t seem to grasp what Win32s was. It wasn’t some sort of transition API meant to be discarded. It was an implementation of the Win32 API (which is the core of the WinNT and Win9x lines) on top of Win16 (the older Windows API). It basically implemented all the parts of Win32 that could easily be bolted on top of Win16. You didn’t get threading and some other fancy stuff.
In short: A valid Win32s program is a valid Win32 program. Win32s wasn’t some transition API intended never to be spoken of again. It was a backport of Win32 to the extent that was reasonably possible.
If you want a Mac analogy, it would be like Apple porting large chunks of Cocoa to MacOS 9 after the release of OS X to help developers transition.
You definitely don’t know what you’re talking about.
If you really want to compare with Microsoft, the only arguable comparision would be MS not porting the API for 16bit Windows 3.x applications in Windows 95 to 32bit. Wait.. they didn’t, and nobody cared at all!
Edited 2007-06-14 18:31
“You definitely don’t know what you’re talking about.”
It’s an API that Apple promised would have 64 bit support a year ago, and now they are saying that it won’t. What’s not to understand about that?
“It’s an API that Apple promised would have 64 bit support a year ago, and now they are saying that it won’t. What’s not to understand about that?”
If you would’ve said that, I wouldn’t had complained. But you made an abstruse comparison, which I had to correct.
You didn’t talk about undelivered promises and how Microsoft performs better on that topic, did you?
“You didn’t talk about undelivered promises and how Microsoft performs better on that topic, did you?”
No, I didn’t…I don’t pit software houses against each other. But what you’re saying is because Microsoft has done it, that means it’s ok for others to hide behind that reasoning when they cut features?
Bitness is a hot topic right now in the developer world. The general opinion seems to be that Apple should support all common bitnesses until they decide to stop development on Carbon all together. It just seems like an odd feature to cut so close to the next release of their OS.
“Bitness is a hot topic right now in the developer world. The general opinion seems to be that Apple should support all common bitnesses until they decide to stop development on Carbon all together. It just seems like an odd feature to cut so close to the next release of their OS.”
I’m pretty much sure that the amount of code that assumes fixed width pointers and such on Carbon are *absurdly* larger than an API that was created to support multiple processor families from the ground up, like OPENSTEP and it’s immediate successor, Cocoa.
Heck, I’m even pretty sure the amount of endianness quirks on Carbon haven’t been fully done with yet.
All in all, I’m still not surprised that a compatibility API is being phased out. This is a sign that Apple has been making Cocoa more independent of Carbon, and more able to access lower-level resources either directly or through Darwin APIs.
And any way of empowering Cocoa is much nicer than the wrapping around Carbon, no matter how one cuts it.
Edit: tried to make something useful of the otherwise placeholder comment. =P
Edited 2007-06-14 21:15
Heh, there really should be a feature on OSNews where you can delete your own comment within a set timeframe if A) there aren’t any responses and B) it hasn’t been modded. I’ve done that on more than one occasion ;-).
Hell yes. We finally agree
If you really want to compare with Microsoft, the only arguable comparision would be MS not porting the API for 16bit Windows 3.x applications in Windows 95 to 32bit. Wait.. they didn’t, and nobody cared at all!
You can still run Win3.x apps on modern 32 bit Windows. I’m assuming you mean MS didn’t port the Win16 API to 64 bit. There’s a reason for that – when you enable 64 bit mode on an x86 chip, it completely disables the ability to run 16 bit code. Win64 can’t possibly run Win16 apps as the CPU doesn’t support it. The best you can do at that point is run something like DOSBox that emulates the CPU.
“You can still run Win3.x apps on modern 32 bit Windows.”
As you can run 32bit Carbon apps on OS X in 64bit mode.
But you cannot compile Win3.x apps as 32bit apps. That’s what this discussion is about (not being able to compile 64bit Carbon apps).
“I’m assuming you mean MS didn’t port the Win16 API to 64 bit.”
Nope
If you are going to write a game on Mac, you write it in Carbon, so I disagree, there SHOULD be 64-bit Carbon. Carbon apps perform much better than Cocoa apps (and don’t give me that crap about computers are getting faster, its no excuse) and I rarely use Cocoa.
And Carbon is NOT just old compatibility crap, there are a lot of parts in Carbon that are OS X only!!
That’s nonsense. Why should Cocoa be slower than Carbon?
Photoshop
QuarkXPress
Acrobat
MS Office
These applications are not insignificant, and all of them rely on Carbon. There are others very important Mac apps too that pre-date Mac OS X that all rely on Carbon, such as Illustrator.
It’s arguable as to whether or not a 64-bit Carbon would really be all that useful for Acrobat or MS Office…. Given the demo that Steve gave at the keynote though it’s clear that Photoshop and QuarkXPress could both benefit.
Whoa! Whoa!
Are you saying that Photoshop, Office et al, will not be 64-bit in the future?
Edited 2007-06-15 13:28
Well, the development teams are probably spread quite thin. The iPhone takes a good chunk of development hours to finish. MS had Vista to finish.
ZFS was never announced by Apple, it was blurted out by a Sun director at a non-Apple conference and it had been spotted in a Leopard beta. G3 support could be dropped, simply because there is too much support going on and Apple can’t stretch resources that thin.
It seems to me that Steve might have called the Safari dev team and said “I want Safari 3.0 beta released at WWDC, no discussion. I don’t have a ‘One more thing’ for the keynote!” where the Safari project leader says in a nervous tone “uh.. yes, sir!” and goes crapping his pants, having to tell the dev team the good news that sleep is going to be banned for the next few weeks, because either satisfy Steve or be Steved.
It’s not the same mess as Vista, which probably never will be perfect, but underwent seemingly endless nightmare of rewrites and still isn’t good enough. They had 5 years to do an OS.
I think the Safari release was just particularly poorly coordinated.
Excuses, excuses, yes, but I don’t think you can say that things are running out of control in a Vista like way. They were in the 90’s with hundreds of projects going no where, but I don’t think that’s the case today.
Well, the development teams are probably spread quite thin. The iPhone takes a good chunk of development hours to finish. MS had Vista to finish.
MS also had the Xbox 360, Zune, etc to finish as well. Apple should have a team dedicated to OS X, and hire additional people to work on other products as the need arises.
ZFS was never announced by Apple, it was blurted out by a Sun director at a non-Apple conference and it had been spotted in a Leopard beta.
Yeah, but some features in Leopard, such as Time Machine, really needed it and could benefit from it… zfs allows Time Machine to be well integrated rather then hacked into the system.
It seems to me that Steve might have called the Safari dev team and said “I want Safari 3.0 beta released at WWDC, no discussion. I don’t have a ‘One more thing’ for the keynote!” where the Safari project leader says in a nervous tone “uh.. yes, sir!” and goes crapping his pants, having to tell the dev team the good news that sleep is going to be banned for the next few weeks, because either satisfy Steve or be Steved.
Is that a good way to run a company? I think thats why Google is rated a much better place to work, and why I personally tend to find Google’s products to be top notch, moreso then Apple with the pretty interface on top of an existing product.
Even though I am a big mac fan and am excited about leopard, I will have to agree with you. At least leopard still has innovation. Hopefully the next release will go better.
Well you didn’t get the -5 … 🙂
But I can’t see how you can count ZFS as a dropped feature, when Apple did not say they would be including it in the first place.
Why does everyone put Apple on such a high pedestal?
If you have your expectations so high, when they disappoint you are let down even more than normal… In Vistas case no one had these high expectations and actually expected it to be crap.
When it comes to Apple everyone expects the OS to be so great and the computers so great, it never gives Apple any room for error…
OSX is great, it is by far the best OS I’ve ever used (and that is a bold statement), coming from a Linux background I find it stable and *nix like to the point where I don’t actually miss not using linux.
Now I expect Leopard is going to be great and it’s going to be stable, it’s only slipped a few months (not years) so relax and wait for it.
Don’t allow rumors of what to expect to dictate your thoughts, rather let Apple tell what they are doing. This is probably why they keep so many things secret.
I’m not surprised to see G3 support dropped – when was the last time they released a product that used the chip? They’re trying to move to a completely different architecture, so there’ll be a little bit of pain along the way. Anyone who has a G3 will be doing well to run Tiger, nevermind Leopard which looks to push things a bit more.
As for 64bit Carbon – what would the point be? Anyone who at this point still is running Carbon apps really needs to find alternatives. Good riddens.
Damien
Like Adobe & Microsoft?
They’re really dragging their heels on Mac. Damn, I wish there were more serious competition. If Corel released Paint Shop Pro for Mac, I’d buy it right away and put Photoshop in the bin.
Apple gave Adobe/Macromedia and Microsoft a time limit as to when they would abandon Carbon. They extended it more than once and finally are now letting it die slowly.
Adobe can use QT within OS X if it wants. It will be dependent on Trolltech to make it work with Cocoa and it’s Events Model.
Microsoft can keep their apps 32 bit and still run in Leopard.
I was curious, so i just checked over at everymac.com, the last G3 product (the 14″ ibook 900 Mhz g3) was discontinued in october of 2003. So 4 years to the month of leopards release.
Actually not as long ago as it feels like.
Umm… I believe we should have known that G3 support is going the way of the Dodo since last year’s WWDC because , umm, Apple actually said it outright.
Why all the Carbon hate?
I also don’t think the report that 64 bit Carbon has been dropped is correct, although I may be wrong since I’m not attending WWDC’07. Last year, the official party line was that legacy Carbon technologies like QuickDraw and SoundManager will not be made 64 bit, but if one uses their modern equivalent (Quartz, CoreAudio, etc.) the rest of the Carbon code can very well be 64 bit.
Well, I guess we will find out sooner or later what’s the deal with this, but for now I don’t believe Apple will so drastically part form what they were preaching last year.
What again was the Cocoa alternative to Maya, Cinema 4D and Lightwave?
I’m pretty sure I remember Jobs saying 10.5 would support the G3. If they don’t that will piss off a lot of people who bought an iBook in Sept 2003.
apple has to draw the line some where! dropping G3 support was going to eventually happen! Hell…. has’nt been 5 years since they sold a G3. I could be wrong, but hey… I am sure tiger will suit a g3 well in to the future! if you really want 10.5…. i am pretty sure you can pick up a g4 for like $200.
Lets be reasonable here!
apple has to draw the line some where! dropping G3 support was going to eventually happen! Hell…. has’nt been 5 years since they sold a G3. I could be wrong, but hey… I am sure tiger will suit a g3 well in to the future! if you really want 10.5…. i am pretty sure you can pick up a g4 for like $200.
Lets be reasonable here!
Apple isn’t being reasonable if they do actually drop G3 support. Just a few short years ago I purchased my brand new iBook G3 800Mhz for $1300 in Apr 03.
Geeks.com has 4 G4 eMacs, the lowest price is $230 plus shipping, then lets add in the $99 for the Leopard upgrade (maybe more, but I’m using Tiger’s price right now) and your at $330. To me, that’s a lot of dough to use an operating system, which should by all rights run on my four year old iBook!
Lastly, and I may be wrong on this but, aren’t most Apple programs written for the PPC architecture, written for the G3?
(BTW, Tiger runs just fine on my iBook with it’s meager 640MB of RAM.)
Lastly, and I may be wrong on this but, aren’t most Apple programs written for the PPC architecture, written for the G3?
I’m sure about ‘written’, but logically they have to be compiled into G3-compatible machine code or else they wouldn’t run on your G3. I think.
I don’t have an Apple system, so I’m speculating: does the OS installer select different binaries and/or libraries depending on what level of PPC you have? Or if I had a G5 I’d still be running G3 code, and making it difficult to use the extra features of the G5?
Extrapolating from both the hardware and software scenarios, given what’s now been announced about dropping G3 support, the last of which having been sold 4 years ago, buying a G4 would give one a machine that would be supported until 2010-2011, it’s true (last g4 pulled, what, March 06; time between Tiger and Leopard, 2.5 years, hence again support for G4 till at least around first quarter, 2010 – hope I got the Math right!)
However, the recent-ish rate of attrition in terms of Linux distros for PPC may well mean that by that time you will only have the BSDs as a reliable alternative . Nothing wrong with that, but the options will be pretty squeezed.
Normally leaving out Carbon in the 64 bit transition wouldn’t be such a big deal (i.e. for small apps, commercial apps, etc…). However, this is going to probably be somewhat of a problem for efforts like QT and Openoffice.org which use Carbon as the basis for their frameworks/ports. Especially for Mac users hoping to see a native OpenOffice port, this is bad news.
Why would OOo _need_ to be 64-bit? I can’t say I’ve ever tried creating 4GB+ documents before.
And I need a 64-bit version of OpenOffice for what reason, exactly? Bragging about having a 100% 64-bit clean OS without a single shade of legacy around?
…
How about talking how only Apple managed to keep 32-bit device drivers working on the 64-bit OS? This is FAR bigger news in my book.
Obviously a 64 bit openoffice isn’t the major point. While Cocoa has clearly been the framework of choice for building new applications, Carbon and Cocoa have been up until now essentially equivalent frameworks sitting on top of CoreFoundation and Quartz (esp. when writing in objective C was not an option). This is the first time we’re seeing a major signal on Apple’s part about the future deprecation of Carbon. In that case should OpenOffice.org change porting strategies? I’m interested in what they think about this. In addition, I find it funny that no one’s commented on QT. If you read the thread in which 64 bit Carbon was ruled out in Leopard, TrollTech is clearly unhappy (as are many other developers) about this news.
Right, and prematurely so. They didn’t wait a single second before bitching about something that was going to be addressed in a dedicated session a couple days ahead.
Every API deprecation/transition is going to piss the developers who insisted in not reading the tea leaves.
What was the last time that using the path of least resistance and building your business upon the compatibility API meant being future-proof?
Yet once again: hate the Objective-C syntax? Can’t work with it at all? Objective-C++ was created specifically to address this. Now get up and do your part, Apple clearly didn’t sprinkle ninja spikes around the floor. There was a clear path to staying current and future-proofed. Too bad some chose not to walk that path.
No, it was not. Objective-C++ was created so you can access your legacy C++ code in an ObjC Cocoa app. You can not directly use Cocoa objects/classes/methods in C++ code. In other words, we can not write a Cocoa program purely in C++.
http://developer.apple.com/releasenotes/Cocoa/Objective-C++.html#se…
Edited 2007-06-14 18:16
I might have expressed myself unclearly, but your second sentence was precisely what I meant to say.
The meat of the application remains C++, you only need few thin wrappers of Obj-C to call APIs you can’t otherwise.
[i]”What was the last time that using the path of least resistance and building your business upon the compatibility API meant being future-proof? “
Last WWDC and during the Leopard Tech Talk Tour, when Apple said “sure, you can build 64-bit apps in Carbon! Here, let us show you how to do it”.
Let’s talk about this one, since it’s really interesting: I read somewhere (I think in the Apple developer list thread discussing 64-bit carbon’s disappearance), that the way this is accomplished is by making the OS mostly 32 bits. When kernel code is being executed, the processor is switched to compatibility mode and runs 32 bit code. All the 32/64 bit switching occurs at the interupt and syscall gates.
It’s an interesting decision, and I’d bet that it is likely the most pragmatic way to make this transition, since the OS itself doesn’t really need 64-bit address space (I think Mac already has a 4 GB system address space that is switched to on every syscall). It’s only the apps that need to be 64-bit, so there’s no disadvantage to keeping most of the Core OS as 32-bit (except for marketing purposes… you can’t call it 64-bit clean).
It appears to be the case. The relevant article is here: http://lists.apple.com/archives/darwin-drivers/2007/Feb/msg00046.ht…
Huh, I guess that the POS Darwin kernel still isn’t 64-bit clean. Aside from the driver compatibility bit (which is fairly pointless on a platform where Apple writes all the drivers anyway!), this mostly sucks. Darwin’s system calls are already an order of magnitude slower than Linux’s system calls, and doing a full mode switch on each call will just make things worse.
Honestly, Darwin really needs to be drug out back and shot. I won’t weep for it.
XNU is a pretty poor kernel…. every 3 years or so Apple upsets its developer universe with some huge transition. This wasn’t true in the late 90s, but that’s only because the company was on the brink of destruction, so it couldn’t piss people off too much. Wanna start a pool about the next revision being a different kernel… perhaps Solaris?
They were thinking about having NT as the mac kernel before the NeXT purchase, so anything is possible, but Solaris or straight-up FreeBSD would be the best fit to replace XNU.
If Apple replaced XNU with Solaris I think I’d pass out from sheer joy.
Perhaps if you got off your ass and applied for Kernel God we could all stop hearing about how what a POS this kernel is to you.
I posted a link in another thread the other day. Apple has clarified its ZFS stance and said that ZFS will be included in Leopard. It just won’t be the default OS. So you may have to do a custom install. Big deal.
Looks like that has changed again. Now it is partial support. Looks loke Steve wants to keep us guessing. Afterall, where’s the fun in having everyone know all about it before it is released. Stay tuned for the next chage. 🙂
Edited 2007-06-14 17:47
I did Cocoa programming much of last year (as part of my hobbiest programming), and as far as I can tell, much of Cocoa is built on top of Carbon.
For example, in Cocoa’s NSView:drawRect method, you can call
[[NSGraphicsContext currentContext] graphicsPort]
to get the underlying Carbon CGContextRef handle, and then make low-level Carbon CG calls on it. In fact, if you look at a lot of Cocoa’s NS* api you can see that they’re built on top of corresponding Carbon api. So I’m not sure I see how Apple could just remove Carbon altogether.
I assume that 32-bit Carbon will remain in place (in fact, it has to, as major apps depend on it). But it seems that 64-bit Carbon would have to remain as well, for the parts of 64-bit Cocoa that would rely on it. Maybe 64-bit Carbon won’t be availble for use by apps, but will be available internally for use by the OS; or maybe 64-bit Cocoa will thunk down to 32-bit Carbon when necessary.
Incidentally, I think that jayson.knight’s analogy that this is like Microsoft dropping 64-bit Win32 and requiring that all 64 bit apps be .NET is more or less accurate.
Edited 2007-06-14 18:18
You have to remember that in OS X there are now actually three toolkit-like entities. Cocoa is the Obj-C framework and Carbon is the old Mac C framework. Under both of them is a set of C libraries: HIToolbox, HIView, Quartz, and OpenGL (among other ones). What Apple has been doing since 10.0 is beefing up HIToolbox to support all the functionality that was previously only available through Carbon/Quickdraw. Up to 10.4, this transition was incomplete. For example, you couldn’t create a window at the lowest levels without using bits of Quickdraw functionality. It appears that in 10.5, the last of the Quickdraw dependencies are gone from the system, and presumably Cocoa’s low-level dependencies have been moved to HIToolbox/HIView. Note that your example is just a demonstration of this: the method returns a Quartz graphics handle, and Quartz is not part of Carbon.
Cocoa was only dependent on parts of Carbon that were necessary during the transition.
Carbon was supposed to have been scrapped many years ago.
It’s finally reaching that point.
Cocoa was always going to be the future of Apple.
“Carbon is a procedural API designed for C use and backwards compatibility. It would be more like MS dropping VB6 support, or MFC or any of the other archaic APIs in Windows.”
MFC is very much alive and is actively developed. Most of the development at Microsoft is done in C++, for the simple reason of performance. Managed code is not fast enough. Funny that everyone thinks C++ is dead on Windows, like Sun would rewrite Solaris in Java. That means that Microsoft PR is very effective though…
Everyone only thinks C++ is dead on Windows because Microsoft says so, because they’re pushing hte hell out of C# and .NET/WinFX
Never mind the fact that some^H^H^H^H all of their major apps aren’t written in .NET
Get over it… I mean, really. When was the last time Apple sold a G3-based product? If you purchased your G3 with AppleCare then even that has long-since expired.
Besides, there are a few quality G3-to-G4 upgrades out there that work fine in B&W G3s and such.
One day Apple will not support PowerPC at all, who knows when, and Ubuntu dropped “official” support after Feisty, but good news:
Owners of PowerPC (32-bit or 64-bit) may enjoy T2 Linux, http://www.t2-project.org … one of the broadest chipset support regimes in Linux. Unlike Debian or Gentoo, the T2 packages for alternative CPUs are actually kept up-to-date, because the build system is designed for it. Puppy Linux now uses T2 under the hood. You may want to wait a little bit until T2 ships 7.0 final (there is a release candidate for x86).
This could be a boon for PPC based Macs as upgrading options go away, running Linux or a BSD will be very attractive options. I have an old G3 iBook happily running Linux – and the boast in speed is remarkable. So you have an Apple that is too old to run OSX, but it’ll run Linux fine…for free.
Gnash is supposedly almost ready for a proper release that supports big flash sites like youtube [http://www.gnu.org/software/gnash/] after that there’s really nothing holding back folks (or at least die hard geeks) from picking up a late model mac and having a very nice workstation to play/work on.
Don’t get me wrong, but ‘normal’ (ie non-geek) Mac users demand a certain aesthetic that no Linux distro currently offers – even Ubuntu which is the best of the lot just doesn’t have the polish.
If I was stuck with a G3, I’d run the latest OS X I could, and buy bargain software on eBay.