iTunes 2.0 Installer Deletes Hard Drives 511
Cheviot writes: "It seems Apple's new iTunes 2 installer deletes the contents of users' hard drives if the drives have been partitioned. I personally lost more than 100gb of data. More information is available at Apples Discussions board. (registration required). Apple has pulled the installer, but for hundreds, if not thousands, the damage is already done." The iTunes download page has a nice warning about the problem. Ouch.
How the hell does this happen? (Score:4, Funny)
if(installDrive->hasEnoughSpace()){
return startInstall(instalDrive);
} else {
installDrive->formatRecklessly();
return startInstall(installDrive);
}
Hard-to-spot bug, actually.
[PATCH] Re:How the hell does this happen? (Score:2, Funny)
--- itunes-install.pseudo-orig Sun Nov 4 01:36:11 2001
+++ itunes-install.pseudo Sun Nov 4 01:36:19 2001
@@ -1,5 +1,5 @@
if(installDrive->hasEnoughSpace()){
- return startInstall(instalDrive);
+ return startInstall(installDrive);
} else {
installDrive->formatRecklessly();
return startInstall(installDrive);
Re:[PATCH] Re:How the hell does this happen? (Score:3, Funny)
It's pseudocode. You can't patch pseudocode. You have to pseudopatch it, like this:
- return startInstall(instalDrive);
+ return startInstall(installDrive);
or like this:
Replace instalDrive with installDrive.
the REAL code, and how this did happen (Score:4, Informative)
rm -rf $2Applications/iTunes.app 2
where "$2" is the name of the drive iTunes is being installed on.
The problem is, since the pathname is not in quotes, if the drive name has a space, and there are other drives named similarly then the installer will delete the similarly named drive (for instance if your drives are: "Disk", "Disk 1", and Disk 2" and you install on "Disk 1" then the command will become "rm -rf Disk 1/Applications/iTunes.app 2
The new updated version of the installer replaced that line of code with:
rm -rf "$2Applications/iTunes.app" 2
so things should work fine now.
Re:How the hell does this happen? (Score:5, Funny)
Re:How the hell does this happen? (Score:3, Flamebait)
Sorry.
Extensive testing went out of style around the mid 90's.
Oh -- and actually writting REALLY good code, that's been out of style since at LEAST the 80's.
I blame colleges for letting so many graduates think that they are instantly coders.
Real coders are born, not made.
And anybody who got into computers for the money, and not the thrill of writing code -- well -- they're worse than lame. And they probably use AOL.
Re:How the hell does this happen? (Score:3, Insightful)
It takes more than a love of computing to make a good programmer. In my humble opinion, it takes a fair amount of education. A brilliant but naive programmer can screw things up pretty impressively. I'd prefer to use code written by someone who isn't such hot shit but takes the time to learn APIs, read documentation, and familiarize himself with the idiom of the language and/or operating system in question.
Re:How the hell does this happen? (Score:5, Insightful)
Having been the author of a 3rd party product bundled and shipped on Apple hardware, I can tell you that the extent of their QA process doesn't go much beyond making sure the software installs and runs on an out of the box system, followed by some mediocre mashing of buttons and menus. They really don't understand or implement the concept of actually testing on live, deployed, end user (like) systems. They have racks of off the shelf machines with standard software loads. If they install and run and stay up over the weekend, it's shippable.
We would get reams and reams of complaints about how dialog boxes weren't formatted just so, etc., but their QA department never caught a single defect that most would consider a bug in the code. And there were certainly bugs to catch.
This is a chronic problem that most commercial software houses have. They tend to put junior people with little product experience in the QA organizations and assume that by acting like reasonably competent users, they will somehow uncover logic flaws, data errors, and other engineering foibles. The only time I ever saw QA done right was on a NASA project with life critical software systems. The project was staffed with the very most senior engineers running the QA department and all of the junior engineers were slinging code.
It was up to the gray beards to make sure the junior guys wrote code that was to spec, integrated properly, handled all of the possible input scenarios, and actually performed in a live environment. These senior guys were also the architects of the system, so they knew what the software was supposed to do, how it was supposed to be constructed, and what it should take to break it. I doubt that 1 in 100 commercial shops today have an engineer working in the QA department that actually understands the code they are testing down to the module level. When was the las time you saw a QA guy in a design session, learning about how the system he's going to test is going to be architected?
This is so far from the current practice in commercial industry today as to almost have the flavor of a fairy tale. Apple's no different than any number of other companies who are rushing to ship software on a too short schedule. They pay lip service to QA and rely on their early adopter users to find any lingering problems. In this case, they totally dicked over their customers by not doing their job. However, they're only partially to blame since I think the development of iTunes is still done by Casady and Greene under contract to Apple. I'd be surprised if they weren't ultimately responsible for creating everything, including the installer. Regardless, Apple should have tested this before sticking it on-line on a Saturday night.
Re:How the hell does this happen? (Score:2, Interesting)
I would like to offer some comments as a tester, myself.
Yes, testing is not generally done correctly or particularly rigorously. There have been some common factors in my experience:
1) Code not developed to Specification. This is by far the most common. I can't count how many times I've been told "But this is a better way to implement XXXX."
2) Poor unit testing of software.
3) Delay in testing due to: delays in development, delays in configuration/delivery of environment. (Don't get me wrong, this is really a management issue. I have NEVER been on a project that has let the testing deadline slip even though the entry criteria were slipped - sometimes even by 3 months! It is ridiculous to not adjust testing periods.)
4) Unrealistic expectations or deadlines by PM/managers.
5) Downright incompetent testers. ("Oh, we don't need to test that.")
But, I would tend to disagree about your point concerning QA participation in code reviews of module level code. Frankly, module testing is the responsibility of development. The finest granularity that testing function should be concerned with is the interface level. (unless, of course, your org uses QA people to do module testing.) This is because testing is required to have an understanding of *more* components/modules than any given developer. To expect them to know the intricate workings of the interior of each module is unrealistic. To expect them to know the interface of those modules, how they behave together, the data flows, etc is quite reasonable. This reminds me actually of the biggest problem that I've encountered (addendum to above): poor or non-existent requirement documents. How the hell are developers supposed to do a reasonable job, and testers test it if there are no frickin' requirements?
Re:How the hell does this happen? (Score:2)
Having used open source and commercial software, I'd have to say there's no clear distinction between which is more or less buggy. It comes down to companies or individuals. But, with open source, you CAN fix the bugs if you want, and you WILL get more frequent fixes. In the meantime, in either case, you're left sitting there with an unusable product until the fix comes in. Plenty of time to look for alternatives.
Re:How the hell does this happen? (Score:2, Informative)
Yes, pax is a complete piece of crap. The good folks over Stepwise warned about problems with it a long time ago [stepwise.com] (scroll down to the heading "Installer.app"). Apple blithely went on using pax anyway.
Perhaps after this disaster, Apple will finally realize they should maybe start using something more robust for their packaging system on X.
It is worth noting that the Mac OS 9 version of the iTunes 2.0 installer (yes, they are still updating the Mac OS 9 version of iTunes) did not exhibit the problem, as it doesn't use pax. It uses Apple's old "tome" installer archive format instead.
Re:*sigh* Amateurs... (Score:2)
New Apple Slogan (Score:4, Funny)
Liability (Score:2, Interesting)
"You should've backuped. We're not responsible
for any damage that erasing all your data caused."
(Yes, it's in the license. But can it be valid?)
Re:Liability (Score:3, Interesting)
I didn't lose any data, that would have sucked.
Re:Liability (Score:2)
Re:Liability (Score:2)
> the damage you do.
But in this case, the "you" is the user. The user downloaded and installed a software package that happened to have a bug in it, and in so doing, they may have lost data and have to restore from backups. End of story.
Software bugs are a Fact of Life. They weren't invented yesterday.
The ironic thing here is that the Mac OS X installer is rarely used
Exactly. (Score:2)
ie: Where it can be very clearly demonstrated that both parties thoroughly understood, in detail, the terms of the contract.
Re:Liability (Score:2, Informative)
<quote>
Aha! It seems that this is not quite correct for some jurisdictions. They could be liable per the EULA, last line of implied warranty section:
"SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES OR LIMITATIONS ON APPLICABLE STATUTORY RIGHTS OF A CONSUMER, SO THE ABOVE EXCLUSION AND LIMITATIONS MAY NOT APPLY TO YOU. "
</quote>
(BTW: You definitely got the uppercase right. Obviously it is used to make the EULAs even more unreadable.)
Oh, come on... (Score:2, Interesting)
Don't they test these things, anymore?
Really, in the current economic climate, all the monkeys should have been thrown out of the high-tech jobs, leaving only clueful people.
How does a bug like this occur?
Re:Oh, come on... (Score:5, Insightful)
Well, what you said is the working theory, anyway.
Having worked in the corporate world and the academic world this is the furthest from the truth. The people with a clue, ethics, responsability, talent, skills or value customers are usually the first on the chopping block.
After all, the managers making those 5 and 6 figure salaries have to remain employed so they can continue the (vicous) cycle.
Cynical? Oh, yeah, been there, been IT, seen it happen too many times.
Could apple be any different? That is a tough one to answer. I would have to say no, but to a lesser extent, perhaps.
Why to a lesser extent? For the simple reason that Steve Jobs and Lee Iacocoa (sp?) understood two things about running a company/taking over one:
First get everybody on board with a plan to succede/improve morale.
Second (and this is the kickass part) when you clean house *never, ever* get rid of your workers.
Clean up/fire your middle and upper management levels.
This solves 2 problems (imagine a pyramid):
1) when most layoffs happen they happen to the "base of the pyramid". What happens when you weaken the "foundation" of a company/structure.
Yeah, it falls down or does irrepairable damage.
2)Wiping out the middle section brings those "at the top" closer to the base. Most executive understand the "how and what" of a business, but understanding the "who and why" is what keeps thing "moving forward".
If I remember correctly, Lee I was first, and Jobs subscribed to the idea...it may have come from a
Very good interview.
Of course I've always said a "Phd/manager saying 'in theory' is akin to a used car salesman saying 'trust me' ".
I guess in my snide cynicism I found humor in your altruistic logic
Survey says... (Score:2)
Assume for a moment that you're a hard working, productive worker building your product or otherwise producing more income to the company than they pay you. You are a "good" employee, and the company would prefer to keep you. Now, another employee who was hired along side you is promoted to your manager. But you reflect back at all the asinine questions that person asked, and how perfectly obvious they made the fact that they should be working at McDonalds and not making $100,000 a year bossing you around (let alone in this industry).
Why did they get promoted? Is it because they're buddies with the boss? It is because everyone is in some maniacal conspiracy against you?
No. It's because of two things. Either they get promoted, or they get fired. Sometimes a company will chose to promote rather than fire an employee. But more likely, the simple fact is that you are productive in your position. If you were to be promoted to manager, your job would radically change and the company would not have the benefit of your skills working towards completion of the product.
That's why most management is "stupid" and "doesn't get it." Because they were workers who were stupid and don't get it. Granted, there are some members of management who are good at what they do -- these are the few that won't get fired when management has its shakedown. And not everyone is promoted to management... but if they were hired on, does that necessarily make them good at their job?
Think about it, if management were that great, it'd cost a lot more.
Re:Oh, come on... (Score:3, Interesting)
Ask a bunch of hiring managers right now and I think they'll tell you that they'd prefer someone adequate for a job over someone perfect for a job if it meant a salary difference of $10K - $20K. This recession isn't going to lead to a concentration of clueful people in our industry. It's going to lead to a concentration of monkeys.
Good Read (Score:2, Redundant)
It has some info about causes and solutions...
Re:Good Read (Score:2)
Link [macnn.com], or if you're scared I'm trying to show you porn:
http://newforums.macnn.com/cgi-bin/ultimatebb.c
Already updated (Score:3, Informative)
http://www.apple.com/itunes/download/
Corrected version 2.01 already posted by Apple. (Score:3, Informative)
Aplle lies (Score:2)
- they have not even admitted failure. Instead they engage in Microsoftian doublespeak talking about an "issue". Instead, they should write: "due to a defect in our software installer
- they don't take responsibility. No compensation for people who sufferered sever data losses.
Posting a patch isn't always enough.
You just don't wipe people's hard drives. Never. Having an installer that is even capable of such is a sign of faulty design. They are to blame.
f.
Re:Aplle lies (Score:2)
How do you make an installer that can remove the old version of a program, and yet have zero chance that it never removes the wrong thing?
(yes, it was a bad bug, very bad, but I'm not sure how you design a drool proof installer that has zero chance of deleting the wrong thing -- I know how to do a not drool proof one though. Put iTunes2 on a disk image along with a README that says "delete the old one before installing the new one").
Re:Aplle lies (Score:2)
ow do you make an installer that can remove the old version of a program, and yet have zero chance that it never removes the wrong thing
Easy. require apps to declare their contents to the system and provide an interface to manage these apps and their versions. Then require that apps use that interface exclusively to manage them.
It's really hard to wipe an entire drive with uninstallComponent("iTunes", VERSION_ALL);
Re:Aplle lies (Score:2)
Already does, you put them in a direcory named Foo.app where Foo is the name of the application, then users can move it around without things getting out of sync...
That depends on how "uninstallComponent" is implmented. If it is written in a shell like language it can be pretty easy...
Wrong, mind you, but not so hard to do wrong. I would guess some Linux and other generic Unix installers have problems with spaces in file names... I know for sure they have problems with display numbers other then zero, and this mistake is about as basic.
Re: (Score:2)
Re:How to do it (Score:2)
Ok, that's a good idea. There are a few problems with it, but I think they are smaller the the problems with real removal.
Very good idea. Someone tell Apple :-)
P.S. it is owned by root: drwxrwxr-x 3 root admin 58 Nov 3 17:30 /Applications/iTunes.app/.
Re:Corrected version 2.01 already posted by Apple. (Score:2)
The error in the installation script was, in part, due to Apple's relaxation of certain unix conventions regarding spaces in filenames--conventions that have proven useful. And while some might dismiss this as merely evidencing Apple's unfamiliarity with UNIX, shouldn't this have been caught by the Nextstep engineers?
Nonetheless, most x.0 releases are buggy.Windows 3.0 was widely regarded as half baked. OSX-10.0x was very slow. The subsequent x.1 release is usually far better.
This even extends into free software. linux-2.4.0 was buggy. gcc-3.0 was buggy. It used to be that there were no hard and fast deadlines for free software, but significant pressure to shorten long development cycles may cause corners to cut. The gcc team even has deadlines...
At least the standard installation scripts (provided by GNU tools) are reliable and trustworthy... (I hope).
Wide spread? (Score:2, Interesting)
Re:Wide spread? (Score:3, Insightful)
I knew a guy who did graphic design who did this, I always though it was kind of dumb back then, since apps not running on the boot volume in Mac OS 8.1 - 9.x took a performance/VM hit. It doesn't have that impact on X, but I still don't see much benefit.
The bug (Score:5, Interesting)
The problem appears to be in two portions of the installer script which could translate into rm -rf /your_drive, if certain paths $1 or $2 contain spaces:
Though when I looked, nobody seemed to have found where exactly $1 and $2 are defined; also it might be that disaster only strikes with localized versions of the OS.quote (Score:4, Informative)
Apparently it only strikes if you 1) havn't uninstalled iTunes first 2) have multiple partitions and 3) have spaces in the name of your partitions
This from MacSlash [macslash.com] (posted by Graff as AC):
Well, there is a fixed installer up now. Looks like the following change was made to the "Preflight" file inside the "iTunes.pkg" package:
old version:
#!/bin/sh
# if iTunes application currently exists, delete it /dev/null
if [ -e $2Applications/iTunes.app ] ; then
rm -rf $2Applications/iTunes.app 2>
fi
exit 0
new version:
#!/bin/sh
# if iTunes application currently exists, delete it /dev/null
if [ -e "$2Applications/iTunes.app" ] ; then
rm -rf "$2Applications/iTunes.app" 2>
fi
exit 0
As you can see, they basically placed quotes around the file paths so that any characters such as spaces in path names would not mess up the rm command. So easy, and yet even the best of us forget to do it at times. That's one of the things about the command line - lots of power when used properly, but also many powerful ways to mess everything up.
- Graff
Re:quote (Score:2)
It also shows one of the weaknesses of a programming language which is based on collections of things (in this case token words on a command) or data structures which can be changed merely by the value of some part of it (e.g. a variable with spaces).
Re:quote (Score:2)
When I went to download it (before the bugfix) , I did notice that the download page prominently said something to the effect of "If you have a previous version of iTunes installed, you must remove it first". Fortunately, for once, I followed those instructions.
In retrospect, this is a little odd if the installer had the ability to remove the old version. Hrm.
<paranoid>
Maybe this is one of those times when the programmer noticed the bug just before release and the manager cared more about the release deadline than the bug and said "Well, release it for now, and start working on the x.y.1 release." In my experience, not the first time that's happened!
</paranoid>
Hrm.. just noticed another thing. 'if [ -e $2Applications/iTunes.app ];': even if iTunes *had* been de-installed... if '$2' had whitespace in it, -e would still fail, giving an [: xxx/Applications: unexpected operator error (if 'xxx' was the part of the volume name after the whitespace...
Depending on what this script is run on, it might only have effect on people who choose to install it on partitions with whitespace -- so, if your chosen partition didn't have whitespace but your other partitions did, it might not affect it. *shrug*
Massive cock-up on Apple's part, all the same.
Why using scripting anyway? (Score:2)
Oh well.
Re:quote (Score:3, Informative)
For example (in csh):
% setenv foo \"
% echo $foo
"
% echo "some quoted text:$foo"
some quoted text:"
Everything within quotes is passed as one argument to the echo command, and the fact that $foo contains a quote character doesn't cause any problems. If the quotes were evaluated after variable substitutions, an unmatched quote error would have been reported in the last example.
Re:The bug (Score:2)
uh... $0
man bash, search for ARGUMENTS.
Re:The bug (Score:3, Insightful)
After I shot down his first half a dozen proposals, he started to gain an appreciation for the difficulty of the problem.
So how would *you* rewrite the shell to get rid of problems like this? Be specific. Remember, in 30 years of unix, no one has found a solution to this problem that doesn't break more things than it fixes. So if you do so, you'll be famous.
I wait with bated breath.
Re: (Score:2, Funny)
mmm... (Score:2, Troll)
- A.P.
Need to have a warranty! (Score:2)
Are you going to sue? Did you read your EULA (End User License Agreement)? You probably waved that right when you said "OK".
Apple probably waived all warranty when you installed the software (in some states this isn't legal though)
This is one area where the law needs to be fixed.
With Open Source software at least you have the ability to read the source code.
Imagine if Ford were to wave any warranty with your next Explorer.
Kevin
Re:Need to have a warranty! (Score:5, Insightful)
Why I hate the software industry (Score:5, Insightful)
People regularly sue if hardware is made faultily. Toshiba paid billions to settle a lawsuit [slashdot.org] with floppy disks that never showed up in the field and couldn't be reproduced. I personally have lost track of the number of class action lawsuits I've seen for faulty computer products.
What if it gets fried by a lightning strike?
Being struck by lightening is an act of nature which is completely different from human negligence. Please get your analogies right.
Even if Apple was found to be grossly negligent, they shouldn't be held responsible for data that was lost due to the negligence of the computer's owner.
Why shouldn't they be held responsible? If attaching your DVD player to your TV blows it up or your fax machine shreds your documents, are you also liable in such situations? Quite frankly I am disgusted with the attitudes of most people in the software industry that assumes that shoddy work is inevitable (all software has bugs? WTF?) and then blames customers when their shittily written software fails to behave as it should.
Programming is less difficult than building a bridge or an airplane and yet software companies have hoodwinked the public into making it seem that badly made software is a fact of life. One day people are going to realize that the software industry has been shamming them all this time and the lawsuits will start to pour in. This is probably when software companies will finally go back to using techniques developed decades ago to improve and measure software quality but by then the damage will be done.
Re:Why I hate the software industry (Score:3, Insightful)
Not a programmer, obviously.
You need to understand that not all bugs are actual errors or "shoddy work". Sometimes it's the interaction between multiple pieces of code, each of which works perfectly well, which causes the problem. Sometimes it's people using the code in unexpected ways which causes the problem (the programmer is not omnipotent, remember). That's why programmers say "all software has bugs". It's not that all software has flaws, but rather that it's almost a sure thing that any given piece of software can be used in a way which causes a problem (or "bug") to arise.
Take this iTunes software bug, for example. Even here, it sounds like there would have been no problem if people followed the directions. Given the simplicity of the fix, it should probably still be called a programming bug. However, what happens if some user actually had the old sh shell on there instead of a link to bash? There could be some subtle errors, as bash does not behave 100% like sh. Bug? Probably not, unless you argue that the programmer should have seen it coming. All right then, suppose some user decides that they only want to use csh, so they link sh to csh instead of bash (note: a Bad Idea)? The installer wouldn't work at all. Bug? Hardly.
The point being, the programmer can't plan for every contingency, and this can lead to problems which people call "bugs". That's why "all software has bugs"... because even if the code is flawless, there's no guarantee that it won't fail somehow.
Re:Need to have a warranty! (Score:2)
Have EULAs been tested in court? (Score:2)
Even if the court says the data on the drive should have been backed up, you should be compensated for time spent restoring that data, reinstalling the OS, and generally getting the computer back in shape. Not to mention the woeful negligence factor as a simple test should have uncovered this problem prior to the product being released. An application install should not wipe your hard drive out.
As usual, IANAL (But I play one on TV)
Re:Need to have a warranty! (Score:2)
In this case the bug was in the installer, which is a shell script and quite readable. It was a novice shell script error, which is understandable since Apple is a novice Unix OEM...
Anyway, you can read that part, and even fix it.
Still sucks though.
Re:Need to have a warranty! (Score:3, Insightful)
Hmm
Also, the 'read the code and fix it yourself' argument is starting to wear very thin, as both Linux and MacOS X can quite easily be found in the hands of non-techies these days.
To whoever mod'd this down as a troll
Nature of the bug (Score:4, Redundant)
From the discussion on the Apple discussion web site, the nature of the bug is as follows.
The original installer script has the lines
while the replacement (2.0.1) has In these scripts, $2 corresponds to the volume on which iTunes is to be installed, and will be of the formFor those unfamiliar with Bourne shell variable expansion, if $2 has spaces in it, the argument to the rm command in the first version of the script will expand to more than one word, and rm will try and delete both of these. The -rf tells rm to delete everything down recursively and not complain about it.
This is particularly a problem on the Mac, where filenames and volume names often have spaces in them., even at the beginning of the name. If one had multiple partitions mounted in /Volumes, and the one on which iTunes was to be installed was called, say, ' OS X', then the rm command would expand to
and would then try and delete everything underThe second version, by including quotes around the argument, fixes the problem. The quotes force the argument to be treated as a single argument after variable expansion.
Traditionally, people have been super careful about destructive operations and shell expansions. I don't think I've ever seen something like this written in a 3rd party script before, in fact (let alone from the OS vendor!). This could well be an example of programmers new to a Unix-like platform still getting used to the Unix way of doing things, and getting bitten as a result.
bogus shell quoting rules (Score:5, Informative)
The folks at Bell Labs seem to have realized that this was a mistake, which is why the "rc" shell (also available for Linux) now handles things differently: variable substitution does not result in re-tokenizing.
Re:bogus shell quoting rules (Score:3, Informative)
Okay, there have been multiple posts to this effect, and they're all wrong.
Sorry, but this is not a "problem". The shell operates on lists of words. A variable is assumed to contain a list under most circumstances. List elements (words) are separated by an Internal Field Separater character, defined by $IFS.
Every single one of my Bourne-compatible shells' man pages explicitly state the types of expansion that are employed generally (including word splitting) and provide a short list of exceptions.
This is expected, normal, useful behavior. And it's easily handled, as you can simply wrap any variable in quotes if you don't want it to be tokenized as multiple parameters. If it's something you can't cope with, that's a shame, but don't act as though it's some flaw in the shell... it's there on purpose, and with good reason.
Re:bogus shell quoting rules (Score:2)
Re:bogus shell quoting rules (Score:2)
No, I live by the "hammer for a nail, screwdriver for a screw" approach to programming. It's not unexpected behavior if you don't look at an apple and say "hey, that's just like that orange I've been eating."
Bourne is not, nor is any other derivative shell, very much like any other scripting language that was not based largely upon it. You have only to look at the structure of the [ operator, the way control structures are broken up, and the way variables are expanded to recognize that. It's designed primarily for use on a commandline... the fact that you can write your scripts to a file and run them through the shell non-interactively is bonus.
That said, Bourne is usually the right tool for software installation scripts on a Unix machine. You just have to recognize that you're not wielding a screwdriver.
Also, I do realize it's a common mistake. But so is dropping a semicolon or forgetting to close parens in your C-like language of choice. That doesn't make the need for a semicolon or a close-paren a design flaw.
Re:bogus shell quoting rules (Score:3, Insightful)
No, $1foo means "expand $1 and append foo". You, the intrepid Bourne scripter, should realize that $1 may very well contain IFS characters, recognize what that will mean if the string is retokenized, and quote appropriately.
Look at this:
VARIABLE="$VARIABLE $ELEMENT"
This is a common way of building lists in Bourne. The reason this is common is that it is understood that $VARIABLE will be tokenized when it is expanded, and word splitting on IFS characters will occur. It is also commonly understood that if you do not want a string to be word-split, you quote it so that its IFS characters are ignored. Like I said before, not hard.
I'm sorry, but it takes all of ten seconds to grasp the fact that variables will be expanded and their words split. Occasionally you take it for granted that a list will only have one element, and get away with stuff like $1foo. However, it's not something you do unless you have total control over the contents of $1 (as in, say, a function you've defined that only you will call), and even then it's bad practice.
That's not a justification any more than "Windows crashes because it dereferences dangling pointers" is a justification for Windows crashing.
I couldn't have said it better. The problem there is that someone unfamiliar with basics of pointer manipulation went and dereferenced a null one... the problem is not that the language let him have a null pointer to begin with.
Re:bogus shell quoting rules (Score:2)
Re:bogus shell quoting rules (Score:2)
I don't see why we should blame the programming language. The fact that
#!/bin/sh
rm $1
doesn't work is nonintuitive and painful. If a programming language has a 'feature' that results in a lot of bugs then that feature should have been designed a different way, especially in a language like shell where bugs like these can be so dangerous.
Blaming the programming language is like blaming Apple; the programmer should have double checked his code, but trusted the language not to annihilate everything on a simple typo; the end-user should have double checked the code, but trusted Apple not to annihilate everything on a simple uninstall.
Re:bogus shell quoting rules (Score:2)
#!/bin/sh
rm $1
doesn't work is nonintuitive and painful.
Erf. It does work, and it is intuitive, if you stop thinking of Bourne as a scripting language that can be used interactively and start thinking of it as a shell that can be scripted.
If I call that script like so:
script something else again
I would expect it to remove 'something', which it does, and leave 'else' and 'again' alone, which it does. If I want it to remove all three, I have to do:
script "something else again"
It will then tokenize the string "something else again" and pass it as a set of three parameters to 'rm'. This is a good thing. It allows me to deal with parameter grouping and pass-through efficiently and intuitively. And since this is a shell, that's very helpful. It is truly scripting and not programming. You're feeding the shell a list of commands to run. It just happens to have a few handy programming features like flow control and conditionals.
If you're in a position where you don't just essentially need a bunch of external commands to run in a given sequence, then for God's sake use a programming language like Perl, Python, Tcl, or even Ksh (which is as much a programming language whose interpreter serves as an interactive shell as Bourne is vice versa).
Re:bogus shell quoting rules (Score:2)
But if a system is designed in such a way that people frequently make a certain mistake, and if it is easy to change the system, without limiting its functionality, to keep people from making that mistake, then the system has a design flaw. This applies to the Bourne shell, and that's presumably why its successor at Bell Labs doesn't behave this way anymore.
As for Apple, they should have been using decent package management. If they do need to script, they should have been using a scripting language that gets this right (Perl, Python, etc.). As a last resort, they should at least know their tools.
Re:Nature of the bug (Score:2)
Anyway, it's quite embarrassing to make such a mistake in an installer. It shows how little testing software gets nowadays before it is released. I can't imagine that this couldn't have been noticed by testing the installer on several internal machines (and not just developer ones).
Re:Nature of the bug (Score:2)
Re:Nature of the bug (Score:2)
Shells don't care about
Re:Nature of the bug (Score:2)
It's above that layer.
So old, it's a classic joke (Score:3, Funny)
% ls .o .o: No such file or directory
foot.c foot.h foot.o toe.c toe.o
% rm *
rm:
% ls
%
Same bug. Welcome to the world, Apple. :-)
Peace,
-McD
Re:Nature of the bug (Score:2)
If you want to learn shell, I suggest lurking in comp.unix.shell.
page out of Roxio's book (Score:2, Interesting)
well, i guess it's catching, whatever it is.
lol, i think i'll be waiting a few weeks after the release of software from now on. bleeding edge one to many times.
This might be very good. (Score:2, Funny)
So this installer comes in very handy because it deletes just all data and you don't have to decide whether to delete the picture of all these nice kitties or not.
So you have much more space on your harddisk and can download again much more nice pictures from the internet with cats.
My problem is however that i don't have an MAC and i hope they port it to linux soon so that i have again nice 30 megabytes of free harddisk space.
It is of course very sad that people with important data have lost all important data but you can't have much space and important data on your harddisk all the same time anyway.
Gotta be said (Score:5, Funny)
Relative severity vs. a MS flaw (Score:5, Insightful)
The Classic version (which most Mac owners are still running) was fine, and the bug seems to have only hit people who didn't follow Apple's instructions that said "remove the old one first" and/or had multi-partitioned drives (multiple partitions aren't nearly as common among Mac users as they are among Windows and Linux users).
So Apple made a gross mistake on one hand, but on the other hand they owned up to it quickly, pulled the offending installer, and fixed/reposted it less than 24 hours later. Most Linux vendors respond about as well, Microsoft usually doesn't (though they were very good about pulling, fixing, and notification with their recent RDP fix that knocked people's Terminal Server systems off the network entirely).
The other mitigating factor was that there aren't that many Mac users relative to the installed base who were affected by the bug - but unfortunately the people who were likeliest to be affected (users who are already running 10.1 as their base OS, have multiple partitions, and don't read the instructions thorougly because - after all - "it's a Mac, who needs instructions?") are exactly the kind of Mac "power users" who swarm Apple's servers constantly looking for new stuff and install it the second it's posted.
I run 10.1 on my TiBook 667, and I downloaded the update. But I deleted the old iTunes version beforehand and only have a single 30GB partition, hence the install went fine..
Re:Relative severity vs. a MS flaw (Score:3, Insightful)
Re:Relative severity vs. a MS flaw (Score:2)
If I recall correctly when SP6 was noticed to affect Lotus Notes it took Microsoft 26 hours to respond!
Those bastards!!!!!!!!
not mine (Score:2)
Worked for me. (Score:3, Interesting)
Gee, I guess I was just lucky?
Bias and stories? (Score:2)
Can Mac really be the anti-Christ? :)
100BG! Ouch (Score:2, Funny)
....
....
Somewhere, in a little corner of the basement of a house, someone is installing their new iTunes...
{blip, squeek}.. Oh man, this is sooo cool!
{HD Grrrrinnd!!}
huh? What thee.. !!
NooooOOooooOOOOO!!!! My PORN!!!
Oh my God!
Later that day, at a Starbucks, we see a man, trembling as he sips is triple MochaBucka Latte-chino...
Brtney... GONE!
Pam....GONE!
Margolis....GONE!
That chick doing the horse...GONE!
My life is over....
Just curious. (Score:2)
The shell script not the problem... (Score:2, Funny)
After the installer formats your HD, you can record the high pitched scream you emit into an mp3 and then change the pitch to all bass.
So, now Apple just "equalized" itself with all other unicies.
To Apple I say, "I feel your pain" but you need to "strategize" some more.
Ow, crossing OS, platform and political lines... for shame! for shame!
(on a side note, modding me down as overrated because of my +2 bonus makes about as much sense as hating people for being intelligent...Oh, wait, that is what happens to "us" nerds all the time... I just answered my own question, never mind...so, being different is ok, as long as you are different like everyone else? Heh, makes sense...NOT!)
Yes I'm an esoteric, tenacious, longwinded SOB.
I'll never need therapy as long as I can post to slashdot.
Orbb: "keep talking, I'm reloading"
Apple. So easy to use.... (Score:2)
"Ah... Apple... So easy to use, now wonder it's number on.."
*quack* *quack*
"what?... huh?... oh, son OF A BIT#$%!"
Possible Fix... (Score:4, Informative)
I didn't test this because iTunes didn't mess up my 5 partitions, thankfully.
-Henry
Re:Users in OS X (Score:2, Informative)
the root acount is disabled as in the password is * meaning none which means you can't login with it
HeadBulb
Re:Users in OS X (Score:3, Informative)
You can enable root login in the NetInfoManager. When you do, it asks you to put in a root password, and then you can log in or su to root if you want.
Re:The big mistake here... (Score:3, Interesting)
I will admit that most applications should just use the "drag and drop" installation and Apple agrees [apple.com]. But there are some cases where the use of an installer can not be avoided and this is one of those cases.
Re:The big mistake here... (Score:2)
Kernel modules (Score:2)
Disclaimer: I don't run OS X, and I've never configured a Linux kernel.
However, I have configured FreeBSD kernels. And in FreeBSD, some kernel modules are externally loadable, but they always need hooks into the compiled kernel (and it's generally better to put the kernel modules you always need directly into the /kernel file, that way you don't need to do so much disk access)... And, so far as I know (I haven't installed any FreeBSD past 4.0), device drivers are not hookable in any version of FreeBSD. IIRC OS X & FreeBSD share a lot of kernel traits in common, this I would expect to be one of them.
Re:The big mistake here... (Score:2, Informative)
Re:OS 9 Forever! (Score:2)
yes, while system 9 is just so terrifically mature that it stuns you with it's depth. i also remember how much I thought that system 7 was an anathma to the Macintosh look a and feel and "useability".
I detested OSX and need my mac to make money with, so have I little time for flakey eye candy. But ever since I Installed OS 10.1 on my drive i have yet to boot into OS 9. Yes it is far less mature and has some goofy little idiosynchosies but it also runs all my DTP/WebDev OS 9 apps perfectly, but then i can also exploit 10's native apps to get grunt work (word proc, mp3 playing, browseing and proofing etc...) all multi-threaded and so on... every day i am amused to find a hidden little nuance to aqua, and i also get to run xdarwin interleaved with aqua so i can run BSD, classic and OSX apps flawlessly, simultainiously.
Also this: Quartz.... mmmm... beatiful display postcript (PDF, i know) love...
So i sympathize with you. and perhaps some lunitic will come up with a nice OS 9.2.1 theme and theme manager to run it over aqua for you. but I think apple is kicking big OS ass with 10.
OS 9 forever? my ass, how many times did you reboot today?
Re:OS 9 Forever! (Score:2, Insightful)
On the subject of the earlier systems - they were fantastic. Why wouldn't they be when the only alternatives were DOS and a very broken early Windows.
Re:OS 9 Forever! (Score:2, Insightful)
Mac OS X is based on UNIX, a design which, if you'd noticed a previous story today on slashdot, is now 30 years old, much older than Classic Mac OS.
Mac OS X has a carefully redesigned UI that actually works really well. Believe me, I haven't used Classic Mac OS in about 4 weeks now, and even then it was for DVD playback due to an oversight in Mac OS X. The new UI is just as carefully designed, and just as carefully planned as the old one. It has one disadvantage however:
It's new.
That means that there are going to be kinks for a while yet (ever used Mac OS 1.0? I have, and believe me, it has more UI kinks that Aqua does now).
That said, I can't go back to Classic Mac OS for two reasons: Protected Memory and real Multitasking. Between the time that my Centris died, and the acquisition of my iBook Dual USB, my primary computer was an Intel system running Debian Linux. I can happily say that I was able to put up with KDE's quirks (it's nice, but it's got a long way to go before it gets close to Mac OS for usability), simply because the system NEVER BLOODY CRASHED!. Seriously. The only reboots I perform on it are for power outages and kernel upgrades.
Mac OS X is just the same. While I got a few kernel panics on the older 10.0.x series (3... all of them while in public for some reason
The point is, I would happily live at a commandline if it meant the OS wasn't going to freeze up at least once a day, or if I could happily run as many applications as I wanted without worrying about memory (No more memory size settings! YESSSSS!). And that's not even mentioning the fact that the system actually MULTITASKS. Whoa! Who'd have thought that a Mac would ever be able to multitask and provide memory protection? They've only had an MMU for what? 10 years now?
I love Macs, always have, always will, but the old OS was kludge upon kludge upon kludge. It's old, It's broken, it's been replaced. Stop using it, please. And Aqua takes all of 5 minutes to adjust to from Platinum. It's harder to jump to windows from Platinum than to Aqua.
I mean seriously... would you go on using Windows on an Intel system if you knew that a newer and better operating system was available that didn't have all of Windows bugs?
Re:Stupid, stupid, stupid (Score:2, Insightful)
Re:Sue them. (Score:2)
> program, performs some sort of check, then
> delivers a payload. If thats not a virus,
> then i don't know what is. Just because
> Apple may 'claim' its a mistake, is no
> excuse. People have gone to prison for
> less so i say, give them a big fat law
> suit.
Are you listening to yourself?
Re:Sue them. (Score:2)
Are you listening to yourself?
He's right to some extent. A bug that causes a program to crash is perfectly ordinary, if annoying. One that 'oops, we just wiped out your entire hard drive, so sorry' is totally unacceptable. Hell, most viruses aren't even designed to be that bad. Software can always be expected to be buggy, but this crossed the line between 'not quite enough debugging' and criminal negligence on Apple's part. Prison is a bit much, but financial liability is quite reasonable.
Re:it's not that far-fetched. (Score:2)
Renumeration Remuneration (Score:2, Funny)
However, this does not address any Remuneration!
Re:Ahh... Imagine if this were a Microsoft product (Score:2)
Yes, because on the Mac, the presence of multiple partitions != dual-booting user. OS X will reside quite happily on the same partition as OS 9.x, and you can choose between them with the Startup Disk control panel.
The only advantage I found to putting OS X on a different partition is, you can select which operating system you want to boot in every time you power on the machine, by holding down the Option key until presented with the menu.
~Philly
/. said something bad about the iPod? hells yeah. (Score:2, Insightful)
And there was a /. story about the iPod - and it had nothing bad to say about Apple
Go back and read it again [slashdot.org]. There's a negative comment by Taco in the initial post.
Slashdot is inherently anti-Apple due to the attitude of editors which is quickly imitated by the troll hordes and flamebaiters. 'cuz everyone knows the easiest way to generate wind is to get a bunch of Mac zealots in one place and say one bad thing about Apple or the Mac OS.
For the record, I'm a long-time Apple customer that got tired of the OS wars a long time ago. I'd much rather be coding in my very nice Mac OS X setup, thank you very much.