Yes, but that's one of the reasons it's so entertaining. There's a related post by the assistant he takes great pains to put down, and it puts a slightly different spin on things. It's still pretty funny, though.
Here's a related read. It's long, but very entertaining. Of special interest is the hilarious account of how the drum tracks for an entire album were edited at great expense, because the drummer couldn't play the drums to save his life.
Maybe because the comment identifies the function names it documents, and gives one a clue about the history of the code in question (the comments were inserted before said modularization took place, and that gives you a way to track when the code was supposedly copied into Linux).
Why? Every response they made so far has been a non-sequitur - why change a winning strategy? Most likely, he'll just dismiss it, as he has done so far with every bit of evidence and common sense presented to him.
Hey, this is David Boies you're talking about! He represented President Gore, saved Napster, brought Microsoft to heel and mediated the peace accord between the Klingon Empire and the Federation of Planets. All true! He's a master sushi chef and has a black belt in Feng Shui; in 1995, he played a violin concerto in New York, broke a string, yet he kept on playing the concert to a standing ovation. He discovered gravity, found it lacking, and fixed it. Mr. Boies is a terrific ballroom dancer, and an outstanding ice sculptor - the finest in Arizona.
You'd be foolish to underestimate the accomplished and feared David Boies.
1. You're right. Linux does differentiate between removable and non removable media. 2. You're contradicting yourself, or at the very least ignoring your own arguments. Since you suggested that an automated script to kill applications that hold on to mounted removable storage devices as an acceptable solution, you can't use my example of why this is a bad idea to justify your position. My point was to show that killing applications is not a solution.
The OS should by design make it harder for applications to encounter such conditions.
Where it makes sense. How would you feel about brk() calls that block when you're out of core?
What's wrong with a design that keeps the current mount behavior, but allows you to specify a mount option that makes the device unmountable while in use. Applications that try to use the device after it's removed (via open fd's) get a sensible error (EBADF?) and are free to die or handle the error.
One way is, of course, NOT to/eject a cd/unmount a partition/whatever/ when a process is still using it.
It's one way, and it's not a very good way, judging from some of the stories on this thread.
Why do you think killing processes (including my desktop, for crying out loud!) is a reasonable solution to a design problem (namely, that Linux doesn't differentiate between removable and non-removable media).
A script doesn't come close to solving this, because in today's systems, killing off one process can have unpredicatble results - processes are linked via Bonobo, CORBA, they could be piping data to each other, connected with sockets to other processes...
Applications should be designed to handle unavailable resources. In Unix, they got away without it for too long, but it doesn't meant that it's good design, or reliable design to keep on doing so.
Unless you're claiming that movix doesn't mount a filesystem from the CD, I don't see why you'd even mention this.
So, let's not bother with drivers ed either. Cars should behave as most drivers expect it to.
If I may say so, you don't strike me as a stupid person by any means. Therefore, I find it hard to believe that you'd take your own argument seriously - what I'm proposing is analogous to building better and safer cars. If cars had brake pedals that only worked sometimes, and required that you push a secret button under the dash on the rare occasion that they didn't, would you still argue that drivers need to be "educated" about this so they don't crash into trees, little dogs and each other? Or would listen to reason and have car manufacturers make reasonable cars?
It's funny - we expect kids to go through 15 - 20 years of schooling to learn things, then, once they get into the "adult real world",we expect that they lose all capacity to learn or adapt.
No, I expect them to excel in what they do, and that includes building systems to work well and are easy and fun to use. I don't want Linux to be easy to use because I think people are stupid - far from it. I want it to be easy to use because that's how I like the tools I use - reliable, fun to use, and out of your way. It's why I started using Linux in the first place.
Oh, and journaling file systems are yet another reason why we shouldn't care whether a volume gets unmounted from under the application. Let the application deal with it.
ps - there's no such thing as a root cd drive. maybe you meant the cd drive from which the fs was loaded:-)
Well, you obviously understood what I meant, and file systems are typically mounted, not loaded.
User education is not the answer, because there are many more users than I (or anyone) have time to educate people. Education shouldn't be necessary when the system behaves as most users expect it to.
File sharing is irrelevant. It's just another application that needs to deal with a file system going away (smbd is still a user process, for example). Ideally, the error condition should be passed on to the remote client, and the remote client will recover gracefully.
As for the fire alarm going off - you're forgetting that the building just might not burn down, and that you might want to return to the affected system and deal with whatever damage you did by yanking the cable. And besides, it was just an example, and a bad one at that.
Somebody here described the way the Amiga handled removable storage devices. Is there any reason not to implement something similar?
In that case, Nautilus was not doing the right thing when I closed one of its windows, but the underlying problem is deeper.
If the system allowed CDs to be ejected on the user's whim, application programmers will be forced to handle errors from the the file system when devices go away in a reasonable way. Like closing the file and displaying an error to the user.
None of those scenarios apply in a desktop environment. Specialized distributions etc. should be able to do what they want with the system, but a decent desktop environment shouldn't force the user to have a deep understanding of the system just to get simple tasks done.
So, movix should be able to lock the root CD drive, and I should be able to yank my USB backup device and run out of the building when the fire alarm goes off.
But an OS shouldn't need community support for the little things.
I want my mother to use Linux, so I can give her actual support when she has a problem with her computer, rather than blow her off because I live 6000 miles away from her. As long as simple everyday computing tasks can cause data corruption or even just cause unnecessary confusion, this won't happen, and that's a shame.
Me. And it didn't work. The window was gone, but the process was still keeping an open file on the CD. I killed nautilus and that "fixed" the problem, but the real issue is that there's any number of things that can go wrong on a system that would cause this, and this points to a fundamental design problem.
Ejecting a CD shouldn't require a deep understanding of system internals.
In both cases, the problem ultimately comes down to the end user's error (trying to umount when their shell's cwd is/mnt/cdrom, or not looking in the tray before adding a cd). In neither case is this a "bug" or "feature".
In my case, it was a bug in Nautilus (which was fixed already, I believe). It's not a user error if you close the window you use to browse a CD, and the software won't close files on it. It's also not a user error if you close an image viewer (eog, or something like that) and the process becomes a zombie rather than go away.
I see nothing wrong with assuming that if a user pushes the cd eject button, she really wants her CD back. Eject the damn thing, unmount it, and let every process stupid enough to still want it die out or display an error. What's wrong with that?
Strangely enough, this worked for me out of the box when I installed RedHat 8.0 on my laptop, and I have no idea why it worked. I can't make this happen on my other RedHat 8.0 machine.
I do know about it, but there's absolutely no reason why it should be necessary to use it in some of the situations I encountered.
For example, I have a digital camera that I can mount as a usb mass storage device. If I look at the mounted directory with Nautilus, and then just close the window and try to unmount the camera, it won't work, because Nautilus keeps a file open on that directory.
Ok, so I've been using Linux since version 0.99pl5, I know all about man pages, and in most cases I'd rather just go poking under/proc to get what I need, but having a GUI that's supposed to make things easy do the opposite is annoying.
I've gotten into similar situations when a kernel module was doing something with my CD drive, and wouldn't let go. This is worse, because you can't unmount the CD since it's still in use, and you can't unload the module because you still need it for the CD. These things are rare enough that I don't remember the details, but they're still annoying.
Slashdot Mirror
It won't run Windows binaries, because it merely provides the Win32 APIs. The hardware CPU still runs the actual code.
It can probably be used to compile native PPC binaries of Win32 apps, if you have the source code.
There you go: The renegade Lance chronicles.
Everything is linked to from the page I pointed to earlier.
Yes, but that's one of the reasons it's so entertaining. There's a related post by the assistant he takes great pains to put down, and it puts a slightly different spin on things. It's still pretty funny, though.
Here's a related read. It's long, but very entertaining. Of special interest is the hilarious account of how the drum tracks for an entire album were edited at great expense, because the drummer couldn't play the drums to save his life.
See here.
The BSD code was in dispute, and is in the clear now.
Maybe because the comment identifies the function names it documents, and gives one a clue about the history of the code in question (the comments were inserted before said modularization took place, and that gives you a way to track when the code was supposedly copied into Linux).
Why? Every response they made so far has been a non-sequitur - why change a winning strategy? Most likely, he'll just dismiss it, as he has done so far with every bit of evidence and common sense presented to him.
Have you seen his house in Philadelphia? It's nothing but a steel frame. No wonder he moved.
Winmodem?
I'd rather not think about that.
I don't think Larry Flint's in this line of business.
Hey, this is David Boies you're talking about! He represented President Gore, saved Napster, brought Microsoft to heel and mediated the peace accord between the Klingon Empire and the Federation of Planets. All true! He's a master sushi chef and has a black belt in Feng Shui; in 1995, he played a violin concerto in New York, broke a string, yet he kept on playing the concert to a standing ovation. He discovered gravity, found it lacking, and fixed it. Mr. Boies is a terrific ballroom dancer, and an outstanding ice sculptor - the finest in Arizona.
You'd be foolish to underestimate the accomplished and feared David Boies.
I wasn't trolling.
/eject a cd/unmount a partition/whatever/ when a process is still using it.
1. You're right. Linux does differentiate between removable and non removable media.
2. You're contradicting yourself, or at the very least ignoring your own arguments. Since you suggested that an automated script to kill applications that hold on to mounted removable storage devices as an acceptable solution, you can't use my example of why this is a bad idea to justify your position. My point was to show that killing applications is not a solution.
The OS should by design make it harder for applications to encounter such conditions.
Where it makes sense. How would you feel about brk() calls that block when you're out of core?
What's wrong with a design that keeps the current mount behavior, but allows you to specify a mount option that makes the device unmountable while in use. Applications that try to use the device after it's removed (via open fd's) get a sensible error (EBADF?) and are free to die or handle the error.
One way is, of course, NOT to
It's one way, and it's not a very good way, judging from some of the stories on this thread.
Hey, what's wrong with custom Gibson guitars?
Why do you think killing processes (including my desktop, for crying out loud!) is a reasonable solution to a design problem (namely, that Linux doesn't differentiate between removable and non-removable media).
A script doesn't come close to solving this, because in today's systems, killing off one process can have unpredicatble results - processes are linked via Bonobo, CORBA, they could be piping data to each other, connected with sockets to other processes...
Applications should be designed to handle unavailable resources. In Unix, they got away without it for too long, but it doesn't meant that it's good design, or reliable design to keep on doing so.
The initrd is loaded into ram, not mounted :-)
Unless you're claiming that movix doesn't mount a filesystem from the CD, I don't see why you'd even mention this.
So, let's not bother with drivers ed either. Cars should behave as most drivers expect it to.
If I may say so, you don't strike me as a stupid person by any means. Therefore, I find it hard to believe that you'd take your own argument seriously - what I'm proposing is analogous to building better and safer cars. If cars had brake pedals that only worked sometimes, and required that you push a secret button under the dash on the rare occasion that they didn't, would you still argue that drivers need to be "educated" about this so they don't crash into trees, little dogs and each other? Or would listen to reason and have car manufacturers make reasonable cars?
It's funny - we expect kids to go through 15 - 20 years of schooling to learn things, then, once they get into the "adult real world",we expect that they lose all capacity to learn or adapt.
No, I expect them to excel in what they do, and that includes building systems to work well and are easy and fun to use. I don't want Linux to be easy to use because I think people are stupid - far from it. I want it to be easy to use because that's how I like the tools I use - reliable, fun to use, and out of your way. It's why I started using Linux in the first place.
Oh, and journaling file systems are yet another reason why we shouldn't care whether a volume gets unmounted from under the application. Let the application deal with it.
ps - there's no such thing as a root cd drive. maybe you meant the cd drive from which the fs was loaded :-)
Well, you obviously understood what I meant, and file systems are typically mounted, not loaded.
User education is not the answer, because there are many more users than I (or anyone) have time to educate people. Education shouldn't be necessary when the system behaves as most users expect it to.
File sharing is irrelevant. It's just another application that needs to deal with a file system going away (smbd is still a user process, for example). Ideally, the error condition should be passed on to the remote client, and the remote client will recover gracefully.
As for the fire alarm going off - you're forgetting that the building just might not burn down, and that you might want to return to the affected system and deal with whatever damage you did by yanking the cable. And besides, it was just an example, and a bad one at that.
Somebody here described the way the Amiga handled removable storage devices. Is there any reason not to implement something similar?
Nice picture. Why does he breathe through his mouth, though?
In that case, Nautilus was not doing the right thing when I closed one of its windows, but the underlying problem is deeper.
If the system allowed CDs to be ejected on the user's whim, application programmers will be forced to handle errors from the the file system when devices go away in a reasonable way. Like closing the file and displaying an error to the user.
None of those scenarios apply in a desktop environment. Specialized distributions etc. should be able to do what they want with the system, but a decent desktop environment shouldn't force the user to have a deep understanding of the system just to get simple tasks done.
So, movix should be able to lock the root CD drive, and I should be able to yank my USB backup device and run out of the building when the fire alarm goes off.
But an OS shouldn't need community support for the little things.
I want my mother to use Linux, so I can give her actual support when she has a problem with her computer, rather than blow her off because I live 6000 miles away from her. As long as simple everyday computing tasks can cause data corruption or even just cause unnecessary confusion, this won't happen, and that's a shame.
Woah, who would have thought of that?
Me. And it didn't work. The window was gone, but the process was still keeping an open file on the CD. I killed nautilus and that "fixed" the problem, but the real issue is that there's any number of things that can go wrong on a system that would cause this, and this points to a fundamental design problem.
Ejecting a CD shouldn't require a deep understanding of system internals.
In both cases, the problem ultimately comes down to the end user's error (trying to umount when their shell's cwd is /mnt/cdrom, or not looking in the tray before adding a cd). In neither case is this a "bug" or "feature".
In my case, it was a bug in Nautilus (which was fixed already, I believe). It's not a user error if you close the window you use to browse a CD, and the software won't close files on it. It's also not a user error if you close an image viewer (eog, or something like that) and the process becomes a zombie rather than go away.
I see nothing wrong with assuming that if a user pushes the cd eject button, she really wants her CD back. Eject the damn thing, unmount it, and let every process stupid enough to still want it die out or display an error. What's wrong with that?
Strangely enough, this worked for me out of the box when I installed RedHat 8.0 on my laptop, and I have no idea why it worked. I can't make this happen on my other RedHat 8.0 machine.
I do know about it, but there's absolutely no reason why it should be necessary to use it in some of the situations I encountered.
/proc to get what I need, but having a GUI that's supposed to make things easy do the opposite is annoying.
For example, I have a digital camera that I can mount as a usb mass storage device. If I look at the mounted directory with Nautilus, and then just close the window and try to unmount the camera, it won't work, because Nautilus keeps a file open on that directory.
Ok, so I've been using Linux since version 0.99pl5, I know all about man pages, and in most cases I'd rather just go poking under
I've gotten into similar situations when a kernel module was doing something with my CD drive, and wouldn't let go. This is worse, because you can't unmount the CD since it's still in use, and you can't unload the module because you still need it for the CD. These things are rare enough that I don't remember the details, but they're still annoying.