It's not at all easy to understand, nor easy to implement, nor does it have any tangible advantages.
It's one of these superfluous pseudo-standards that do nothing but add needless clutter. But gladly nobody seems to be using it anyway, I see only one directory in my ~/.local: vlc.
The first benefit is that it removes clutters from your $HOME.
The second benefit is that you can now manage and backup your settings in a sane way.
* ~/.config contains config files (should not be lost, but if lost you can recreate them);
* ~/.local contains user data files (save them often, never lose them for they are not replaceable);
* ~/.cache contains cached information (can be tmpfs mounted, you can delete it any time you want, no loss in functionality, you just lose some optimization);
* ~/.run is for temporary system files (must be tmpfs mounted or it must be cleaned during at shutdown or power on).
Luckily most of the apps used on Linux systems now use it, you are probably using Mac OS X.
All of your points are invalid for a simple reason:
Almost no software uses this fancy standard.
And for the backup-case: Whitelisting is usually a futile idea to begin with. Normally you'd prefer to backup the odd superfluous file rather than miss an important one.
Luckily most of the apps used on Linux systems now use it
My box is not a desktop, so that's probably the difference. I still find that scheme an atrocity.
When going to that length they could at least have settled for one directory (~/.appdata or whatever). Half-baked is the most polite description I can come up with.
Yes, if you push me like that I'll say it: it's incompetently overdone.
When your goal is to "reduce clutter" then 2 layers would be the minimum. You make another 4(?) folders in my home-directory and call that reducing clutter?
And when I delete an app then I have to look in all of them?
That is just utterly backwards for no conceivable reason.
Due to the semantics you now suddenly need a cronjob or similar abomination that traverses all home-directories and picks out stuff ("MUST" be blown away). This will by definition be fragile and have funny corner-cases in the first few iterations. Also what happens when ".run" is not blown away, like on a system that does't implement this nonsense?
The definitions are blurry and complex, many apps will get them wrong (.local vs .config etc.).
Unix already has a location for temp files. It's called /tmp.
And what the heck is going in .local anyways? When the user saves a file then he pretty surely doesn't want it buried under some dot-directory.
When your goal is to "reduce clutter" then 2 layers would be the minimum. You make another 4(?) folders in my home-directory and call that reducing clutter?
I can see a clear and very useful difference between RUNTIME_DIR, CACHE_DIR, and CONFIG_DIR. Consider a scenario where $HOME is on a networked filesystem. RUNTIME_DIR has to be outside that, and local to the machine's namespace. That's because it references things inherently local to the machine. That is, pids and pipes. These wouldn't make sense on any other machine and will just make the application's job harder.
I also set CACHE_DIR to be local (/tmp/$USER.cache.) That's because caching performs terribly when it's flying over the network. Chrome is the main culprit for me. It also fills my file quota with hours of using it. However, it's still useful to keep that data in the medium term.
CONFIG_DIR and DATA_DIR, however, don't seem to be very different to me. I can't imagine a scenario where I want one but not the other. I might be using the wrong sort of applications. (For the record I have 8 files in .config, 10 dot files, and just 1 in .local/share.)
Due to the semantics you now suddenly need a cronjob or similar abomination that traverses all home-directories and picks out stuff ("MUST" be blown away).
Having RUNTIME_DIR on a tmpfs, like what most distributions do with /var/run, solves that problem. I map mine to /var/run/$user, even though I've yet to see an application actually use it. The spec BTW doesn't even specify the default value!
And what the heck is going in .local anyways? When the user saves a file then he pretty surely doesn't want it buried under some dot-directory.
I agree, the default values are silly. This, like most of Modern Unix, is an ugly hack which makes dealing with the rest of the ugly hacks a bit easier. If you want an elegant solution you'll probably have to throw away most of what was added during last 20 years. May I suggest starting with sockets?
> The first benefit is that it removes clutters from your $HOME.
Invisible clutter? That's a strange concept.
But the rest of your point indeed makes sense. It still is easier and probably comment to backup the whole $HOME. But those points you can see as a benefit, though not obvious.
As Rob mentions in his post, the more dotfiles there are in $HOME the slower path resolution for any subfiles becomes. How do we navigate to ./src? We open the directory and read all the entries until we find the one called "src". What happens if we encounter a morass of dotfiles beforehand? src takes a while to find. The clutter may be invisible to you, but it does gum up the works.
For what it's worth, most modern file systems (JFS, XFS, ext4, reiserfs, btrfs, ...) have logarithmic (or better) directory lookup times. This is achieved using hashes and b-trees (or even hash tables).
I consider it good practice to allow users to customize where your program creates files. I don't like $HOME to be the default dumping ground for anything I run.
A standard that uses environment variables means programs don't have to provide extra options for this customization (I've seen -f,--file , -c,--config and other variants). It allows for common code (libraries that implement the spec).
If you poke around for feature requests for various open source programs, you'll find XDG basedir compliance come up occasionally (moreso for CLI utils). I wouldn't say "nobody seems to be using it"; quick scan of my folders includes Chromium, uzbl, htop. Git's next release will be compliant too.
I don't particularly like dumping everything in home, but XDG is worse. Now, if I want to start over with a clean profile, there's a whole list of locations I have to zap. Spraying shit in three directories is worse than one.
my problem with that "one" directory is that i have to take care specifically to back it up. applications that at least use ~/.cache means i don't have to worry about backing up a bunch of useless stuff.
Consider a browser cache. /tmp is not guaranteed to be preserved between program invocations[1]. /var/tmp [2] might be a better place. /var/cache [3] is intended for exactly this kind of thing.
Unfortunately, it can be far more useful for an administrator in a multi-user setup to want user-specific caches in home directories. That way, you get all of the infrastructure for managing user data for free, like quotas.
Also note: if you're considering putting data into /tmp or /var/tmp, please honor the TMPDIR environment variable, if it is set[4].
> If you poke around for feature requests for various open source programs, you'll find XDG basedir compliance come up occasionally (moreso for CLI utils).
What fraction of those requests are by XDG advocates?
I ask because every standard comes with folks insisting that it be followed. While those folks claim to represent the interests of users, those requests are different.
I guess I should have said "a modern linux desktop environment." Are these shell boxes or desktops? In my experience the majority of propgrams that use this spec are gtk/qt programs.
PS Listing a kernel version does not really provide any information about your modern linux distro.
I am always pleasantly surprised when programs follow XDG. One notable example is the fish shell. Most shells put dotfiles in $HOME, like .bash_profile or .zshrc. Fish puts everything in .config/fish/.
Somehow .dotfiles work just fine under Windows :). As such they are somehow more "portable"
Emacs saves them under %USERPROFILE% - I have in there - .alice, .android, .easyhg, .eclipse, .gstreamer-0.10, .lighttable, .m2, .matplotlib, .... .VirtualBox, .zenmap
Also in "Application Data" - .emacs.d, .mc, .subversion
My point is - this system works somehow even under non-unixy systems.
True. I actually kinda like the Windows directory structure since Vista. If only the application devs would also follow the standard (hence the whole My Documents mess).
Incidentally, Emacs will use %UserProfile%\.emacs.d if you set %HOME% to %UserProfile%, which, as a UNIX user, I personally prefer for consistency. While not Emacs-specific, another trick I've found useful is that, on 64-bit Windows, you can open %SystemRoot%\System32\somefile in 32-bit Emacs iff you refer to it as %SystemRoot%\sysnative\somefile (the original path yields %SystemRoot%\SysWOW64\somefile).
You can create them in Windows Explorer with a little trick: type the name with a trailing dot. Entering ".vimrc." will save as ".vimrc", no trailing dot.
I would have preferred if it did not rely on environment variables since almost nobody sets them which means there will be untested code in applications implementing the specification.
I notice the $XDG_DATA_HOME environment variable isn't set in my Intrepid install. Maybe its set in later Ubuntu version.
But the value not being set for me means implies to me that it not being set is pretty common. Thus it seems like supporting this standard is going to involve supporting a fall-back of whatever you would do otherwise.
So I don't see "easy" at all but rather extra BS. Sorry.
From the spec: If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used. Similarly there's a default (.config/) defined for XDG_CONFIG_HOME. So the fallback is well-defined rather than "whatever you would do otherwise".
Also, for my 2c, you should consider updating your Intrepid install if you at all can. It hasn't been supported for over two years, so it hasn't seen any security updates in that time. The Ubuntu do-release-upgrade system is pretty easy and reliable.
To be fair, that's how it works. They have default values when they're not set. These are for when you want to override them, e.g. to keep cache files local instead of over your net mounted home directory.
"Between semicolon-free folks and JavaScript traditionalists, who gets to play the role of the expert?"
You're framing this as a disagreement between equals. It is not. There are degrees of expertise. (Total lines of production code * amount of usage) is a reasonable approximation, and those who rank highest on this scale are overwhelmingly in favor of requiring semicolons.
If Carmack and Torvalds were in agreement on a C best practice while Odesker^W^W^W^W^W^W^W Topcoder user #12571 said to do something else, I wouldn't go with the latter.
You can think about the effect of coding style instead of letting the experts think for you.
If you are doing a Topcoder round, then the random Topcoder user's advice is probably better than Carmack's. Carmack or Torvalds would probably tell you to use a variable name that gives a lot of information about its purpose, so that other people will find it easier to read your code. The Topcoder user might tell you to use a cryptic abbreviation that helps you remember a variable's purpose but clues little to the outside reader, since Topcoder users are penalized for allowing others to find their bugs. When implementing an algorithm, Carmack or Torvalds would code it as part of an extensible system with an API so that it can be used for many purposes. The Topcoder user might code it with no potential for reuse, but would do it in the way easiest to code quickly without making a mistake.
"You can think about the effect of coding style instead of letting the experts think for you."
Right, because what could those experts possibly have to teach you? Fuck that intellectual crap, brogrammers are here to crank out some code yo! Just because those dinosaurs have spent "thousands of hours" studying and trying out different programming styles and concepts means I should listen to them? This is the internet age man. Some guy in a github comment told me different and github is cool.
It's like those functional programming professors who try and talk about how continuation passing style was a bad road to go down because of maintenance problems and how difficult refactoring and just reasoning about code becomes in large systems.
Fuck that egghead noise, node.js has callbacks and node is how you get webscale.
You completely and utterly missed the point, in addition to just being needlessly rude.
The point of your parent was "don't let the experts think for you", not "screw the experts" -
that's a very important distinction. You should form your own opinions, not just uncritically
adopt the opinion of some expert. It's unquestionable that expert knowledge and experience is
important - but nothing beats forming your own (hopefully informed) opinion.
Who said "let the experts think for you"? No one. You were arguing against "give the experts' opinions more weight than others, often a lot more"
"You should form your own opinions, not just uncritically adopt the opinion of some expert."
False dichotomy again, there is a lot of ground between "uncritically adopt the opinion of some expert" and "forming your own opinion and hoping it's informed".
You should find that middle ground, it's where all the smart people are.
I didn't miss the point at all, I just completely disagree with you. I don't think it was needlessly rude either, it was sarcastic. And I feel no need to treat people who are promoting anti-intellectualism with kid gloves.
Intellectualism is not about showing off how much you agree with authorities. Intellectualism is about thinking and understanding, eventually until you become one.
When discussing coding style, you can quote experts. Or you can understand their arguments, understand the impact and tradeoffs of coding decisions, and realize why they are true. And in the case of Topcoder, about as far as possible from building large systems, you can realize that the optimum style changes and understand why.
I think there's a broad trend to treat code as magic, something where anything can happen. Most people learn coding styles by being given suggestions, and then noticing from experience that they like it better. If you reject this mindset and believe that code is orderly, then this advice changes from Wisdom of the Elders (TM) into an engineering calculation. I specialize in automated restructuring of software architecture, so this mindset is something I try hard to fight against.
I don't see how this applies to me taking issue with the parents "figure it out yourself instead of letting the experts think for you" statement.
"Intellectualism is not about showing off how much you agree with authorities"
My point was that intellectualism is not about agreeing with authorities but giving proper weight to the opinions of intellectuals in the field when weighed against lay opinions or smaller groups of intellectuals.
You certainly don't seem to be arguing for the post-modern interpretation I was arguing against where expert opinion is considered "just another opinion, equally valid" so I'm confused why you think my stance is almost the opposite of what I was stating.
The opinion of an intellectual is indeed stronger Bayesian evidence than that of a layperson. But if they have an opinion, they should provide an argument to back it up, and that argument is far more important.
My first comment hit the advice to always follow Carmack over the random Topcoder user. It's important to understand what makes a best practice a best practice rather than just listening. A Topcoder round and Quake differ greatly enough that the random Topcoder user is sometimes the greater authority.
You seemed to map the call to critically evaluate expert opinion to a call to ignore it, something I'm sure you've seen too much of. But it's important to understand the difference between critical evaluation and anti-intellectualism. Indeed, the former is the higher form of respect.
In general I agree completely, standard philosophy of science stuff.
I'm not sure how well it applies to a subject like best practices where it's either subjective or at least fuzzy. The arguments are "in my experience this causes problems when working with other people and is more prone to errors long term". There have been no counter examples or analysis I've seen around this issue, just a "that's just what the traditionalists say" type argument. Something along the lines of your topcoder example that applied to the semicolon argument (god i hate this issue) would be very welcome.
Any critical analysis here is hard to do objectively, and there is a consensus of experts (including Eich) on one side. If i'd seen any actual critical analysis rather than a jump to "don't let the experts tell you what to do! be a rockstar!" then I wouldn't been so fast to use the anti-intellectualism card. But it's so prevalent in the node community (more than Ruby's but less than PHP's) that it's depressing.
The reason for using semicolons in JS is quite simple: It makes it easy to determine the boundaries between statements, both for humans and machines.
With semicolons, the search for the boundary between statements reduces to the search for that single character -- that means fast code skimming.
The boundary is also robust against changes; as long as that semicolon stays in place, nothing that happens within that statement can cause that boundary to become an interior.
There is an exception: Strings. This is no trouble for machines, as strings are processed by the lexer. Humans can't instantly take a string and process it as a chunk, but a UI innovation does this work for us: syntax highlighting.
As an example, consider the code:
x = a && b
foo()
If I try to change the "b", I might accidentally turn the code into
x=a &&
foo()
The grammar allows the malformed statement to interact with its neighbor, and thus, instead of getting a parser error, I'll get a program bug.
LR parsers take advantage of this for error recovery, allowing them to find more than one parse error at a time.
A more sophisticated view is to think about syntax abstractions. Given a program like "x=y; return x;" we can create a program written in the abstract syntax "statement; statement". (The dual operation is to concretized that back into the set of all two-statement programs. This kind of relationship is known a Galois connection.) Having semicolons makes the abstract syntax unambiguous, allowing us to efficiently reason at the statement level.
Brandon Eich on twitter (or in comments here) will also say that it is his opinion, and he recognizes that it seems to work pretty well for the NPM guys, but maybe it is just because they are such great devs, he doesn't see it scaling down that well.
And finally, Crockfords reasoning about things like this seems based on the presumption that js developers are drooling idiots. For example, he recommends against using the new keyword for object creation in javascript, even though object factories can often be a huge waste of memory, because dumb javascript developers may forget to use the new keyword at times when they want to instantiate objects.
I am not saying you shouldn't listen to smart people, but I am saying that you should actually learn the reasons they say the things they do, and use your own brain when making choices.
I cannot overemphasise how much easier it is to understand Monads once you've groked Functors and Applicatives. It allows you to build an intuition for the _general_ structure and purpose of the typeclasses instead of trying to start with Monads by viewing them through the lens of IO or State.
This is a great post that gets mentioned from time to time and covers the underlying theory well. I'd supplement it with Chapter 9 of the Pro Git book: http://progit.org/book/ch9-0.html , which focuses more on the actual implementation and shows how to create commits from scratch using Git's content-addressable primitives.
RMS has the FSF and Defective By Design sites as soapboxes if he wished to gain more attention from Jobs's death. This was a post on his political notes page. He did nothing to publicize it.
He didn't post to aggregators or tweet to ask for upvotes (technically it was posted on his Identi.ca account which is linked to his political notes feed, but it got no special treatment).
If some major sites hadn't picked up on it and provided the publicity, most readers would never know. So RMS wrote a politically incorrect opinion on his personal page. Can we move on now?
I think I’m justified in saying that someone is clueless about communication if that person honestly believes that a statement by a very public spokesperson in any public place – no matter how obscure – will or should remain obscure.
That’s not how communication works. Sorry.
I thought that was sort of implied by my comment, no need to explicitly say it, because it’s so damn obvious. But I’m sorry if you though that my comment was nothing but an attack.
I understood what you meant, I just found it ironic in the extreme that you chose to complain about poor communication by genuinely using poor communication, especially given the context of the thread.
You've been commenting that Stallman should have deported himself better, and yet you break out with a comment like that yourself.
Understanding you perfectly well isn't the issue at point, it's the manner of how you present yourself - witness all the crap in this thread about RMS from those people who now accept that he didn't wish Jobs dead, but still say he should have been more polite about it. You don't have much of a credible leg to stand on if you don't engage in that which you request of others.
Edit: changed 'moral' to 'credible' to avoid semantic bickering about the loaded word.
What I find more interesting: are you as good at hacking as rms? Or is being better at communication the only thing you can take pride in? I suspect that might be behind all the ranting.
I was going to say something similar but you've done it much better, with a story to boot. So I'll just chip in with one point I had that you didn't cover directly.
A lot of the posts here are generally of the form "you can't speak ill of the newly dead". (Why? Because that's what regular people do, that's why). But adhering to social norms takes away from freedom. Indifference to what society prescribes is consistent with RMS's beliefs.
Call him what you want, but the man is consistent.
I'm guessing a lot of the angry responders here will have similar "I'm glad he's gone" feelings on RMS's death. Would not publishing those feelings give you the moral high ground over those who do?
How about this: "Speaking ill of the newly dead increases suffering unnecessarily."?
But I think the larger point that both you and the gp are missing is that, sure, sometimes it's effective to violate social norms. Steve Jobs was famously blunt with his criticism in an environment that's excessively polite.
But RMS often violates social norms in a way that does little to advance his cause, the gp's story notwithstanding. Maybe this event was an appropriate time to violate the particular social norm of not criticizing your hosts. But it seems that, increasingly, most of RMS's violations close people's minds to the ideas he champions, instead of persuading them.
The point is to be persuasive. If it's effective to be shockingly blunt, great. Expressing relief at the death of Steve Jobs? Anecdotally, it does nothing to persuade me, and everything to dissuade me.
RMS is an extremist, and extremists never get their way - they do, however, pull the center towards them.
If RMS were a nice guy, who would you hear raising these issues? There's no real names springing to mind, not that have the kind of recognisability that RMS has (who's known by his mere initials, no less)
Yes, Stallman often violates social norms in a way that does little to advance his cause. My friend Sofia was volunteering at Wikimania a few years ago, and when he couldn't answer some question he asked her, he yelled at her and called her an idiot. She laughed about it at the time but she also dropped her involvement with Wikimedia.
It probably seems to you like this kind of behavior is increasing, but I think that's some kind of cognitive bias. You'll probably never talk to Sofia unless you come to Buenos Aires, and so you never would have heard about her story if I hadn't told you about it. Similarly you probably didn't know about the conferences Stallman's been uninvited from over the decades, the old friends who don't talk to him any more; you probably didn't even know that the FSF had two founders. Because people forget stuff like that, or they don't talk about it and then new people never learn, and then they use Emacs every day. So when you see him committing some shocking social faux pas, you naturally think that this is some kind of new phenomenon that never could have occurred 15 or 20 years ago.
Stallman pointed out that what I said is nonsense; I didn't mean "when he couldn't answer some question he asked her" but rather "when she couldn't answer some question he asked her".
There is a detailed breakdown provided as well. Sample output:
Total size Compressed size
All archives 697 MB 323 MB
(unique data) 215 MB 100 MB
This archive 148 MB 67 MB
New data 17 MB 5.2 MB
Edit: Don't want to misrepresent Tarsnap's granularity. The print-stats option gives size in bytes. Above output was generated with the --humanize-numbers option.
More sample output, from a heftier machine, in case anyone is curious:
Total size Compressed size
All archives 3321059166180 1113881916696
(unique data) 116996664943 27182261608
This archive 13831036740 4855451330
New data 336950399 62343192
(Yes, that's 3.3 TB deduplicated and compressed down to 27 GB.)
I do my best to avoid busses. (I've always been more of a fan of switched point-to-point connections than busses, to tell the truth.)
In all seriousness, if I get hit by a bus Tarsnap probably won't live on without me -- but it runs itself smoothly enough that there should be plenty of time for people to download their data.
Can I automatically sync files using it? I work in multiple places and if I have to manually run a sync operation before I leave, I'm certain to forget or be unable to at some occasion, and then I'm screwed.
Tarsnap doesn't do sync. Doing sync while maintaining security is a much harder problem: Tarsnap's design requires each system to know what's on the server before uploading or deleting blocks, and that breaks if you have multiple systems accessing the same storage space.
I assume this is only deduplication within a single account? Because I don't see anything there on how one would provide dedupe across crypto domains (which, to the best of my knowledge, should be theoretically impossible if the crypto is done right).
If you're not using Bundler and have a simple dependency chain, you can get further improvement from symlinking your gems into a single directory (see https://gist.github.com/975509 ).
This patch certainly improved my load time tremendously, but the core of the problem still lies with the way rubygems and bundler dump all directories of gems in the load path. The promise of $LOAD_PATH is that all the directories in it will be tried -- the most bang-for-buck optimization is thus minimizing its size.
If rubygems did this, everything would be much better.
There is one problem though, and it is that some libs are bad citizens and install stuff outside of lib|bin and depend on it (haml's VERSION file is an example of this), and that sucks.
"My goal in not showing points on comments was to prevent the sort of contentious exchanges where people (in this case literally) try to score points off one another."
I think a suitable compromise would be to hide for X days until most voting activity is over (reusing the threshold where downvotes are no longer available but upvotes still are might work). This would still meet your goal without the cost of information loss.
You want them to think "is this interesting and on-topic for HN?"
My earlier proposal (http://news.ycombinator.com/item?id=2242453 ): deduct karma from submitter and _anyone who upvoted_ on submissions that were successfully flagged. That should get people to think the way you mention not only when submitting, but when upvoting as well.
Improve the submissions and comments will naturally improve -- submissions that are one-sided/gossipy/demagogic tend to attract similar comments. Whereas submissions full of technical content are often rich with links to further reading, contrasting viewpoints with cited evidence, etc. (Disclaimer: observations in this paragraph may be subject to fundamental attribution error).
I think there would need to be a little more to associate the action with the punishment. Since the point deduction would be pretty delayed from the voting, voters might not recognize which votes were poorly placed, and wouldn't learn to place better votes.
It's easy to understand and requires only a marginal increase in effort/code.