Hacker News Reader

Comment by nycticorax | Hacker News Reader

To me, the real problem is not the dotfiles, but the regular (i.e. non-hidden) files that applications surreptitiously create in my home folder. (Which the author does mention as being particularly bad.) dotfiles in the home folder are not a new thing on Linux (e.g. .bashrc, .profile, .emacs, etc.), even if it would be better if more applications used the XDG folders. And if I don't see them when I "ls", they don't bother me.

But nowadays, lots of applications seem to think it's OK to put normal files in my home folder without asking first. This is just outright barbarism. In particular, Ubuntu now seems like it's all-in on snaps, and if you use snaps, they create a non-hidden "snap" folder in the user's home folder. Madness! And when people complain, the devs have the gall to suggest that this is all fine:

https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053

I like the idea of snap/flatpak in the abstract, but until they get their act together, and stop creating non-hidden files in my home folder without asking first, I am never going to use snaps.

And of course, all this is on top of the new fashion for the OS to "helpfully" create Documents, Music, Video, etc folders in my home folder, and set the XDG environment variables to point to them. Noooooope.

But at least in that case the user can change the environment variables and delete the stupid folders. No such luck with ~/snap.

View on HN

This is particularly weird, since click (snap's "predecessor" at Canonical/Ubuntu) was fully XDG compliant, even encouraging developers to separate data from cache etc. (unlike flatpak which just dumps everything in ~/.local/share/[...], though that is still infinitely better than using ~/snap).

I personally don't like xdg. I have bin files from pip and other stuff in ~/.local/bin.

I have huge amounts of cache files in both .cache and .config. It's supposed to make my life easier by being able to backup .config and dump everything. but in reality this doesnt happen.

Backing up .config for just the user defined configs is a massive PITA. you have to put so many gitignore exceptions and I'm not even talking about the gigs of data all the chromium derivatives put into that folder.

Can you ln -s /tmp .cache. ?

You can try. I mount .cache as tmpfs. You need at least 500mb for your browser alone.

Browsers tend to work fine. Some apps just fail badly like rofi (command history stored there oof)

For what it's worth I also tmpfs+asd .nvm, .npm, and */node_modules, without any major headaches. I did have to fix a couple minor pathing dramas but nothing too drastic.

You can export XDG_CACHE_HOME=/tmp

> you have to put so many gitignore exceptions and I'm not even talking about the gigs of data all the chromium derivatives put into that folder

Yeah but chrome devs half-assing the trivial xdg spec doesn't mean that xdg sucks - its just not implemented properly.

I think xdg has an issue of being obtuse when I googled it a while ago, it was very confusing, and I didn't find any real definitions. However I didn't look that hard.

Freedesktop standards are nothing if not overly complicated and confusing.

I agree, you didn't look very hard.

> unlike flatpak which just dumps everything in ~/.local/share/[...]

Here you are referring to separating the config and data? Is this actually a problem? I can see how for things like games it would be valuable to have a special location for thing like saves games, like how you can move the roaming save for minecraft from a computer to another; but I never understood the net gain from splitting the application files in config/data

Config is the personal, but public data. "Data" is personal private data.

Curated configuration generally outlives data. If storage space becomes an issue, there is value in recovering storage space but config is generally small and much more important in the long term.

I just use 'exa' with --ignore-glob option to filter out unnecessary folders as 'ls' replacement and things are clean.

It also has an option to ignore entries listed in your .gitignore.

So, invest in yet another program that likely further exacerbates the issue just to sweep the underlying issue under the rug?

Yeah it is crazy when I noticed Ubuntu created a ~/snap folder that is required when anything is installed via snap. People defend placing application data/config folders in ~/ because they're old and it's always been like that, but Snap is brand new and they still neglected to follow the modern standard.

Other "new" softwares that fail to follow best-practices by putting top level files into ~/ just on my laptop are: npm, Ansible, pylint, docker, steam, rustup+cargo, vscode, IDEA IDE, Zoom, AWS CLI. These applications have no excuse.

Also I agree on the Documents, Music, Video, etc. I hate upper case letters in my folders, so when I do a reinstall I delete those and restore my backups from the lower-case versions.

You can customize those 'well known' directories.

https://www.freedesktop.org/wiki/Software/xdg-user-dirs/

The Arch wiki has more instructional docs:

https://wiki.archlinux.org/index.php/XDG_user_directories

This strongly reminds me of installing software on Windows, where most games and programs would use My Documents as a dumping ground.

It's fair to store documents and saved games in My Documents.

Much better than storing them in C:\Windows or C:\Program Files, as was the case a decade ago, before windows introduced UAC and blocked write access to these.

It's senseless to store files that don't have user-facing meaning in My Documents. I know games that use it varyingly for web caches, shader caches, binary config files, debug logs, Lua scripts, downloaded mods, and even executables. And while arguably most gamers understand what save files are, they can't be double-clicked to open them, so I don't consider them documents (Maybe this is pedantic).

All this kind of stuff is what Appdata\Roaming and Appdata\Local are supposed to be for.

Save games is a poor example.

Users often need to back them up. Backup systems often include Documents by default but not AppData.

Files in AppData are hidden, and you would not expect users to find them.

Further, many save games can be opened with a text editor just fine :)

