Dotfile madness - <AUTHOR> https://0x46.net/thoughts/2019/02/01/dotfile-madness/ <comment><USER2> 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](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.

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

<comment><USER4> 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.

<comment><USER5> 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.

<comment><USER6> 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 :)

<comment><USER7> 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.

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

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

<comment><USER9> when was the last time a gaming machine is a multi-user system?!

<comment><USER10> Since when every person in a house has their own gaming PC?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> The real problem is that any app I run accesss all files I own with equal permissions. App1 and App2 shouldn't write their data to my home, or read each other's data, or, please, be able to write each other's data.

A video game can read my tax forms. WTF.

Mobile & tablet OSs solve this. Everything has to follow.

Until then, basically every app should run in a docker container. Then it can do what it wants.

<comment><USER12> _Mobile & tablet OSs solve this. Everything has to follow._

No no _no_ _NO!!!!_

Think of all the things you can't do on a mobile device that you can do on a PC, or which require ridiculous workarounds like uploading from one app to some server on the Internet and then downloading again into another. Effortless data interchange is what makes computing great, and stops proprietary walled-garden data-silos from becoming the norm.

<comment><USER13> Agreed, and we're now in serious danger of "Okay button fatigue" or whatever you'd like to call it.

If every normal app has to ask for permission to use your disk, you're just going to click "Okay" when malware asks. Then the whole system was for naught.

<comment><USER14> So just don't do that. The application needs an "Open" dialog already so you can tell it what files to open, just have that dialog be a process run by the system instead of the application, treat the permission as implicit since the user is the one selecting the file, and pass a handle back to the application.

