131–140 of 156 posts
Earlier quoted context omitted.
*knowledgable enough
No, 'smart' is the right word.
Earlier quoted context omitted.
No, 'smart' is the right word.
Why is that? As a long time Windows user who only recently switched to a Unix system, I was unfamiliar with dot files. Windows uses a different method to hide files. Would you call me stupid because of that? Once I gained the knowledge I needed, these files were no longer a mystery (in fact I learned that there are actually three ways to hide files in Unix systems).
Earlier quoted context omitted.
Because it was creating real directory entries that caused "." and ".." to be visible to userspace programs reading a directory, which then led to the hack in "ls" to hide them, which is where the article picks up. It also isn't that easy to roll back once userspace programs start to rely on it - for example, the assumption that the number of files in a directory is equal to st_nlink - 2 is now so widespread that it'…
Except, like, in the root.
Earlier quoted context omitted.
Why? Seems like a brilliantly simple quick solution that would be rather easy to roll back in the future and lacks any real downsides besides being a tad weird.
Because it was creating real directory entries that caused "." and ".." to be visible to userspace programs reading a directory, which then led to the hack in "ls" to hide them, which is where the article picks up. It also isn't that easy to roll back once userspace programs start to rely on it - for example, the assumption that the number of files in a directory is equal to st_nlink - 2 is now so widespread that it'…
Earlier quoted context omitted.
I counter your anecdote with my anecdote: $ find ~ -maxdepth 1 -name '.*' | wc -l 354 $ find ~/.local/ -maxdepth 1 | wc -l 3 $ find ~/.local/share -maxdepth 1 | wc -l 66 $ find ~/.config/ -maxdepth 1 | wc -l 108 $ find ~/.cache/ -maxdepth 1 | wc -l 803 $ uname Linux $ lsb_release -d Description: Ubuntu 12.04 LTS
That's interesting, and sort of disturbing. My box is not a desktop, so that's probably the difference. I still find that scheme an atrocity. When going to that length they could at least have settled for one directory (~/.appdata or whatever). Half-baked is the most polite description I can come up with.
.config can be posted online, and shared with others (like the many "dotfile" repos you'll see on github)
.local needs to be backed up, and may have private data.
.cache can be blown away (or tmpfs.)
.run MUST be blown away on restart.
This is simple, sane, and works well.
Earlier quoted context omitted.
It always did, at least in NTFS. What did not, and still does not, is to create them via Windows Explorer. You can create them just fine from the command line, or via Windows APIs.
You can create them in Windows Explorer with a little trick: type the name with a trailing dot. Entering ".vimrc." will save as ".vimrc", no trailing dot.
Earlier quoted context omitted.
OSX, because of its big corporate watchdog, and the separation of the 'GUI' layer and the unix layer, has the cleanest directory structure by far IMO. Most of the times you don't even need a manpage or google to find out how to repair a misbehaving application - just delete its plist in ~/Library/Preferences, possibly also its ../ApplicationSupport directory. The OSX defaults system is so well designed, every time I…
Why can't I reply to some comments? That comment about the new sandboxed folder structure made me realize he's right. What's going on with all those symlinks inside the container directory? This just shows to me what a bad idea sandboxing is for those kind of apps that are supposed to interoperate with the whole system. Is there even a security benefit vs. pure unix permissions if you sandbox the filesystem but then…
Isn't the point of sandboxing specifically to prevent apps interoperating with the whole system? (I've not really paid it much attention so far)
Earlier quoted context omitted.
Why can't I reply to some comments? That comment about the new sandboxed folder structure made me realize he's right. What's going on with all those symlinks inside the container directory? This just shows to me what a bad idea sandboxing is for those kind of apps that are supposed to interoperate with the whole system. Is there even a security benefit vs. pure unix permissions if you sandbox the filesystem but then…
> This just shows to me what a bad idea sandboxing is for those kind of apps that are supposed to interoperate with the whole system. Isn't the point of sandboxing specifically to prevent apps interoperating with the whole system? (I've not really paid it much attention so far)
dotfiles are not perfect, but to have this very negative vision on a feature that also helped is a bit a revisionist attempt IMHO. Dotfiles provided a poor, but at least simple way to store program-specific-user-specific configuration, since another standard was missing. After all it's a simple and decentralized system that worked very well with the concept of unix user and ACL: you write something inside your home d…
How does any of those advantages apply only to dotfiles and not just plain files?
Earlier quoted context omitted.
That's interesting, and sort of disturbing. My box is not a desktop, so that's probably the difference. I still find that scheme an atrocity. When going to that length they could at least have settled for one directory (~/.appdata or whatever). Half-baked is the most polite description I can come up with.
But all those folders are different, so a single one would be annoying (or: require two layers.) .config can be posted online, and shared with others (like the many "dotfile" repos you'll see on github) .local needs to be backed up, and may have private data. .cache can be blown away (or tmpfs.) .run MUST be blown away on restart. This is simple, sane, and works well.
When your goal is to "reduce clutter" then 2 layers would be the minimum. You make another 4(?) folders in my home-directory and call that reducing clutter?
And when I delete an app then I have to look in all of them? That is just utterly backwards for no conceivable reason.
Due to the semantics you now suddenly need a cronjob or similar abomination that traverses all home-directories and picks out stuff ("MUST" be blown away). This will by definition be fragile and have funny corner-cases in the first few iterations. Also what happens when ".run" is not blown away, like on a system that does't implement this nonsense?
The definitions are blurry and complex, many apps will get them wrong (.local vs .config etc.).
Unix already has a location for temp files. It's called /tmp.
And what the heck is going in .local anyways? When the user saves a file then he pretty surely doesn't want it buried under some dot-directory.