I understand not backing up AppData/Local, but everything in AppData/Roaming is supposedly important enough to sync it over the network (if you use domains or another mechanism to give you the same Windows account on multiple computers). Any default policy which doesn't back up AppData/Roaming seems ill advised.

It's ill advised to synchronize game saves by default. Quite a few popular games generate gigabytes of saves.

My witcher saves were 10GB, until I realize that problem and deleted them, no wounder backups were slow. Skyrim is not that far off.

Pretty sure backup is already integrated in steam for these two games.

I don't know what they save but 10GB is surely not purely saved games. It's those games fault not about 'saving saved games by default'.

Nope, Witcher 1 saves are just really large (for some reason in addition to all the flags they also contain some locale data and such). 10GiB is actually pretty reasonable for a Witcher playthrough.

It's similar in the Witcher 2, 3 and Skyrim. The saves start small and they grow to 10MB as you progress in the game. I guess there is a lot of world state and items to hold in an RPG. Count a few hundred saves, manual or autosave and that's a lot of space.

In the witcher 1 there is also an uncompressed BMP thumbnail with each save that is about a megabyte. It's PNG compressed in the witcher 2. They learned from their mistake.

My "Roaming" is 12GB. I don't think Chrome and Firefox listen to that advice.

My AppData/Local is 14GB, mostly caches from Chrome, Firefox and Spotify. My AppData/Roaming is 3.3GB, mostly my emails (with my Browser's localstorage a distant second).

Chrome's cache is in AppData/Local/Google/Chrome/User Data and Firefox's cache is in AppData/Local/Mozilla/Firefox/Profiles/. The only big offender on my system is npm with a cache in AppData/Roaming/npm-cache

Thunderbird infamously places the local copy of IMAP mails (i.e. Effectively a cache) into Appdata\Roaming. It's the single largest directory I have there. Everything else is quite reasonable in size.

As noted below there's a special folder called "Saved Games" that's specifically meant for this purpose. A lot of games still don't use it.

And here I am, still wanting my save files to reside next to the games exe...

Fair enough but on multi-user systems you can surely see the value in separate save game folders?

when was the last time a gaming machine is a multi-user system?!

I'm currently typing this on a machine that's used for gaming by more than one person.

Since when every person in a house has their own gaming PC?

There's no reason there couldn't be separate per-user folders within the game's installation path for that.

Do you also store your birth certificate in your car's glovebox?

What a misleading comparison...

I don't even get what you want to say.

A game's exe dir is a long-lived but potentially replaceable thing, like a car. Saved games may be persisted across game versions, so you don't necessarily want them to be in the same directory. Admittedly not the best analogy, but was just observing that it's strange and incongruent to store the 2 together.

To be fair it's widely used now, it just took a while to adopt because of compatibility issues.

Finding the directory requires new APIs introduced in Vista and Server 2008. See SHGetKnownFolderPath

Sure but in the non-game software world we'd do a runtime check to see if the OS was Vista or later and fallback if not.

You can't do it as a runtime check. You have to compile the software with the flags to import and link to the latest windows library. The program will hard crash if run on an older version.

I just tried to use the API. I literally couldn't find a working example on the internet in 2 hours so I guess noone figured it out in a decade.

Wrote https://stackoverflow.com/a/54499257/5994461

What's wrong with calling IsWindowsVistaOrGreater[0]?

[0] https://docs.microsoft.com/en-us/windows/desktop/api/version...

You won't have the chance to call anything. If the executable is statistically linked to the latest API, the executable won't be able to load on older systems.

I'm surprised that these new IsWindows...() functions claim compatibility down to Windows 2000. Doubt microsoft knew how they would name their next release 20 years ago. A Google search indicates that they are in fact broken.

You won't be able to compile with the function imported using the modern lib (because it doesn't exist on XP) but you can conditionally link it at runtime with LoadLibrary/GetProcAddress.

