jwecker

Give 240cm or 360cm a name (like STL for "standard-timber-length", 1 stl = 240 cm) and you're effectively doing the exact same thing as the imperial system. Then it's just a popularity contest (which is fine and appropriate and metric wins except for wrt time) but at least conceding the fact that base-10 scaling of units is not intrinsically superior for all units & situations.

Edit: If the argument is that metric is more intuitive (less memorization because of consistent scales) then I think that's a great argument. If the argument is that it's more standardized and more widely adopted, I think that's also a great argument. But I think that the argument that the metric-system is somehow superior intrinsically because only scales of powers of 10 are worth naming (as the name implies) is a poor argument, as you've helped illustrate.

I would love to hear from someone who does carpentry (or some craft-like equivalent) with the metric system- specifically what kind of ruler/tape they use and whether it has a special 1/3 and 2/3 mark on it (since you don't want to have to eyeball 0.33333....) or if they just avoid dividing things by three altogether.

Because the truth is, your perspective is a political one more than a practical one. The whole idea of "officially" adopting either system is somewhat misleading- regardless of politicians or zealots decide, most craftspeople would use rules that easily divide into three, most programmers would often reference things in terms of base-2, and most people would still prefer 24 hours in a day. There is no general-case optimal winner that applies to all measurement and work-flow situations.

In the case of base-2, international bodies have already found a nice dual-system ( http://physics.nist.gov/cuu/Units/binary.html ). A simple solution for (for example) carpentry that would give the best of both worlds would be to define a unit that is exactly 1/60th of a meter. Let's call it a "sixer." Now someone crafting things can have all the convenience and easy division they need (here- cut this at 1/5 of 1/3 of a meter- no problem!) and still have it unified with the meter at some scale. There would be issues- but it's situational, which is my point.

I am not anti-metric by any means, but having done carpentry a lot in the past it always strikes me when this comes up that one of the central arguments for (a limited use-case of) the imperial system is usually glossed over: the fact that in many crafts (especially historically), using base-12 makes certain things much easier. It divides into 3rds far more easily, divides into 4ths slightly more easily, and still divides into 5ths with only one digit after the decimal.

Just like computer programmers have no problem immediately recognizing that 256 is 2^8, it became intuitive when working with the Imperial system (at limited scales) that 48 inches is the same as 4-feet but that it is also 3-stud-distances long (studs in walls are often placed 16 inches apart).

Even if you don't work in crafts where dividing things by 3 is more frequent than dividing by 5 it is easy to imagine how certain things might be more difficult if we used base-10 for time (as, it has been pointed out, has been attempted)- and thereby using the ability to easily divide an hour into 3 parts (for example).

Consistent base-10 and international standardization has advantages that far outweigh these minor things- but I think it's important to recognize that there is, surprise, a rational practical reason for sticking in some cases to Imperial units- it's not purely tradition or politics or their "organic-ness" (anymore).

Totally. "Science" requires precision because science in many ways is the mechanism by which we learn truths with greater and greater precision. That doesn't mean though that science naturally abhors imprecise "for-scale" measurements though- they just reserve them for illustration and avoid using them for the actual science. (e.g., http://imgur.com/gallery/ESp2j - marianas trench scale)

As you've illustrated, we've come to value precision over intuition. The reason people using metric don't feel like they're missing something without organic units is because people who use the relics of those organic units don't use them in the fuzzy organic sense either anymore. When someone tells me "1 foot long" I expect exactly 12 standardized inches- not something roughly as big as my foot (even though, in my case, my foot is almost exactly 12 inches).

In modern times when we want a more organic measure we find ourselves dropping standard units (whether metric or imperial) and using random analogous items instead- like number of empire-state-buildings or 10-paces then turn left, or (more often perhaps but slightly different)- about 3 blocks away.

The moment people started caring about whether it was Henry I's nose-to-thumb length or some multiple of grains of barley dry it stopped mattering. I'm very average sized and my pace is almost exactly one yard per step (or, as you pointed out, more or less a meter as well). I would be fine using the term 'yard' in the intuitive or organic sense- but when you're using it to tell me exactly where my property line is I suddenly need precision, agreed on standards, and at that point the question of inches vs centimeters is strictly a question of familiarity (or I suppose, as the article mentions, politics).

In my (admittedly limited) experience with peering I've never seen a contract. Lots of ad-hoc verbal agreements, and occasionally emails outlining a mutual understanding, but because it so often is obviously beneficial to both parties it is almost always handled in a casual way and decisions are deferred to network engineers for engineering considerations. I've never seen legal get involved. If Verizon brought it to a point where it is a contract dispute then it would be just as much of an indictment- it doesn't change the substance of the post at all.

In the context of clever startup solutions, this brings to mind the quote from George S Patton: "A good plan, violently executed now, is better than a perfect plan executed next week." Even if they didn't approach optimal solutions, the fact that generating random feasible solutions can be much easier and result in more tractable mental models (and therefore easier to maintain code etc.) means you can be 'violently executing' in the field of battle much earlier.

The fact that they approach optimality is gravy.

Justin.tv was part of the summer 2007 y-combinator batch (with dropbox and disqus among others). Twitch branched off of justin.tv a few years ago (I think technically part of the same legal entity at the moment but I'm not sure- they were trying to separate the infrastructures etc. when I left). Emmett, the CEO of Twitch, is also a partner at Y-combinator if that hasn't changed.

The fact that there's no immediate obvious answer is what makes it by definition clever.

In my experience people are usually far less passionate about making a bunch of money than they think they are (there are those who really are passionate about the abstract idea of making money or are truly passionate about some derived benefit- but they have to work a lot harder to avoid becoming an... unsavory person). We conflate our desire to generate and create value and wealth- which tends to be subjective at a deep level- with generating income.

Scott wrote for the perspective of success = money, appropriate for the publication and to some degree reflective of his personal passions, but I suspect that most HN users are more interested in the act of creation. Money / being rich remains a very, very powerful method of validation and obviously a primary source of "potential creation" and to a lesser degree freedom- but for at least "makers" it is a mistake to confuse it for a fulfilling passion.

Giving a perpetual royalty free license to anything you may ever patent for the rest of your life because of a subtle loophole in a license that people aren't generally aware of is, IMO, new and outrageous, irrespective of the utility (or lack thereof) of software patents.

I don't believe a single stated "No" in the FAQ will be very meaningful, except to point out that even the creators of the license failed to notice the loophole.

Edit: Also, the fact that the interpretation can exist and is in written form is what suddenly makes it an issue, at the very least for anyone going forward. (IANAL)

Brilliant. From the live office webcams page (where you have the option to taunt specific employees):

"Are those traffic lights real? Yes! There is another set of traffic lights, hidden to the left of the camera, too! They keep my staff awake with visual stimulation in the same way that my website invigorates my visitors!"

The office looks just like the website.

So by saying 'cannot _always_ work,' and 'very unlikely to work,' you are implicitly conceding the point- that it is possible. The question then becomes, given the size of the OS environment space (and the quality of the randomness in the originals), could one in 50 attempts actually succeed in shaving off a byte? I sincerely doubt that Mike, despite his superior knowledge of information theory, actually took the time to figure out just how good or bad the odds were. He assumed that it was fundamentally impossible, when it is in fact not impossible, just unlikely (to some unknown [to me] degree).

Classic compilation. Always check for cpu builtin functions (rtfm gcc) first though when you need this kind of optimization "in real life."

To me this is where the real complications come in, especially when trying to do something portable.

From comments in http://news.ycombinator.com/item?id=4369485 -

Linux behavior vs. OSX (or, differences between terminal emulators): http://news.ycombinator.com/item?id=4369732

Different behaviors when using ssh et al.: http://news.ycombinator.com/item?id=4369751

Now combine those issues with the chart and you end up with something that is, true- deterministic, but not really useful. In the end, most people end up just having the startup files boil down to the same thing by sourcing their preferred one. And in the end most people don't try to think to much about the login vs. interactive vs. batch vs. posix/sh - even when they should be.

Indeed. https://github.com/josephwecker/bashrc_dispatch - thanks to gioele for already doing some cleanups and speedups.

Good call. Merged into the repo https://github.com/josephwecker/bashrc_dispatch . Thanks!

Kind of... That's pretty much what mine had evolved into, a bunch of them sourcing each other and making sure they weren't recursively sourced for when they're used on a different OS/machine, with complex conditionals to re-detect if it was interactive or not and logic to try to not re-run things too often that was only supposed to be run on login... with no certainty that they were really doing what I intended in weird circumstances like `ssh ... command`.

But those wouldn't have been "shareable" or standard either- unless they were all shared as a group. When someone says "here are some lines from my .bash_profile"- they are not implying something by having them in bash_profile and not bashrc. No one in their right mind would think "must be something they only want to run when they log in." Instead, you take those lines and put them into your .bashrc or .profile or whatever you happen to have working well enough. Or, worse, someone says "here's my .bash_profile" and someone new to osx drops it in their home directory and all of a sudden nothing works because bash stopped looking at their .profile that already existed, while someone on linux drops it into their home directory and it looks like it's not doing anything at all.

etc. (: obviously people get it to work, and obviously "madness" was a euphemism, but I was tired of all the ambiguity.

So I admit it's a 10 minute hack done on my way home on the train, but the issue is real even if you understand the man page. Here's roughly the way these work normally.

Starting with "login" bash invocation- which means:

* On linux, usually only when you first ssh into a machine or boot up into a terminal- and then _never again_ as you open various terminals or su etc. If you boot into gdm or something like most desktops/laptops do nowdays, you may hardly ever see your local machine invoke bash as a login shell.

* On a mac, "login" mode is invoked on pretty much every terminal you open.

* The login mode of a shell is _orthogonal_ to the shell being interactive (in theory. In practice, and in the gist, a login-shell is almost always a small subset of interactive shell invocations [or larger subset on mac]).

The rules for the login shell invocation are to load:

('/etc/profile' THEN (~/.bash_profile OR ~/.bash_login OR ~/.profile - one and only one, the first one it finds)) (and nothing else)

UNLESS bash is invoked as a login shell with the 'sh' name, in which case it does:

('/etc/profile' THEN ~/.profile)

IF the shell is NOT a login shell but IS interactive, don't load any of the profile stuff but load ~/.bashrc (ignored if bash is invoked as 'sh')

Finally, a shell in posix mode and a shell invoked by a script- i.e., non-interactive, will first load any file specified in the BASH_ENV environment variable and nothing else.

On a mac, the default for new home directories is to have a ~/.profile sitting there. Should you unwittingly drop a ~/.bash_profile or ~/.bash_login in there one day, you would find (and many have found) that the ~/.profile suddenly stops working (more likely you suddenly notice your PATH isn't set anymore). Except sometimes, when bash is being invoked as sh, in which case ~/.profile is alive again.

And, note that .bashrc isn't loaded at all for a login invocation, even if it is interactive (true the vast majority of the time). On a mac, .bashrc seems useless, then on linux, .bash_profile seems useless. So many on linux end up filling up their .bashrc with the good stuff and then realize that when they log in remotely nothing gets loaded so they troubleshoot, read the manpage, and end up sourcing .bash_profile from their .bashrc. On mac, people tend to do the reverse. Oh, and when you are trying to remember what is what and why you should care-- the manpage is almost 5,000 lines long. AFAIK, it's the only manpage the size of a book.

Anyway, I was putting my dotfiles into github and spend a lot of time on OSX and Linux so was merging the two sets. I also have seen (and written) so many rc scripts that liberally mix stuff that is relevant for interactive-mode with stuff that should really only be done at login, etc. That said, it _is_ a 10 minute hack so forks + fixes appreciated.

It's more than a common pattern- they are lowercase numerals, even if they don't get used much. Although I see what you meant by random in the sense that lowercase 'g' "randomly" descends while lowercase 'l' randomly ascends.

How is it a rebuttal? Pogue's primary complaint was the weakness of the new magnet versus the old 90º magnet. In fact, he specifically says that the last incarnation (which was a T-shaped- just with a stronger magnet) was the ideal balance, which they've now lost. The L-clip was mentioned to illustrate the continuum toward weaker and weaker connections.

kind of. They are obviously vague predictions, which is kind of a cop-out / cheating. But after reading how silly all the specific predictions seemed, even when correct, I got to thinking about things with a strong historical precedence- things that would likely remain true. The language used makes it sound kind of like the platitudes you would see in Barnum statements, but those lead to the Forer effect because some number of them _do_ apply to lots of people (leading people to confirmation bias and to assigning some weight to a non-existent authority). I hope that the imprecision in my predictions make them boring and obvious because they're true for the majority of 25-year spans in recorded history, not because they pretend to be tailored specifically toward individuals reading or toward this coming 25 years.

2037

Some promising technologies will still be struggling along in 2037. Others have disappeared or been replaced completely. No matter how miraculous and marvelous the advances that have happened though, society will have managed to consider them mundane and probably inevitable. I don't know what quantum computers and machine learning will have allowed by 2037- (better weather prediction? deep mathematical truths?), but I suspect that the things people think about the most, like how to have meaningful relationships and fulfilling work, will have only been minimally affected. On the other hand, I predict that some people thinking about those things now will have found, individually, exactly what they were looking for.

Each generation will be less mature (at least until it reaches the same age as the last). Each new generation (there will have been a couple by 2037) will, despite its immaturity, regressiveness, and destructiveness, manage to yield forth individuals who inspire and transform, who rise above petty concerns and a world brimming with distraction and reveal something new about the capacity of mankind.

In short, the fundamental struggle will continue between technology that exalts our knowledge and capacity, and human nature that debases and waste them.

Existential threats to mankind will still occasionally surface. The threat of genocide, tyrants who oppress and reign in terror, the Earth groaning under its abuse as we attempt to listen better, to act better. But, as always there will be pockets of peace and prosperity where others can sit and take a moment to write an entry for 2062.

I had a similar experience. I forked ffmpeg on github and fixed a few bugs that I was sure no one would care about but us. I figured I'd polish it up over a couple of weeks and send a patch for possible inclusion upstream. But the next morning I had an email waiting from Michael. He had found the fork, found my "experimental" branch, and emailed me to compliment me on the code, suggest a couple of changes, and ask if it would be cool to cherry-picked some of the commits into the mainline. I've been involved in a lot of opensource projects and have _never_ seen something that gracious. He obviously has taken whatever lessons he learned in the schism to heart. Between that and the fact that his code base is (more often than not, but not always) more stable and functional, I have little doubt which way things will flow eventually, perhaps after time has allowed more of the bad feelings to dissipate.

They're just warnings. I got the same ones but it still created a perfectly good executable. (you kind of have to assume warnings with obfuscated code :)

The key untested question then, I think, is whether you can successfully identify the 5 vs 1000 when recruiting. I think it would be pretty easy to show that there exist teams of 5 that outperform teams of 1,000 (certainly teams of 20 outperforming teams of 4,000). (be grateful you haven't had to work for any of the latter)

A secondary open question would be whether an existing team of 5 who currently outperform some larger number tend to continually outperform them after being acquired. I would bet that the performance gap would be close to the same. At the very least I would suggest that the cases from other industries give us next to no insight for software development.

"If you were launching a technology or developing a product, would you rather have five great engineers rather than 1,000 average engineers?"

The 5, in a heart-beat. If you were painting a mural on the ceiling of a large structure that you want to be admired for generations to come- do you hire 5 brilliant painters or 1000 average painters? Even happily ignoring the exponential communication overhead that diminishes returns significantly as he does in the original article, there are leaps of imagination that a small brilliant team are more likely to make than any-sized average team.

Edit: Also, his case examples are not coding related. Obviously a non-software-technologist not knowing or understanding the unique background behind the comments in the context of software development and, particularly, software startups. 100x productivity is of course a generalization and has received valid criticism, but examples from sports and trading are irrelevant.

Looking through it I don't see it as a replacement for reset except in a few cases. In particular, most of the stuff in there (great documentation, btw) seems to be oriented toward fixing strange browser quirks not covered by reset. For example, things like "Remove Android and iOS tap highlight color [from html-tag] to prevent entire container being highlighted..." Seems like a very natural add-on to reset to me.

Considering that I've worked with dozens and have known hundreds of serious computer professionals and have yet to meet a single one that supports software patents (including many who have them!), and I suspect that I may never meet such a person- I have to agree that there is some public support for this issue.

Admittedly, we're a small percentage of the general population, but we are certainly influencers. I believe that askforit.com is specifically trying to overcome the issues that snopes talks about (and even if they don't, it's silly to think that that will remain the "last word" on the issue- it's relevant for late-90's early 2000's technology). Secondly, if you were to pull 'Big copyright/DMCA' and 'Non-computer-related IP like pharma' out of 'Big IP' you'd be left with a peppering of small disreputable companies (that are really lawyers and not technologists) that actually attempt to make a little bit of money off of software patents, and big industry that use them as a form of mutually-assured-destruction - who are more or less ambivalent toward them but have to have them as insurance.

So in short, I'm not totally disagreeing, but instead of the implied "tiny group of HNewsers vs. Every big corporation" I think it's more along the lines of "pretty much everyone that does anything serious with computers vs. general apathy and a small smear of vested interests."

What would prove me wrong: Is there even a single currently reputable/established company big enough to lobby congress that has software patent royalties as a significant revenue source? If so, are there several of these? I'll be impressed if someone can think of one... but is there really some hidden computer software industry perhaps deep in the bowels if the fortune-500s that I somehow just never hear about that actually use software patents in the intended way [i.e., not for insurance against competing patent claims]?

EDIT: I'm responding to you and andrewvc at the same time- sorry if it countered arguments that you actually didn't make.