Noone ever said that linux was the most stable design either.
There is a clear boundary between the kernel and user mode. There are a few ways root can crash the system from user mode, if you really want to. But as non root user, you cannot crash the system unless you find a bug in the kernel.
That is also my experience. If I have a problem with Linux, it gives me all the messages and tools I need to find the exact cause of the problem. With Windows I often have to give up, because it refuse to tell me, what I need to know. Knowing what the problem is, is the first major step towards solving it.
Talking about putting flammable stuff in your hair makes me think about some (crazy) guys, who built an orange cannon using hair spray as fuel. It can shoot over 100m.
Then link to/mirrors/ instead of the top of kernel.org. (Some time in the past I was unable to contact kernel.org for days, so I started mirroring the list of mirrors near my country.)
and in the end, he had to buy 2 drives,
i wonder if the recovery prices inclued
a new drive??
When I read about those "exhorbitant" prices, my first thought was that it was cheap. My guess would be that you could end up paying ten or hundred times as much for data recovery than the price of the drive. Anyway whenever somebody asks me about data recovery, I ask them how valuable their data is. If the data is more valuable than a new disk, they should buy one, because it will always come in handy during the recovery. If the data is less valuable I wouldn't waste any time on recovery.
We were talking about Linux annoyances.
Yes. And xine is not a part of Linux. It is a program which can run on top of Linux (And maybe other OSes as well, I never tried). By your logic Windows must suck a lot more than Linux, because there are so many more bad programs that run on top of Windows than there are bad programs running on top of Linux. Besides xine was not my first suggestion. Ogle was my first suggestion.
People complain, but nobody listens
Why should they listen to anybody who just wants to complain? If you really want the program to become better, you have got to be more constructive. There have to be something you like about the program before you can participate in improving it. When you have reached the point, where you want to make a good program better, people will start listening to you. But just because they listen, they don't have to agree. Nobody is forced to think the same way as somebody else, that works both ways.
Xine still amuses me with its "://" button. What do Linux developers smoke when they create things like that?
Hey, did anybody say xine had a good GUI? I hate the GUI, but the player works well in most cases. (Make sure not to use a cripled version supplied with your distribution.) But though the xine GUI is not the best, it is still better than mplayer. If you want a simple GUI use ogle.
Most people want thier CD tray to eject and most people don't know the proc filesystem. Therefore the solution to the Cd tray ejecting problem can't use the proc filesystem.
It sure can. A feature to do exactly as requested already exists in the kernel. It is just not enabled by default, but any distributer can insert an appropriate command to enable it. If the cdrom driver is a module, the command would probably need to be post-install in/etc/modules.conf, blame your distributer if you disagree with the default configuration.
Should the computer tell the root program to lump it, unmount the disk, and hope the program running as root handles IO errors correctly?
You just got me thinking about some unfortunate experiences with IRIX handling of floppies. Our department have some IRIX machines with external SCSI floppy drives. Every few seconds the drive is probed to see if any media is present, and it does auto mounting/unmounting.
A few times I have logged into such a machine and done a litle work on a floppy from a simple terminal. I didn't need a full graphic environment just for copying a few files to/from a floppy. When I was done I might realize I needed to do something else, which required the GUI, so I would type x in the terminal and wait. A litle later I would remove the floppy because I was done with it. A few seconds later when the system realized the floppy was gone, it would unmount it first killing all users including my login shell. There goes my graphical user interface, not because any of the programs was actually using the floppy, just because everything was started from a shell that happened to have its current directory on the floppy.
This happened to me a couple of times before I realized the connection between removing the floppy from the drive, and being kicked off the system two seconds later.
A particularly popular response is to blindly continue execution after a failed system call and eventually segfault.
Or even worse: Silently cause data corruption. It could even happen without needing an I/O error, if a read/write request returns a short byte count, the application might not be prepared to handle it, and simply think the full count had been handled. I don't see how you could end up with a segfault though, except from dereferencing the NULL pointer from a failing fopen, but that could happen as well if the file was nonexistent.
Pressing RESET can be a lot more harmful than ejecting a CD, lest make that controlled by the OS too.
I have actually seen a laptop, where Windows 95 somehow managed to disable the reset button and crash. Removing the battery was the only option. Afterwards I tried the reset button on a running system, and this time the reset button did work. I even tried everything I could think of to disable it, but it still worked. Yet later Windows 95 once again managed to disable the reset button and crash.
Linux at least is smart enough to name partitions according to their order on disk
Actually their order in the partition table, which doesn't have to match their order on the disk. However the two orders are in most cases the same, and some partition programs will even give you warnings if they are not.
To be fair now, that was at least a decade ago when computers were a lot simpler and there weren't things like hard drives to worry about.
My Amiga have a harddrive (actually two, but I only use one of them). It is even hotplugable (at least in theory, the driver doesn't always like the drive getting removed).
does whatever's in the autorun.inf.
Since you mention AUTORUN.INF, I'd like to point out, that it is a security hole. AmigaOS versions before 2.0 had a similar security hole, which was actually abused by multiple viruses. When I bought my first Amiga in 1991 the hole was already closed. Four years later Microsoft reinvented that security hole. The only reason it didn't turn into a major problem probably was, that writing to a CD is so much more complicated than writing to a floppy.
Can anyone explain in more detail the differences between the Amiga and Windows versions?
In AmigaOS media are known by their volume name, not the drive name. So you could open a file on a floppy not currently in any drive, and the OS would request that it was inserted. You could use multiple media and switch as requested by the OS. And in some cases you could even reinsert a media in a different drive and continue using it as if nothing had happened. You could access directories and files by drive name too, but that would just mean the disk that is currently in the drive. In other words it would continue using the same disk even if it is no longer in the same drive.
It's fairly easy to write a daemon which detects mounting of a new volume and creates a symlink to it, using the name of the disk
If by mounting you mean through the use of the mount system call, detecting that is of course easy, but it is just not enough. I want to detect the media being inserted, removed, and the eject button. Besides how do you easilly find the volume name of a media with an unknown filesystem?
What's the difference between this and the Mac way of doing
things?
Well. I haven't used Mac that much, but the major difference I have noticed is of course the lack of an eject button on the Mac. It is more tricky to get the disk out of a Mac, and I have not actually seen the nice requests for inserting disks that AmigaOS has. However it might be, that if the Mac had a button on the drive to activate the software eject feature, and if I had the chance to use it a litle more, I might have ended up liking it as much as the AmigaOS
implementation.
I have also heard that Mac would have trouble shutting down, if a previously seen floppy was no longer in the drive. With AmigaOS if a floppy was not actually in use, the system would forget everything about it as soon as it was removed. Of course AmigaOS would not have the shut down problem, because AmigaOS is a system you can just turn out without having to shut down first. Just ensure no process is accessing your media as you turn off the power.
Re:Parent point valid despite foul language
on
Worst Linux Annoyances?
·
· Score: 2, Interesting
if I hit the eject button, and some app is using the CD, I should get a popup dialog on my screen
Actually I think the AmigaOS way of handling that situation is even better. Rather than showing the popup when you try to eject, it actually let you eject the disk. If some app is really going to use the CD you will get a popup requesting you to reinsert the CD. That popup have a retry button and a cancel button. You can actually insert another CD and start using it. You can have two different apps (or even the same) using the two discs. You will get requests when you need to switch.
What I have described is the way AmigaOS handles floppies (and probably also CDs, but I never owned an Amiga with CDROM). And it is the way I want Linux to handle CDs, and other removable media as far as hardware permits. Of course in Linux it gets complicated by X vs. terminals and the fact that the graphical user interface is not a part of the kernel. It also gets complicated by the fact there can be multiple users. But I have ideas about how to handle all of those problems.
You can give a look at the automount kernel feature.
I know the automount feature. For large numbers of NFS mounted user filesystems it is a nice feature, and it almost works. But for removable media the automounter is just not enough. You cannot eject a media while it is in use. In fact you even cannot eject it the first minute after it was last used (by default). And lowering the timeout is going to bite as well, because we really don't want the media unmounted with cache flushes as a result. The feature I want is better than the automounter, but there are a few hardware details I need to know before I can implement it. Actually I think the existing automounter filesystem (the kernel part of the automounter) can be used by my implementation as well.
I didn't read the code yet, but this is the basic idea behind it.
I did read some of it, and even straced the user mode daemons. That was back in the days of RH7.0, and I was having a nasty problem. It turned out to be a bug in the driver in the kernel. I ended up downgrading the user mode daemon, not because it was buggy, but because the older version did not trigger the kernel bug. I didn't loose anything from downgrading, as the major difference I could see was, that the new user mode daemon tried to use a kernel 2.4 feature. Since RH7.0 shipped with kernel 2.2.16, it actually had to fall back on the old approach. And it was this fall back, that didn't work, causing an ENOENT error on the first access after mounting. The bug might still be present in newer kernels, but the user mode daemon is not going to trigger it, cause it doesn't have to use the fall back.
There's a good sample on how to do something similar (in userland) at linux/Documentation/dnotify.txt.
No, that is something completely different. Sure dnotify is a nice feature. But it is completely unrelated to handling of removable media.
The Amiga used floppy drives that had different hardware than the PC
Actually the difference was in the controller. The 880KB drives in the Amiga were identical to the 720KB drives in PCs. At least that is what I have read in many places. The controller on the Amiga was much more flexible than the one on the PC. So it might be impossible to have the PC handle floppies as well as the Amiga did. But I really don't care about floppies. I consider floppies to be obsolete. What I want is Linux to handle CD's at least as good as the Amiga was at handling floppies.
However, I seem to remember that when you took a disk out of an Amiga drive, you'd hear a periodic soft click, like maybe every few seconds. Perhaps that was sort of a 'ping' that looked to see if the disk was present or not, or if it had changed.
That is all true. But that was all done in software. And somebody found a different way to ping the drive without making that sound.
Slashdot Mirror
Noone ever said that linux was the most stable design either.
There is a clear boundary between the kernel and user mode. There are a few ways root can crash the system from user mode, if you really want to. But as non root user, you cannot crash the system unless you find a bug in the kernel.
For me, Linux errors are helpful
That is also my experience. If I have a problem with Linux, it gives me all the messages and tools I need to find the exact cause of the problem. With Windows I often have to give up, because it refuse to tell me, what I need to know. Knowing what the problem is, is the first major step towards solving it.
Talking about putting flammable stuff in your hair makes me think about some (crazy) guys, who built an orange cannon using hair spray as fuel. It can shoot over 100m.
Try http://www.kernel.org...
Why? http://kernel.org/ is enough.
Department of Redundancy Department?
I think a Redundant Department of Redundancy would be more appropriate.
Then link to /mirrors/ instead of the top of kernel.org. (Some time in the past I was unable to contact kernel.org for days, so I started mirroring the list of mirrors near my country.)
and in the end, he had to buy 2 drives, i wonder if the recovery prices inclued a new drive??
When I read about those "exhorbitant" prices, my first thought was that it was cheap. My guess would be that you could end up paying ten or hundred times as much for data recovery than the price of the drive. Anyway whenever somebody asks me about data recovery, I ask them how valuable their data is. If the data is more valuable than a new disk, they should buy one, because it will always come in handy during the recovery. If the data is less valuable I wouldn't waste any time on recovery.
Uh, how do you feel that the Mac and Amiga ways of handling removable media differ?
I actually already answered that question.
We were talking about Linux annoyances.
Yes. And xine is not a part of Linux. It is a program which can run on top of Linux (And maybe other OSes as well, I never tried). By your logic Windows must suck a lot more than Linux, because there are so many more bad programs that run on top of Windows than there are bad programs running on top of Linux. Besides xine was not my first suggestion. Ogle was my first suggestion.
People complain, but nobody listens
Why should they listen to anybody who just wants to complain? If you really want the program to become better, you have got to be more constructive. There have to be something you like about the program before you can participate in improving it. When you have reached the point, where you want to make a good program better, people will start listening to you. But just because they listen, they don't have to agree. Nobody is forced to think the same way as somebody else, that works both ways.
If you modify something interesting please let me know!
If I can find somebody who will offer me the bandwidth, I will put up a story for slashdot.
Xine still amuses me with its "://" button. What do Linux developers smoke when they create things like that?
Hey, did anybody say xine had a good GUI? I hate the GUI, but the player works well in most cases. (Make sure not to use a cripled version supplied with your distribution.) But though the xine GUI is not the best, it is still better than mplayer. If you want a simple GUI use ogle.
there has yet to be a Free Hardware movement.
opencores.
Most people want thier CD tray to eject and most people don't know the proc filesystem. Therefore the solution to the Cd tray ejecting problem can't use the proc filesystem.
/etc/modules.conf, blame your distributer if you disagree with the default configuration.
It sure can. A feature to do exactly as requested already exists in the kernel. It is just not enabled by default, but any distributer can insert an appropriate command to enable it. If the cdrom driver is a module, the command would probably need to be post-install in
Should the computer tell the root program to lump it, unmount the disk, and hope the program running as root handles IO errors correctly?
You just got me thinking about some unfortunate experiences with IRIX handling of floppies. Our department have some IRIX machines with external SCSI floppy drives. Every few seconds the drive is probed to see if any media is present, and it does auto mounting/unmounting.
A few times I have logged into such a machine and done a litle work on a floppy from a simple terminal. I didn't need a full graphic environment just for copying a few files to/from a floppy. When I was done I might realize I needed to do something else, which required the GUI, so I would type x in the terminal and wait. A litle later I would remove the floppy because I was done with it. A few seconds later when the system realized the floppy was gone, it would unmount it first killing all users including my login shell. There goes my graphical user interface, not because any of the programs was actually using the floppy, just because everything was started from a shell that happened to have its current directory on the floppy.
This happened to me a couple of times before I realized the connection between removing the floppy from the drive, and being kicked off the system two seconds later.
A particularly popular response is to blindly continue execution after a failed system call and eventually segfault.
Or even worse: Silently cause data corruption. It could even happen without needing an I/O error, if a read/write request returns a short byte count, the application might not be prepared to handle it, and simply think the full count had been handled. I don't see how you could end up with a segfault though, except from dereferencing the NULL pointer from a failing fopen, but that could happen as well if the file was nonexistent.
Pressing RESET can be a lot more harmful than ejecting a CD, lest make that controlled by the OS too.
I have actually seen a laptop, where Windows 95 somehow managed to disable the reset button and crash. Removing the battery was the only option. Afterwards I tried the reset button on a running system, and this time the reset button did work. I even tried everything I could think of to disable it, but it still worked. Yet later Windows 95 once again managed to disable the reset button and crash.
Linux at least is smart enough to name partitions according to their order on disk
Actually their order in the partition table, which doesn't have to match their order on the disk. However the two orders are in most cases the same, and some partition programs will even give you warnings if they are not.
To be fair now, that was at least a decade ago when computers were a lot simpler and there weren't things like hard drives to worry about.
My Amiga have a harddrive (actually two, but I only use one of them). It is even hotplugable (at least in theory, the driver doesn't always like the drive getting removed).
does whatever's in the autorun.inf.
Since you mention AUTORUN.INF, I'd like to point out, that it is a security hole. AmigaOS versions before 2.0 had a similar security hole, which was actually abused by multiple viruses. When I bought my first Amiga in 1991 the hole was already closed. Four years later Microsoft reinvented that security hole. The only reason it didn't turn into a major problem probably was, that writing to a CD is so much more complicated than writing to a floppy.
Can anyone explain in more detail the differences between the Amiga and Windows versions?
In AmigaOS media are known by their volume name, not the drive name. So you could open a file on a floppy not currently in any drive, and the OS would request that it was inserted. You could use multiple media and switch as requested by the OS. And in some cases you could even reinsert a media in a different drive and continue using it as if nothing had happened. You could access directories and files by drive name too, but that would just mean the disk that is currently in the drive. In other words it would continue using the same disk even if it is no longer in the same drive.
It's fairly easy to write a daemon which detects mounting of a new volume and creates a symlink to it, using the name of the disk
If by mounting you mean through the use of the mount system call, detecting that is of course easy, but it is just not enough. I want to detect the media being inserted, removed, and the eject button. Besides how do you easilly find the volume name of a media with an unknown filesystem?
What's the difference between this and the Mac way of doing things?
Well. I haven't used Mac that much, but the major difference I have noticed is of course the lack of an eject button on the Mac. It is more tricky to get the disk out of a Mac, and I have not actually seen the nice requests for inserting disks that AmigaOS has. However it might be, that if the Mac had a button on the drive to activate the software eject feature, and if I had the chance to use it a litle more, I might have ended up liking it as much as the AmigaOS implementation.
I have also heard that Mac would have trouble shutting down, if a previously seen floppy was no longer in the drive. With AmigaOS if a floppy was not actually in use, the system would forget everything about it as soon as it was removed. Of course AmigaOS would not have the shut down problem, because AmigaOS is a system you can just turn out without having to shut down first. Just ensure no process is accessing your media as you turn off the power.
if I hit the eject button, and some app is using the CD, I should get a popup dialog on my screen
Actually I think the AmigaOS way of handling that situation is even better. Rather than showing the popup when you try to eject, it actually let you eject the disk. If some app is really going to use the CD you will get a popup requesting you to reinsert the CD. That popup have a retry button and a cancel button. You can actually insert another CD and start using it. You can have two different apps (or even the same) using the two discs. You will get requests when you need to switch.
What I have described is the way AmigaOS handles floppies (and probably also CDs, but I never owned an Amiga with CDROM). And it is the way I want Linux to handle CDs, and other removable media as far as hardware permits. Of course in Linux it gets complicated by X vs. terminals and the fact that the graphical user interface is not a part of the kernel. It also gets complicated by the fact there can be multiple users. But I have ideas about how to handle all of those problems.
You can give a look at the automount kernel feature.
I know the automount feature. For large numbers of NFS mounted user filesystems it is a nice feature, and it almost works. But for removable media the automounter is just not enough. You cannot eject a media while it is in use. In fact you even cannot eject it the first minute after it was last used (by default). And lowering the timeout is going to bite as well, because we really don't want the media unmounted with cache flushes as a result. The feature I want is better than the automounter, but there are a few hardware details I need to know before I can implement it. Actually I think the existing automounter filesystem (the kernel part of the automounter) can be used by my implementation as well.
I didn't read the code yet, but this is the basic idea behind it.
I did read some of it, and even straced the user mode daemons. That was back in the days of RH7.0, and I was having a nasty problem. It turned out to be a bug in the driver in the kernel. I ended up downgrading the user mode daemon, not because it was buggy, but because the older version did not trigger the kernel bug. I didn't loose anything from downgrading, as the major difference I could see was, that the new user mode daemon tried to use a kernel 2.4 feature. Since RH7.0 shipped with kernel 2.2.16, it actually had to fall back on the old approach. And it was this fall back, that didn't work, causing an ENOENT error on the first access after mounting. The bug might still be present in newer kernels, but the user mode daemon is not going to trigger it, cause it doesn't have to use the fall back.
There's a good sample on how to do something similar (in userland) at linux/Documentation/dnotify.txt.
No, that is something completely different. Sure dnotify is a nice feature. But it is completely unrelated to handling of removable media.
The Amiga used floppy drives that had different hardware than the PC
Actually the difference was in the controller. The 880KB drives in the Amiga were identical to the 720KB drives in PCs. At least that is what I have read in many places. The controller on the Amiga was much more flexible than the one on the PC. So it might be impossible to have the PC handle floppies as well as the Amiga did. But I really don't care about floppies. I consider floppies to be obsolete. What I want is Linux to handle CD's at least as good as the Amiga was at handling floppies.
However, I seem to remember that when you took a disk out of an Amiga drive, you'd hear a periodic soft click, like maybe every few seconds. Perhaps that was sort of a 'ping' that looked to see if the disk was present or not, or if it had changed.
That is all true. But that was all done in software. And somebody found a different way to ping the drive without making that sound.