If IsWindows... doesn't work then you can use the VerifyVersionInfo function directly.

Why did they have to narrow it down to games? Could just go with "Saved config (and data)", so other apps could just dump small config files which can be effectively backed up.

I haven't used My Documents for documents for years now. The directory is useless because of all the cruft, I store useful things elsewhere now.

My Documents meant as /var/tmp to me ever since it existed. Never put my own files there.

It is not okay for some application to store files in My Documents folder. If it's not MY document then it doesn't belong in My Documents.

The user folder exists for a reason. Drop your crap in there.

It hasn't been "My Documents" since Windows XP. It's just "Documents" now, so if we're taking the name literally, then any document can go there.

To be pedantic, My Documents still exists as shortcuts in the user folder.

If it's the entire game, it might be to allow kids to install the game without administrator privilege (read: parental knowledge/consent), though I agree that letting people choose would be best.

If your kid can write and execute in any directory on your system then they can run whatever software they like.

What? I'm not sure how that connects to my comment. I'm saying that some games install to "My Documents" to avoid requiring administrator privilege for users who might not have that privilege.

Sorry, definitely missed the context on that one. Why wouldn't you want to install in AppData/local?

Windows actually has the same dotfile infestation problem these days. I mean, you still get stuff in Documents that shouldn't be there, but on top of that you get apps - often Unix ports - that believe that %USERPROFILE% (i.e. one folder above Documents) is the appropriate place for their configs and such (it's not - that should also go into AppData\Local or \Roaming as needed). And they usually use a dot-prefixed name, just because.

I just looked at my Win10 profile dir, and it has 36 dot-prefixed folders, and 7 more files on top level. Offenders include .gitconfig, .rustup, and .vscode, just to name a few.

On Windows, you could move the configs elsewhere, make a symlink to them in the old place, and mark the symlink as hidden so you don't see it in explorer. Too bad this can't work on Linux because the hidden-state is encoded in the filename.

