### Except when you type it into the keyboard. There are already keyboard sniffer worms out there to handle that.
There are already smartcards on the market that have their own numpad (like those creditcard sized calculators), so even a sniffer on the client couldn't actually sniff anything. And even with a non-seperate numpad, all the sniffer could ever get would be the pin that protects the smartcard, which in turn would be relativly useless unless the attacker gains physical access to the smartcard itself.
### There's no way I'm carrying a card around to log into some phpBB board.
You wouldn't carry one card specificically for your phpBB, but one card for basically EVERYTHING, you login into the computer itself, some phpBB and whatever. Maybe an additional card for hi-security stuff like banking, but thats it. The whole point of such a system would be that you have a single point to log into a system which requires a physical device and is thus basically impossible to crack via the net, unlike a short-password, which most people use on the net.
### Password managers are a pretty ideal solution.
They are a good workaround due to lack of alternatives, nothing more. With all the worms, viruses and bufferoverflows a password manager isn't really secure, since all the information is stored on the client, easy to spy away. A smartcard on the other side could never be spyed by breaking into the computer, since it would be a seperate device, no secret information would ever need to go unencrypted on the clients computer.
a) be protected by a pin b) additionally protected by biometrics c) easy to lock in case of loss d) keept in the users pocket, so MUCH LESS likly to get into the hands of 'evil' then simple password (birthday, name of doughter or whatever) or a post-it sticked under the keyboard
A smartcard done right would always be at least as secure as a simple password, but would in addition to that require to have physical access to the victim.
Banks use a smardcard based system (aka HBCI) for a reason, you know.
The smartcard would only need to handle the information necesarry for login, not additional information such as credit card, name, address or whatever. The smartcard really should only replace username+password, nothing more, but it could do that much more secure AND much more comfortable with only a little bit of extra costs.
What the parent poster was refering to was IMHO that MS Passport stored all information to log into passport on the client, so it ended up being no better than all those password-managers that we have today and which also save information on the client.
### based on data resident on a machine administered so incompetently...
That is what I call bad implementation, if done right this whole thing would have worked via smartcards. Have a key stored on that card and encrypt the login information on the card itself, don't store any information on the computer itself. Would have even allowed to move to another computer and login there without risking to get the password spyed away. Good smartcard are ever protected by a pin which you can enter on the card itself, so you don't even need an extra numpad. On the server side all that would be needed would be some standard protocoll to comminucate with the client/smartcard.
Downside is of course that such smartcard reader would have cost a little bit of money, but given that now basically every PC comes with Flash-, SD-, XD- and whatever they are called slots, such a reader shouldn't have ben all that expensive, especially if Microsoft would have backed it up with a little 'force'.
Sadly all dreams, and we are stuck for the coming years with passwords and password managers which basically store everything in almost plain-text on the client...
Back in the early days the binaries in/sbin/ might have been statically linked, today however/sbin/ is really no more then a not-so-usefull hack to seperate binaries only executable by root from those executable by a user. The difference between the binaries for root and user is however not done via permissions, user can still execute everything in/sbin and some of the/sbin programms in there can be quite usefull for a user too (ifconfig). So overall the seperation is mainly there for historic reasons without actually being all that usefull today.
If somebody has root you have lost anyhow, either reinstall the machine or verify a trusted log of checksums. Hiding stuff is standard practice of rootkits, they don't need any PATH-wildcards for that.
I second that, world could be so much easier already if we just had wildchard support in PATH and other environment variables.
PATH=$PATH:/opt/*/bin/
or something along the lines could make life much easier.
The throuble is really that the current filehierachie was designed to only contain a basic unix system, (ls, rm, libc, etc.) not a fullblown multimedia desktop, as what most linux are today. Stuff like the LHS don't even try to fix the mess, they just standardize it. Most likly we will be stuck with the current mess of a file hierachie for long time to come and hardcompiled paths in a bunch of binaries don't make it much easier to get rid of it either.
You don't need storage that lasts 70+ years, you only need storage that is easy enough to replace every ten years or so. CDs or DVDs are for sure no good for that, since they would require you to sit two weeks in front of the PC to copy them all, nobody would do that and they would simply rot over the years. I think the way storage will be done in the future goes more into the direction of network storage devices, say you have a 'cube' full of harddisks in your basement, all RAID or something more advanced that automatically replicates the data in case that a single drive fails. So you can basically forget the device for most of the time, maybe only check every few years the status of the device, once half the disks have died or so you buy a replacement, connect it to the old box and it would replicate itself to the new one without ever doing more then put the plug into the storage-jack.
Instead of having the data only on a single physical device it could of course also happen in a P2P style way where all those little storage boxes are connected to each other and replicate each other automatically, so even in case your box burns down, other boxes on the net would have your data and you would just need to connect a new box to the net to get it back.
The hardware for all that is really already there today, all that is missing is some easy-to-use wrappering of it and the right software.
### Is there anybody out there with a ten year old computer operating with its original OS and hard drive that was formatted only once...when it was new?
I know some NeXT boxes which have been around for almost a decade and are still in active use. Biggest problem there is actually that the monitors brightness and contrast have fallen down to a level where it gets hard to actually see anything, but beside from that the boxes are still doing quite fine, even form a usability point of view.
The 50MB by which your home directory grows will however most likly be not all your own personal selfwritten data, half of it or so will be random downloads from the net and stuff like that that is not uniq to yourself. So if we ever get such a record-your-life device I am sure that it would have some way to 'compress' away such non-uniq data, say by having a giant P2P network that contains all data that is shared among menkind. So if you download 600mb worth a movie on a day, the device would just need to store the MD5/SHA-1 of it and could retrieve the movie itself from the P2P network. Copyright-police might of course have something against that, but hopefully we will have solved that problem until then.
And just for the record, 500$ for a 1TB is todays cost of it and its a one-pay for a lifetime. So in the future it will for sure get a lot cheaper and of course nothing stops you from buying a new TB once you run out of space. So even collecting 10 or even 100TB of data wouldn't be all that unrealistic, even by todays prices and by future prices even 1000TB should be a non-issue.
The only thing that stops such things currently is really the lack of reliable storage, I mean realy reliable easy to use ones, not rather primitive self-build IDE-Raid stuff. More like IBMs IceCubes, where you have a bunch of connected cubes of storage and can simply add or replace them at will, replication and redundancy would happen automatically and there would be no danger that all your data get lost just because a harddisk or two went 'bye,bye'.
The Bittorrent download worked fine for me, not super fast, but I got my 20-30kb/s. The non-torrent download via their own download tool and ftp however didn't managed to download more then 30kb in half an hour for me.
### I've heard it argued both ways but as I understand it, both nvidia and ati drivers are ass-pains in linux.
ATI drivers are still a pain, NVidia drivers however are now among the easiest to install drivers outside the standard kernel. They come in the form of a simple self-extracting script which you just run, it will automatically detect the correct kernel headers and such and will in most cases compile out-of-the-box without ever manually configuring anything, even on a Debian box. Beside from the easy install of Nvidia drivers they also run great, good speed, no crashes and full feature support (pbuffer, GLSL) something which one can't really say about the ATI ones.
### Do you mean the md5sum of an installation package/archive before you install it? Or you somehow want to test the program after install?
Basically both, if one wants a self healing system, the system needs first a way to find out that something is wrong in the first place. If there isn't a way to detected that some files got broken, then a self-healing system can do nothing. Beside from that it might of course also help to detect some cracker attacks or corrupt harddisks easier.
### Only when you limit your OS choices to turds. See below.
Feel free to suggest one, neither Windows, MacOSX, Linux (any distri) nor FreeBSD get the job done properlly.
### Why in hell does the OS have to be involved in an application install?!?!?!
If not the OS, then who else should take care of it? If the application are free to dump themself anywhere there won't without anybody taking care of them doing it properly its just a matter of time since one app will to bad things.
### VMS. Old news. Also lots of disk space needed
VMS, I now, current OS however are still behind that. About diskspace, yep, plenty, my HD and those of basically EVERYBODY else has at least a few hundred megabytes free, often that would be more than enough for recovery of a accidently overwriten file.
### And why not a Trashcan inside the trashcan.
Trashcan only works if the application does use it, most however don't and never will. Beside from that it can't catch overwritten files only deleted ones.
### Just how in hell is the OS supposed to determine that a third-party application's file hasn't had it's "integrity" destroyed? How on God's good Earth would the OS even define integrity?
Application comes with a bunch of MD5 or whatever checksums which the OS can check again.
### Yeah, but it's really only Windows that sucks.
No, all OS do, some just more then others.
### it's actually really easy, because an app always knows where it's located
No, the app does not know where it is located. The only way to do that portably on Unix today are hardcoded path inside the binary, which simply causes endless throuble in case one wants to relocate a application. Registry is of course not the best solution out there, but hardcoding configuration values into a binary for sure is just an ugly hack.
### Something must be stored somewhere so that the system can identify a modified binary.
Well, the system ultimativly knows when something changes, since it is the one who changes it. You are right that one needs some metadata, those however in most cases already comes with the packages (deb/rpm) one installs, there just isn't a standard way to automatically check these changes. However this problem can be solved completly in userspace with a cronjob, would just be nice to have a standard way to do it.
### During the desktop's formative years, the raw drive space needed to actually implement these kinds of things just wasn't available.
While that might be true, that was at least 10 years ago. Since we count in GigaByte we have more space then needed and in most cases more then we ever can legally fill. And even if the harddisk runs full from time to time it isn't much of a problem, a versioning filesystem should simply scale back and automatically discard older versions, but as long as there is still free space on the harddisk I see little reason to not use it for something usefull.
### The second problem is tough as well, but there are patches to libc's unlink() function
The throuble with that patch is the same as with the trashcans, they only get what you actually delete, not what you overwrite, fill with 0 bytes or destroy by other operations. I don't have any hard numbers, but in my experience the deleted files don't happen that often compared to the overwritten ones.
### If a program writes 1MB to a file 1 byte at a time, is that one million revisions?
If it does 'fopen(.., "a"); write() close();' then yep, one million revisions. A new version should be created once the filehandled is opened for writing, something that is hard to catch from userspace. Storing of the new version could then happen in some Copy-on-write style manner, thats why the kernel need to play at least some role.
### How are you going to tell this apart at the kernel level?
Since you only need to listen to open() and close(), how many bytes are written inbetween that is not much of an issue. And about the "nobody cares" part, well, the programmer might not, the users who yet again have lost data however might a lot, but as with all things that are only usefull if things go wrong it of course isn't much good for marketing.
While a self healing system sounds nifty, todays systems aren't even good enough to be healed manually.
Uninstalling applications is often not handled by the OS and has to be done by application itself, resulting in incomplete installations, config files and registiry entries that havn't been properly cleaned up and whatever.
Files arn't versioned, so every change done to a file will simply erase the former content forever, not so good if the former content might have been important.
Undelete? Nope, we don't have that either, we have this hack of a Trashcan, but that won't help you much if some programm deleted the file.
Check of integritiy of an installed piece of software isn't possible either, sure there are third-party solutions, but again that should be something that the OS provides at default
Well, there are millons of more issues why todays system suck and why it is often easier to simply reinstall from scratch then to try to actually fix the mess, and yep, that is true for both Linux, Windows and MacOS, sure for some more then for the others, but thats it.
Windows doesn't spread an installed application all over the filesystem but keeps them in their local directory. That said, the registry still contains a whole bunch of redundant information which makes moving applications difficult. However moving basic application in Windows around is pretty doable. Last not least, this in not only about moving them, but installing them in a different location in the first place. Say installing a RPM/DEB in the users homedir, on Windows that is no problem, since basically all applications can be installed wherever you like, under Linux its basically impossible with a binary (hex-editor tricks asside).
Yep, leads however to several uglynesses. Since command-line options are pretty dynamic, one needs to write them down somewhere, which in turn leads than to Wrapper scripts, which then require renaming of the real binary (foo -> foo.real), which in turn makes 'ps aux', 'gdb', 'killall' and a bunch of other things more difficult to use, since you always have to lookup the real name of the binary first. Overall probally the best solution today, however still not really optimal.
What I would like would be EA (extended records) on the binary file itself which carry the necesarry start-up config filename, the access to the records could go via the/proc/self/exe Symlinks and if those EAs are relative they might even survive basic moving around in the filesystem. However EAs are as far as I know still not available on all major filesystems or only with patches, so it wouldn't work much good today.
LSB rpms depend by their very nature NOT on other stuff, LSB rpms will depend in most cases on just pure LSB, thats what its used for in the firs place and if they will depend on something else it will just be other LSB rpms.
### Said RPM's could overwrite any file on my system
No, because they go to/opt/ and nowhere else.
### Making RPM the "standard package tool" entices vendors to use Redhat Linux as their base
You haven't yet understand the purpose of LSB, have you? LSB is for stuff OUTSITE your distribution, its not meant to replace it. It won't mess with your distri, it won't require your distri to switch to RPM, nada, all it requires it that your distro provides some way to install lsb-rpms, be it alien, rpm2cpio or whatever is completly up to your distro.
Well, what are people going to do with their Linux-Installation:
a) Wipe it out and replace it with Windows b) Throw the computer into the trashcan c) Continue to use Linux because it gets the job done
I think c) is perfectly ok, b) is rather unlikly and if they do a), what do you expect? Either WinXP will run even more slow or it will be a faster, if its slower, no lose, people will figure its not Linux fault that the computer is slow, if XP is faster, then well, Linux IS actually slow and people will remember it, because its the truth. Can't see anything bad with that.
### Even if a simple recompile doesn't work it is still possible to modify the source to get it to work.
Yes, there is always a way to get it work somehow, however that is often WAY bejoint that what a normal user can do. Compiling something like a older version of Gnome or so is a hell of a task, since all its dependencies have moved on two and you have to do some good digging in the historie books and what you need and where you can still get it. Doesn't sound usefull? Well, thats exactly what I would have liked todo a few years ago when Gnome2 came out and the distro switched to that, wanted to get my Gnome1.4 back, however there was no way getting that back without a heapload of manual work. When LSB would have been more widespread back then it wouldn't have been a problem in the first place, since I just could have/opt/lsb-gnome-1.4 and a/opt/lsb-gnome-2.0 installed in parallel without much problem, however that wasn't available back then and still isn't, but at least the direction in which LSB goes is correct.
Slashdot Mirror
3000*40=120'000, not 400
### Except when you type it into the keyboard. There are already keyboard sniffer worms out there to handle that.
There are already smartcards on the market that have their own numpad (like those creditcard sized calculators), so even a sniffer on the client couldn't actually sniff anything. And even with a non-seperate numpad, all the sniffer could ever get would be the pin that protects the smartcard, which in turn would be relativly useless unless the attacker gains physical access to the smartcard itself.
### There's no way I'm carrying a card around to log into some phpBB board.
You wouldn't carry one card specificically for your phpBB, but one card for basically EVERYTHING, you login into the computer itself, some phpBB and whatever. Maybe an additional card for hi-security stuff like banking, but thats it. The whole point of such a system would be that you have a single point to log into a system which requires a physical device and is thus basically impossible to crack via the net, unlike a short-password, which most people use on the net.
### Password managers are a pretty ideal solution.
They are a good workaround due to lack of alternatives, nothing more. With all the worms, viruses and bufferoverflows a password manager isn't really secure, since all the information is stored on the client, easy to spy away. A smartcard on the other side could never be spyed by breaking into the computer, since it would be a seperate device, no secret information would ever need to go unencrypted on the clients computer.
The smartcard could:
a) be protected by a pin
b) additionally protected by biometrics
c) easy to lock in case of loss
d) keept in the users pocket, so MUCH LESS likly to get into the hands of 'evil' then simple password (birthday, name of doughter or whatever) or a post-it sticked under the keyboard
A smartcard done right would always be at least as secure as a simple password, but would in addition to that require to have physical access to the victim.
Banks use a smardcard based system (aka HBCI) for a reason, you know.
The smartcard would only need to handle the information necesarry for login, not additional information such as credit card, name, address or whatever. The smartcard really should only replace username+password, nothing more, but it could do that much more secure AND much more comfortable with only a little bit of extra costs.
What the parent poster was refering to was IMHO that MS Passport stored all information to log into passport on the client, so it ended up being no better than all those password-managers that we have today and which also save information on the client.
### based on data resident on a machine administered so incompetently...
That is what I call bad implementation, if done right this whole thing would have worked via smartcards. Have a key stored on that card and encrypt the login information on the card itself, don't store any information on the computer itself. Would have even allowed to move to another computer and login there without risking to get the password spyed away. Good smartcard are ever protected by a pin which you can enter on the card itself, so you don't even need an extra numpad. On the server side all that would be needed would be some standard protocoll to comminucate with the client/smartcard.
Downside is of course that such smartcard reader would have cost a little bit of money, but given that now basically every PC comes with Flash-, SD-, XD- and whatever they are called slots, such a reader shouldn't have ben all that expensive, especially if Microsoft would have backed it up with a little 'force'.
Sadly all dreams, and we are stuck for the coming years with passwords and password managers which basically store everything in almost plain-text on the client...
The cameras can take at max 30 picture per second, they are not limited to a shutter time of 1/30s.
Back in the early days the binaries in /sbin/ might have been statically linked, today however /sbin/ is really no more then a not-so-usefull hack to seperate binaries only executable by root from those executable by a user. The difference between the binaries for root and user is however not done via permissions, user can still execute everything in /sbin and some of the /sbin programms in there can be quite usefull for a user too (ifconfig). So overall the seperation is mainly there for historic reasons without actually being all that usefull today.
If somebody has root you have lost anyhow, either reinstall the machine or verify a trusted log of checksums. Hiding stuff is standard practice of rootkits, they don't need any PATH-wildcards for that.
I second that, world could be so much easier already if we just had wildchard support in PATH and other environment variables.
PATH=$PATH:/opt/*/bin/
or something along the lines could make life much easier.
The throuble is really that the current filehierachie was designed to only contain a basic unix system, (ls, rm, libc, etc.) not a fullblown multimedia desktop, as what most linux are today.
Stuff like the LHS don't even try to fix the mess, they just standardize it. Most likly we will be stuck with the current mess of a file hierachie for long time to come and hardcompiled paths in a bunch of binaries don't make it much easier to get rid of it either.
You don't need storage that lasts 70+ years, you only need storage that is easy enough to replace every ten years or so. CDs or DVDs are for sure no good for that, since they would require you to sit two weeks in front of the PC to copy them all, nobody would do that and they would simply rot over the years. I think the way storage will be done in the future goes more into the direction of network storage devices, say you have a 'cube' full of harddisks in your basement, all RAID or something more advanced that automatically replicates the data in case that a single drive fails. So you can basically forget the device for most of the time, maybe only check every few years the status of the device, once half the disks have died or so you buy a replacement, connect it to the old box and it would replicate itself to the new one without ever doing more then put the plug into the storage-jack.
Instead of having the data only on a single physical device it could of course also happen in a P2P style way where all those little storage boxes are connected to each other and replicate each other automatically, so even in case your box burns down, other boxes on the net would have your data and you would just need to connect a new box to the net to get it back.
The hardware for all that is really already there today, all that is missing is some easy-to-use wrappering of it and the right software.
### Is there anybody out there with a ten year old computer operating with its original OS and hard drive that was formatted only once...when it was new?
I know some NeXT boxes which have been around for almost a decade and are still in active use. Biggest problem there is actually that the monitors brightness and contrast have fallen down to a level where it gets hard to actually see anything, but beside from that the boxes are still doing quite fine, even form a usability point of view.
The 50MB by which your home directory grows will however most likly be not all your own personal selfwritten data, half of it or so will be random downloads from the net and stuff like that that is not uniq to yourself. So if we ever get such a record-your-life device I am sure that it would have some way to 'compress' away such non-uniq data, say by having a giant P2P network that contains all data that is shared among menkind. So if you download 600mb worth a movie on a day, the device would just need to store the MD5/SHA-1 of it and could retrieve the movie itself from the P2P network. Copyright-police might of course have something against that, but hopefully we will have solved that problem until then.
And just for the record, 500$ for a 1TB is todays cost of it and its a one-pay for a lifetime. So in the future it will for sure get a lot cheaper and of course nothing stops you from buying a new TB once you run out of space. So even collecting 10 or even 100TB of data wouldn't be all that unrealistic, even by todays prices and by future prices even 1000TB should be a non-issue.
The only thing that stops such things currently is really the lack of reliable storage, I mean realy reliable easy to use ones, not rather primitive self-build IDE-Raid stuff. More like IBMs IceCubes, where you have a bunch of connected cubes of storage and can simply add or replace them at will, replication and redundancy would happen automatically and there would be no danger that all your data get lost just because a harddisk or two went 'bye,bye'.
The Bittorrent download worked fine for me, not super fast, but I got my 20-30kb/s. The non-torrent download via their own download tool and ftp however didn't managed to download more then 30kb in half an hour for me.
### I've heard it argued both ways but as I understand it, both nvidia and ati drivers are ass-pains in linux.
ATI drivers are still a pain, NVidia drivers however are now among the easiest to install drivers outside the standard kernel. They come in the form of a simple self-extracting script which you just run, it will automatically detect the correct kernel headers and such and will in most cases compile out-of-the-box without ever manually configuring anything, even on a Debian box. Beside from the easy install of Nvidia drivers they also run great, good speed, no crashes and full feature support (pbuffer, GLSL) something which one can't really say about the ATI ones.
### Do you mean the md5sum of an installation package/archive before you install it? Or you somehow want to test the program after install?
Basically both, if one wants a self healing system, the system needs first a way to find out that something is wrong in the first place. If there isn't a way to detected that some files got broken, then a self-healing system can do nothing. Beside from that it might of course also help to detect some cracker attacks or corrupt harddisks easier.
### Only when you limit your OS choices to turds. See below.
Feel free to suggest one, neither Windows, MacOSX, Linux (any distri) nor FreeBSD get the job done properlly.
### Why in hell does the OS have to be involved in an application install?!?!?!
If not the OS, then who else should take care of it? If the application are free to dump themself anywhere there won't without anybody taking care of them doing it properly its just a matter of time since one app will to bad things.
### VMS. Old news. Also lots of disk space needed
VMS, I now, current OS however are still behind that. About diskspace, yep, plenty, my HD and those of basically EVERYBODY else has at least a few hundred megabytes free, often that would be more than enough for recovery of a accidently overwriten file.
### And why not a Trashcan inside the trashcan.
Trashcan only works if the application does use it, most however don't and never will. Beside from that it can't catch overwritten files only deleted ones.
### Just how in hell is the OS supposed to determine that a third-party application's file hasn't had it's "integrity" destroyed? How on God's good Earth would the OS even define integrity?
Application comes with a bunch of MD5 or whatever checksums which the OS can check again.
### Yeah, but it's really only Windows that sucks.
No, all OS do, some just more then others.
### it's actually really easy, because an app always knows where it's located
No, the app does not know where it is located. The only way to do that portably on Unix today are hardcoded path inside the binary, which simply causes endless throuble in case one wants to relocate a application. Registry is of course not the best solution out there, but hardcoding configuration values into a binary for sure is just an ugly hack.
### Something must be stored somewhere so that the system can identify a modified binary.
Well, the system ultimativly knows when something changes, since it is the one who changes it. You are right that one needs some metadata, those however in most cases already comes with the packages (deb/rpm) one installs, there just isn't a standard way to automatically check these changes. However this problem can be solved completly in userspace with a cronjob, would just be nice to have a standard way to do it.
### During the desktop's formative years, the raw drive space needed to actually implement these kinds of things just wasn't available.
While that might be true, that was at least 10 years ago. Since we count in GigaByte we have more space then needed and in most cases more then we ever can legally fill. And even if the harddisk runs full from time to time it isn't much of a problem, a versioning filesystem should simply scale back and automatically discard older versions, but as long as there is still free space on the harddisk I see little reason to not use it for something usefull.
### The second problem is tough as well, but there are patches to libc's unlink() function
The throuble with that patch is the same as with the trashcans, they only get what you actually delete, not what you overwrite, fill with 0 bytes or destroy by other operations. I don't have any hard numbers, but in my experience the deleted files don't happen that often compared to the overwritten ones.
### If a program writes 1MB to a file 1 byte at a time, is that one million revisions?
If it does 'fopen(.., "a"); write() close();' then yep, one million revisions. A new version should be created once the filehandled is opened for writing, something that is hard to catch from userspace. Storing of the new version could then happen in some Copy-on-write style manner, thats why the kernel need to play at least some role.
### How are you going to tell this apart at the kernel level?
Since you only need to listen to open() and close(), how many bytes are written inbetween that is not much of an issue. And about the "nobody cares" part, well, the programmer might not, the users who yet again have lost data however might a lot, but as with all things that are only usefull if things go wrong it of course isn't much good for marketing.
While a self healing system sounds nifty, todays systems aren't even good enough to be healed manually.
Uninstalling applications is often not handled by the OS and has to be done by application itself, resulting in incomplete installations, config files and registiry entries that havn't been properly cleaned up and whatever.
Files arn't versioned, so every change done to a file will simply erase the former content forever, not so good if the former content might have been important.
Undelete? Nope, we don't have that either, we have this hack of a Trashcan, but that won't help you much if some programm deleted the file.
Check of integritiy of an installed piece of software isn't possible either, sure there are third-party solutions, but again that should be something that the OS provides at default
Well, there are millons of more issues why todays system suck and why it is often easier to simply reinstall from scratch then to try to actually fix the mess, and yep, that is true for both Linux, Windows and MacOS, sure for some more then for the others, but thats it.
### And what does Windows provide?
Windows doesn't spread an installed application all over the filesystem but keeps them in their local directory. That said, the registry still contains a whole bunch of redundant information which makes moving applications difficult. However moving basic application in Windows around is pretty doable. Last not least, this in not only about moving them, but installing them in a different location in the first place. Say installing a RPM/DEB in the users homedir, on Windows that is no problem, since basically all applications can be installed wherever you like, under Linux its basically impossible with a binary (hex-editor tricks asside).
Yep, leads however to several uglynesses. Since command-line options are pretty dynamic, one needs to write them down somewhere, which in turn leads than to Wrapper scripts, which then require renaming of the real binary (foo -> foo.real), which in turn makes 'ps aux', 'gdb', 'killall' and a bunch of other things more difficult to use, since you always have to lookup the real name of the binary first. Overall probally the best solution today, however still not really optimal.
/proc/self/exe Symlinks and if those EAs are relative they might even survive basic moving around in the filesystem. However EAs are as far as I know still not available on all major filesystems or only with patches, so it wouldn't work much good today.
What I would like would be EA (extended records) on the binary file itself which carry the necesarry start-up config filename, the access to the records could go via the
Wasn't Linus sister still using Windows or has she switched in the meantime?
LSB rpms depend by their very nature NOT on other stuff, LSB rpms will depend in most cases on just pure LSB, thats what its used for in the firs place and if they will depend on something else it will just be other LSB rpms.
/opt/ and nowhere else.
### Said RPM's could overwrite any file on my system
No, because they go to
### Making RPM the "standard package tool" entices vendors to use Redhat Linux as their base
You haven't yet understand the purpose of LSB, have you? LSB is for stuff OUTSITE your distribution, its not meant to replace it. It won't mess with your distri, it won't require your distri to switch to RPM, nada, all it requires it that your distro provides some way to install lsb-rpms, be it alien, rpm2cpio or whatever is completly up to your distro.
Well, what are people going to do with their Linux-Installation:
a) Wipe it out and replace it with Windows
b) Throw the computer into the trashcan
c) Continue to use Linux because it gets the job done
I think c) is perfectly ok, b) is rather unlikly and if they do a), what do you expect? Either WinXP will run even more slow or it will be a faster, if its slower, no lose, people will figure its not Linux fault that the computer is slow, if XP is faster, then well, Linux IS actually slow and people will remember it, because its the truth. Can't see anything bad with that.
### Even if a simple recompile doesn't work it is still possible to modify the source to get it to work.
/opt/lsb-gnome-1.4 and a /opt/lsb-gnome-2.0 installed in parallel without much problem, however that wasn't available back then and still isn't, but at least the direction in which LSB goes is correct.
Yes, there is always a way to get it work somehow, however that is often WAY bejoint that what a normal user can do. Compiling something like a older version of Gnome or so is a hell of a task, since all its dependencies have moved on two and you have to do some good digging in the historie books and what you need and where you can still get it. Doesn't sound usefull? Well, thats exactly what I would have liked todo a few years ago when Gnome2 came out and the distro switched to that, wanted to get my Gnome1.4 back, however there was no way getting that back without a heapload of manual work. When LSB would have been more widespread back then it wouldn't have been a problem in the first place, since I just could have