OSNews

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.

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.

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.

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?

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.

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.

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?

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.

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]"What was the last time that using the path of least resistance and building your business upon the compatibility API meant being future-proof? "[/b]

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.