Of course, IE for the Mac is dog slow (its carbon, not naitive cocoa code)
You don't know what you're talking about - the performance of an application has nothing to do with it being written to Carbon or Cocoa, and there's nothing more "native" about applications written to the Cocoa framework.
E.g., just look at iCal, iPhoto, or the Jaguar Calculator: all written in Cocoa, and all embarrassingly slow.
Nothing tops when Apple had to recall those PowerBooks shipped with bad batteries.
The 5300 may have been a crappy PowerBook, however they were never recalled due to batteries - 2 battery units overheated (neither caught fire) whilst being tested at Apple, and none of the problem Sony batteries were ever shipped to customers. An extended warranty (9 years IIRC) program was introduced to handle other problems with this model - the screen hinges were lousy, the plastics would often split, and there were was a rash of models with bad motherboards.
Unfortunately it's become an urban legend that Apple shipped some kind of burning PowerBook - but they didn't. You must be thinking of Compaq (had to recall 55,000 batteries from their Armada laptops), Dell (about 30,000 batteries from the Latitude and Inspiron models), or IBM (about 220,000 ThinkPad power adapters).
The statement about the UI being proprietary is sheer ignorance.
I'm afraid not. The Appearance Manager was introduced with Mac OS 8 (not System 7), and it provided backwards compatibility for people who were using the standard System 7 UI widgets.
Although adopting the Appearance Manager gave you access to lots of new widgets, if an application had been written correctly it would not have had to do anything to pick up the new "platinum" appearance.
Quark's problem was the same as most of the other apps which had problems in that transition - they wrote their own UI widgets, which were designed to mimic the System 7 look. Which of course meant that they were left behind when the system UI was updated. There were several shim classes available ("Gray Council" was one of them I believe) for class libraries like PowerPlant, which would let you write apps that would select either the Appearance Manager widget, a facsimile of it to work around AM bugs, or the same widget with a System 7 look-and-feel.
Quark could easily have updated their code to use the same technique (i.e., update their custom widgets to be able to draw in both styles), but why would then when people didn't have a choice?
It wasn't just a Quark problem of course - NeXT apps had the same problem on Windows, as they drew all their own widgets rather than using the system widgets. Which worked great. And then Windows 95 came out...:-)
That's Office for Mac OS X, not Office for BSD. Just because Carbon sits on top of BSD on Mac OS X doesn't mean you'll be running Office on NetBSD any time soon.
Bitrate peeling is not a good idea because it seperates the audio signal, with hi frequency data being seperate from low and mid frequency data.
I'm not sure if it's frequencies that are being separated here - the idea seems similar to wavelet image compression, where refinements to the original data arrive over time.
Note I know nothing about Ogg, so it probably isn't based on a wavelet approach, but the idea sounds more like you get low resolution data (covering the full frequency range) followed by higher resolution data. I.e., you're increasing the sampling rate over time - but the range of frequencies you sample is the same regardless.
Directx is Satan spawn. I would hate for this to be the primary graphic base for games on my mac
I hate to break it to you, but this technique (a wrapper that implements Direct3D/Draw/etc on top of OpenGL) is the primary graphic base for games on your Mac.
Every Mac porting house already has their own set of libraries to do just this, it's just none of them have bothered to make them public like MacDX.
The real market for this is for PC developers, and it remains to be seen how many of them will actually take the bait and try and port titles over themselves (making money off developer tools is a real challenge, as you're selling to the very people who could write it themselves:-).
There are a lot of other issues you need to consider when doing a port (endian-swapping is the biggest time sink normally, followed by code using VC-- "extensions", then platform specific issues - working around bugs in OpenGL on 9 which will never be fixed, etc), and the code which talks to DirectX is normally a pretty small part of a game's code base.
If people don't have the mental capacity to fairly easily filter out most spam, maybe they should stick to dead-tree-based mail...
-1, Utter Bollocks...
Why should I have to put up with endless financial scams and obscenity laden drivel whenever I check my email? Saying "oh, it's not hard to hit delete" is a cop-out. If you don't object to deleting 10 mails a day, what about 50? 100? 200? 1000? Presumably you have a limit on how much you'll take personally, so what are you planning to do when you start getting double that?
You wouldn't put up with it in any other medium (phone, post, people coming to your house), so why email?
I doubt it. The vast majority of spam I receive is non-Western (various East Asian charsets).
Proves nothing - it all depends on which lists you end up on. I get about 120 spams a day, of which about 115 are in ASCII - and 95% of those come from the US.
I suspect the US will never legislate effectively (i.e., at a federal level) against spam. Any legal framework is likely to come out of the EU, which has much stronger data protection laws.
Although they did replace it no questions asked with a Powerbook 1400
Not in general they didn't . There was an extended warranty program (8 or 9 years I believe) for the 5300, but there wasn't any kind of official trade-in program. You may have had a friendly dealer who let you trade up, but the regular 5300 repair program was just to do a component replacement.
The biggest problem with the 5300 wasn't the battery overheating (which occurred in one test unit, and never actually reached customers let alone "caught fire" - unlike Compaq's recall of 55,000 shipped batteries), it was poor plastics (cracked hinges and screen frames) and faulty motherboards (failure to boot, mysterious sound problems).
The extended warranty program was certainly helpful though - mine went through three screens and two motherboards in its life (before I bought a 1400).
Pre-emptive threading has been available on Classic Mac OS for some time - either through the Thread Manager (first thread API, dates to 68K Macs) or MP Tasks (second thread API, developed in conjunction with Daystar for their PowerPC clones and still available in Carbon on 9 or X).
Of course up until Mac OS 9 threads suffered from not being able to call much in the way of system APIs, so threaded apps were not as common as they are on Windows (but were still used for cases where it was worth doing: Photoshop, renderers, etc).
Refactoring is often about injecting the last good idea you had into working code. I won't dispute that there are legitimate cleanups, but if a developer couldn't do it right the first time, I have my doubts that round two is going to be much better.
I think you're probably right on both counts...:-) My experience has been that refactoring is most successful when applied to code that was in pretty poor shape to start with.
Often this is because it was the first attempt by someone who didn't really know what they were doing, they kept hacking on it until it limped into life, and then it got shipped. "Refactoring" in these cases is really just a face-saving way of cleaning up someone else's mess...
If you've been working professionally for more than 5 years, and you're reasonably good at it, then writing clean maintainable code should be second nature ("refactoring" as a new concept is really for people who didn't pick up "structured programming" the first time round...).
many middle-tier and upper-level managers think that such concepts are useless and timewasting.
Their problem is, it's very difficult for them to tell if refactoring was actually worth it - their developers start with a program that does A, they stop working on new features for the next release for 3 months, and they come back with a program that still does A ("but better!").
As a developer you can explain how cleaning up code is preventative maintenance to make development easier in the future, but if you're not a developer that's a very hard thing to measure.
Even if you trust your engineers implicitly, any good manager has to realise that developers love intellectual problems over more mundane tasks - and refactoring's biggest problem is that by design you end up looking like nothing happened.
That's a specious argument - you could just as easily say that's because the vast majority of Linux GUI apps are so atrocious they don't merit a mention.
Neither of which are completely true, but the problem is that UI matters enough for commercial apps that people are willing to set up sites like this to mock the bad examples.
Basic UI awareness is only just starting to emerge on "Open Source OSes" - look at how long it has taken to get even somewhat usable, never mind standardised, open/save dialogs.
The part of MS which sells to corporations probably isn't too worried - their biggest worry is a free competitor like Linux undercutting them with equivalent (and free) servers and acceptable (and free) desktops.
The part of MS which sells to consumers is more worried (if they have any sense) - their biggest worry is a competitor which is sexy. A lot of people are starting to come around to the idea that life with an N-Ghz x86 box running Windows might not be as trouble-free as a whatever-Mhz Mac running Mac OS X.
These people aren't the hard core gamers/built-it-yourself/overclockers/pick-a-subcu lture, these are the (far more numerous) people who're looking for a computer that has an appliance-like simplicitly. All of the apps these kind of people are looking for are all available on the Mac (Office, email, web, The Sims, etc) and if they're thinking of buying a new computer why not get a nice-looking Mac this time?
Of course Apple could triple their marketshare without causing MS any major concerns, but if MS are looking for their potential consumer competitor then Apple are it.
In any large software system, the truly unique code probably accounts for about 1% of the source.
Hmm, not on any large software system I've ever worked on... The important part isn't some magic 1% of the source, it's the fact that you got a group of people together for long enough to ship the thing.
This negates one of his basic points, and doesn't really contribute much over his previous rant...
Quicktime is as we all know the most crappy videoformat ever.
QuickTime is an API that defines a file format, not a codec. If you're not happy with the output of whatever codec you're using, use a better codec (or more likely, learn how to tune the one you're using for your subject matter).
It's bloated, and has a ugly player which you can't replace.
You do realise that QuickTime (the API) is not the same as QuickTime Player (the app)?
If you want to write a better movie player on top of QuickTime, knock yourself out - there used to be several such things on the Mac, all using the same API calls as the official player (QuickTime itself doesn't care - it's app agnostic).
Re:And you ask the /. community..
on
Just One Page a Day
·
· Score: 5, Funny
You're both right - the menu tracking was incorrect on 10.0, but this was one of the (many) things fixed in 10.1. There's some more information about this subject here, along with some other Mac subtleties.
E.g., one extremely useful one is the way the cursor vanishes when you start typing (but re-appears if you grab the mouse). Systems which don't implement this have the extremely annoying problem where you click in an edit-field to type, and then you can't see what you're typing because the cursor is blocking your view...
I wonder if this will force them to reconsider such a relatively insecure approach to OS security?
Considering that the Apple implementation uses 128 bit keys, and it took 4 years to brute force a 109 bit key, I don't think it's anything like "relatively insecure".
In theory degraded quality, although given that people used to swap tape to tape dubs at school in the '80s that's hardly a reason to stop...
The obvious response is to keep the data digital and encrypted all the way to the speakers - that would only stop you if you had a mic, and then the step after that would be to require that only licensed operators are allowed to purchase microphones.
You might laugh, but everything the record industry has done to date has indicated this would be their ideal scenario - they want an audience of passive consumers, with the law on their side to keep control of production technology.
The sad thing is that the software industry tried this, and rejected it, in the 80s/early 90s. Evenutally everyone realised that copy protection is fundamentally pointless, and you get better results by putting your energy into creating something that people actually want to purchase (insert comment about those who don't know history being doomed to repeat it via Palladium here).
Slashdot Mirror
Of course, IE for the Mac is dog slow (its carbon, not naitive cocoa code)
You don't know what you're talking about - the performance of an application has nothing to do with it being written to Carbon or Cocoa, and there's nothing more "native" about applications written to the Cocoa framework.
E.g., just look at iCal, iPhoto, or the Jaguar Calculator: all written in Cocoa, and all embarrassingly slow.
Nothing tops when Apple had to recall those PowerBooks shipped with bad batteries.
The 5300 may have been a crappy PowerBook, however they were never recalled due to batteries - 2 battery units overheated (neither caught fire) whilst being tested at Apple, and none of the problem Sony batteries were ever shipped to customers. An extended warranty (9 years IIRC) program was introduced to handle other problems with this model - the screen hinges were lousy, the plastics would often split, and there were was a rash of models with bad motherboards.
Unfortunately it's become an urban legend that Apple shipped some kind of burning PowerBook - but they didn't. You must be thinking of Compaq (had to recall 55,000 batteries from their Armada laptops), Dell (about 30,000 batteries from the Latitude and Inspiron models), or IBM (about 220,000 ThinkPad power adapters).
The statement about the UI being proprietary is sheer ignorance.
:-)
I'm afraid not. The Appearance Manager was introduced with Mac OS 8 (not System 7), and it provided backwards compatibility for people who were using the standard System 7 UI widgets. Although adopting the Appearance Manager gave you access to lots of new widgets, if an application had been written correctly it would not have had to do anything to pick up the new "platinum" appearance.
Quark's problem was the same as most of the other apps which had problems in that transition - they wrote their own UI widgets, which were designed to mimic the System 7 look. Which of course meant that they were left behind when the system UI was updated. There were several shim classes available ("Gray Council" was one of them I believe) for class libraries like PowerPlant, which would let you write apps that would select either the Appearance Manager widget, a facsimile of it to work around AM bugs, or the same widget with a System 7 look-and-feel.
Quark could easily have updated their code to use the same technique (i.e., update their custom widgets to be able to draw in both styles), but why would then when people didn't have a choice?
It wasn't just a Quark problem of course - NeXT apps had the same problem on Windows, as they drew all their own widgets rather than using the system widgets. Which worked great. And then Windows 95 came out...
They already did release Office for BSD
That's Office for Mac OS X, not Office for BSD. Just because Carbon sits on top of BSD on Mac OS X doesn't mean you'll be running Office on NetBSD any time soon.
YHBT. HAND.
This has to be a new record, surely. It's a duplicate. The original was only 5 days ago. And it was posted by the same person!
Ye gods...
btw...anyone know if it would be possible to ./ data?
Uh, no. You see, web servers are from real life. Data is a character on a TV show.
Bitrate peeling is not a good idea because it seperates the audio signal, with hi frequency data being seperate from low and mid frequency data.
I'm not sure if it's frequencies that are being separated here - the idea seems similar to wavelet image compression, where refinements to the original data arrive over time.
Note I know nothing about Ogg, so it probably isn't based on a wavelet approach, but the idea sounds more like you get low resolution data (covering the full frequency range) followed by higher resolution data. I.e., you're increasing the sampling rate over time - but the range of frequencies you sample is the same regardless.
Directx is Satan spawn. I would hate for this to be the primary graphic base for games on my mac
:-).
I hate to break it to you, but this technique (a wrapper that implements Direct3D/Draw/etc on top of OpenGL) is the primary graphic base for games on your Mac. Every Mac porting house already has their own set of libraries to do just this, it's just none of them have bothered to make them public like MacDX.
The real market for this is for PC developers, and it remains to be seen how many of them will actually take the bait and try and port titles over themselves (making money off developer tools is a real challenge, as you're selling to the very people who could write it themselves
There are a lot of other issues you need to consider when doing a port (endian-swapping is the biggest time sink normally, followed by code using VC-- "extensions", then platform specific issues - working around bugs in OpenGL on 9 which will never be fixed, etc), and the code which talks to DirectX is normally a pretty small part of a game's code base.
If people don't have the mental capacity to fairly easily filter out most spam, maybe they should stick to dead-tree-based mail...
-1, Utter Bollocks...
Why should I have to put up with endless financial scams and obscenity laden drivel whenever I check my email? Saying "oh, it's not hard to hit delete" is a cop-out. If you don't object to deleting 10 mails a day, what about 50? 100? 200? 1000? Presumably you have a limit on how much you'll take personally, so what are you planning to do when you start getting double that?
You wouldn't put up with it in any other medium (phone, post, people coming to your house), so why email?
I doubt it. The vast majority of spam I receive is non-Western (various East Asian charsets).
Proves nothing - it all depends on which lists you end up on. I get about 120 spams a day, of which about 115 are in ASCII - and 95% of those come from the US.
I suspect the US will never legislate effectively (i.e., at a federal level) against spam. Any legal framework is likely to come out of the EU, which has much stronger data protection laws.
Although they did replace it no questions asked with a Powerbook 1400
Not in general they didn't . There was an extended warranty program (8 or 9 years I believe) for the 5300, but there wasn't any kind of official trade-in program. You may have had a friendly dealer who let you trade up, but the regular 5300 repair program was just to do a component replacement.
The biggest problem with the 5300 wasn't the battery overheating (which occurred in one test unit, and never actually reached customers let alone "caught fire" - unlike Compaq's recall of 55,000 shipped batteries), it was poor plastics (cracked hinges and screen frames) and faulty motherboards (failure to boot, mysterious sound problems).
The extended warranty program was certainly helpful though - mine went through three screens and two motherboards in its life (before I bought a 1400).
Pre-emptive threading has been available on Classic Mac OS for some time - either through the Thread Manager (first thread API, dates to 68K Macs) or MP Tasks (second thread API, developed in conjunction with Daystar for their PowerPC clones and still available in Carbon on 9 or X).
Of course up until Mac OS 9 threads suffered from not being able to call much in the way of system APIs, so threaded apps were not as common as they are on Windows (but were still used for cases where it was worth doing: Photoshop, renderers, etc).
Refactoring is often about injecting the last good idea you had into working code. I won't dispute that there are legitimate cleanups, but if a developer couldn't do it right the first time, I have my doubts that round two is going to be much better.
:-) My experience has been that refactoring is most successful when applied to code that was in pretty poor shape to start with.
I think you're probably right on both counts...
Often this is because it was the first attempt by someone who didn't really know what they were doing, they kept hacking on it until it limped into life, and then it got shipped. "Refactoring" in these cases is really just a face-saving way of cleaning up someone else's mess...
If you've been working professionally for more than 5 years, and you're reasonably good at it, then writing clean maintainable code should be second nature ("refactoring" as a new concept is really for people who didn't pick up "structured programming" the first time round...).
many middle-tier and upper-level managers think that such concepts are useless and timewasting.
Their problem is, it's very difficult for them to tell if refactoring was actually worth it - their developers start with a program that does A, they stop working on new features for the next release for 3 months, and they come back with a program that still does A ("but better!").
As a developer you can explain how cleaning up code is preventative maintenance to make development easier in the future, but if you're not a developer that's a very hard thing to measure.
Even if you trust your engineers implicitly, any good manager has to realise that developers love intellectual problems over more mundane tasks - and refactoring's biggest problem is that by design you end up looking like nothing happened.
That's a specious argument - you could just as easily say that's because the vast majority of Linux GUI apps are so atrocious they don't merit a mention. Neither of which are completely true, but the problem is that UI matters enough for commercial apps that people are willing to set up sites like this to mock the bad examples.
Basic UI awareness is only just starting to emerge on "Open Source OSes" - look at how long it has taken to get even somewhat usable, never mind standardised, open/save dialogs.
OS X is not completely OSS!
Oh my god!
So why would MS deem OS X to be a threat ?
u lture, these are the (far more numerous) people who're looking for a computer that has an appliance-like simplicitly. All of the apps these kind of people are looking for are all available on the Mac (Office, email, web, The Sims, etc) and if they're thinking of buying a new computer why not get a nice-looking Mac this time?
The part of MS which sells to corporations probably isn't too worried - their biggest worry is a free competitor like Linux undercutting them with equivalent (and free) servers and acceptable (and free) desktops.
The part of MS which sells to consumers is more worried (if they have any sense) - their biggest worry is a competitor which is sexy. A lot of people are starting to come around to the idea that life with an N-Ghz x86 box running Windows might not be as trouble-free as a whatever-Mhz Mac running Mac OS X.
These people aren't the hard core gamers/built-it-yourself/overclockers/pick-a-subc
Of course Apple could triple their marketshare without causing MS any major concerns, but if MS are looking for their potential consumer competitor then Apple are it.
In any large software system, the truly unique code probably accounts for about 1% of the source.
Hmm, not on any large software system I've ever worked on... The important part isn't some magic 1% of the source, it's the fact that you got a group of people together for long enough to ship the thing.
This negates one of his basic points, and doesn't really contribute much over his previous rant...
Quicktime is as we all know the most crappy videoformat ever.
QuickTime is an API that defines a file format, not a codec. If you're not happy with the output of whatever codec you're using, use a better codec (or more likely, learn how to tune the one you're using for your subject matter).
It's bloated, and has a ugly player which you can't replace.
You do realise that QuickTime (the API) is not the same as QuickTime Player (the app)?
If you want to write a better movie player on top of QuickTime, knock yourself out - there used to be several such things on the Mac, all using the same API calls as the official player (QuickTime itself doesn't care - it's app agnostic).
for it's spelling
:-)
Or grammer...
("it's" == "it is", "its" == possessive form)
Every 3D linux game: Rune, heretic2, q3a, ut, ut2003, descent, hg2, sof, terminus, parsec... Should I continue?
Nope, I think you got them all...
It seems to me that OS X does it pretty well.
.
You're both right - the menu tracking was incorrect on 10.0, but this was one of the (many) things fixed in 10.1. There's some more information about this subject here, along with some other Mac subtleties
E.g., one extremely useful one is the way the cursor vanishes when you start typing (but re-appears if you grab the mouse). Systems which don't implement this have the extremely annoying problem where you click in an edit-field to type, and then you can't see what you're typing because the cursor is blocking your view...
I wonder if this will force them to reconsider such a relatively insecure approach to OS security?
Considering that the Apple implementation uses 128 bit keys, and it took 4 years to brute force a 109 bit key, I don't think it's anything like "relatively insecure".
What's stopping people doing this?
In theory degraded quality, although given that people used to swap tape to tape dubs at school in the '80s that's hardly a reason to stop...
The obvious response is to keep the data digital and encrypted all the way to the speakers - that would only stop you if you had a mic, and then the step after that would be to require that only licensed operators are allowed to purchase microphones.
You might laugh, but everything the record industry has done to date has indicated this would be their ideal scenario - they want an audience of passive consumers, with the law on their side to keep control of production technology.
The sad thing is that the software industry tried this, and rejected it, in the 80s/early 90s. Evenutally everyone realised that copy protection is fundamentally pointless, and you get better results by putting your energy into creating something that people actually want to purchase (insert comment about those who don't know history being doomed to repeat it via Palladium here).