Fully agreed. Hardware has been behind the panics I've seen on MacOS X, and I've not seen one on Tiger. And I use piles of apps at the same time, many creating sound... and I run the Terminal while running the software updater. If you manage to starve an app for resources (e.g., it's trying to do more than it can do with the resources allotted by the kernel, and the kernel is workign to prevent the app from creating a local DOS), and that app gets a spinning ball, and your other apps do just fine, thank you. You can cure app hang in MacOS X just like you can anywhere else in BSD-land. You most certainly didn't crash the OS if you were seeing a spinning beach ball, buster.
So, how do you crash MacOS X? My experience has been that panics indicate hardware issues; I've had those and the problems cleared with under-warranty hardware replacement. This is a world different from MS-Win, where panics merely prove you are running your machine. MacOS X stresses RAM (i.e., USES RAM) much more violently than Apple's previous OSses, revealing latent problems with a lot of hardware. I've replaced RAM (vendors are usually pretty good about it) and solved panics.
So, what do you do with your box to panic it? And by comparison, what do you do with the Linux box? I suspect that the GUI miracles occurring on the MacOS X machine result in a great deal more stress on hardware (CPU, GPU, RAM...) than occurs running a list of replacement apps on most other OSses. Tiger eats lots of RAM; Tiger is doing lots of "extra" work; Tiger is intended to provide a whole lot of bells a whistles that other BSD variants do not, and if you want pure speed, get BSD.
I suspect on the mini you had modest RAM and were trying to do a lot. Launching apps while the system is replacing critical frameworks could definitely qualify as a confusing issue for a machine... You can cure spinning balls on MacOS X like you can cure UI hangs on BSD elsewhere... of course, on MacOS X the spinning ball generally only exists in the one unresponsive app, and in your case it's not clear whether this was the launching terminal or the software update. FYI, I launch apps during update without problems, so this isn't an OS issue, though you may have had a machine far too busy to handle what you demanded without having at least some apps starved for resources.
the linux development model will offer solutions very sloooooowly, if ever
Let me think a sec. Last I checked, Linux was a project to make a Unix-workalike kernel. The project had just ditched (or been ditched by) its code management tool, and created "git" to replace it, so one could argue the Linux project does have an application to offer. However, X11 isn't a Linux project, most of the "modern" apps with nice friendly GUIs depend not only on x11 but on particular window managers, and these projects have developers which come from wildly different backgrounds and motivations primarily because the projects themselves solve problems which attract completely different support. Users and developers of Perl, PHP, Python, and Ruby exist on multiple platforms and have uses ranging from the novice/hobbyist to the specialist/professional. PostgreSQL, MySQL, and what have you solve problems for people with different focuses, hence their different feature sets, development priorities, and sources of support.
To say there is a "Linux development model" with respect to anything but the Kernel strikes me as a bit odd. Some distros might have a cognizable development model, but their collections of code are amalgamations of so many other projects that their capacity to offer a solution is heavily impacted by the development models of all the incorporated projects.
Projects by people in their spare time to provide something they plan to use for fun, projects by people hired by businesses to solve an economic concern, and everything in between comprise the code base that is drawn on to provide various distributions. Projects have internal organization wildly variant from one another, and they vary markedly in funding, pace of development, and in the measurements they take to determine how development is going and in the means used to establish development priorities.
I don't think that one can say of the broader code in operating system distributions which use a Linux kernel that there is a "development model" that offers any particular feature or demerit; the variation is too great to so characterize.
... and to bring this back to MacOS X, the inheritance enjoyed by Cocoa apps gives all you rlegacy Cocoa apps full advantage of improvements in the font system, in auto-spell-check tools, in services offered by applications the authors of your app knew nothing about...
Apple bought a cool environment when it bought NeXT. Runtime linking allows a lot of interesting stuff, and the ability to upgrade all the apps on your system by upgrading your OS or the frameworks you install is a world different from systems whose upgrades force you to replace all your apps.
OS/2 used to have an argument that object orientation allowed the OS to upgrade your apps, rather than force you to replace them, and thus was unlike a MS-Win upgrade (which was compared to repainting your room, which forced you to change your furniture).
Now that OS/2 is dead, and its developers are making MS-Win apps (can you say Stardock?), it's good to see someone is still carrying the torch on this front.
I fear that if I get a ppc mac that 6 years down the road I wont be able to find working applications for it.
I bought a Pizmo (G3 Powerbook with 100MHz bus and firewire) when Apple seemed about to adopt Unix as its OS, and ended up sitting on MacOS 9 longer than I intended. Interestingly, the Classic apps I started with run just fine on MacOS X, despite the fact that Classic has been deprecated for a while and is now obsoleted and, I think, now even unsupported.
Look at what you want to do, and ask if the hardware is up to it. If it is, then you will be happy regardless what Apple builds next, because that won't stop the hardware. Apple's dev tools are cross-platform, and Apple's developers know Apple customers keep their hardware for years (I still have and use the 5yo Pizmo) and understand they should click the checkboxes to build for both. For several years, I would think Apple's installed base of PPC will vastly outnumber the x86 gear they will be hawking. I doubt the Powermacs will be moved to Intel until a couple of years from now, since the desktop isn't where Intel is offering Apple the better roadmap (the reason Apple announced it was changing: performance per watt). Looking at what IBM is producing, I would guess Powermacs would look very good after the next major upgrade. If you are looking at notebooks, then the Intel looks pretty good.
You have to go back and ask what you are wanting.
FYI, I ran OS/2 Warp v.4 until the hard drive died, and the next one. Loved that OS. Now, THAT was a system that lost support. However, the apps I ran kept on running and running until the box died. Then... I ran OS/@ Warp v.4 in VirtualPC on MacOS, that was fun:-)
In linux swsusp is actually a software implementation, that also uses your swap partition, so you do not have to waste space on a special suspend partition that your bios understands.
Um, is this an x86 issue generally?
Apple hasn't written RAM to disk during sleep since some version of MacOS 9, and I expect that Apple sleep would lose its apparent performance if this were the case after the x86 transition. Apple's swap by default is to a file at/var/vm/ so I would think reading data out of this to repopulate RAM would be something of a time eater on a relatively busy / -- assuming there was even room.
Ahh, archives of lists... great way to et cutting-edge data on a product with regular paid upgrades and a binary updater system for minor upgrades. also: KPI introduction a likely harbinger of major kernel internals reworking.
Though, in your favor, a Darwin kernel developer recently chided a list poster who asked about Darwin x86 on MP systems; he said, if you want performance go use FreeBSD or Linux, that's not what Darwin x86 is about. That must have felt good to have posted less than a week before the x86 migration announcement! In Darwin's favor: actual disk synchronization for databases and other systems requiring real synch. Some of the comparisons out there appearing to favor Linux tend to prove Linux does not actually force synch like users expect. On the other hand, Linux could also suffer from a plague of drives that ignore synch commands to pretend to have better performance... however, to get knowledgeable on the synch issue, you'd have to read development lists rather than the bitch lists of third party developers.
Slashdot Mirror
so you were actually giving Tiger a panic? Not just getting a beach-ball?
Fully agreed. Hardware has been behind the panics I've seen on MacOS X, and I've not seen one on Tiger. And I use piles of apps at the same time, many creating sound ... and I run the Terminal while running the software updater. If you manage to starve an app for resources (e.g., it's trying to do more than it can do with the resources allotted by the kernel, and the kernel is workign to prevent the app from creating a local DOS), and that app gets a spinning ball, and your other apps do just fine, thank you. You can cure app hang in MacOS X just like you can anywhere else in BSD-land. You most certainly didn't crash the OS if you were seeing a spinning beach ball, buster.
So, how do you crash MacOS X? My experience has been that panics indicate hardware issues; I've had those and the problems cleared with under-warranty hardware replacement. This is a world different from MS-Win, where panics merely prove you are running your machine. MacOS X stresses RAM (i.e., USES RAM) much more violently than Apple's previous OSses, revealing latent problems with a lot of hardware. I've replaced RAM (vendors are usually pretty good about it) and solved panics.
... You can cure spinning balls on MacOS X like you can cure UI hangs on BSD elsewhere ... of course, on MacOS X the spinning ball generally only exists in the one unresponsive app, and in your case it's not clear whether this was the launching terminal or the software update. FYI, I launch apps during update without problems, so this isn't an OS issue, though you may have had a machine far too busy to handle what you demanded without having at least some apps starved for resources.
So, what do you do with your box to panic it? And by comparison, what do you do with the Linux box? I suspect that the GUI miracles occurring on the MacOS X machine result in a great deal more stress on hardware (CPU, GPU, RAM...) than occurs running a list of replacement apps on most other OSses. Tiger eats lots of RAM; Tiger is doing lots of "extra" work; Tiger is intended to provide a whole lot of bells a whistles that other BSD variants do not, and if you want pure speed, get BSD.
I suspect on the mini you had modest RAM and were trying to do a lot. Launching apps while the system is replacing critical frameworks could definitely qualify as a confusing issue for a machine
Let me think a sec. Last I checked, Linux was a project to make a Unix-workalike kernel. The project had just ditched (or been ditched by) its code management tool, and created "git" to replace it, so one could argue the Linux project does have an application to offer. However, X11 isn't a Linux project, most of the "modern" apps with nice friendly GUIs depend not only on x11 but on particular window managers, and these projects have developers which come from wildly different backgrounds and motivations primarily because the projects themselves solve problems which attract completely different support. Users and developers of Perl, PHP, Python, and Ruby exist on multiple platforms and have uses ranging from the novice/hobbyist to the specialist/professional. PostgreSQL, MySQL, and what have you solve problems for people with different focuses, hence their different feature sets, development priorities, and sources of support.
To say there is a "Linux development model" with respect to anything but the Kernel strikes me as a bit odd. Some distros might have a cognizable development model, but their collections of code are amalgamations of so many other projects that their capacity to offer a solution is heavily impacted by the development models of all the incorporated projects.
Projects by people in their spare time to provide something they plan to use for fun, projects by people hired by businesses to solve an economic concern, and everything in between comprise the code base that is drawn on to provide various distributions. Projects have internal organization wildly variant from one another, and they vary markedly in funding, pace of development, and in the measurements they take to determine how development is going and in the means used to establish development priorities.
I don't think that one can say of the broader code in operating system distributions which use a Linux kernel that there is a "development model" that offers any particular feature or demerit; the variation is too great to so characterize.
... and to bring this back to MacOS X, the inheritance enjoyed by Cocoa apps gives all you rlegacy Cocoa apps full advantage of improvements in the font system, in auto-spell-check tools, in services offered by applications the authors of your app knew nothing about ...
Apple bought a cool environment when it bought NeXT. Runtime linking allows a lot of interesting stuff, and the ability to upgrade all the apps on your system by upgrading your OS or the frameworks you install is a world different from systems whose upgrades force you to replace all your apps.
OS/2 used to have an argument that object orientation allowed the OS to upgrade your apps, rather than force you to replace them, and thus was unlike a MS-Win upgrade (which was compared to repainting your room, which forced you to change your furniture).
Now that OS/2 is dead, and its developers are making MS-Win apps (can you say Stardock?), it's good to see someone is still carrying the torch on this front.
I fear that if I get a ppc mac that 6 years down the road I wont be able to find working applications for it.
... I ran OS/@ Warp v.4 in VirtualPC on MacOS, that was fun :-)
I bought a Pizmo (G3 Powerbook with 100MHz bus and firewire) when Apple seemed about to adopt Unix as its OS, and ended up sitting on MacOS 9 longer than I intended. Interestingly, the Classic apps I started with run just fine on MacOS X, despite the fact that Classic has been deprecated for a while and is now obsoleted and, I think, now even unsupported.
Look at what you want to do, and ask if the hardware is up to it. If it is, then you will be happy regardless what Apple builds next, because that won't stop the hardware. Apple's dev tools are cross-platform, and Apple's developers know Apple customers keep their hardware for years (I still have and use the 5yo Pizmo) and understand they should click the checkboxes to build for both. For several years, I would think Apple's installed base of PPC will vastly outnumber the x86 gear they will be hawking. I doubt the Powermacs will be moved to Intel until a couple of years from now, since the desktop isn't where Intel is offering Apple the better roadmap (the reason Apple announced it was changing: performance per watt). Looking at what IBM is producing, I would guess Powermacs would look very good after the next major upgrade. If you are looking at notebooks, then the Intel looks pretty good.
You have to go back and ask what you are wanting.
FYI, I ran OS/2 Warp v.4 until the hard drive died, and the next one. Loved that OS. Now, THAT was a system that lost support. However, the apps I ran kept on running and running until the box died. Then
In linux swsusp is actually a software implementation, that also uses your swap partition, so you do not have to waste space on a special suspend partition that your bios understands.
/var/vm/ so I would think reading data out of this to repopulate RAM would be something of a time eater on a relatively busy / -- assuming there was even room.
Um, is this an x86 issue generally?
Apple hasn't written RAM to disk during sleep since some version of MacOS 9, and I expect that Apple sleep would lose its apparent performance if this were the case after the x86 transition. Apple's swap by default is to a file at
Is this really where MacOS X is headed?
Take care.
CUPS isn't what ships on your Linux? I thought MacOS X got it from the Lin folks ... CUPS works great on macs :-)
Ahh, archives of lists ... great way to et cutting-edge data on a product with regular paid upgrades and a binary updater system for minor upgrades. also: KPI introduction a likely harbinger of major kernel internals reworking.
Though, in your favor, a Darwin kernel developer recently chided a list poster who asked about Darwin x86 on MP systems; he said, if you want performance go use FreeBSD or Linux, that's not what Darwin x86 is about. That must have felt good to have posted less than a week before the x86 migration announcement! In Darwin's favor: actual disk synchronization for databases and other systems requiring real synch. Some of the comparisons out there appearing to favor Linux tend to prove Linux does not actually force synch like users expect. On the other hand, Linux could also suffer from a plague of drives that ignore synch commands to pretend to have better performance ... however, to get knowledgeable on the synch issue, you'd have to read development lists rather than the bitch lists of third party developers.