The biggest is coordination across multiple files. Suppose I want to update both foo.txt and bar.txt simultaneously. How can I jigger around temporary files in such a way that both files are guaranteed to remain consistent? I don't think you can.
By the way, I should say that you can if you create a sort of "lock" file. When I want to do my thing, I create exclusive that lock file, move around those files in such a way that they can be backed out, sync, remove the lock file, remove the temporary files.
However, this still isn't as fully-general as a true transactional FS. Other processes running your program now cannot (legally) read the protected file if the lock file exists. This means that you can't have a long-running transaction, which you might want to do if you want to be able to read a consistent image for a long period of time. (Of course, you could solve that by making a private copy of those files -- hopefully COW -- and referring to those, but this sure is a lot of complexity in your program because the system is too lazy to provide a useful feature.)
Furthermore, I'm not sure how much isolation TxNTFS transactions provide. In particular, suppose I have a process A that's doing some edits inside a transaction, then another process B that is reading the file but the process is entirely non-transaction-aware. What you'd hope for is that A's changes aren't visible to B until commit. I suspect TxNTFS provides this though I don't know for sure. (They do state that it's full ACID.) However, my lockfile "suggestion" does not: non-transaction-aware processes (in this context, non-lockfile-aware processes) can get an inconsistent view of the files.
So I think the biggest benefit is the wrapping up thing you mention. But there are a number of other compelling benefits that I think you get from something like TxNTFS that you can't get via the temp file approach. (I'm not super familiar with all this, so I may be talking out of my ass a bit, but I would bet some reasonably small amount of money I'm right.)
The biggest is coordination across multiple files. Suppose I want to update both foo.txt and bar.txt simultaneously. How can I jigger around temporary files in such a way that both files are guaranteed to remain consistent? I don't think you can.
A smaller benefit is that you don't need temporary files. Suppose my program is working on some multi-gigabyte file in such a way that it can, consistency guarantees ignored, just update some blocks in the middle of the file and be done with it. With TxNTFS, it can just do that. Without it, if you want consistency, you now have to copy that multi-gigabyte file to a temporary file, then rewrite the blocks you want. If you're not using a COW file system, that's terribly expensive. Fortunately, while COW systems are still reasonably rare, they are increasingly common (with ZFS and Btrfs both being COW systems).
Another benefit you can get with the way transactions are implemented in Windows is better coordination across multiple entities. This is probably not very important on Linux, but is moreso on Windows. For instance, transactions can span both file system accesses and registry accesses and have ACID semantics in total. That only has some applicability to Linux. But I think that it's also possible to write a program that hooks into the Windows KTM (kernel transaction manager) to provide other transactable entities. For instance, you could imagine that a DBMS would hook into the KTM -- and then you would be able to write programs that have transactions that span both regular file system accesses as well as DB accesses through that DBMS.
I'm not sure how useful that last bit would be though. I find the actual, formal API for doing transactions (instead of doing the sort of hacky "transactions" that you have to now) as well as multi-file transactions the most important benefits.
Crap, HTML problems. Posting again for your reading ease. I'll preview this time even.:-)
First off, logically/lib should be a subfolder in/bin since libraries are needed to make executables works and are not an entity in themselves. Rename/bin into/programs or some-such for clarity./dev,/proc and/sys also belong together though I am not sure how. Maybe under/devices. Crap like/etc should be all collected in/config or something clearly named.
I actually like pretty much all of these. I'd suggest putting/dev,/proc, and/sys together into/system./dev becomes/system/devices,/proc becomes/system/processes (actually I'd be OK with keeping the abbreviation and using/system/proc), and/sys becomes... well, something. We're closer anyway.:-)
Make a/users folder. This would contain all user info.
To be honest, I think/home is still fine, though I wouldn't object to/users.
This is where/root belongs logically.
Yeah, agreed here as well./home/me and/root always struck me as strange. Presumably it's so you can split them on different partitions, so it's not a meaningless distinction... but I'd rather see that handled in some other way. Perhaps by allowing something like the equivalent of "mount/dev/sda0 on/home, except don't hide/home/root".
And/sbin should be in/root logically./tmp should only be present on server installs. A distro aimed at personal use should not have it.
Hmm, I'm not sure about these. I don't know where/sbin should go. I'd sort of rather see it in/programs/system or something. And/tmp has plenty of use for personal systems... though maybe it should be a per-user directory instead.
/var should be renamed to something clear like/logs and should be present in every user folder, not globally.
This I actually disagree with. There's a lot of "system" applications who will want to log data, like Apache or something. If you've got 5 admins who all need access, why are they going dipping into some user's ~, even if it's just a "virtual" user just for Apache who doesn't actually exist?
(And on an unrelated note: let's promote the notion of ~ to the kernel level -- or at least glibc.)
/media,/mnt and other crap like that just needs to be in/dev
Strongly disagree with these./media and/mnt should be merged, but they shouldn't go in/dev (or your/devices or my/system). That directory should remain pretty much untouched by typical users, and putting mounted media there I think is the wrong idea.
I'm quite happy with a/media at the top level. (I'd also consider/removable-media or something but that's probably too verbose even for my preferences.)
That said, I think some of my objection is guided by the way I view the/system directory -- which is also why I named it as I did.
First off, logically/lib should be a subfolder in/bin since libraries are needed to make executables works and are not an entity in themselves. Rename/bin into/programs or some-such for clarity./dev,/proc and/sys also belong together though I am not sure how. Maybe under/devices. Crap like/etc should be all collected in/config or something clearly named.
I actually like pretty much all of these. I'd suggest putting/dev,/proc, and/sys together into/system./dev becomes/system/devices,/proc becomes/system/processes (actually I'd be OK with keeping the abbreviation and using/system/proc), and/sys becomes... well, something. We're closer anyway.:-)
Make a/users folder. This would contain all user info.
To be honest, I think/home is still fine, though I wouldn't object to/users.
This is where/root belongs logically.
Yeah, agreed here as well./home/me and/root always struck me as strange. Presumably it's so you can split them on different partitions, so it's not a meaningless distinction... but I'd rather see that handled in some other way. Perhaps by allowing something like the equivalent of "mount/dev/sda0 on/home, except don't hide/home/root".
And/sbin should be in/root logically./tmp should only be present on server installs. A distro aimed at personal use should not have it.
Hmm, I'm not sure about these. I don't know where/sbin should go. I'd sort of rather see it in/programs/system or something. And/tmp has plenty of use for personal systems... though maybe it should be a per-user directory instead./var should be renamed to something clear like/logs and should be present in every user folder, not globally.
This I actually disagree with. There's a lot of "system" applications who will want to log data, like Apache or something. If you've got 5 admins who all need access, why are they going dipping into some user's ~, even if it's just a "virtual" user just for Apache who doesn't actually exist?
(And on an unrelated note: let's promote the notion of ~ to the kernel level -- or at least glibc.)/media,/mnt and other crap like that just needs to be in/dev
Strongly disagree with these./media and/mnt should be merged, but they shouldn't go in/dev (or your/devices or my/system). That directory should remain pretty much untouched by typical users, and putting mounted media there I think is the wrong idea.
I'm quite happy with a/media at the top level. (I'd also consider/removable-media or something but that's probably too verbose even for my preferences.)
That said, I think some of my objection is guided by the way I view the/system directory -- which is also why I named it as I did.
They also contribute to why you need a package manager in the first place, because adminning a Unix system without one is a PITA. Want to upgrade a package? Have fun. Especially if it doesn't provide a "make uninstall" -- which is more common than it should be. If you had a separate directory and just wanted to replace it, that'd also be easy: just delete the old directory and install the new version. The other reason to have one is to do resolution of dependencies, and of course this is still very relevant if you have separate directories. But package managers could be a lot simpler if that was their sole task.
This paragraph is pretty poorly worded. Let me try again:
Dumping every binary in/usr/bin, every library in/usr/lib, etc contributes to why you need a package manager in the first place, because adminning a Unix system without one is a PITA. Want to upgrade a package? Have fun. Especially if it doesn't provide a "make uninstall" -- which is more common than it should be. If you had a separate directory and just wanted to replace it, that'd also be easy: just delete the old directory and install the new version. The other reason for package managers is to do resolution of dependencies, and of course this is still very relevant if you have separate directories. But package managers could be a lot simpler if that was their sole task.
Please, pick one place and make everyone migrate their data there!
You can support this effort by finding a developer of a Linux program and hitting them over the head with a rubber chicken until they make it so they read configuration information from either ~/.config/frobinator.conf or ~/.config/frobinator/whatever.
(I have seriously thought about writing an LD_PRELOAD library that redirects any access to a file named ~/.something to ~/.config/something, but that seems... dangerous.)
Heck, nowadays all you need is Windows 7 and one such game and you'll be pushing 30 GB. Windows is what, 15 GB? (My Windows directory is actually a little over 22 GB, but I'm not sure that's a fair comparison.) Portal 2 is 12 GB. Boom, 27 GB, conservatively. Starcraft 2: 9.4 GB. Mass Effect 2? 11.4 GB.
I think the idea of keeping track of what files belong to what package is the job of the package manager, not the filesystem layout.
It's amazing to me how un-Unix like Unix can be sometimes and still have its adherents saying it's doing the right thing.:-)
Unix already has tools for dealing with anything you could imagine (okay, not true, but work with me) regarding the file system. Why should I need an entirely different set of tools for dealing with packages?
(I sort of said this already in reply to another of your posts, but I liked my opening line and thought of it only after submitting that.:-) )
I'm pretty much as big of a Windows fan as anyone on Slashdot, but that still makes me cringe.:-)
I think that every, say, 10 years, everyone should have to rewrite all their software and ignore backwards compatibility cruft like applications hard coding c:\windows\system32 (which is why I'm guessing they did that). Then make it illegal to run any code that has since gone through more than one rewrite (and is thus >20 years old).
(Of course I say that with my tongue pretty firmly planted in my cheek... but god damn are there some ugly things sticking around in computing because that's the way things have been for decades or because fixing them will break lots of programs etc.)
Separating files by their intended purpose, the way traditional *nix does, has some advantages.
And separating files by their package also has a lot of advantages.
For instance, keeping multiple versions side-by-side becomes basically trivial. Version 1 goes in/opt/foo-1.0 and version 2 goes in/opt/foo-2.0. It doesn't matter if the packages weren't designed to sit side-by-side, if they use the same file names, etc.; it just works.
They also contribute to why you need a package manager in the first place, because adminning a Unix system without one is a PITA. Want to upgrade a package? Have fun. Especially if it doesn't provide a "make uninstall" -- which is more common than it should be. If you had a separate directory and just wanted to replace it, that'd also be easy: just delete the old directory and install the new version. The other reason to have one is to do resolution of dependencies, and of course this is still very relevant if you have separate directories. But package managers could be a lot simpler if that was their sole task.
For instance, how many package managers can you use without root? (The answer is approximately zero. I believe none of the big ones -- Apt, Emerge, Yum/RPM, etc. -- support it.) Now imagine an alternative world where software was built to install in a more Windows or (even better) OS X-like way -- now it doesn't matter what your package manager runs as. It just downloads any missing dependencies and extracts them to wherever you tell it to. If you have permission, it succeeds. And because the packages are built so that you can put them anywhere -- in contrast to now where they are usually built so they won't work outside of/usr/bin or whatever the maintainer decides -- they work.
On a more philosophical level, isn't one of the benefits of Unix's "everything's a file" and "everything uses text for configurations and to communicate" approaches supposed to be that you can use the same tools for everything? If you want to edit a configuration file, you've got grep and sed and all that jazz to edit them. But now we have this second class of entity -- the package. And I can't use du on it. And I can't use rm on it. I have to go through the package manager because nothing else knows about what the packages are.
I've got first-hand working with a system that has this sort of organization. What is basically the IT dept for the CS department here maintains a network file system with programs in our/s directory. Here is just some of the output of running: ls -d/s/a*:
Furthermore, there's another file system that pretty much anyone can install programs to. (You need to get a role that lets you do this, but it's pretty freely given out, at least to grad students.) I've put a number of programs there. That's organized in much the same way.
The whole system works beautifully. I find it way better than the typical Unix organization. The only thing that would make it better is if we didn't have to manually resolve dependencies ourselves and then compile everything.
${deity} help us all when Ubuntu changes names to "/user files/local files/et-cetera/my configurations/my apache configuration" in a moment of complete insanity...
Personally I await that day with bated breath; I should be able to use spaces in file names and not worry about buggy scripts breaking because of it.
Computers are for people to use. And_there's_a_reason_we_don't_write_sentences_like_this.
OS X also supports self-contained app bundles insensitive to FS location, such that "installation" is just copying or moving the bundle (a single directory with stuff underneath it) wherever you want it to go, and uninstallation consists of deleting the bundle. Linux users often praise package management systems like RPM as if they're a great reason to run Linux, but IMO they're just bandaids which make a horribly broken design marginally tolerable to use, rather than a desirable state of affairs.
I couldn't have said this better myself. To me the fact that the typical state of affairs on Unix is you build a package with a particular --prefix, and if you want to put it somewhere else you have to rebuild it is absolutely ludicrous. It won't work if you move it from/opt/blah to/opt/blah-5.10, because/opt/blah was baked into the executables when they were built because that's what you gave as --prefix.
At least on Windows there's typically a crappy excuse for this behavior, which is that the installation usually writes some configuration information external to the install folder (in particular, in the registry), and that information isn't updated. That's not the case on Linux... the information is stuff like the rpath of the executables and who knows what.
It's like the Unix people implemented relative paths and rpath's $ORIGIN and such and then forgot that they did that.
(Of course, I also think that FS layouts like what GoboLinux gives you are way, way superior to what you get by default. GoboLinux gives you actual separate installation directories for each package (keeping related things together! what a concept!), then puts symlinks in the standard locations.)
Fortunately, he's also wrong about the last time NTFS was updated: it got some significant updates with Vista. An admittedly sucky and long-overdue symlink feature, but also the very intriguing transactional NTFS.
The latter is the sort of thing I'd actually love to see more of in the Linux world, but the Linux folks are too busy spouting off about how MS never innovates.
I can think of a few things; in particular, how good the metadata support is and whether you can seek. At least for me, both of those are more important than a 10 or 20% compression difference.
Though I strongly suspect both FLAC and AALC are pretty comparable on this point.
If it takes this long to bring production back up to schedule after a couple weeks delay,...
How long the delay is is pretty independent of the time it takes to get up to speed later. If you give me a snow globe I can break it in a couple seconds... it would take you far longer to fix.
From the second article it sounds like the plants have experienced water damage: "They asked us to speed up draining water from the plants. If it could be done in one to two months, the company expected to then take about four to six months months for repairs."
"Without this database and others like it, computers would display Greenwich Mean Time, or the time in London when it isn't on summer time. People would have to manually calculate local time when they schedule meetings or book flights.'"
Or, you know, manually specify the offset from GMT. Or set your clock to local time.
So I'm sort of right and sort of wrong. There are digit-extraction methods for pi, but according to wikipedia, they work in O(n^2) time (for the n'th digit). But it also looks like there's an algorithm to compute up to the nth digit in time O(n log(n) log(log(n))).
Which means that asymptotically, if the storage requirements of the second alogrithm don't preclude its use in those cases, there's some N for which it's actually faster to compute all of the first N digits than just do the N'th digit directly.
I think there are formulas for calculating the nth digit without knowing the previous ones. Assuming this is so, you can get a probabilistic proof very easily: just pick 100 random digits, compute their values, and check against the claim. (It may require some computational power to do this, but it should still be plenty tractable.) If they all match, you've got solid evidence it is correct.
That sounds like an awfully high number, even for normal USB
If you're counting anything that has a normal USB port, no way, especially if you count every such device that has ever been manufactured instead of requiring it to be currently in use.
This CNET article claims that there the number of cell phone subscribers hit 5 billion last year. Many of those have USB. Add in all the computers, mice, keyboards, cameras, flash drives, game consoles, controllers, etc. and 10 billion looks almost conservative.
I mean take the extreme. If it only showed you one line at once, would that be just as good because you could scroll? Of course not. (If you say "yes" then... we probably have irreconcilable differences.:-))
This is just a less extreme version of that. It's not terrible, but it's still worse than it was.
Considering the 1st amendment as absolute protection is something that I'm pretty sure has absolutely never been done. There's precedent out the wazoo for it, from defamation laws to false advertising laws to copyright laws.
Slashdot Mirror
The biggest is coordination across multiple files. Suppose I want to update both foo.txt and bar.txt simultaneously. How can I jigger around temporary files in such a way that both files are guaranteed to remain consistent? I don't think you can.
By the way, I should say that you can if you create a sort of "lock" file. When I want to do my thing, I create exclusive that lock file, move around those files in such a way that they can be backed out, sync, remove the lock file, remove the temporary files.
However, this still isn't as fully-general as a true transactional FS. Other processes running your program now cannot (legally) read the protected file if the lock file exists. This means that you can't have a long-running transaction, which you might want to do if you want to be able to read a consistent image for a long period of time. (Of course, you could solve that by making a private copy of those files -- hopefully COW -- and referring to those, but this sure is a lot of complexity in your program because the system is too lazy to provide a useful feature.)
Furthermore, I'm not sure how much isolation TxNTFS transactions provide. In particular, suppose I have a process A that's doing some edits inside a transaction, then another process B that is reading the file but the process is entirely non-transaction-aware. What you'd hope for is that A's changes aren't visible to B until commit. I suspect TxNTFS provides this though I don't know for sure. (They do state that it's full ACID.) However, my lockfile "suggestion" does not: non-transaction-aware processes (in this context, non-lockfile-aware processes) can get an inconsistent view of the files.
So I think the biggest benefit is the wrapping up thing you mention. But there are a number of other compelling benefits that I think you get from something like TxNTFS that you can't get via the temp file approach. (I'm not super familiar with all this, so I may be talking out of my ass a bit, but I would bet some reasonably small amount of money I'm right.)
The biggest is coordination across multiple files. Suppose I want to update both foo.txt and bar.txt simultaneously. How can I jigger around temporary files in such a way that both files are guaranteed to remain consistent? I don't think you can.
A smaller benefit is that you don't need temporary files. Suppose my program is working on some multi-gigabyte file in such a way that it can, consistency guarantees ignored, just update some blocks in the middle of the file and be done with it. With TxNTFS, it can just do that. Without it, if you want consistency, you now have to copy that multi-gigabyte file to a temporary file, then rewrite the blocks you want. If you're not using a COW file system, that's terribly expensive. Fortunately, while COW systems are still reasonably rare, they are increasingly common (with ZFS and Btrfs both being COW systems).
Another benefit you can get with the way transactions are implemented in Windows is better coordination across multiple entities. This is probably not very important on Linux, but is moreso on Windows. For instance, transactions can span both file system accesses and registry accesses and have ACID semantics in total. That only has some applicability to Linux. But I think that it's also possible to write a program that hooks into the Windows KTM (kernel transaction manager) to provide other transactable entities. For instance, you could imagine that a DBMS would hook into the KTM -- and then you would be able to write programs that have transactions that span both regular file system accesses as well as DB accesses through that DBMS.
I'm not sure how useful that last bit would be though. I find the actual, formal API for doing transactions (instead of doing the sort of hacky "transactions" that you have to now) as well as multi-file transactions the most important benefits.
Crap, HTML problems. Posting again for your reading ease. I'll preview this time even. :-)
First off, logically /lib should be a subfolder in /bin since libraries are needed to make executables works and are not an entity in themselves. /bin into /programs or some-such for clarity. /dev, /proc and /sys also belong together though I am not sure how. Maybe under /devices. /etc should be all collected in /config or something clearly named.
Rename
Crap like
I actually like pretty much all of these. I'd suggest putting /dev, /proc, and /sys together into /system. /dev becomes /system/devices, /proc becomes /system/processes (actually I'd be OK with keeping the abbreviation and using /system/proc), and /sys becomes... well, something. We're closer anyway. :-)
Make a /users folder. This would contain all user info.
To be honest, I think /home is still fine, though I wouldn't object to /users.
This is where /root belongs logically.
Yeah, agreed here as well. /home/me and /root always struck me as strange. Presumably it's so you can split them on different partitions, so it's not a meaningless distinction... but I'd rather see that handled in some other way. Perhaps by allowing something like the equivalent of "mount /dev/sda0 on /home, except don't hide /home/root".
And /sbin should be in /root logically. /tmp should only be present on server installs. A distro aimed at personal use should not have it.
Hmm, I'm not sure about these. I don't know where /sbin should go. I'd sort of rather see it in /programs/system or something. And /tmp has plenty of use for personal systems... though maybe it should be a per-user directory instead.
This I actually disagree with. There's a lot of "system" applications who will want to log data, like Apache or something. If you've got 5 admins who all need access, why are they going dipping into some user's ~, even if it's just a "virtual" user just for Apache who doesn't actually exist?
(And on an unrelated note: let's promote the notion of ~ to the kernel level -- or at least glibc.)
Strongly disagree with these. /media and /mnt should be merged, but they shouldn't go in /dev (or your /devices or my /system). That directory should remain pretty much untouched by typical users, and putting mounted media there I think is the wrong idea.
I'm quite happy with a /media at the top level. (I'd also consider /removable-media or something but that's probably too verbose even for my preferences.)
That said, I think some of my objection is guided by the way I view the /system directory -- which is also why I named it as I did.
First off, logically /lib should be a subfolder in /bin since libraries are needed to make executables works and are not an entity in themselves. /bin into /programs or some-such for clarity. /dev, /proc and /sys also belong together though I am not sure how. Maybe under /devices. /etc should be all collected in /config or something clearly named.
Rename
Crap like
I actually like pretty much all of these. I'd suggest putting /dev, /proc, and /sys together into /system. /dev becomes /system/devices, /proc becomes /system/processes (actually I'd be OK with keeping the abbreviation and using /system/proc), and /sys becomes... well, something. We're closer anyway. :-)
Make a /users folder. This would contain all user info.
To be honest, I think /home is still fine, though I wouldn't object to /users.
This is where /root belongs logically.
Yeah, agreed here as well. /home/me and /root always struck me as strange. Presumably it's so you can split them on different partitions, so it's not a meaningless distinction... but I'd rather see that handled in some other way. Perhaps by allowing something like the equivalent of "mount /dev/sda0 on /home, except don't hide /home/root".
And /sbin should be in /root logically. /tmp should only be present on server installs. A distro aimed at personal use should not have it.
Hmm, I'm not sure about these. I don't know where /sbin should go. I'd sort of rather see it in /programs/system or something. And /tmp has plenty of use for personal systems... though maybe it should be a per-user directory instead. /var should be renamed to something clear like /logs and should be present in every user folder, not globally.
This I actually disagree with. There's a lot of "system" applications who will want to log data, like Apache or something. If you've got 5 admins who all need access, why are they going dipping into some user's ~, even if it's just a "virtual" user just for Apache who doesn't actually exist?
(And on an unrelated note: let's promote the notion of ~ to the kernel level -- or at least glibc.) /media, /mnt and other crap like that just needs to be in /dev
Strongly disagree with these. /media and /mnt should be merged, but they shouldn't go in /dev (or your /devices or my /system). That directory should remain pretty much untouched by typical users, and putting mounted media there I think is the wrong idea.
I'm quite happy with a /media at the top level. (I'd also consider /removable-media or something but that's probably too verbose even for my preferences.)
That said, I think some of my objection is guided by the way I view the /system directory -- which is also why I named it as I did.
They also contribute to why you need a package manager in the first place, because adminning a Unix system without one is a PITA. Want to upgrade a package? Have fun. Especially if it doesn't provide a "make uninstall" -- which is more common than it should be. If you had a separate directory and just wanted to replace it, that'd also be easy: just delete the old directory and install the new version. The other reason to have one is to do resolution of dependencies, and of course this is still very relevant if you have separate directories. But package managers could be a lot simpler if that was their sole task.
This paragraph is pretty poorly worded. Let me try again:
Dumping every binary in /usr/bin, every library in /usr/lib, etc contributes to why you need a package manager in the first place, because adminning a Unix system without one is a PITA. Want to upgrade a package? Have fun. Especially if it doesn't provide a "make uninstall" -- which is more common than it should be. If you had a separate directory and just wanted to replace it, that'd also be easy: just delete the old directory and install the new version. The other reason for package managers is to do resolution of dependencies, and of course this is still very relevant if you have separate directories. But package managers could be a lot simpler if that was their sole task.
Please, pick one place and make everyone migrate their data there!
You can support this effort by finding a developer of a Linux program and hitting them over the head with a rubber chicken until they make it so they read configuration information from either ~/.config/frobinator.conf or ~/.config/frobinator/whatever.
(I have seriously thought about writing an LD_PRELOAD library that redirects any access to a file named ~/.something to ~/.config/something, but that seems... dangerous.)
Or more than 2 modern AAA video games installed.
Heck, nowadays all you need is Windows 7 and one such game and you'll be pushing 30 GB. Windows is what, 15 GB? (My Windows directory is actually a little over 22 GB, but I'm not sure that's a fair comparison.) Portal 2 is 12 GB. Boom, 27 GB, conservatively. Starcraft 2: 9.4 GB. Mass Effect 2? 11.4 GB.
I think the idea of keeping track of what files belong to what package is the job of the package manager, not the filesystem layout.
It's amazing to me how un-Unix like Unix can be sometimes and still have its adherents saying it's doing the right thing. :-)
Unix already has tools for dealing with anything you could imagine (okay, not true, but work with me) regarding the file system. Why should I need an entirely different set of tools for dealing with packages?
(I sort of said this already in reply to another of your posts, but I liked my opening line and thought of it only after submitting that. :-) )
I'm pretty much as big of a Windows fan as anyone on Slashdot, but that still makes me cringe. :-)
I think that every, say, 10 years, everyone should have to rewrite all their software and ignore backwards compatibility cruft like applications hard coding c:\windows\system32 (which is why I'm guessing they did that). Then make it illegal to run any code that has since gone through more than one rewrite (and is thus >20 years old).
(Of course I say that with my tongue pretty firmly planted in my cheek... but god damn are there some ugly things sticking around in computing because that's the way things have been for decades or because fixing them will break lots of programs etc.)
Separating files by their intended purpose, the way traditional *nix does, has some advantages.
And separating files by their package also has a lot of advantages.
For instance, keeping multiple versions side-by-side becomes basically trivial. Version 1 goes in /opt/foo-1.0 and version 2 goes in /opt/foo-2.0. It doesn't matter if the packages weren't designed to sit side-by-side, if they use the same file names, etc.; it just works.
They also contribute to why you need a package manager in the first place, because adminning a Unix system without one is a PITA. Want to upgrade a package? Have fun. Especially if it doesn't provide a "make uninstall" -- which is more common than it should be. If you had a separate directory and just wanted to replace it, that'd also be easy: just delete the old directory and install the new version. The other reason to have one is to do resolution of dependencies, and of course this is still very relevant if you have separate directories. But package managers could be a lot simpler if that was their sole task.
For instance, how many package managers can you use without root? (The answer is approximately zero. I believe none of the big ones -- Apt, Emerge, Yum/RPM, etc. -- support it.) Now imagine an alternative world where software was built to install in a more Windows or (even better) OS X-like way -- now it doesn't matter what your package manager runs as. It just downloads any missing dependencies and extracts them to wherever you tell it to. If you have permission, it succeeds. And because the packages are built so that you can put them anywhere -- in contrast to now where they are usually built so they won't work outside of /usr/bin or whatever the maintainer decides -- they work.
On a more philosophical level, isn't one of the benefits of Unix's "everything's a file" and "everything uses text for configurations and to communicate" approaches supposed to be that you can use the same tools for everything? If you want to edit a configuration file, you've got grep and sed and all that jazz to edit them. But now we have this second class of entity -- the package. And I can't use du on it. And I can't use rm on it. I have to go through the package manager because nothing else knows about what the packages are.
I've got first-hand working with a system that has this sort of organization. What is basically the IT dept for the CS department here maintains a network file system with programs in our /s directory. Here is just some of the output of running: ls -d /s/a*:
Furthermore, there's another file system that pretty much anyone can install programs to. (You need to get a role that lets you do this, but it's pretty freely given out, at least to grad students.) I've put a number of programs there. That's organized in much the same way.
The whole system works beautifully. I find it way better than the typical Unix organization. The only thing that would make it better is if we didn't have to manually resolve dependencies ourselves and then compile everything.
${deity} help us all when Ubuntu changes names to "/user files/local files/et-cetera/my configurations/my apache configuration" in a moment of complete insanity...
Personally I await that day with bated breath; I should be able to use spaces in file names and not worry about buggy scripts breaking because of it.
Computers are for people to use. And_there's_a_reason_we_don't_write_sentences_like_this.
OS X also supports self-contained app bundles insensitive to FS location, such that "installation" is just copying or moving the bundle (a single directory with stuff underneath it) wherever you want it to go, and uninstallation consists of deleting the bundle. Linux users often praise package management systems like RPM as if they're a great reason to run Linux, but IMO they're just bandaids which make a horribly broken design marginally tolerable to use, rather than a desirable state of affairs.
I couldn't have said this better myself. To me the fact that the typical state of affairs on Unix is you build a package with a particular --prefix, and if you want to put it somewhere else you have to rebuild it is absolutely ludicrous. It won't work if you move it from /opt/blah to /opt/blah-5.10, because /opt/blah was baked into the executables when they were built because that's what you gave as --prefix.
At least on Windows there's typically a crappy excuse for this behavior, which is that the installation usually writes some configuration information external to the install folder (in particular, in the registry), and that information isn't updated. That's not the case on Linux... the information is stuff like the rpath of the executables and who knows what.
It's like the Unix people implemented relative paths and rpath's $ORIGIN and such and then forgot that they did that.
(Of course, I also think that FS layouts like what GoboLinux gives you are way, way superior to what you get by default. GoboLinux gives you actual separate installation directories for each package (keeping related things together! what a concept!), then puts symlinks in the standard locations.)
Fortunately, he's also wrong about the last time NTFS was updated: it got some significant updates with Vista. An admittedly sucky and long-overdue symlink feature, but also the very intriguing transactional NTFS.
The latter is the sort of thing I'd actually love to see more of in the Linux world, but the Linux folks are too busy spouting off about how MS never innovates.
I can think of a few things; in particular, how good the metadata support is and whether you can seek. At least for me, both of those are more important than a 10 or 20% compression difference.
Though I strongly suspect both FLAC and AALC are pretty comparable on this point.
If you RTFA you'd know that he's done it since the early 80s.
Google has been using "elaborate" HTTP redirection tricks for ages.
Yep - referrer will show as NONE
That's not quite true, at least based on TFA. It says that you'll still be able to tell the search came from Google, just not what the terms are.
If it takes this long to bring production back up to schedule after a couple weeks delay,...
How long the delay is is pretty independent of the time it takes to get up to speed later. If you give me a snow globe I can break it in a couple seconds... it would take you far longer to fix.
From the second article it sounds like the plants have experienced water damage: "They asked us to speed up draining water from the plants. If it could be done in one to two months, the company expected to then take about four to six months months for repairs."
"Without this database and others like it, computers would display Greenwich Mean Time, or the time in London when it isn't on summer time. People would have to manually calculate local time when they schedule meetings or book flights.'"
Or, you know, manually specify the offset from GMT. Or set your clock to local time.
So I'm sort of right and sort of wrong. There are digit-extraction methods for pi, but according to wikipedia, they work in O(n^2) time (for the n'th digit). But it also looks like there's an algorithm to compute up to the nth digit in time O(n log(n) log(log(n))).
Which means that asymptotically, if the storage requirements of the second alogrithm don't preclude its use in those cases, there's some N for which it's actually faster to compute all of the first N digits than just do the N'th digit directly.
In the case of 'pi', the fact that most keyboards don't have a 'pi' key on them might have something to do with it.
I think there are formulas for calculating the nth digit without knowing the previous ones. Assuming this is so, you can get a probabilistic proof very easily: just pick 100 random digits, compute their values, and check against the claim. (It may require some computational power to do this, but it should still be plenty tractable.) If they all match, you've got solid evidence it is correct.
That sounds like an awfully high number, even for normal USB
If you're counting anything that has a normal USB port, no way, especially if you count every such device that has ever been manufactured instead of requiring it to be currently in use.
This CNET article claims that there the number of cell phone subscribers hit 5 billion last year. Many of those have USB. Add in all the computers, mice, keyboards, cameras, flash drives, game consoles, controllers, etc. and 10 billion looks almost conservative.
It's still slower than scanning.
I mean take the extreme. If it only showed you one line at once, would that be just as good because you could scroll? Of course not. (If you say "yes" then... we probably have irreconcilable differences. :-))
This is just a less extreme version of that. It's not terrible, but it's still worse than it was.
Considering the 1st amendment as absolute protection is something that I'm pretty sure has absolutely never been done. There's precedent out the wazoo for it, from defamation laws to false advertising laws to copyright laws.