Well, the hidden-bit on Windows is really semantically equivalent to dot-prefix on Unix, and people set up their file managers to show such files for similar reasons (I don't even use Explorer, mostly). In Win10, it's even exposed as a setting in Settings | For Developers

What do you use in lieu of Explorer, out of curiosity?

15 year Mac user (re)exploring Windows due to bad hardware...

Compared to 15 years ago I think Explorer is much better now, it could be even called usable.

Nevertheless there are alternatives. One liked by many are Norton Commander alike file managers like Total Commander or even Far. I am not too much in favor of them though.

I like to use Directory Opus. It is powerful and flexible. Costs money though.

For actual file management, and generally working in the terminal, I'm firmly in the "two blue panes" club, so it's Far Manager on Windows (and Midnight Commander on Linux). Far is probably the most advanced text-mode file manager in general right now.

https://www.farmanager.com/screenshots.php?l=en

Directory Opus.

https://www.gpsoft.com.au/

That's why I just let them be and create 'Data' folder at the drive's root where no one will taint and to keep the way I want organized.

Which is sort of an improvement from the past, where user-level config data was thrown into the actual app directory in "program files." So if you ever wanted to back-up those settings, you needed to track down every single unique location for each app.

I have a slightly different pet peeve. I don't like applications that default to saving files to my home folder. I wish they would look for e.g. /home/user/Documents or whatever else seems appropriate and even semi-standardized given the type of file.

But just dropping stuff in my home directory--look, if I'm in a hurry and my defenses are down, you basically just encouraged me to clutter things up.

The last software I found that does this is a "download helper"...even though I have a Downloads folder that my distro already set up, that Chrome and Firefox know to use, this download helper thinks I want those downloads dumped in my home folder. I hope some generous person changes this behavior, meanwhile I forgot to charge it manually for the last batch and I have a bunch of cleanup to do.

That’s what the article talks about. How applications should use $XDG_DATA_HOME, $XDG_CONFIG_HOME and $XDG_CACHE_HOME and some defaults if they’re not set.

I'm not seeing it. Where does XDG define when and how an app should use:

/home/user/Documents/

/home/user/Downloads/

/home/user/Pictures/

/home/user/Videos/

Let me know what I'm missing.

I can't find "official" XDG documentation of this, but the Arch Wiki describes, for instance, the XDG_DOCUMENTS_DIR and XDG_VIDEOS_DIR environment variables:

https://wiki.archlinux.org/index.php/XDG_user_directories

It looks like maybe the "official" documentation is here:

http://user-dirs.freedesktop.org/releases/xdg-user-dirs-0.17...

But I haven't gone through that carefully.

Why would it have to define those directories in particular?

You should be able to change the default settings for these directories by changing /etc/xdg/user-dirs.defaults (system-wide) and ~/.config/user-dirs.dirs (users override)

There's no pleasing everybody.

I strongly prefer apps default to the previously used directory, and the home directory otherwise. IME apps are wrong 99% of the time when they guess their own save location.

I have great difficulty understanding why the snap developers think the excuse “it’s hard to change!” flies.

If it’s hard to change, you should’ve either fixed your architecture from the start, or thought a bit harder about the implications of magically creating a new directory in $HOME.

It shouldn't be hard to change unless the string "/snap" is hardcoded all over the codebase. There should be a function like "get_app_dir" or "get_install_dir" or some other config string lookup that doesn't use a static string.

They probably mean it's hard to migrate existing users and not break.

Same for the default gopath. That was horrifying the first time. At least you can override it.

Default gopath was just a way to let newbies get up and running quickly; it originally required you to specify where to put it. I imagine they put it at ~/go so it would be glaringly obvious. Hopefully modules will render it all moot anyway.

They put it at ~/go because that's what every official document used as the example $GOPATH, before it had a default value, so it's largely just to minimize change from what they previously recommended.

That said, for something like source code, it makes sense to go into $HOME, so I don't understand this particular complaint the other poster made.

Other people's code shouldn't be in my $HOME if I didn't put it there explicitly. If it's part of the dependencies of a project, it should be either in a cache directory of that particular project, or in the cache directory of the build tool (that preferably conforms to XDG), like all sane build tools do. GOPATH is an incomplete (thus incorrect) solution to a problem that was being solved correctly and completely in other languages (like Ruby).

It's weird that the Go developers were working in such isolation that they didn't pick up on this. All programming languages that I know of that work on modern tooling (Haskell, Rust, Node.JS, even C#!) adopted the Ruby style dependency management when it turned out to be correct years ago.

Ruby dependency and version management is as much a clusterfuck as any other language, imo.

In my comment I say that it's better than the way Go did it, and Go is switching to the Ruby style, so maybe you could add some kind of argument why it's actually not better than that in any other language?

I can't remember the last time I had a version management problem in Ruby, though the ecosystem is so stable right now not many backwards incompatible things happen any more.

The gopath still contains a pkg directory when using modules, it seems.

On Windows Golang defaults to install to C:\. Had no problems running it from Program Files instead. It's crazy that a new programming language cannot follow decades-old conventions!

Python did this until very recently too. Windows has a problem, because people expect to use those programs in the command line and the %PATH% has a size limit and is a bit difficult to set-up properly.

The sum of the length of all environment variables has to be below 32767 characters. That doesn't seem like a good excuse to save 14 characters by putting your program's folder in C:/ instead of C:/Program Files/

If you do deeply nested paths (as npm used to do) then you can run against the old MAX_PATH limit that limits paths to 260 characters, but the correct solution is to either choose a flatter directory structure or use the newer APIs that allow paths with 32,767 characters.

C:\ isn't protected by UAC like C:\Program Files, though

Steam is doing just fine writing into C:\Program Files (x86)\Steam\steamapps from an unpriviledged process. It just gives all users full rights over that folder. (whether that's a great idea is a different question, but UAC isn't a problem if you just set your access rights correctly)

This assumes the user had admin privileges to begin with

If the user never had admin priviledges then you can't install in C:\ either and the program should just install in AppData\Local (as my sibling poster correctly stated)

Steam has definitely been handling Program Files wrong for as long as Program Files has existed. It's a marvel that there isn't more historic Malware intentionally targeting Steam install paths, though it looks like that storm is brewing on the horizon as I've seen references to such malware in the process of becoming a problem.

Steam should have worked to figure out a better approach to UAC years ago. At this point it is one of several big tech debt issues with Steam that has my confidence in Valve at an all time low as a consumer.

The correct place to install local user apps is

C:\Users\username\AppData\Local

Or even better to work with localization

%LOCALAPPDATA%

I always add C:\U to my Path and store all standalone executable programs to C:\U

I also have C:\CMD for my own batch files.

Every single program should be fully contained in its own directory including all the settings,logging,configuration etc...

No touching of any common resource or repository.

It should be enough to delete single tree to fully uninstall program with all the garbage it created along the way

Most people like to separatly store data and executables for good reasons.

\Programs\VendorX\ProgramY\data

\Programs\VendorX\ProgramY\code

The problem there is "how lazy is VendorX"? With \Program Files\ Microsoft has a ton of top level ACLs to lock down access to the directories that everything just inherits by default. How much work does the OS need to do to allow something like "folders named `data` under \Programs\ have ACLs XData and `code` have ACLs YCode"? Does it need to watch for silly mistakes like Devs that localize `code` (`Código` for instance) or misspell it (`ocde` or `coode`)?

Also would make it easier to backup the program and its data or copy them to a new system.

But it seems because of the idea that some people may want to back up data and config separately, we end up with stuff scattered everywhere, with some even hidden away in the Windows Registry. Makes backups ridiculously complex.

I always thought it was because that space in “Program Files” was troublesome for a lot of programs, particularly command-line ones. IIRC, older versions of MinGW for instance would simply not work at all if installed in a path containing a space, because some of their startup scripts didn’t properly quote all parts of the path.

The last time I went near MingW I think I came across that very problem. Suffice it to say I backed off slowly and didn't go back!

Lots of programming languages and IDEs seem to do this. Rosegarden (the sequencer) and Steam (last time I tried anyway) both create folders right under my home folder as well. Barbarism is right.

Use the flatpak for Steam! It makes almost all my headaches with the platform disappear including the .steam directory.

> And when people complain, the devs have the gall to suggest that this is all fine

From my impression the answer was more "we set up things in a hurry because of deadlines and now we are stuck with this until we implement the epoch system"

Suggestion. Just do:

    mkdir ~/real_home

And use that as your real home :)

Ah, just like on Windows, where one has to create a second My Documents folder to maintain sanity.

Ew.

> And of course, all this is on top of the new fashion for the OS to "helpfully" create Documents, Music, Video, etc folders in my home folder, and set the XDG environment variables to point to them. Noooooope.

Yuuuup. It baffles me how Linux users can simultaneously complain that 'its never the year of the Linux desktop' and then at the same time rile against basic usability tenets. The average users wants/needs Documents, Pictures, Videos, etc folders, and it wants the OS to be aware and use these as such. Now I'm okay with being able to set a specific flag that doesn't make these folders during install, but by default they absolutely should be there, unless you're doing a server install.

They should not be created by default and left empty.

Well, I know that I hate them. And I know a lot of other people that hate them. And I'm pretty suspicious of 'features' that allegedly make life easier for naive users by definitely making life harder for experienced users.

And I guess I would call it a "basic usability tenet" that the computer does what I tell it to. Documents, Music, and Videos folders violate this, because if I do the seemingly-obvious thing of just deleting them, the applications that want to use them will just recreate them unless I edit ~/.config/user-dirs.dirs. So, if developers really think they need to 'help' their 'average users' by creating these folders by default, they should finish the job and honor my desire to not use them, which I've expressed by deleting the damn things.

Also, if I want to rename them, the system should honor that. E.g. if I rename "Music" to "music", applications should not then go and re-create a "Music" folder.

Or, you know, they could just simplify my life and theirs by not creating these 'special' folders in the first place.

Damn straight. Where does the system get off trying to tell me how I should organize my stuff? Keep system stuff in a folder for system stuff and the rest of the file hierarchy is mine, because it is my goddamned computer. The original Mac got this right and no one else has since.

It's always amazing to me how confident random people on the internet are that they know precisely what the average user wants.

Snaps sound good in principle and aren't a horrible solution when they work, but despite the tagline ('Snaps are universal Linux packages') it's not clear that they work well outside of Ubuntu: they aren't sandboxed unless Apparmor is present, and despite their touted 'universality' have a hard (and unnecessary) dependency on systemd.

At this point, Guix and Nix seem the most promising for cross-distro packages.

I use ubuntu 18.04 (kde) and my snap folder is /snap

I don't know how I did this.

Do you just have a /snap directory and no $HOME/snap? Normally, snap creates /snap for the binaries (shared among all users) and $HOME/snap for the per-user configuration/data files.

Running something with sudo?

I am using snap on Arch and my snap folder is /snap as well.

I'm not surprised, I left ubuntu a decade ago because their way of doing things was causing me headaches and they did not seem to care, all that seemed to matter was bug 1 : becoming microsoft in place of microsoft.

I use a tool from ESA called Snap. It defaults to ~/snap as well. Oh, the collisions.

I don't understand the whole Snap thing. Not a single snap has ever worked in any of my computers in the past 5 years (I've tried maybe 5 or 6), and they always say they'll add themselves to the system. Add where? Where are these beasts hiding?

