Quartz Extreme requires support for non-power-of-two textures, which is something that the older, non-Radeon, ATI GPUs do not have. AFAIK, enabling that is much more than new drivers.
Obviously, I don't know how much QE depends on this feature, but I suspect it is fairly fundamental.
And, as the owner of an unsupported ATI GPU, I would be extremely pleased to be proved wrong.
'strong' is a much overused word, and pretty meaningless without significant qualification. Which is stronger: Balsa wood or Teak? OK, so when was the last time you made a model plane out of teak then?
Materials have the following attributes (and others of course):
brittle/tough (glass vs steel)
elastic/inelastic (aka stiffness)
isotropic/anisotrpic
density
tempera ture stability
chemical stability (resistance to corrosion)
cost of raw material
cost of manufacture
hardness
Now, stiffness is one of the important ones. High Young's modulus (stiffness) good, low Young's modulus bad. Stiff and light is better; stiff, light and tough really attracts attention.
So don't 'support' the users. This is not the same as not allowing them.
I've worked with an ISP that had this very policy. If you ran Win9x and IE, the help desk would assist you. If you ran anything else---you are on your own. Anything else included Win/NT, Win2k etc.. Just the lowest common denominator 'consumer' systems were supported. BUT, all the documentation on what you needed was available. If you ran *nix/Mac you were assumed to be clueful enough to deal.
Do this, and the only cost is the drivers. Maybe not trivial, maybe. So open source them. Let someone else write them for you. Your profit is not in the IP held in these drivers---which are just a means to an end---namely getting more customers online.
Not only that, maybe the drivers will be better than the in-house ones. Being open source, you can benefit from that, roll them back into your Win drivers, provide better service, equals happier customers, equals more---and more profitable---customers.
The people in our household all seem to have their own preferences for screen resolution, so I'd say the resolution changes 3-4 times a day, not counting full-screen games:-)
Of course, any one person changes their screen resolution somewhat less frequently.
Best? A reboot is simple, but I don't think it's the 'best'.
Apple could walk through the process list and restart any of the standard daemons that needed it. They could suggest that a reboot would be a Good Idea, but I don't think it should be mandatory.
Debian manages this sort of thing with apt-get just fine without a reboot.
It's a mindset thing. Someone is still stuck in the 'any change to the system = reboot!' frame.
Was that restart really necessary? Even for an update that replaces libraries, I would have thought the most that would be required would be to restart the odd daemon, not the whole system!
I was under the impression the Darwin framework system was sophisticated enough to deal with new versions replacing old on running systems.
Is this just a holdover in thinking from the OS 9 days?
Re:Think of the mpeg2 quality.
on
Atomic Scale Memory
·
· Score: 3, Insightful
Parkinson's Law:Work expands so as to fill the time available for its completion
MS used to make a fair word processor for DOS. Called Word. It had stiff competition from WordPerfect, which was generally considered superior.
MS ported Word to the Mac. The code base was not shared, and there were features in the DOS version (such as character styles) that never made it into the Mac version. In fact, MS Word on the Mac was more a workalike than a port.
MS created a very good spreadsheet program, called Excel, on the Mac. However, on the PC, Lotus 1-2-3 ruled supreme.
The PC Word was a DOS program. Character, not Window oriented. The Mac programs were, perforce, window oriented.
MS Needed a WordPerfect killer for Windows 3, and they needed a window based, not a character based app, so they ported---a real port this time---Word 5 from the Mac over to Windows. One goal was to share a common code base between platforms. To this end, Word was re-targeted into an intermediate framework. Which was heavily biased towards Windows (not Mac) and heavily optimised for Windows.
MS then ported Word back to the Mac, with the execrable Mac 'interpreter' and Windows look and feel. It was not, shall we say, well received.
As you say, they eventually recanted and built Office again as a Mac app, with very little of the original code base. The goal of shared code was unrealised.
The point I find interesting, is that both Word and Excel were originally Macintosh apps, ported to Windows.
Looks very cool. It also looks very similar to Celestia, a free app which also uses OpenGL to do its thing. Since they both ultimately use the same information---the 3-D location of the stars in the Milky Way---I wonder if you could just plug the Partiview database into Celestia? In fact, I wonder if the databases are appreciably different?
Not quite. This link gives quite bit more background about Darwin. In particular:
Part of the history of Mac OS X goes back to Berkeley Software Distributions (BSD) UNIX of the early seventies. Specifically, it is based in part on BSD 4.4 Lite. On a system level, many of the design decisions are made to align with BSD-style UNIX systems. Many of the libraries are derived from NetBSD (http://www.netbsd.org/), while many of the utilities are from FreeBSD (http://www.freebsd.org/). For future development, Mac OS X has adopted FreeBSD as a reference code base for BSD technology. Work is ongoing to more closely synchronize all BSD tools and libraries with the FreeBSD-stable branch.
Although Mac OS X must credit BSD for most of the underlying levels of the operating system, Mac OS X also owes a major debt to Mach. The kernel is heavily influenced in its design philosophy by Carnegie Mellon's Mach project. The kernel is not a pure microkernel implementation though since the address space is shared with BSD processes.
The Mac OS X kernel (also known as XNU) is a monolithic kernel (unlike Mach, but like Linux and xBSD) with Mach and BSD sitting side-by-side.
Some earlier Apple Unix efforts were true micro kernel implementations. This was also driven by the attraction of a pure hardware abstraction layer. With Darwin this seems to have moved to a more pragmatic recognition that performance matters.
In Darwin, the Mach bits handle memory management, IPC and device drivers. BSD handles users and permissions, the network stack, the virtual file system and POSIX.
So, this won't directly benefit Darwin, though if it is generally useful then someone/anyone can try and put it into Darwin---long live open source! I confess I don't know how the Mach part of Darwin handles scheduling, though I had heard that the Mach VM and scheduling was pretty good.
Did you find this link? It gives a good overview of what is going on from a Unix perspective. Some useful quotes:
Part of the history of Mac OS X goes back to Berkeley Software Distributions (BSD) UNIX of the early seventies. Specifically, it is based in part on BSD 4.4 Lite. On a system level, many of the design decisions are made to align with BSD-style UNIX systems. Many of the libraries are derived from NetBSD (http://www.netbsd.org/), while many of the utilities are from FreeBSD (http://www.freebsd.org/). For future development, Mac OS X has adopted FreeBSD as a reference code base for BSD technology. Work is ongoing to more closely synchronize all BSD tools and libraries with the FreeBSD-stable branch.
Although Mac OS X must credit BSD for most of the underlying levels of the operating system, Mac OS X also owes a major debt to Mach. The kernel is heavily influenced in its design philosophy by Carnegie Mellon's Mach project. The kernel is not a pure microkernel implementation though since the address space is shared with BSD processes.
The Mac OS X kernel (also known as XNU) is a monolithic kernel (unlike Mach, but like Linux and xBSD) with Mach and BSD sitting side-by-side.
Mach handles memory management, IPC and device drivers. BSD handles users and permissions, the network stack, the virtual file system and POSIX.
Once outside the kernel it's much more BSD like, with a large dollop of NeXT-isms thrown in. Most of the CLI and utilities are BSD like. Mac OS X tends to use OpenBSD for networking. (As an aside, Mac OS 8-9's OpenTransport is streams based, like Solaris. In fact, written by Mentat who wrote the NetWare and Solaris stacks too).
The chief gotcha may be that Mach handles I/O. The BSD/dev tree is there, but putting devices into the tree is done dynamically by Mach. In other words, you can't make use of any BSD device drivers.
Well first, its highly unlikely that the browser is using anything but good old TCP/IP, so mentioning AppleTalk is somewhat irrelevant.
Secondly---since you have mentioned it:-)---like many other things that are well known, AppleTalks 'chattiness' relative to other protcols "ain't necessarily so".
As an exercise, take a look via tcpdump at what is actually happening on your LAN (more difficult now everybody uses switches, but it will give an idea). Don't just assume, don't just theorize, measure!.
See the flood of NetBIOS messages. Look at the Novell SAP torrent. Shudder as page after page of NetBEUI broadcasts flash by. (What you will see depends on what protocols are present on your LAN of course). Tell me again about chatty protocols?
But wait---now look to see just what percentage of the available LAN is consumed by all these chatty exchanges. 1-2%? Ask yourself---does this chatter actually matter anyway?
I'd never recommend AppleTalk over TCP/IP, since AppleTalk has a number of scalability problems and is just not appropriate for modern networks, but I'm so sick of the 'chatty' AppleTalk myth.
That will be in about 3 months, when it is released to the pay-per-view cable companies.
It will be released then, ta dah!, on BETA tape, Digital BETA too. Why, because that's what the professionals use, and have done for years. (You thought the cable company digitized off 35mm film?)
The question has to be, why, given the existence of DVC and DVC-pro variants, do we need this new format? Oh, because it's copy protected... (briefly).
In fact, when speaking of structures, 'strong' is almost entirely meaningless without qualification. Which is 'stronger', balsa wood or cast iron? And why wouldn't you make a model glider out of cast iron? There are a whole range of properties that matter, more usefully defined by stiffness, toughness, hardness, isotropy, thermal and chemical stability, density, etc.
For a couple of really good books on the subject, try J. E. Gordon's "Structures" and "The New Science of Strong Materials" (See this page for a very brief review of Structures. The books are quite old now, but the basic principles haven't really changed.
Well, Jordan Hubbard claimed that With the release of OS X, Apple will literally be the largest Unix vendor on the planet.
Whether this has been substantiated post the release of Mac OS X, and how that relates to Linux as a whole, I don't know. Does Apple ship more Unix than:
RedHat?
Redhat+Debian combined?
Linux + FreeBSD + NetBSD + OpenBSD combined?
Or not?
BTW, since Mac OS X is a BSD variant by at least some measures, Linux/BSD users>Mac OS X users for all Linux users1
If by computers that crash, you mean Apple. That's not what is happening. In your other reply below you imply that these computers execute code without checking, which would be a design flaw, but isn't actually what happens.
You may be unable to eject certain copy-protected audio discs, which resemble Compact Discs (CD) but technically are not. Some computers start up to a gray screen after a copy protected disc has been left in the computer.
So, some Apple computers won't recognise the CD---which is the effect the malware is trying to achieve. These also won't let you eject the CD---which I agree should most certainly be fixed, if possible (as I said, it may be that the drive goes all catatonic and won't respond).
Additionally, when you reboot, some computers may also get confused by the bad CD. Basically, during the boot process they scan all available disks---and the CD never responds, and the computer never times out. Again, a bug (in the computer boot firmware) which needs to be fixed. But it's not caused by the computer executing untrusted code.
Apple tends to cover up the manual eject button and the 'paperclip' emergency eject button---but they are there, and that trip to the shop involves some tech finding for you. (Shouldn't be a challenge to any/.r I'd have hoped).
As for the manufacturers---I rather hope that this little debacle does indeed prompt the PC manufacturers to re-evaluate who they get their drives off. I'm sure that Sony Electronics will be even more pleased with Sony Music than they now are.
There is a sound principal used by the IETF: Be strict in what you produce and liberal in what you accept.
So, the PC should check that the track is corrupt, and recover gracefully.
The problem however, is that the malware CDs, don't just contain random cruft, as would result from a scratch. They contain information that intentionally attempts to deceive.
We can argue that the PC should not react inappropriately to this, but we can also argue that a PC should not react inappropriately to a virus, trojan or other attack: this still in no way exonerates the perpetrator of the virus, trojan or Celine Dion.
As a further complication, it is not even software in the PC that is being attacked, it is firmware in the CD drive itself. Firmware that in many cases is in drives manufactured by Sony. Firmware written by Sony. The PC doesn't even get a chance to react. It asks the drive to read the CD and that's the last the PC hears from the drive.
Assuming the drive doesn't go completely catatonic when it sees such a CD, it should be possible to get the PC to send a "reset and eject" sequence of commands, and Apple should provide a way to do this.
But, maybe it isn't possible. Maybe some drives won't accept commands while they are confused by a malware CD. I don't know, any./s who do?
Certainly, Apple should provide firmware updates for the drives to prevent the problem, but as I just pointed out, there could be some issues there given where the firmware has to come from.
In summary, while some of it may be Apple's fault, there may be extenuating circumstances---for Apple. I can't think of any for Sony. (And indeed, you won't find the malware CDs for sale in a number of jurisdictions where they are plainly illegal under local consumer protection laws.)
Firewire (as opposed to i.Link), has one huge advantage---the connector.
You've seen it before, take a look at your Gameboy.
Apparently when they came to look for a really robust connector they decided that the Gameboy one fit the bill. If it can survive massive PFY abuse it should survive anything.
Of course, that might explain Sony's reluctance to use it, being tainted by association with Nintendo.
The USB connector, by comparison, destroys far too easily.
Slashdot Mirror
Obviously, I don't know how much QE depends on this feature, but I suspect it is fairly fundamental.
And, as the owner of an unsupported ATI GPU, I would be extremely pleased to be proved wrong.
Nope, no good. there is only one way to be sure.
Materials have the following attributes (and others of course):
Now, stiffness is one of the important ones. High Young's modulus (stiffness) good, low Young's modulus bad. Stiff and light is better; stiff, light and tough really attracts attention.
For a very readable introduction to this, I recommend The New Science of Strong Materials (or why you don't fall through the floor) by J.E. Gordon, also his Structures.
I've worked with an ISP that had this very policy. If you ran Win9x and IE, the help desk would assist you. If you ran anything else---you are on your own. Anything else included Win/NT, Win2k etc.. Just the lowest common denominator 'consumer' systems were supported. BUT, all the documentation on what you needed was available. If you ran *nix/Mac you were assumed to be clueful enough to deal.
Do this, and the only cost is the drivers. Maybe not trivial, maybe. So open source them. Let someone else write them for you. Your profit is not in the IP held in these drivers---which are just a means to an end---namely getting more customers online.
Not only that, maybe the drivers will be better than the in-house ones. Being open source, you can benefit from that, roll them back into your Win drivers, provide better service, equals happier customers, equals more---and more profitable---customers.
Oh, I see Palmer Eldritch beckoning to me through the cracks. Sorry, got to go now---it was good while it lasted.
Of course, any one person changes their screen resolution somewhat less frequently.
Apple could walk through the process list and restart any of the standard daemons that needed it. They could suggest that a reboot would be a Good Idea, but I don't think it should be mandatory.
Debian manages this sort of thing with apt-get just fine without a reboot.
It's a mindset thing. Someone is still stuck in the 'any change to the system = reboot!' frame.
I was under the impression the Darwin framework system was sophisticated enough to deal with new versions replacing old on running systems.
Is this just a holdover in thinking from the OS 9 days?
Parkinson's Law of Data: Data expands to fill the space available for storage
Asimov's corollary to Parkinson's Law of data: Backlog expands to overfill planned extensions.
I'm sure we'll find a way to use it...
As you say, they eventually recanted and built Office again as a Mac app, with very little of the original code base. The goal of shared code was unrealised.
The point I find interesting, is that both Word and Excel were originally Macintosh apps, ported to Windows.
Looks very cool. It also looks very similar to Celestia, a free app which also uses OpenGL to do its thing. Since they both ultimately use the same information---the 3-D location of the stars in the Milky Way---I wonder if you could just plug the Partiview database into Celestia? In fact, I wonder if the databases are appreciably different?
The Mac OS X kernel (also known as XNU) is a monolithic kernel (unlike Mach, but like Linux and xBSD) with Mach and BSD sitting side-by-side.
Some earlier Apple Unix efforts were true micro kernel implementations. This was also driven by the attraction of a pure hardware abstraction layer. With Darwin this seems to have moved to a more pragmatic recognition that performance matters.
In Darwin, the Mach bits handle memory management, IPC and device drivers. BSD handles users and permissions, the network stack, the virtual file system and POSIX.
So, this won't directly benefit Darwin, though if it is generally useful then someone/anyone can try and put it into Darwin---long live open source! I confess I don't know how the Mach part of Darwin handles scheduling, though I had heard that the Mach VM and scheduling was pretty good.
So, does this mean that they have finally worked out a license deal for MPEG-4, and if so, what is it?
Aspartamine may be sweet, but it also has its own distinctive taste---which I happen to loath.
The article says it is similar to aspartamine so it may have a similar taste, or it may taste quite different.
Fortunately I don't need to restrict the amount of sugar in my diet, so this is no big deal for me personally.
I am reminded of a quote (probably misremembered) from Kurt Vonnegut's Breakfast of Champions
The Mac OS X kernel (also known as XNU) is a monolithic kernel (unlike Mach, but like Linux and xBSD) with Mach and BSD sitting side-by-side.
Mach handles memory management, IPC and device drivers. BSD handles users and permissions, the network stack, the virtual file system and POSIX.
Once outside the kernel it's much more BSD like, with a large dollop of NeXT-isms thrown in. Most of the CLI and utilities are BSD like. Mac OS X tends to use OpenBSD for networking. (As an aside, Mac OS 8-9's OpenTransport is streams based, like Solaris. In fact, written by Mentat who wrote the NetWare and Solaris stacks too).
The chief gotcha may be that Mach handles I/O. The BSD /dev tree is there, but putting devices into the tree is done dynamically by Mach. In other words, you can't make use of any BSD device drivers.
Well first, its highly unlikely that the browser is using anything but good old TCP/IP, so mentioning AppleTalk is somewhat irrelevant.
Secondly---since you have mentioned it :-)---like many other things that are well known, AppleTalks 'chattiness' relative to other protcols "ain't necessarily so".
As an exercise, take a look via tcpdump at what is actually happening on your LAN (more difficult now everybody uses switches, but it will give an idea). Don't just assume, don't just theorize, measure!.
See the flood of NetBIOS messages. Look at the Novell SAP torrent. Shudder as page after page of NetBEUI broadcasts flash by. (What you will see depends on what protocols are present on your LAN of course). Tell me again about chatty protocols?
But wait---now look to see just what percentage of the available LAN is consumed by all these chatty exchanges. 1-2%? Ask yourself---does this chatter actually matter anyway?
I'd never recommend AppleTalk over TCP/IP, since AppleTalk has a number of scalability problems and is just not appropriate for modern networks, but I'm so sick of the 'chatty' AppleTalk myth.
It will be released then, ta dah!, on BETA tape, Digital BETA too. Why, because that's what the professionals use, and have done for years. (You thought the cable company digitized off 35mm film?)
The question has to be, why, given the existence of DVC and DVC-pro variants, do we need this new format? Oh, because it's copy protected... (briefly).
For a couple of really good books on the subject, try J. E. Gordon's "Structures" and "The New Science of Strong Materials" (See this page for a very brief review of Structures. The books are quite old now, but the basic principles haven't really changed.
Whether this has been substantiated post the release of Mac OS X, and how that relates to Linux as a whole, I don't know. Does Apple ship more Unix than:
Or not?
BTW, since Mac OS X is a BSD variant by at least some measures, Linux/BSD users>Mac OS X users for all Linux users1
In the Apple Knowledge Base article it describes the symptoms as:
So, some Apple computers won't recognise the CD---which is the effect the malware is trying to achieve. These also won't let you eject the CD---which I agree should most certainly be fixed, if possible (as I said, it may be that the drive goes all catatonic and won't respond).Additionally, when you reboot, some computers may also get confused by the bad CD. Basically, during the boot process they scan all available disks---and the CD never responds, and the computer never times out. Again, a bug (in the computer boot firmware) which needs to be fixed. But it's not caused by the computer executing untrusted code.
Apple tends to cover up the manual eject button and the 'paperclip' emergency eject button---but they are there, and that trip to the shop involves some tech finding for you. (Shouldn't be a challenge to any /.r I'd have hoped).
As for the manufacturers---I rather hope that this little debacle does indeed prompt the PC manufacturers to re-evaluate who they get their drives off. I'm sure that Sony Electronics will be even more pleased with Sony Music than they now are.
So, the PC should check that the track is corrupt, and recover gracefully.
The problem however, is that the malware CDs, don't just contain random cruft, as would result from a scratch. They contain information that intentionally attempts to deceive.
We can argue that the PC should not react inappropriately to this, but we can also argue that a PC should not react inappropriately to a virus, trojan or other attack: this still in no way exonerates the perpetrator of the virus, trojan or Celine Dion.
As a further complication, it is not even software in the PC that is being attacked, it is firmware in the CD drive itself. Firmware that in many cases is in drives manufactured by Sony. Firmware written by Sony. The PC doesn't even get a chance to react. It asks the drive to read the CD and that's the last the PC hears from the drive.
Assuming the drive doesn't go completely catatonic when it sees such a CD, it should be possible to get the PC to send a "reset and eject" sequence of commands, and Apple should provide a way to do this.
But, maybe it isn't possible. Maybe some drives won't accept commands while they are confused by a malware CD. I don't know, any ./s who do?
Certainly, Apple should provide firmware updates for the drives to prevent the problem, but as I just pointed out, there could be some issues there given where the firmware has to come from.
In summary, while some of it may be Apple's fault, there may be extenuating circumstances---for Apple. I can't think of any for Sony. (And indeed, you won't find the malware CDs for sale in a number of jurisdictions where they are plainly illegal under local consumer protection laws.)
You've seen it before, take a look at your Gameboy.
Apparently when they came to look for a really robust connector they decided that the Gameboy one fit the bill. If it can survive massive PFY abuse it should survive anything.
Of course, that might explain Sony's reluctance to use it, being tainted by association with Nintendo.
The USB connector, by comparison, destroys far too easily.
What sort of performance hit does this impose? For instance, is it low enough to run nearly everything in the sandbox as a matter of course?
How many mod points is an XServer worth I wonder?