<comment><USER15> E.g. Flatpak has the concept of "Portals" for that: [https://github.com/flatpak/flatpak/wiki/Portals](https://github.com/flatpak/flatpak/wiki/Portals)

</comment></comment></comment></comment></comment><comment><USER16> One thing I've been thinking about is that it would be nice to tag files with the program that created them. Aside from the clutter in my home directory, I have a lot of files that I have to guess as to where they originated from based on metadata like modification timestamps or permissions, but it would be nice to see something like "~/.config was created by some-tool".

<comment><USER17> A general tagging mechanism, reasonably supported _across filesystems_ , would be great to have. Not only for media collections.

It's not easy to implement nicely, though.

<comment><USER18> Why wouldn't it to be easy to implement? You could probably make a global LD_PRELOAD library that hooks into all open() CREAT calls and tags the inode's xattr with the program that created the file. You could use an attribute like, user.created_by.

<comment><USER19> Programs can use programs like 'touch' to create the files so you'd have to get meta into a chain of process ownership or something while exempting the user's shell.

<comment><USER20> Have you seen actual programs (not shell scripts) that do that? I've heard of code smells, but that's a programmer smell with there.

<comment><USER18> I think touch is a generic example, but not a practical one. The idea is that program A can launch program B, and you'd have to recursively search for the parent. But it's not easy to find which parent is the true owner, maybe an exception can be made for init but shells can't have that exception as they are sometimes the owner.

</comment></comment></comment></comment></comment></comment><comment><USER21> The lack of useful names on the files is IMHO the most egregious issue. (OK using names that don't start with '.' is worse). I don't ls -A my homedir as much, but what the hell are .517827.padl? Who created .android (I don't use android and don't develop for it) etc.

These people are arrogant shitheads and I'd like to know who they are so I can avoid their software. I assume if they do crap like this their software does other nefarious things.

<comment><USER22> > These people are arrogant shitheads and I'd like to know who they are so I > can avoid their software.

Wow, this is really assuming the worst in people. It's much more likely to be ignorance because the other developer doesn't know where the file came from either (some compiler flag on a library accidentally enabled), or also doesn't ls -a in their home.

<comment><USER21> > Wow, this is really assuming the worst in people.

Yes, I am. I'm fed up with programs that spam my system without asking: install plug ins, menu items, directories on the desktop, dock items etc for "convenience" \-- it's convenient for them, not me. It's especially painful when I _pay_ for an app and it sprays shrapnel through my filesystem.

> It's much more likely to be ignorance

Indeed, but if they can't be bothered to learn basic system hygiene how can I be confident the rest of their package is safe to use?

A big driver for sandbox/containers in user systems is not protection against malign actors per se but against the lazy and ignorant.

Have I written bugs into code? Of course I have, I'm human. But at least I _try_ to get things right up front; to be a good citizen.

(there are additional reasons for containers in server systems, hence my qualification of "user systems" above).

</comment></comment></comment><comment><USER23> A lot of other people have made some fantastic points here, so I won't harp on "putting random crap in ~/ bad!" any further.

However, since it has not been mentioned, I would like to shout out to the Python "appdirs" module[1], which neatly solves this issue for those writing programs in Python with minimal effort. The best part is that it uses the platform's native standards, so XDG on Linux, plus whatever macOS and Windows call their implementations.

Sadly I am not aware of comparable options for other programming languages. I think having high-quality easy to use libraries for this sort of thing would go a long way.

1 - [https://pypi.org/project/appdirs/](https://pypi.org/project/appdirs/)

<comment><USER24> In C# and other .NET languages, you'd use this:

[https://developers.redhat.com/blog/2018/11/07/dotnet- special...](https://developers.redhat.com/blog/2018/11/07/dotnet-special- folder-api-linux/)

Many of these are named Windows-centric because of the history of the API. But where possible, they still map to something reasonable elsewhere. Looking at the mapping table, I can't think of anything it doesn't cover.

</comment></comment><comment><USER25> Related pet peeve: macOs '.DS_Store' files. Can someone better-informed than me please explain how to prevent heir creation? Barring that, I'd settle for a justification.

<comment><USER26> They're a bug/feature from the early days of OS X. Apple should have done the work of storing directory metadata in something like ~/Library/Preferences/com.apple.finder.plist but they were too busy getting anything at all to work.

This is the type of low hanging fruit that Apple evidently doesn't care about anymore, but would go really far towards improving user sanity. It's like when you go to a restaurant and order the cheapest thing on the menu as a way to gauge the overall quality of the food there.

<comment><USER27> Leaving it next to the files means if directories are moved, copied, or renamed, the metadata is still there. So you or I might prefer it to live in a separate file under ~/ but I cannot say littering the whole tree with the metadata buys nothing or can't serve a purpose.

<comment><USER26> macOS knows when files and directories are moved via inodes:

[https://eclecticlight.co/2018/03/03/how-macos-tracks-your- fi...](https://eclecticlight.co/2018/03/03/how-macos-tracks-your-files-inside- the-inode/)

so I can't see any conceptual reason to keep .DS_Store.

<comment><USER28> Because macOS doesn't know when files and directories are moved _on other devices, network drives_ , etc.

Nor can it preserve that metadata across other devices, network drives, etc. without copying it across somehow; the easiest solution was to store that data in hidden files and let Finder handle their automatic transfer.

Failure of your imagination isn't failure on someone else's part.

<comment><USER26> Hmmm this is the first good argument I've heard for the existence of .DS_Store files. You get a point :-)

I'd be curious to test this, by zipping folders, copying them to other machines, etc. My gut feeling is that Apple probably missed something and it doesn't quite preserve the metadata like it should (most likely due to version incompatibilities or duplication of state somewhere else in the OS that overrides it). I'd be pleasantly surprised if it did work though.

It brings up another point however, that probably metadata is as important as data (and sometimes more important, if you look at how we organize data today). The earliest filesystems probably should have implemented multidimensional storage somehow, similar to the metadata in the BeOS filesystem. I'm not familiar with how it's implemented, and it probably also breaks when files are copied to another filesystem, unfortunately:

[https://news.ycombinator.com/item?id=12309686](https://news.ycombinator.com/item?id=12309686)

</comment></comment></comment></comment></comment></comment><comment><USER29> This kind of just sounds like more standard crazy unix/linux "someone did the wrong thing and now everyone's doing the wrong thing and it's too late to realistically fix", for which it's easier to just come up with another subversion ( _waves at the three different 'user' solutions_) like not just building a user home dir, but creating a dir inside that the user's usename as well, so that ~ is for all the bullshit dotfiles and ~/yourusername is actually your data. And then someone will no doubt come up with an alias that takes you to that dir instead of just the original homedir, like "cd `" instead of "cd ~" (and no, ~ doesn't make any more sense than ` would, it's just what we got used to)

</comment><comment><USER30> This is a symptom of a bigger problem, which is that programmer respect for resources that belong to the user is at an all-time low.

* CPU: We'll just have this web page peg the user's CPU running gobs of code because our designer wants to unnecessarily animate this thinggy or our ad network wants to mine bitcoins. (Related resource: Mobile phone battery)

* Memory: We'll just use this web framework and embedded browser that uses up 1GB of the user's RAM, for a one-window chat application we're writing because we can't be bothered to learn anything but Javascript.

* Disk/Storage: We'll just cache 20GB of easily-regeneratable internal data so the app seems faster than it is, dumping it somewhere for the user to find and clean up.

* Network Bandwidth: Our shopping cart web page load is larger than the full installation of a 2000-era video game because we have to have 6 layers of framework abstraction and taking the time to optimize/minimize it wouldn't let us release fast and "crush it" in the market!

Nobody seems to care. "Oh, Xyz is cheap, programmer time is expensive!" is the rallying cry. So let's push the cost our shitty practices to the user and make her buy more hardware.

</comment><comment><USER31> Oddly I feel completely the opposite about this topic. I think dot files in your home directory are exactly the way to go. Using the XDG standard leaves you with whatever the distro decides is the correct location for these files. While their recommendation is all in the home directory, I wouldn't put it past some of these distro developers to make some crazy /var/users/{uid}/config directory. This is important when setting up your partitions. I keep home and the system separate so that I can easily swap out the OS. Home should be the only location a user has write access.

<comment><USER32> Yeah, when I got to this:

 _To those of you reading this: I beg you. Avoid creating files or directories of any kind in your user 's $HOME directory in order to store your configuration or data._

My immediate response was pretty much "where the hell else should they put them then?"

What exactly else is the /home dir even _for_ otherwise?

The purpose of home is for user-level persistent files. Giving it access to something else means giving random programs write access to some global part of the file tree, and I'd rather not allow that except when actually necessary. As it is I hate having stuff that manual installs in /opt, or the way too many programs on Ubuntu are configured to require sudo to work.

I'm actually totally on board with more stuff that installs entirely local only, especially if it's from outside the distro's package system. I don't like stuff mangling the global tree with no clear standardized path for removal and uninstallation. At least if it's in /home, I can just delete it myself without even needing to go sudo.

And the purpose of .dotfiles in /home is because it prevents those user configuration files and other such local data from cluttering your directory when doing a plain ls for regular user files.

This article just sounds like a misunderstanding of how the file tree is even supposed to work.

<comment><USER33> > My immediate response was pretty much "where the hell else should they put > them then?"

He didn't mean to avoid $HOME as a whole. Just the root of the $HOME directory.

I too much prefer having programs write their config files to $HOME/.config/program-name instead of $HOME because it's less clutter and now I can think "ok, $HOME/.config is where all of my app's configuration is", instead of having a bunch of files littered in $HOME while other apps use $HOME/.config/file_name or $HOME/.app_name.

It bothers me that .pypirc exists in $HOME, rubygems credentials are in $HOME/.gem/credentials and Docker's credentials are in $HOME/.docker/config.json. That's 3 different location styles for an app's config file. They should all be in $HOME/.config/$app_name/relevant_file_name for whatever the config is for.

</comment></comment></comment><comment><USER34> I have long deplored the sheer amount of config files that clutter the top level of any project nowadays. .gitignore, package.json, webpack.config.js, babelrc, travis.yml, it's endless. This very short list is really the tip of the iceberg. These things need to be in a dedicated config folder.

It's so nice to see this article at the top of HN. I had long thought I was the only one who felt this way.

</comment><comment><USER35> This isn't just a Linux problem. In Windows, the users /documents folder is polluted in exactly the same way these days.

<comment><USER36> Also on macOS, where [~]/Library/ApplicationSupport is the designed and recommended place to store config files, logs, preferences and all kinds of persistent data, the home directory still gets cluttered.

It's a laziness issue, it won't be solved solely by making is easier to access the right locations on each system/platform, but that would be a step in the right direction.

<comment><USER37> I would honestly like to blacklist my home folder. Do you want to create a new file/folder? I am notified with a popup and if you ask to often I am gonna stop using that. Not really workable but one can still dream...

<comment><USER38> This is actually possible (on Linux, at least, probably Mac/Windows too) with something like selinux. It ends up being a huge headache though, both because selinux is kinda hard to configure, and because you will get a constant barrage of requests.

<comment><USER39> That sounds pretty funny, it reminds me of [UAP]([https://blog.codinghorror.com/windows-vista-security- through...](https://blog.codinghorror.com/windows-vista-security-through- endless-warning-dialogs/)).

</comment></comment></comment></comment></comment><comment><USER40> It seems to me that distros are in the right position to nudge this in the right direction. For example, Fedora did the /usr merge, moved to systemd, wayland, etc. The great dotfile cleanup would probably work by patching all packaged software to do config files the right way, plus sending the patches upstream. Then in a few release cycles this would be more or less solved.

</comment><comment><USER41> On the one hand this is annoying, on the other it's great that you can just backup your home dir and have all your files and settings in one go.

Also this annoyance is easy to solve, just make one dir in home (my is called after my name) and put all your own files in there.

<comment><USER42> So you're running everything under `/home/Epskampie/Epskampie` ?

<comment><USER43> It's /home/Epskampie/.home

</comment></comment></comment><comment><USER44> Slight tangent, but I wish there was a standardized way to tell running processes to re-read their dotfiles.

If I change my .zshrc, I have to re-source it in each running instance of zsh. Sure, I could automate this. But I'd also like the same done in vim. And in weechat. And in mpv. And in everything using GNU Readline... you get the picture.

This is probably at the top of my list _" biggest complaints that won't be resolved for numerous reasons."_ It sure would be nice though.

<comment><USER45> Some programs (I can think of Termite and Kitty) use the USR1 signal to this end.

<comment><USER46> Be careful. Some programs terminate when sent USR1.

</comment></comment></comment><comment><USER47> I don't get the problem. Why bother where dotfiles are written to? GUI file managers and userland tools hide them by default. What would I gain by having them written outside of $HOME?

<comment><USER48> It avoids the realization that you have been paying AWS to back up ~/.cache and ~/.local for the last 6 months.

<comment><USER24> The whole point of .cache is that it's supposed to be that one folder that you know you shouldn't back up. As opposed to a dozen different app-specific ones that we have today.

<comment><USER48> Yes, it's a great idea in principle -- and would be even better if its location were configurable, per the XDG spec.

My comment wasn't meant as a criticism of the basic idea of a standard directory scheme; it was a reply to someone asking why anyone would ever care about files you can't see.

</comment></comment></comment></comment><comment><USER49> I think it makes a lot of sense to have all apps run in a sandbox or container by default. Everything is segregated and easy to monitor and track what its doing.

<comment><USER50> Was thinking about that when tinkering with docker: why are volumes created outside the user's home directory by default ?

<comment><USER51> On my fedora ec2 created with a standard ami, docker doesn't work without sudo (didn't try to reconfigure, so it may if I hack), so that behavior is understandable, though not desirable.

<comment><USER50> Did you add your user to the docker group ?

<comment><USER51> Nope, just installed and started to use.

</comment></comment></comment></comment></comment><comment><USER52> I definitely have looked at my home directory in awe at the number of dot files, but I think the article is a bit hyperbolic. I get that it's "clutter" but I think the simplicity of storing configuration in $HOME might be worth that trade-off.

Even the $XDG_ env variables still require the user to set that up, or the OS maintainer needs to set it up. If the OS maintainer sets it up, the user probably won't know where to find configuration.

The reason $HOME is so commonly used is because the developer knows with almost 100% certainty that the unprivileged user will 1) be able to read/write to it without superuser privileges and 2) it keeps all configuration data contained in the user's home directory for portability, instead of throwing it all over the file system in locations nobody will know.

That portability will come in handy when you're backing up or restoring from backups, which I just did yesterday. It means restoring is as simple as copying your entire home directory back. I don't need to tell each app where my configuration is, it just knows it will be in $HOME.

And that assumption will be correct for almost any *NIX-based operating system.

I do agree that non-dotfiles should not be created in $HOME, that is a nuisance.

<comment><USER53> You missed the point - they default to a dotfolder where all of those dotfiles go. You likely already have one!

The default is there to allow users and OS maintainers to not worry about it. It still goes in your home directory, but at least it's organised.

</comment></comment><comment><USER54> .files are very useful. I like the consistent idiom for where your "global" settings go for virtualenv, npm, tslint, flake8, git, whatever.

But it would have been so nice just to move it into a ~/cfgs or fine... even a ~/.cfgs or whatever.

I'm guessing engineers went, "ewww, I'd have to walk down the tree to find the next most relevant config file to use and then go UP into a directory when I hit home."

<comment><USER55> Most of what I use supports the XDG ~/.config directory, which is nice. But there's still some that doesn't support it.

[https://wiki.archlinux.org/index.php/XDG_Base_Directory#Hard...](https://wiki.archlinux.org/index.php/XDG_Base_Directory#Hardcoded)

</comment></comment><comment><USER56> I appreciate that this article doesn't just end with the complaint but follows through on a recommendation on how to do handle this correctly.

</comment><comment><USER57> I tend to carry $HOME around with me when I change systems. When I ls -Alr it was like opening up a time capsule, or a hope chest. The first 4 pages on a 23 line terminal had file and directory names for content old enough to buy liquor in all 50 states, old friends like .cshrc, .addressbook, .X11Startup, .nofinger, amd.home, .zirconrc, dot.signature, aub.home, and so on.

</comment><comment><USER58> > We are no longer in control of our home directories.

I can axe my home folder and rebuild it with `nixos-rebuild switch`, it's pretty minimal.

<comment><USER59> Do you mean `home-manager switch` or is there a feature in nixos to touch home folders?

<comment><USER58> I just keep my home folder in /etc/username and use this construct:

(just an example, not actual)

environment.etc = {

        "qemu/bridge.conf".text = ''allow br0'';

        "username/.inputrc".text = ''
          \$include /etc/inputrc
          "\e[A": history-search-backward
          "\e[B": history-search-forward
          set show-all-if-ambiguous on
          set completion-ignore-case on
        '';

};

to write configs into /etc proper and my home folder.

<comment><USER59> Hmm that's way radical than I thought. If I understand correctly, this is a read-only home folder. Would be interesting to use, I'll give it a try.

<comment><USER58> It's not read-only, but you need to reset the rights on it if you delete and rebuild it (chown probably can be put here [https://nixos.org/nixos/options.html#activationscripts](https://nixos.org/nixos/options.html#activationscripts))

I haven't used home-manager, but it looks like a bloated thing that I don't need in my life.

</comment></comment></comment></comment></comment><comment><USER60> Indeed!!

Some of us would like to manage our systems, and processes like backups, transfer to a new system, etc., in something resembling an orderly process.

The very concept that architects, designers, &/or programmers think it's OK to just litter our systems with their stuff wherever happens to be convenient to them to code up this afternoon is no better than people just deciding to crap wherever they feel. When I see software doing this, I automatically downgrade them in my assessment of what I want to use going forward.

The simple concept is that there are a few categories of storage used -- these should each be kept separate & independent, under the USER's control.

Why is this a difficult concept?

Program code, system-config, per-user-config, user data. A simple table of the default and user-overridden location for each.

If you as a coder have a problem with this, I really have to wonder what other complexity you will handle badly.

If this simple system is a mess, why would I expect other parts of your system to be any good?

</comment><comment><USER61> I agree. If I hit 'Ctrl-H' my lovely, clean Nautilus File Manager becomes a heinous, ugly clutter which is impossible to navigate. I've tried to delete some or move others to no avail. Please follow this standard. It's clean, organized, and beautiful. Once done, we can then tackle the next problem (I'm looking at you & Snaps Shuttleworth!).

</comment><comment><USER62> I have been fighting this but I gave up: people just don't care or are somewhat opposed, even when presented with a backword compatible patch.

Now I just mount the home directory with rewritefs and try make the mess more or less compliant to the spec. It's not ideal: it's a hack and it causes a performance hit but I can be at peace in my ~.

<comment><USER63> What were some of the reasons people opposed it?

<comment><USER62> Mainly increasing the complexity: it usually requires moving the files to three different locations and handling the migration from the old location.

</comment></comment></comment><comment><USER64> I think this is a silly complaint. These are preferences storage. The home directory is absolutely the most logical place for these.

I actually like that there are applications that actually still have preferences. My biggest pet peeves are applications WITHOUT preferences. Careful what you wish for.

<comment> pi-maker I agree that the home directory is the most logical place for files like these, but it would still be nice if they were in a consistent place. That way, if you wanted to delete your preferences for a specific application, you know exactly where to go without searching around. Personally, I think this should be enforced by the operating system instead of leaving it up to the developers.

</comment></comment><comment><USER65> I have a short, related tale.

In a long battle to be more intentional about what I keep around, I wanted ~/ to function both as my desktop and downloads directory, on both macOS and nixos. Using it like this would force me to deal with cruft quickly, and avoid crap silently piling up out of sight until its origin is forgotten (though desktops will hide the .dotfiles; those could still accumulate unnoticed).

It was easy to set this up on nixos, but I found the handful of apps dropping non-hidden files there grating. Magic folder behavior on macOS didn't work as well with this.

I ended up replacing ~/Desktop and ~/Documents with links to ~/Downloads. The naming isn't sensible, but I'm happy with how this works on both systems so far.

</comment><comment><USER66> All of this is a leftover from the days when *nix was a multiuser OS and used as such. It completely ignores the way we use machines now, with only one owner, and expectations of only one user. In fact, I can't imagine loaning my work laptop to anyone, for security reasons, nor my personal laptop, because that's just gross AND a security violation.

Computing power is so cheap now, that we don't need to share machines when working in the cloud, either. We can, and do, log into our own VMs, work on data and software and commit back to an intermediary before final merge into a shared repository.

Perhaps it's time to return to some version of single user OSes and clean up the relics left behind by no-loner-needed multiuser environments.

</comment><comment><USER67> You're never going to be able to stop developers dumping their shit in ~/. The best you can do is create your own directory like ~/Data to put your stuff in. Since programs don't already know about it, it will stay clean.

</comment><comment><USER68> > Avoid creating files or directories of any kind in your user's $HOME > directory in order to store your configuration or data. This practice is > bizarre at best

I believe the article itself is an existence proof that it is in fact, not bizarre.

</comment><comment><USER69> Crazy idea: what if we were to just nest a personal directory within ~?

i.e., New standard directory `~/personal`, new environment variable, $PERSONAL.

If we could come up with a default `~` like character for globbing to `$PERSONAL` like `~` does to `$HOME`, say, `@` (obviously that isn't the char to go with and I'm not a BASH expert to be able to pick one not already occupied). All your personal dotfiles are in `~`, all your personal files are in `@`. Default `cd` without args to `$PERSONAL`. No worries about tons of files that are in `~` because you live in `@`.

<comment><USER70> I already kinda do this, ~/company for work, ~/kt for personal, and a bash scrip it's alias' and vars to make it easy

</comment></comment><comment><USER71> Same mess on Windows with the My Documents folder. I simply abandoned it, treating the folder as "My Spam From App Programmers", and keep the meaningful stuff in a totally different place.

</comment><comment><USER72> I have the opposite perspective. Dotfiles are fine, and I find the proliferation of XDG directories confusing, mostly because they're misused. Why should a game's save files be under .config? Making dotfiles under $HOME is a simple approach that's worked for a long time and that doesn't cause serious problems, and I see no need to adopt the XDG approach, which I see as overengineered.

<comment><USER73> > I find the proliferation of XDG directories confusing, mostly because > they're misused. Why should a game's save files be under .config?

A game's save should be $XDG_DATA_HOME, misuse is exactly that, misuse. I have hundreds of games installed on my linux machine and not a single one has put it's save files into my $XDG_CONFIG_HOME folder. On the other hand many DO outright ignore XDG and dump all their garbage into .game_name/.dev_name folders (looking at you Factorio). I think you are exaggerating the issue.

> Making dotfiles under $HOME is a simple approach that's worked for a long > time and that doesn't cause serious problems, and I see no need to adopt the > XDG approach, which I see as overengineered.

What exactly is over engineered here? It's just a set of environmental variables, developers ALREADY use $HOME to spam up my home directory. The only real effort a developer needs to put into this is making sure they separate their config, data and cache folders which is something most already do within their cute .program_name folders.

while maybe not "serious" I certainly do find it do be quite the problem that all user-specific program data is randomly dumped into poorly named hidden folders within my home directory. *Nix systems at a root level already divide config files into /etc, cached files into /var and /tmp, and data files into /usr. Why can't there be at least a little symmetry with how the home folder is handled?

<comment><USER72> The XDG approach _is_ over-engineered: it adds complexity and provides no benefit. What is the specific concrete advantage of putting some parts of foo's state in ~/.config/foo, some in ~/.local, and so on? All this approach does is scatter what's conceptually a single state blob across different parts of the filesystem. I dealt with this stuff in Windows for years, and we don't need it in the Unix world.

The conventional dotfile approach is just fine: there's an application and it puts state under a directory named after itself.

<comment><USER46> XDG just extends the traditional Unix approach to home directories.

$XDG_CONFIG_HOME is equivalent to /etc. It has small files you probably want to back up.

$XDG_DATA_HOME is equivalent to /var. It has potentially large files you might want to back up.

$XDG_CACHE_HOME is equivalent to /var/cache. It has potentially large files you probably don't want to back up. You can delete them if you need space.

</comment></comment></comment></comment><comment> crooked-v I just published an NPM package to help deal with this kind of thing for Electron apps and the like: [https://www.npmjs.com/package/basedirs](https://www.npmjs.com/package/basedirs)

Warning, its Windows support is all theorycraft so far (Travis CI + Windows is totally broken for Node projects right now). PRs welcome if anyone wants to give it a try.

</comment><comment><USER74> I'll take dotfile madness over registry madness. I have been trying to figure out where in the registry Visual Studio 2015 puts its install location so I can remove that registry value when I reinstall it to put it in it's default location. So far I've wasted a ton of time trying to accomplish this. A single file .VS2015 would be preferable.

<comment><USER75> There is a program for windows that does this if I recall correctly. It records every file and registry entry created during installation and allows you to compare snapshots of "before" and "after" installation.

<comment><USER74> I recorded the installation of VS2015 and it was a shocking number of files and registry values. 10's of thousands of each!

</comment></comment></comment><comment><USER76> I personally detest the whole XDG thing but lots of non-XDG applications are guilty of littering the home directory. For example, every time I use the Less pager, it creates a .lesshst file (fixable by setting "LESSHISTFILE" to "-"). Vim creates .viminfo files so I had to create an alias to it where vim equals "vim -i NONE".

</comment><comment><USER77> This is not a problem. This is the design.

It makes things completely controllable and you know where to look for configuration files.

<comment><USER78> If it was completely controllable, I'd have the ability to control where they are and put them out of my way. Lazy programmers use home as a default.

Home directories have become the *nix version of the Windows Registry.

<comment><USER77> Very likely you do have the control. You simply haven't taken the time to learn how to configure things.

<comment><USER78> Or not likely at all, since the whole point of TFA is that many popular programs do not follow specifications and user configuration.

</comment></comment></comment></comment><comment><USER79> I prefer to use `ls -lah` which always shows the dot files. It sure would be nice if these were placed in a different folder. Maybe ~/.../ to put all the things. Sure, cat ~/.bash_history would need to be cat ~/.../.bash_history which isn't as convenient.

But, I sure do agree with the frustration. My work machine has nearly a hundred hidden things. My Chrome usually downloads things to ~/Downloads/ but Firefox often likes to store the file in ~ which then is often hard to find when I jump over to a console.

I've made an effort to clean things up. Trying to set firefox to download to the Downloads folder, deleting everything personal out of the home folder. But, of course, then that just goes to prove that I do not have control of my ~ folder. I'm doing everything I can to keep my own stuff out of it. Which is sad.

</comment><comment><USER80> To me, there's a big difference between:

If you want to override the defaults of this command line program, create a .programrc file in your home directory.

and

Thanks for trying out this program, I'll just create a whole directory structure of config files and caches in your home directory.

</comment><comment><USER81> I realised that keeping a clean user home directory was futile long ago... this is not even unique to linux or *nix.

Just don't put anything you care about in home directories: in the modern world people own computers not user accounts, you likely have ultimate control over your system, therefore designate your own "home" directory, don't give the other "developers" the choice to polute it by making it non-standard.

I like to be able to nuke my user-home directory whenever I like, I achieve this without pain by additionally placing my hand picked application configurations that I care about into a read only XDG config directory.

</comment><comment><USER82> That's why I never use $HOME for personal files. All of _my_ files are in the Dropbox folder or another custom folder on my work PC. It's nonstandard, so no one litters in it besides me.

<comment><USER83> I do something similar, everything I want to keep is under /storage.

</comment></comment><comment><USER84> I have abandoned my home directory to this madness. I have a home sub folder where my actual home lives allowing for portability.

This trend is killing the usefulness and practical aspects of having a home folder.

</comment><comment><USER85> I create a "Library" directory on my machines because of this, it's not a great fix at all but it makes it a little more sane.

With this I can also more easily sync my files across machines.

</comment><comment><USER86> Yeah, great, rather than just going to the .foo directory for the foo program to find user specific state for that program I have to first figure out where the particular distribution likes to put things by default and then hunt through something like 5 different hierarchies for the foo directory.

The "old" way forced program developers to put things in a very specific place. The new way allows then to interpret the XDG standard however they want and scatter everything all over the place.

</comment><comment><USER87> node_modules and yarn.lock etc. in the location where the tool was run is a feature, not a bug. Ask any python user digging to find where pip decided to drop it this time.

<comment><USER88> I was going to say, I've been actively working with nodejs for a few years and I've never had node_modules, package-lock.json and yarn.lock in my home dir, on either Linux or macOS. If you run npm/yarn commands in your home dir for some reasons, then you should expect those files there. On the less than handful of times where I ran npm in my home dir accidentally, I make sure to immediately go and delete those files.

It's also possible that the author runs a lot of scripts from various projects from github and sometimes those scripts' authors are not careful about running npm/yarn within their projects. I guess I don't play around with OSS enough. :)

<comment><USER52> I think most of that can be chalked up to someone simply mistakenly running those commands in the wrong directory (root of $HOME). I've never heard of a JS app just randomly storing a global node_modules or yarn.lock to the root of $HOME.

</comment></comment></comment><comment><USER89> On Windows I've never put anything in C:/, yet I have a shitload of install.res.xxxx.dll files, shitload of eula.xxxx.txt files, globdata.ini, vcredist.bmp, install.ini, VC_RED.msi. In my home folder I've .QtWebEngineProcess folder (never installed qt), .mongorc.js (which is empty), .v8flags.xxxx.json, .dbshell, and so on and so on. I'm not delving into insanity which is /Program Data, Windows/Temp, or [user]/AppData

</comment><comment><USER90> Gonna say I expect to see the dot files and don't really care.

I think to be upset over that is just looking for a fight.

It works across all of my OS's, I know its config specific to the app, and if I want to jump in and get some info it is just a ~/ away...the overhead is so low I've spent more time thinking about it in this statement vs all the time ever wrestling through them or battling tribal knowledge.

I guess I just don't see a strong enough argument here.

</comment><comment><USER91> Would exporting HOME to something else (eg the xdg root/appname) prior to invoking programs solve this problem for most apps without code changes?

<comment><USER46> XDG has different roots for configuration, cache, and data files.

</comment></comment><comment><USER28> And to Linux developers who've made the jump to macOS development or are making a cross-platform port, __please __use NSFileManager to find the paths for this or that, don 't hardcode everything into Library/Application Support. Not only that, but a lot of stuff ported from Linux could stand to put things in .app bundles rather than _every bloody where_.

</comment><comment><USER92> TIL I'm using ~ in the wrong way. For me ~ was always the default place for user-level configurations and time taught me to do so: .X* .bash* .vimrc and others.

Than I create my personal folders ~/{src, docs, bin, porn, anime etc}. ~ is for temporary files I'll delete after use like windows users do with their Desktop folder.

Also my ls isn't an alias with -a flag...I'm alone here? :|

<comment><USER93> I think an issue I have with it is if I want to move the configuration to another place, the only way I can do it is via a symlink. If applications used the variables above, you would be able to easily organize things differently if you choose to.

This would also allow you to test if something there is causing issues or if you wanted to format and reset things. Just delete that directory or set the variable to another path.

I don't set ls to ls -a, but sometimes I create hidden folders and files on ~/ so it's not distracting. Scanning through a lot of things because everything is dumped there is a mess.

<comment><USER92> Indeed, without env. var we are stuck with ~ "madness"

</comment></comment></comment><comment><USER94> Not sure what the problem is -- dotfiles or other application files need to be somewhere, whether in the home directory or somewhere else (that the OS doesn't enforce but just requires by convention) makes no difference. What would really help is what another comment mentioned -- the ability to tell which modules owns a particular file -- that would be really cool.

</comment><comment><USER95> One of the advantages, though, is per-user config for the same program, e.g. the .bash files. It's pretty common to have separate /home and / partitions too, and less common but doable to dual-boot different distros but share the same /home partition. Which is itself actually a reason to be very careful with back-compatability of dotfiles

</comment><comment><USER96> If only everyone would just put it in the `.config` dir and be done with it. Predictable. Simple. And without shrapnel in home.

</comment><comment><USER10> Homebrew just started offering Linux support but they would put stuff under /home/linuxbrew/ but wtf is this about? Won't be using until this is fixed.

[https://docs.brew.sh/Linuxbrew](https://docs.brew.sh/Linuxbrew)

<comment><USER16> I haven't used Linuxbrew, but Homebrew is kind of finicky if you try to install anything to a non-standard folder. I remember a while back they used to say "you can change the default folder" but then later said that this was not recommended.

<comment><USER52> Yep, I tried to run mine in ~/.homebrew but gave up. I can't remember why, but stuff was breaking and it was clear Homebrew didn't want you to do it.

I've spent some of my career building packages from source and I know the assumptions you get stuck with because the app developer hard-codes certain things. So it makes sense they just go for what is most standard and expected.

</comment></comment></comment><comment><USER97> The "Serverless Framework" modified my .bashrc and for that they will never be forgiven.

</comment><comment><USER98> The title seems misleading. The problem here isn't dotfiles. The problem is that developers are using $HOME instead of a standard directory for storing user-level config files. I had never even heard of $XDG_DATA_HOME before reading this article.

</comment><comment><USER99> ~/etc would have been so nice.

<comment><USER17> Aka ~/.config.

<comment><USER37> maybe ~/etc would have sounded more "cool"

</comment></comment></comment><comment><USER100> Why should non-desktop applications follow the XDG standard? Even for applications designed for "desktop" use, the standard is questionable IMO. After all, the "Desktop" folder that OP is complaining about is an XDG recommendation.

</comment><comment><USER101> Why do we even need hidden files? Why not just put all the configuration files/directories under a single directory specifically dedicated for this and use file system attributes for all the directory-local metadata?

</comment><comment><USER102> My program is not X-based, it is not designed for Desktop. Why should XDG apply ?

</comment><comment><USER103> Wow I though this was going to be about graphing dot files and I was like what could this madness possibly be about. But hidden dot files, eg ".fileXYX" is spot on in the problems of their proliferation.

</comment><comment><USER104> So, what's gonna happen on Wayland when these X-variables aren't defined? Am I going to lose config and have to copy directories from XDG to .config/ because that's new default?

<comment><USER105> By "X-variables" you mean $XDG_CONFIG_DIRS, $XDG_DATA_DIRS etc.? They aren't related to the X server. The "XDG" is for the old name of the Freedesktop.org project (X Desktop Group) [1]. Freedesktop.org is the host for the XDG Base Directory Specification [2]. Apart from that they are also involved in Wayland. So I see no reason for worry.

[1] [https://en.wikipedia.org/wiki/Freedesktop.org](https://en.wikipedia.org/wiki/Freedesktop.org)

[2] [https://specifications.freedesktop.org/basedir- spec/basedir-...](https://specifications.freedesktop.org/basedir-spec/basedir- spec-latest.html)

</comment></comment><comment><USER106> > It is beyond me why my home directory ended up up containing a node_modules > directory, package-lock.json, a yarn.lock file (I have never even > consciously used yarn!),

Sounds like there's a bigger problem.

</comment><comment><USER107> What's the equivalent of $XDG_CONFIG_DIRS for macOS and Windows?

<comment><USER46> macOS has Application Support, Caches, and Preferences folders under /System/Library, /Library, and ~/Library. Windows has %ProgramData%, %AppData%, and %LocalAppData%.

</comment></comment><comment><USER108> I create my own "home" area so nothing messes with it.. only my stuff resides there as no program knows where it is

</comment><comment><USER109> This smacks of somebody looking for a problem. If it's not a problem when you don't look, and you have to go out of your way to look, how is it a problem?

Anything where your own way of seeing it creates the problem, and you can't describe the problem any other way, you're not ready to pitch it as a problem to other people. Find some harm independent of your perception, and then you've got a reason for people to listen.

<comment><USER28> They've explained why it's a problem. Having an alternative viewpoint on "why programs are randomly polluting my home folder, a sensitive location with my personal data, with unwanted files without leaving any trace of their origin" isn't going to help.

</comment></comment><comment><USER110> Why do programmers do this? What thought process leads to someone thinking this is a good idea?

<comment><USER111> It is safe. Everybody does it, there is .gitconfig, .ssh etc so one more would not hurt.

Until there is 500 dotfiles, some long forgotten.

</comment></comment><comment><USER112> Wouldn't a simple union mount + cron job solve this problem relatively easy?

</comment><comment><USER113> Dont forget .cache. Both chromium and firefox dump gigabytes of space there!

</comment><comment><USER114> This is the consequence of enterprise practices of hiring el-cheapo, hit-and- run contractors or outsourcing development to middlemen in "cost-efficient" regions.

End developer is inexperienced, temporary, not valued and hence his deliverables

</comment><comment><USER115> If you think this is madness, try the alternatives.

<comment><USER116> Like Windows Registry. Yay!

</comment></comment><comment><USER117> Somebody had to say it! Thank you!

</comment><comment><USER118> maybe we do need some kind of registry, tree based key-value with an API for access.

</comment><comment> git-pull My project cihai ([http://cihai.git-pull.com/](http://cihai.git-pull.com/)) and unihan-etl ([https://github.com/cihai/unihan- etl](https://github.com/cihai/unihan-etl)) both use the XDG specification.

The reason I like it is it provides directories to use across platforms (edit: Not sure about Windows), relative to the user. Since the applications download a file (UNIHAN database [1]) to bootstrap, we want to store it in the user's files, not the systems. The other thing I do that's helpful is using sqlite (which is often built with Python).

This combination gives a database, and a place to store configuration, downloaded/built files, in an organized way across systems.

The nice things XDG "standardizes" which I'm using:

$XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.

$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

$XDG_CACHE_HOME defines the base directory relative to which user specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.

Why the implementation is helpful:

It defines a common directory for cache/data/config files, with applications inside them, e.g. ~/.config/i3, ~/.config/tmuxp, rather than adding more stuff to ~/.i3, ~/.tmuxp. When standards aren't being followed, programs end up storing their configurations / data / etc all over.

Another thing is it defines directories relative to the user themselves and for the system files. Dotfiles may imply configuration / artifacts in the users home directory, it doesn't have. The thing I like is I can check for configuration in user files (for instance ~/.gtk-3.0/), then fall back on checking the system files (/etc/gtk-3.0).

The benefit of user files is they're writable out of the box, so if there's going to be any file generated that the user needs to keep (like an unzipped version of UNIHAN) that can be cached so they don't have to download it again.

(XDG Link: [https://specifications.freedesktop.org/basedir- spec/basedir-...](https://specifications.freedesktop.org/basedir-spec/basedir- spec-latest.html))

[1] [https://www.unicode.org/reports/tr38/](https://www.unicode.org/reports/tr38/)

<comment><USER72> > $HOME/.local/share

Just look at that path:

"$HOME": It's my home directory. Cool.

".local": It's in my home directory, but local to it, and not somewhere else? This doesn't make a lot of sense, but er, Okay.

"shared": For Christ's sake, what is this? It's in my home, and local within it, but also _shared_? With whom? How? Why? I give up.

Why would anyone want to do this? What concrete benefit does this path give us? What specific thing does it let you do that ~/.myprogram doesn't? The article is bad, and the XDG standard is bad. The traditional approach is fine.

<comment> git-pull Some things XDG is trying to do that's not readily apparent:

~/.local:

It's intended to be /usr/local in the user's home directory. There's a bit of a backstory here though: Linux distros don't follow `/usr/local` as well as BSD's, not much may be there.

~/.local/share:

Same idea, for /usr/local/share. But on many linux distros, this is `/usr/share`. XDG is trying to do is mirror the system directories in the user's filespace.

Let's assume there's going to be a lot of applications: they won't agree on where cache, config, and data storage is kept at within ~/.myprogram. With XDG, if someone wants to clean out all their cache files? rm -rf ~/.cache.

The other thing is: Typically the user won't be looking at ~/.local/share/myprogram - it's for data the application itself is going to use. It doesn't really count against it. What I think we will be looking at though: configuration files. That's where I think XDG is kind of original - but it's really close to what /etc is.

As for ~/.myprogram: I'd be okay with that, if it were purely configuration. But XDG serves the article writer's purpose fine: Keeping $HOME clean. I kind of think splitting between ~/.config, ~/.local/share, and ~/.cache ends up feeling more consistent with how linux/bsd organizes files.

</comment></comment></comment><comment><USER119> To name and shame some culprits (the one's who have shame, I won't name java because I won't expect them to care)

1) Mozilla

2) Gnome

3) Gimp

4) GPG

5) Thunderbird (Why is there a sep directory and not under .mozilla)

6) mplayer

I guess one reason why this occurs is that it's easier for to be carelessly cross-platform this way. Except you'd expect better from mozilla, specially because they store Windows stuff very well inside %localappdata%

<comment><USER120> Speaking of Windows, their situation is worse. I remember installing a couple of games and suddenly my "My Documents" folder had "EA", "EA Games", "Electronic arts", "Rockstar games" folders.

<comment><USER121> Games do that by design so that they can be cleanly uninstalled without removing saved games and preferences. Also you should be able to backup your documents folder and not your programs folder and be safe. A good uninstaller should ask if you want to save them and remove them if you don't.

I am not saying it is the best way. But I don't think it is malicious or lazy.

<comment><USER122> There is literally a folder in every Windows profile (Vista onwards) called "Saved Games", it should all go there.

<comment><USER123> ^ This. And the amazing thing is it's probably the _least_ common place for games to put save data. I think I've played exactly one game that ever used it.

<comment><USER124> Most likely because the proper API to get the path to that folder was vista- or-later and games preferred to be backward compatible

<comment><USER123> Okay, but now nothing supports XP, so there's no excuse!

</comment></comment></comment></comment></comment></comment></comment><comment><USER125> Files in the Linux ecosystem are a mess. Files scattered everywhere and each instance of Linux uses some different arbitrary directory scheme. We really need a reboot. New micro kernel based OS with clear directory logic and dedicated directories for applications to keep stuff.

<comment><USER126> > dedicated directories for applications to keep stuff.

That's what /opt is for!

<comment><USER127> I thought /opt was for fully self-contained applications. Sort of prehistoric version of snaps.

</comment></comment></comment><comment><USER17> What the article describes is indeed "dot file sanity".

</comment><comment><USER128> > decided to hijack the primary location designed as a storage for my personal > files.

that's the basic misunderstanding, the user folder is for everything that's not system wide on a multiuser system; it's not there for your convenience, it's there to allow programs a writable space that doesn't conflict with everyone's else.

instead of subdirectoring everything else pretending programs to follow some weird never agreed upon specification, just add a "document" folder and put your user generated content there, problem solved.

Edit: apparently even on "hacker news" the mentality of forcing everyone else into obeying instead of solving minor inconveniences the only logical way has taken hold. Not even on widows with their nice buckets and environment variables could solve this, resulting in an exposion of games, my games, three app datas, documents/pictures/videos with apps doing whatever (i.e. shadow play putting screenshots under videos) but no, Rando comes over recycling three environmental variables that are specific of a program and everyone sucks up to it ignoring all the technical, social and other issues to the approach, while shitting upon the only sensible action that can and will work.

So much for applied brains.

</comment><comment><USER129> From a user standpoint, a lot of of unrecognizable things show up if you pass that -l flag.

In my opinion, having a conventional place to look for user configuration in plain text is a _good_ thing, not a bad thing, and of course I would want it to be in the directory on my system where I'm the sole owner. As somebody else mentioned, this means backing up my personal settings and files is braindead simple, too.

Asking programmers to respect $XDG_HOME_CONFIG is not a bad idea, but it's no replacement for home directory hygiene. I believe that ultimately, cleanliness is a personal responsibility.

Edit: reduced smugness quotient while trying to preserve my argument. I apologize for the pre-edit tone issues with this post.

<comment><USER78> _The other way-- and I 'm sorry for how smug this sounds-- is to just not litter in your own home directory without cleaning it up._

How about the other way is I'll just stop using your product/service/business that doesn't respect my machine?

<comment><USER129> That's my point exactly. Most of these programs have command line flags you can pass to indicate the configuration file that should be used. Doing that, and then by default putting my configuration in the most reasonable place for it--a dotfile-- is, in my opinion, the most respectful way a programmer can treat someone's machine.

Not to mention that most of these are free and open source, so building according to convention is the best way to keep their userbase happy (as fiddlerwoaroof pointed out, $HOME was the original conventional dotfile location pre-2003.)

So if your program doesn't respect my machine (meaning allow me to configure it to prevent unwanted behavior) then yes absolutely, into the bin with it. And rm -rf its dotfiles after.

<comment><USER37> you could check if ~/.local/share and ~/.config exist. also there is a difference between files that the user is supposed to interact with and inner configuration of random apps. ~/.ssh is fine, I need to look at it for many .emacs.d is fine as is something you are expected to edit manually, but I don't even know what some of these are: .aspell.en.prepl .dmrc .dropbox .dropbox-dist .gtkrc-2.0 .joe_state .oracle_jre_usage .pdfsam .pylint.d snap .texlive2016 .wget-hsts .vscode .xdvirc

This is from a fresh install 3 months ago, do I need 2 dot-folders for dropbox?</comment></comment></comment></comment>


At Sundance, the VR Filmmaking Revolution Is Officially Underway - <AUTHOR> http://www.wired.com/2015/01/vr-filmmaking-pioneers/ <comment><USER2> Am I wrong in thinking a VR movie would be something like the experience in 'Being John Malkovich'? Even without a compelling narrative I can see that being quite enjoyable; especially for things that are difficult to do in real life - extreme sports, driving a stupidly expensive car or a tour of the ISS.</comment>


45 days later - <AUTHOR> http://www.chris-granger.com/2012/06/01/45-days-later/ <comment><USER2> Congrats, Chris! I waited until the last minute but I'm very glad to have contributed to your KickStarter. Looking forward to seeing what I can do with and without the paid license.

</comment><comment><USER3> Did this just get accepted to YC way after the deadline?

<comment><USER4> If you look at the permalink for the "YC table," that's old news.

</comment></comment><comment><USER5> Great job, Chris!</comment>


Insidious C Behavior - <AUTHOR> http://blog.adamdklein.com/?p=554

<comment><USER2> "Problem" 1 is also well-known behavior for people who actually bother to learn it properly. C being such small language, there is almost no excuse for not learning it properly if you deal with it daily. Also, some C compilers warn about signed/unsigned comparisons.

Some background on the signedness problem: <http://yarchive.net/comp/ansic_broken_unsigned.html>

</comment><comment><USER3> The problem outlined in this post is explained in chapter 2 of K&R. I sympathize with the author and I agree it's insidious but it's also a rudimentary and well known snag.

</comment><comment><USER4> Thanks to apple we have a compiler alternative, that actually helps with this problem.

      alistra@bialobrewy ~ % clang -Weverything 1.c
      1.c:6:8: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
              if(-1 < x)
                 ~~ ^ ~

<comment><USER5> GCC prints a similar warning with `-Wall`

<comment><USER4> actually with -Wextra

      alistra@bialobrewy ~ % gcc -Wextra 1.c
      1.c: In function 'main':
      1.c:6:8: warning: comparison between signed and unsigned integer expressions
      alistra@bialobrewy ~ % gcc -Wall 1.c
      alistra@bialobrewy ~ %

<comment><USER6> Yes, for some reason in gcc, -Wall enables -Wsign-compare in C++ mode, but not in C mode. Maybe too much existing C code uses those kinds of comparisons?

<comment><USER4> The fact the code uses those kinds of comparisons, doesn't mean, that it uses it properly.

</comment></comment></comment></comment></comment><comment><USER7> In example two there is no \0 that is being removed by the compiler to do the concatenation. In the C language this is perfectly valid:

      "Testing something" ": more";

      "Testing something"
      ": more";

This is still only considered one string, whether there are newlines in between or not. The translation unit is from the last semicolon to the next semicolon (overly simplified), so the compiler see this:

      "Testing something"": more";

Now it sees that there is no operator between the two "strings" and simply makes them a single string.

</comment><comment><USER6> The 2nd behavior is useful in macros, which sometimes need to do compile-time string concatenation (that might even be why it exists?).

</comment><comment><USER8> The output of "Problem 1" can actually be "yes", depending on the architecture. -1 is "all bits set" on two's complement signed integers but that's not the only integer encoding in existence. If you want "all bits set", write ~0. That's _exactly_ all bits set and defined behaviour you can rely on in a portable program as opposed to an implementation detail.</comment>


Complete Enumeration Arguments Deemed Harmful - <AUTHOR> http://mat.tepper.cmu.edu/blog/?p=6995 <comment><USER2> I've concluded that I can't just use these example problems to explain things to non-programmers without thinking about them and deciding whether they are targeted specifically at computer scientists or at the public.

For instance: the Byzantine generals problem can be understood by the public as well as scientists: it doesn't seem all that contrived, just simplified. However, the dining philosophers problem doesn't usually go down very well: it seems contrived rather than simplified. The response I usually get is something like: give them more chopsticks, DONE.

On that note, I really wish I had some lucid way of explaining that these model problems are whimsical ways of conveying the essence of a difficult abstract problem, rather than actually representing an actual concrete problem.

</comment><comment><USER3> Yes; the sheer size of the search space isn't what makes the problem hard.

Here is an obvious difference:

In sorting, we have locally correct solutions in that given any two distinct elements a, b out of the N, we know whether a is to the left or to the right of b in the final order. Moreover, for a given a, we can find, in linear time, the smallest b which is greater than a: a's successor in the sorted order. Thus sorting is no worse than quadratic. Also, we can examine any permutation of the N items and tell in one pass whether or not it is in sorted order. So _recognizing_ solutions to the sorting problem is linear.

Given any two cities, a and b out of N, we do not know which one is visited first in the shortest path, and we certainly don't know what a's successor will be in the solution. Even verifying a solution to the problem (Is this sequence of cities the shortest path?) cannot be done in polynomial time.

So, yes, the mere fact that there are N! orders to search through is by itself unconvincing about the hardness of the problem.

Lectures on it would be easy if that were the case: _Good morning everyone; today we discuss a class of so-called "NP hard" problems, which occur whenever there is a combinatorial explosion in a search space._ :)

<comment><USER4> > Even verifying a solution to the problem (Is this sequence of cities the > shortest path?) cannot be done in polynomial time.

This is a pretty funny claim to see made about one of the most famous NP- complete problems there is. As thelema314 points out, the usual certificate verifies "is this path shorter than a threshold?".

<comment><USER5> There are variations of the problem. The optimization version is NP-Hard, the decision version is NP-Complete.

</comment></comment></comment><comment><USER6> I wish I had something more to say than that this is a beautiful essay. As a mathematician, I know that communicating an understanding of what I do requires that I communicate subtleties far finer than non-technical language seems to allow (non-ambiguously). Much of the (very very little) training that mathematicians receive in popular communication teaches us to simplify or elide these distinctions; but it is nice to hear a voice warning that _over_ -simplification, that achieves apparent comprehension at the expense of later profound misunderstanding, can lie at the end of that slippery slope.

<comment><USER7> At the end of the day, language is a set of auditory approximations that allow us to share ideas that we have in our minds with others. As a philosopher, I interpret this as our inability share a complete thought, with all its intricacies and nuance, with another person. In many cases, this means it can be more accurate to imprecisely share a thought than to attempt to do so with precision - the imprecise thought doesn't paint the whole picture, but it leaves fewer unimportant details (at least in the opinion of the speaker) up for interpretation.

This is exactly why the ancient Greeks viewed philosophy and rhetoric as two sides of the same coin. This is also why I feel most engineers need better written / verbal communication skills: "soft skills" are all about when to be verbose / concise, what tone or communication methods to use in what situation, and how to read your audience to know what level of communication they need to hear.

The story from the article tells me a good deal about the interviewer and the interviewee: the interviewer has the presence of mind to understand his meaning was not getting through and how to keep that from happening in the future. The interviewee should have asked more clarifying questions if he did not understand. Misunderstanding is a two-way street; and at least in an interview, it can be helpful to see how someone reacts to a question they don't fully understand.

</comment></comment><comment><USER8> On the bright side the halting problem is not causing much trouble, since people and mathematicians willingly write programs.</comment>


6 links that will show you what Google knows about you - <AUTHOR> https://medium.com/productivity-in-the-cloud/6-links-that-will-show-you-what-google-knows-about-you-f39b8af9decc

<comment><USER2> location history is interesting: I'm showing up in places where i haven't been. Is someones using my login credentials?

<comment><USER3> Probably not. Your traffic may be getting backhauled someplace. For example, I occasionally show up as being in New York because my company is headquartered there and that's where the VPN end points terminate.</comment></comment>


Show HN: SpreadServe: QuantLib Calcs, Quandl Data, Serverized XLS with XLL and RTD - <AUTHOR> http://126.96.36.199:8888/ycb_quandl_pub.xls/Bootstrapping

<comment><AUTHOR> Designed for automated operation of pricing, risk and financial modelling spreadsheets on a server. Supports XLLs, RTD & VBA. WebSocket & RDB integrations so you can take those spreadsheets off trader desktops and share one centralized golden copy of trader developed numerical logic with all users, with no custom coding. The link shows SpreadServe running on an AWS host. Sign up for the beta at spreadserve.com if you want to play with your own copy.

</comment><comment><USER2> In order to feed the generated prices into our trading systems - what API's do you provide and what format would the data be sent in (JSON, XML etc)?

<comment><AUTHOR> Currently SpreadServe has two interfaces for building integrations with other systems: a Python API, and a socket server implemented with Tornado and the Python API. SpreadServe's internal message format is JSON, so to push market data into a pricing spreadsheet you'd code a socket client in Java, C# etc, and send JSON messages. Our RDBMS connector uses this approach, and is coded in Java. If you can code in Python then the Python API exposes more implementation options. We're planning C & Java APIs that will enable integration modules in those languages can avoid talking to the socket server.

</comment></comment><comment><USER3> I have users who are running into problems with slow performance and crashes when doing larges recalcs with 32-bit Excel on their desktops. Can SpreadServe help?

<comment><AUTHOR> Yes: enterprise server class monitoring and logging mean you have a much better chance of nailing the root cause with detailed logging and crash dumps. The scriptability of the SpreadServe environment gives you a better change of reproducing issues. However, SpreadServe can't control the internal implementation details of the 3rd party XLLs it loads. It does provide detailed logging on the behaviour of those XLLs though.

</comment></comment><comment><USER4> Can the user upload a spreadsheet and run it? Or is the setup/bootstrap more complicated? Is there any custom coding required to get it working?

<comment><AUTHOR> No custom coding required. Server side config is needed to setup any XLL the spreadsheet uses; drop the .xll on the server localFS, and add one line of plain text to a config file. Then, if a user is permissioned, they can upload on the repository page, click the 'Run' button next to the SpreadServeEngine on the dashboard page, then load the new sheet.</comment></comment>


Introduction to CoffeeScript - <AUTHOR> http://screencasts.org/episodes/introduction-to-coffeescript/

<comment><USER2> I'm porting over my UI-heavy app from JS to CS this week. The problem with CS is that there's just not enough tutorials/documentation online yet so articles like this are quite welcome. Here's a list of random CS things that took me a little figuring out:

1\. Every function returns the last operation. To not return anything, insert a blank 'return' at the end.

2\. Descending ranges just work: [10..0]

3\. You can use if(`regular JS between backticks`) / else

4\. You don't need node.js to compile CS (or LessJS)*

5\. Don't expect a 1-to-1 conversion between old JS and new CS. CS loops have lots of smart-things built-in and will look different but work just the same or better once you know what you're doing.

* CS and Less both have JS functions that accept a raw string and output compiled string. On OSX, you can use jsc + little bit of bash to compile CS and Less to JS and CSS respectively. It is such a pleasure to work in CS and Less, especially since I know the end result is clean, standard JS/CSS that works everywhere.

<comment><USER3> If you're looking for top-notch tutorials that won't take you long to get through, I'd recommend:

<http://arcturo.github.com/library/coffeescript/>

<http://railscasts.com/episodes/267-coffeescript-basics>

</comment></comment><comment><USER4> fastforward to 6:40 if you don't care to see how to install and configure coffeescript on a mac with homebrew + textmate.

</comment><comment><USER5> You can find this screencast and more on coffeescript here:

<http://www.learnivore.com/search/coffeescript>

</comment><comment><USER6> Why give up jQuery and learn another scripting language?

<comment><AUTHOR> recommendation: read the article - or - watch the movie - linked above.</comment></comment>


YourAnonCentral hijacked the news with fake stories - <AUTHOR> https://www.dailydot.com/debug/youranoncentral-anonymous-hacking-twitter/ <comment><AUTHOR> It's kind of annoying that you can't even trust the anonymous groups anymore. What's left? Vegans?</comment>


Haskell: Announcing the first class records library (2015) - <AUTHOR> http://nikita-volkov.github.io/record/ <comment><USER2> this is from 2015

(and there's been no activity on the project for 2 years)

<comment><USER3> Thanks; added year above.</comment></comment>


How Much Disruption Is Too Much Disruption? - <AUTHOR> https://medium.com/dialogue-and-discourse/how-much-disruption-is-too-much-disruption-480a988145dc <comment><USER2> High misdemeanor.</comment>


How Apple's Lightning-Plug Guru Reinvented Square's Card Reader - <AUTHOR> http://www.wired.com/design/2013/12/the-new-square-reader-a-look-at-how-gadget-guts-are-designed/?cid=co15491064 <comment><USER2> This article has several inaccuracies and fallacies.

 _The magnetic stripe on your credit card stores data in two separate bands. The old Reader grabbed from just one. With their new custom read head, Square can grab both, which makes every swipe more accurate, and more likely to work on one try._

There are three tracks on a magnetic stripe (IATA, ABA and THRIFT), the first two are used in banking. The first track stores alphanumeric data such as your name; the second track stores numerical data, namely the card number. Reading both tracks doesn't make the swipe "more accurate" at all, since there is no redundancy there.

 _On one level, developing a custom chip gave Square total control over the processes at the heart of the product: Decoding the magnetic signal from the credit card, encoding the electrical signal being sent to the smartphone, and all the encryption that happens in between._

First, the decoding of the swipe does not happen on the reader. The first version of Square sent the entire audio clip to their servers for decoding; this new version may do it on the phone. Secondly, there is absolutely no encryption between the reader and the phone, any encryption is between the phone and their servers.

 _The old version relied on a coin cell, which added around two millimeters to the overall thickness of the device. With their own chip, though, Square was able to be much more efficient in their use of power, to the point that they could draw all they needed from the smartphone via the audio jack._

An audio jack provides no power. The signal is created by electromagnetic induction. The previous version of Square used a battery to amplify that signal.

Edit: Square claims their new readers do some sort of "encryption." I am skeptical, but I had only tested the first version of the reader.

<comment><USER3> > An audio jack provides no power. The signal is created by electromagnetic > induction. The previous version of Square used a battery to amplify that > signal.

Huh? I thought that you could get a limited amount of power from the audio jack by playing a tone through it while something's connected. [http://stackoverflow.com/questions/5560867/how-to-get- electr...](http://stackoverflow.com/questions/5560867/how-to-get-electric- power-from-head-phone-jack) seems to agree.

<comment><USER4> I have similar doubts too. If an audio jack doesn't provide any power, how does it drive headphones?

<comment><USER5> Technically the 'audio out' signal isn't power. However as folks have discovered you can send an audio signal, rectify it, and _lightly_ load the audio amplifier (which will think it is driving some really crappy headphones :-)

This is like using a side effect in software to initialize a variable. Clever but not durably so.

<comment><USER6> _Technically the 'audio out' signal isn't power._

Explain? Even if we ignore losses, the 'audio out' signal does work when it drives headphones.

I understand that an AC signal does not perform work when the current and voltage are perfectly out of phase, but that does not describe audio or else there would be no power transfer to drive the transducer.

<comment><USER5> The audio amplifier is designed with certain assumptions "baked in" which are different than those of a power supplying signal pin. In the case of the headphone amplifier, there is the impedance of the headphones and the duty cycle, or power over time component. So lets say you have a "1 Watt" headphone amplifier. Generally that specifies the peak power output when reproducing a signal. However, and many folks who have sent random tones through their stereo amplifiers have experienced this, if you send a 'peak power' tone through the amplifier continuously, the output stage may not (and often does not) have the power dissipation to keep that going. Instead it overheats and shuts off. You can of course design the power amplifier to be able to dissipate its peak power output continuously, but that is not generally necessary when listening to audio from it (even if you are a severe heavy metal listener).

Something _designed_ to supply power will deliver its rated power continuously.

So the audio out signal is designed to drive headphones without distortion between a lower and upper frequency. It also has a power dissipation limit based on what the guy designing it figured you might be listening too and for how long and at what volume. If you guess wrong (as some of the imported "external speakers" for the iPhone did), you risk damaging the headphone amplifier permanently.

So "Yes" there is going to be power available in the audio out signal, how much over what time period, is not part of the externally visible specification. If you damage your phone by attempting to draw too much power they don't fix it because "technically" you were not using it in an approved way.

Does that help?

<comment><USER6> Ok, that confirms what I suspected you meant. I can agree with what you are saying; basically that an audio driver is just about the world's worst electrical power supply and thus should generally not be treated as supply. I was just a little perturbed, fearing you were trying to claim an audio signal delivers no power.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> One thing that's always confused me about the reader is the fact that there's no bracing to prevent stress on the audio jack during a swipe. Almost every merchant I've seen using the reader has some kind of silly putty or jury rigged apparatus that's designed to hold it steady and not stress the jack. Does Square provide some kind of shim now, or is this just not as big of a problem as it seems it would be (and I've seen anecdotally with quite a few merchants)?

</comment><comment><USER8> Is it common for people to still swipe cards in some counties? I pay nearly all my small purchases with RFID and bigger ones with chip and pin.

<comment><USER9> > _Is it common for people to still swipe cards in some counties?_

I think this is Square's biggest problem when it comes to global expansion. It's relatively easy for a company like Stripe to launch in Europe: fundamentally the problem is one of paperwork, negotiation, and contracts. For Square, it's all this plus hardware - EMV hardware that needs to be certified by the card issuers, and that's considerably more complex and probably can't be given away for free.

I wonder how close Square are to having an EMV solution that's cost effective and can work for them...

<comment><USER10> There's already iZettle in Europe which does Chip and PIN, and they started after Square so they've had plenty of time.

</comment></comment></comment><comment><USER11> To comment on a different aspect of the article, I really liked the use of the animated GIF to demonstrate the spring design. Loaded without plugins, high- def, and looked beautiful on the phone screen.

The perpetual auto-loop is not quite perfect, but I can't think of a better alternative. I wonder it's hardware accelerated on most phones or if its sucking battery. I assume the browser is definitely smart enough not to render it when it's off screen, but the loop is too tight to try to 'test' that by timing it while scrolling.

I'm not at home but I'm curious what the bitrate is, what tools are used to produce it. I know anigif is popular on reddit and tumblr, nice to see it getting used in this way.

</comment><comment><USER12> I appreciate the attention to detail.

> You have to make the swipe feel satisfying; you have to make it ready [sic] > accurately enough that it works the first, every time.

I don't think you _have_ to do this. I've used a number of card readers that didn't read my card the first time (or the second, or the third), and that didn't feel good at all. They still collected my money successfully :)

<comment><USER13> Sort of, but if you think about some of the businesses that use this, three or four swipes can mean longer lines at peak times, which can make some people decide to go somewhere else.

So they may not successfully collect money from people at the end of the line.

</comment></comment><comment><USER14> Very nice and everything, but if I went into a store and the payment method was via a device attached to an iPhone then alarm bells ringing "card skimmer" would be going off in my head and I'd walk out the door.

<comment><USER15> Why? Your liability is zero, your potential inconvenience is low, and there's no reason people can't skim your card info using other readers too.

<comment><USER14> Why? Because I don't want the inconvenience. If I call up and complain about unrecognised charges then my card is cancelled, then I have to wait 5 business days minimum for a new card and also a new pin to be issued. If you want my business and my money then get a proper credit card processing terminal, there are plenty of other merchants around.

</comment></comment></comment><comment><USER16> Clearly Steve and his love of simplicity (which is really hard to do well) live on even in those who have moved on.

<comment><USER17> I agree that it's hard to do. And, Steve may have fostered the school of simple, clean design, but let's not give him credit for everything now. If you ever study Chinese brush paintings, you''ll appreciate how simple and elegant they are...and these have been around for centuries.

<comment><USER16> Of course Steve learned it from his various travels and interests. The trick is getting people to agree with you.

</comment></comment></comment><comment><USER18> "how wired can ship your marketing as an article"</comment>


Ask HN: What kind of applications do you develop with Qt? - <AUTHOR> <comment><USER2> Not me - but sports training log software goldencheetah is developed using QT

Ive done some QT coding and it was ok - quite nice, plus its portable

</comment><comment><USER3> this 3d modeler

[https://github.com/shi-yan/pillow](https://github.com/shi-yan/pillow)

this web framework

[https://github.com/shi-yan/Swiftly](https://github.com/shi-yan/Swiftly)</comment>


Nebula Genomics aims to speed research and lower cost of genome sequencing - <AUTHOR> https://www.npr.org/sections/health-shots/2018/11/15/667946213/startup-offers-to-sequence-your-genome-free-of-charge-then-let-you-profit-from-i <comment><USER2> This will probably be a trend for the years to come.

Completely embracing the "you are the product" approach by giving you a service for free while openly selling your data, and giving you a share of the money they make off your data, plus control as to who it is sold to.

Some potential issues: it could backfire if your data gets in the hands of the wrong company (health insurance) or the wrong people (targeted biological attack), and how to trust the data broker in not selling your data behind your back.

<comment><USER3> IF it's what you say, then we'll have to set up some form of education to make sure people do value their data correctly, and therefore, a re in a position to negotiate with that sort of businesses.

Each time a my genome data contributes to one pill to improve the life one person, I want price of the pill P divided by number N of genomes used, divided by 100, so P/(100*N) euro on each pill sold, for my whole life.

<comment><USER4> :)

I like the idea. The other day I thought of whether it would be possible to create drug company around this premise: select a drug for a chronic illness, when that drug's patent expires, structure a company around producing that drug for a low enough price point that you can at least break even running a company that employees people and manufactures that drug. Now if prices low enough so that it undercuts competitors and is not a financial burden to patients, you have a monopoly with a real market and one that gets increased based upon the frequency of expression (if genetically based). If you can price the drug just enough to then fund a research and development department, then maybe you have an interesting business. I thought then, could you "donate" the company to the public, almost making it a public utility.

</comment></comment></comment><comment><USER5> "probably anywhere from $10 to $10,000, if you're some exceptional research resource,"

As someone who has tried to sell things which actually functions to genomics and drug companies, this is ... optimistic. Ridiculous is probably a better word. There's probably something else going on here.

<comment><USER6> ya, it's on the blockchain</comment></comment>


How Much Does Obamacare Rip Off Young Adults? We Ran The Numbers. - <AUTHOR> http://www.forbes.com/sites/scottgottlieb/2014/03/28/how-much-does-obamacare-rip-off-generation-x-we-ran-the-numbers-here-are-the-results/?partner=yahootix

<comment><USER2> I was (am?) a proponent of Obamacare, but I was really taken aback when I got our notification of what my young family's new premiums and plan would be under the ACA. Our premiums are going up 38% and our max-out-of-pocket is doubling. We are also now responsible for 20% of costs after the $3000 deductible instead of 0%.

</comment><comment><USER3> "Obamacare is asking young adults to effectively subsidize the healthcare costs of older Americans." \- so is every other goddamned healthcare system in the world, besides "Devil take the hindmost".

Low risk subsidizes high risk, but someday you will be high risk.

<comment><USER4> You know, it almost sounds like this ACA thing is some sort of insurance.

<comment><USER5> No, it sounds like it's a welfare program. If it were insurance, it would charge proportional to the expected cost of serving the relevant demographic group. But due to the "community rating" provisions, charging actuarially appropriate rates is illegal, so instead we're charging rates that are pretty much guaranteed to make health care even _more_ expensive than it was before.

<comment><USER6> I've heard the car insurance analogies which don't work very well. Perhaps a life insurance analogy would work better... Now everyone can apply and get life insurance regardless of preexisting/current conditions. To make it affordable the young and healthy will pay more than the statistical probabilities that they will die tomorrow. The elder will pay less. How is this sustainable except through ever drastically increasing premiums?

</comment></comment></comment></comment><comment><USER7> "How much does _pay as you go social program_ rip off _demographic not currently served by program_? We ran the numbers."

</comment><comment><USER8> I'm not sure whether to believe TFA, because it conforms _so exactly_ to my initial expectations when I first heard of Obamacare back in 2009. I'm not noted for any skill at predicting outcomes, so this makes me suspicious. If the government wants to transfer (even more) resources from young adult single people to older family-type people, it's going to have to pick a non-voluntary method. ISTM _taxes_ are often used for this. I know the excuse why that didn't happen: that blatant inter-generational transfers wouldn't have passed the legislative process, while this Byzantine obfuscated rat's nest for which dozens of parties can plausibly be blamed did. Maybe that's a problem?

</comment><comment><USER9> Great you pointed out healthcare is hard to solve. How do you fix it? ignoring it is not a good solution.

<comment><USER10> I dunno, maybe ask, every other developed country in the world?

Maybe after the US drops the "rah rah, we're the best fucking country in the world" bs and eats a slice of humble pie it will realize that providing healthcare to it's citizens isn't really a very difficult problem to solve.

<comment><USER11> Yes, the US healthcare system is broken. But its not as easy as you make it out to be. Look at our drug costs - they're way higher than anywhere else. Where's that money going? Largely to medical research companies. The US is, to some degree, subsidizing medical research for the rest of the world.

Now, there are a lot of places we could improve by looking to other countries. But even doing all of those things isn't going to make things as cheap here as they are everywhere else.

<comment><USER8> Drug costs are a great example of where the USA could easily improve, if the lobbyists allowed. Because they are predictable and unceasing, drug costs for chronic conditions should not be covered by an insurance regime. It's as silly as purchasing food or clothing with insurance. Of course, once actual consumers are buying, competition will drive costs down.

That isn't to say I don't have sympathy for those who need extremely expensive drugs on an ongoing basis. That is a hardship, which could be ameliorated by government payments, e.g. Medicare, Medicaid, or something similar. But there should also be a middle category, of drugs that are expensive but which most patients can reasonably afford without government assistance. Drugs in that category will tend to see swift price drops as soon as the FDA allows generic competition.</comment></comment></comment></comment>