I just «snap install pycharm» and it shows up ready for work. Never had an issue with a snap. Can’t recall where it’s stored, but that’s easy to determine with «which». This is on ubuntu 1{6,8}.04 fwiw.

Oh, I was talking about AppImage, not Snap. Sorry.

I actually tried the Snap thing too, I don't remember how it went but I would say it was bad. I think I couldn't find a way to search for packages from the CLI.

Snap search?

If you're speaking of AppImage, what do you mean by "where are they hiding"? AppImages are quite literally exactly where you put them and nowhere else.

So why do they ask me to allow them to add themselves to the system?

Probably that was appimaged, the daemon that handles some convenience things like menu integration and attempting (but usually failing) to show appimage files with icons. appimaged is entirely optional.

But nowadays, lots of applications seem to think it's OK to put normal files in my home folder without asking first. This is just outright barbarism.

If every desktop application that needed to store cross-invocation state asked for permission we'd probably say it was an invasion of bad-design huns.

%APPDATA% doesn't require permission

>And when people complain, the devs have the gall to suggest that this is all fine.

You're complaining on a really high level and nobody suggested "this is fine". They suggested "wishlist" is fine according to their definition of "if it's not immediately broken and a fix is not trivial"

If you have an issue with default folders that are quite normal in a modern desktop environment I suggest you move back to Arch or wherever you came from and install i3 again?

