Domain: m-arriaga.net
Stories and comments across the archive that link to m-arriaga.net.
Comments · 10
-
Sandbox needed even on Unix-style systems...Having your home directory wiped out can be devistating. (This is a bigger problem for some journaled file systems since it can be much more difficult to recover files that have been deleted.)
Since the permissions on a Unix-stle system are to allow the user to control over what they 'own ' (mainly the home directory) there's little to prevent a program run by the user from doing whatever it wants with user data. This applies to Linux, *BSD, and the commercial *nixes as well, not just OSX.
- Here's the kicker: selinux and other ACL enforcement mechanisms won't protect protect the user from these trojan programs.
In the short term there are technical 'fixes' that can help but they are not perfect. Libtrash under Linux or using a backup tool that does *not* have the same rights as the user are good CYA in the short run, though an isolated sandbox or similar tools should really be available. How to pull this off, I don't know...if you've heard of end-user tools that can pass the pointy-haired-boss test, let me know!
- Note on fast user switching: This is a crude sandbox and doesn't prevent
- that user account from being messed with in ways you may not be aware of. It also requires the user to set up this special account...something an automatic sandbox would not require.
-
Re:A couple of thoughts
Bah! Users will never figure out that 'rm' will very much eat their files. Personally, though, I find a misplaced shell redirect '> pron.txt' (Crap, I meant to overwrite plan.txt!) is even more trouble than that. Insta-wipe with no left-over data on the disk.
I'd recommend looking into libtrash. Very handy, saves stretch on your tapes -- we are keeping regular backups, right?
Another good tip that gets me sometimes is, when you use the paste buffer (explicit Ctrl-C), the originating program has to still be running to make the paste.
-
Re:the best shell script
A way to avoid completely screwing over your data when you accidentally delete stuff, I find, is to use libtrash.
It uses LD_PRELOAD to override alot of file destroying commands like unlink() or even fopen() so it sends them to a designated trash can directory instead, where you can delete them later. It's saved my files more times than I can remember. -
Re:so is everyone copying BeOS
Summary of developments:
- BeOS has a good idea
- Microsoft announces a breakthrough in file system technology (around 1996), nothing happens
- newdocms announced on Slashdot in January 2003. Integrates with KDE, so no-one cares
- Microsoft announces WinFS plans for Longhorn. Slashdot decides that Microsoft sucks.
- Initial release of Haystack from MIT. Screenshot has XP interface so no-one gives a toss
- WinFS is reviewed, Slashdot has a flame war about file system layout, and concludes that MS sucks and a database file system is a stupid idea anyway and no-one wants one
- YEDFS (Yet Another Database File System) announced calling itself "Storage". Integrates with GNOME. FLOSS community bows and worships the superiority, leadership and sheer innovativeness of the application.
-
oh wait...
... this sounds familiar. maybe newdocms ??
-
Moving on from trees
I believe the fundamental point here isn't about how to make trees work with symlinks, virtual folders etc. but finding a better paradigm for information storage.
We are accumulating more and more data on our hard drives - documents, music, photos, films etc. - and as we do so trees become less and less effective as a means to organise the data. Many of us probably have seperate photos and movies folders but suppose, for example, you've been on holiday and have a lot of photos and also a few movies you recorded while you were there. If you split these into the movies and photos folders then suddenly you break the connection between the files. If you create a holiday media folder then you can no longer rely on the photos folder to contain all your photos.
I've come across a couple of solutions to the problem. The first is what could be described as an attribute-based filing system, newdocms : files are assigned many attributes which can then be used to search and cluster the files. Unfortunately, the project seemed to die a sudden death at the end of January. Second, is Microsoft's research MyLifeBits project which has a similar concept but adds annotation and hyper-linking.
My personal view is that the answer lies somewhere in fuzzy sets but I haven't quite finished thinking things through yet...
-
Parallelizing feature requestsI think more requested features could be implemented if a competent programmer broke the features down into sub-features, which less competent programmers could implement in their spare time. I see too many projects which try to create complex features. They may eventually succeed, but even then, the sub-features might be more useful as separate parts than as a single monolithic feature.
For example, newdocms is a case of a complex feature, which could be sub-divided to make it easier for more programmers to contribute. Implementing portions of it as a lower-level kernel driver, a user-space daemon, and separate graphical UIs for GNOME, KDE, etc., rather than as a single KDE component, would be both more flexible (e.g. a user could categorize documents from the console) and easier for contributors to work on the separate pieces (assuming the interfaces between them were well defined). -
Re:Linux undelete utiilties [AC reply]
I guess that libtrash is the asnwer.
-
Re:One word: libtrash
Oops, here.
-
On the opposite side on the coin
Yes there are tools to thoroughly delete files on your computer, rather than just unlinking them when they're put in the trash, but it's the distributed nature of content these days that poses a special problem to the Ollie North's of the world.
Well, I don't think any OS has ever been short of undeletion tools - in unix, one can grep the inodes on a disk for a particular known string of a file and recover it fron a known template. Tools like gpart (a partition guesser) also easily recover those vital 512 bytes of your hard disk.
Where Unix has been lacking, behind most other systems, is the opposite - a good, reliable, trashcan. It might be interesting to note that there's now a reliable trashcan for Linux, BSD and other glibc systems th simply preloads and wraps unlink, `move and a couple of other system calls.
Since glibc is a part of the Linux Standard base, it works along with every LSB standard app. Even better, it doesn't matter whether you delete the file from KDE, GNOME, shittyunixtoolkitforhellcirca1980something or a terminal.
Anyway, check out Libtrash. And if you're a GNOME or KDE hacker, I'll give you a big hug if you use this as the default trashcan or your next release. :D