Sorry I do not want a directory /Documents if /docs is what i want when i want it...

It is your lucky day - there is a standard for this as well https://wiki.archlinux.org/index.php/XDG_user_directories

I've only been using Linux for around 10 years as my only desk and laptop OS and this is the first I heard of XDG user dirs! This laptop runs Arch. Thanks for the heads up.

I'll drop "/etc/papersize" in return. If you are not familiar with this and do not print to letter paper then you will find it very, very useful.

Oh wow. If this does what I think it does, I'll be forever grateful for that comment.

It really does make CUPS, Libre Office and all the rest believe you when you say "I want to print on A4, yes A4, no not fucking Letter, A4, end of!" Obviously, substitute your paper size of choice. It probably even lends itself to some form of scripting and perhaps could be changed in reaction to events from say NetworkManager. Whatever.

My life at home is now worth living every time the wife hits print. Such a simple idea - brilliant.

Maybe I'm being unfair to the snap devs. But maybe not. Comments like this don't inspire confidence:

https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053...

Also, the bug was first reported in 2016, and Mark Shuttleworth himself has commented on it. And yet it's still not fixed. That gives me the impression that the devs don't consider it super-important. Which is odd to me, since I consider not doing this kind of thing to be 'table stakes' for any application that wants me to take it seriously.

> If you have an issue with default folders that are quite normal in a modern desktop environment I suggest you move back to Arch or wherever you came from and install i3 again?

Ummm, I came from Linux before they started having default Documents, Videos, etc folders. And, like I said, the nice thing is that, in Linux, I can change the XDG environment variables and delete the (IMHO) foolish Documents, Music, Videos, etc folders.

Reply on news.ycombinator.com