skore

If I recall correctly, battery production is currently a bottleneck for Tesla production and one of the major reasons why there is a waiting period of a few months after ordering. So I'm not sure to what extent he depends on home batteries to find a use for excess capacity, even if Model 3 isn't available yet.

I would imagine something along the lines of - After you have been right so many times (and profitably so), people stop challenging you and just take your word as gospel. At that point, there is no longer a burden to convince people, which is a very helpful mechanism to keep you on your toes.

This mechanism is what you then have to internalize and have out with yourself (and perhaps the very few people you have to work insanely hard on to keep out of acolyte mode) because it is now the only thing in the world that even can keep you on your toes.

> "Für sechs Groschen, Fritz, ist's heute genug"

I'm puzzled over the statement that this is supposedly hard to translate. Both translations offered miss the important distinction of tying the soldiers pay to their willingness to go above and beyond. Let me make an attempt:

> "That's quite enough for six dimes, today, Fritz."

That being said: I'm not sure it's smart to insist on binding your passion only to the money you make from its product. For things like being a soldier, that may be more true than other professions, but there are very few challenges that can only ever be compensated monetarily.

I know it's a common exploitation trope to tell people to not think about the money too much and instead appreciate the experience. However, a lot of people are so focused on never being even slightly exploited in that way that they do miss out on all the potential experiences - sometimes precisely the kind of experiences that would put them in a position where they could be on the better end of that equation.

Exactly! Furthermore: In that case, it gets more vexing the longer it takes you to arrive at that conclusion.

When it's the other way round, you can find peace at some point (even if it takes months or years). But if you were the brick wall, it first takes months or years and THEN, when you finally do realize the reality of the situation, it takes even longer to settle. shudders

None of that makes much sense to me, to be honest.

I find it curious that you just say:

> standard margins, that is 1 on top, left and right and 2 on bottom

No units, which makes me assume you're talking inches... Perhaps your problem is that you also need to switch to metric? ;-)

> And they all have suboptimal layouts.

(my emphasis)

My question would be - would you be willing to ascribe that to taste?

> It was like talking to a brick wall.

I know those types of conversations. They stay with you for months and sometimes years, never ceasing to irritate.

> There is no way to get a proper layout done

This is puzzling - how do you explain the abundance of people who seem to have no problem with this whatsoever?

Finally: I have seen lots and lots of A4 books, but they're simply not as common. It probably does help to live in Europe in that regard.

From the article:

> US Letter: 216 mm x 279 mm

> A4: 210 mm × 297 mm

so it's 18mm longer while being 6mm narrower. At that small a difference, I would assume that a preference of one over the other is similar to that of metric vs. imperial - the one you were raised on just seems right.

Which one did you grow up with?

"The GPL is not a free license. It does not grant freedom, it grants different restrictions."

sigh

Then why have a license at all?

You have to draw the line somewhere - we live in a complicated world full of complicated humans. The FSF chose to draw the line in a very particular way and they have perfectly good reasons for doing that. Other people or companies choose differently for different reasons[0]. This site tries to even landgrab the very particular phrasing of "Free" that the FSF uses. The guts of some people.

[0] The site mentions MIT, BSD or zlib as licenses but guess why Google chooses Apache? Because patents. Because the world is a complicated place full of complicated people.

> How did you detect it was missing < p > tags?

Just opened it up in the inspector in Firefox, no black magic here ;-)

I would definitely look into your font names - it tells me that "Lato-Hairline" is used as: "Lato" and "Lato Regular" is used as: "@font-face:Lato". So perhaps the issue is that Lato-Hairline is the font-weight = 100 and Firefox picks it over the other one, only finds the single font-weight and sticks with it?

Just a guess though, webfonts can be weird. For instance: For Chrome, it can depend on what version you use. Just today I ran into a font rendering bug similar to this one where Chromium versions 37&38 had their font-weights switched so that 300 ended up as 500 and 500 was also picked for "normal". So the bug report "all fonts are bold and it looks terrible" resulted in "CANTFIX old Chrome be weird", basically.

Nitpicking: It seems you might have an issue with font loading - for me (Firefox on Linux), it reverts to font-weight 100, making the text (which is missing <p> tags, by the way) almost completely unreadable.

Fig A.: http://i.imgur.com/9rLQwQQ.png

> Can't we just extend whatever laws with the addition of this specific treatment? Anything else has to be looked at on a case by case basis.

Cue people shouting about how politics are slow and killing people while also forcing politicians into making medical judgements that they may not be qualified for, further increasing the chance that they become the playthings of lobbyists who "do their homework for them".

I'm utterly divided on this issue by the way, just noting the inevitable discussion that follows your logic.

I actually meant both - You CAN consider it the lesser evil while it also has the nice side effect of clearing the market (for simple backup in OSX) from competition as early as possible.

Sorry, should have clarified - Marketing in the sense of: converting people into using an apple solution early, so they won't use one from another vendor later on.

As a Kubuntu user and dedicated nerd, I fully agree. But as somebody who has spent some time trying to make user interfaces understandable to people, I'm a little more pragmatic and can see that pseudo simplicity still yields good results.

The Time Machine thing is pure marketing, of course. It drives conversions. That's its own brand of terrible, but even THEN you could argue that pushing people to do backups in whatever way isn't necessarily pure evil.

> then have a button

> Have a button

> have a button

That's your problem right there.

That's why I wrote "for reference". jQuery, of course, is a different kind of library.

A proper argument would be: jQuery has about three times the contributors that mootools has. If I had to decide between mootools and jQuery, I'd pick the second because of that metric alone, yes. (And this is how the market ended up playing out.)

Angular (born Jan 2010) has 2.5 times the number of contributors of ember (born Apr 2011), 5 times of React (born May 2013). I'm not just trying to find a reason to dismiss React and I do realize that it is still young. From a business standpoint, though, the choice couldn't possibly be any clearer.

I do agree that React has gathered a sizable crowd in a short time and it's definitely on my list of projects that I keep an eye on. But it's simply too young to warrant the same kind of investment that I have personally made into Angular.

I can only quote myself to clarify, here:

> They get community right and at the end of the day, that's the only thing that really counts.

To everybody trying to make this into a tech fight about Angular vs. React/whatever, I've been repeating this like a mantra and even mentioned it in a talk on javascript once[0]:

You can argue about the minor details of the tech stack till you turn green and blue, but Angular wins because it succeeds in the only metric that really counts.

jQuery: (for reference)

    5,656 commits
    7 branches
    122 releases
    199 contributors

React:

    3,003 commits
    10 branches
    18 releases
    226 contributors

Ember:

    7,490 commits
    35 branches
    90 releases
    412 contributors

Angular:

    5,988 commits
    12 branches
    111 releases
    1,044 contributors <---

I have made a bet on Angular two years ago and the reason was: They understand how to herd cats. They get community right and at the end of the day, that's the only thing that really counts (no matter how much nerds like to pretend that it doesn't and it's all about technological purity or what have you).

I am absolutely confident that they are making good calls and the way they have handled the transition periods so far (and the way they are going about these new "big" changes) only increases my confidence.

I would be very surprised if in a few years, Angular wasn't on the same level of "you can basically assume that it's loaded" as jQuery is.

[0] https://www.flickr.com/photos/valanx/14136669418/in/set-7215...

> Recognizing the right answer is the hard part.

Very true, but even further than that: There are very few clearly right or clearly wrong answers. There are actually very few wrong answers - but there is a stupendous amount of right answers that are bad answers. Especially: bad answers for you.

Recognizing a wrong answer is the easy part. Taking a dozen or so "right" answers and selecting and condensing them into the best answer that makes the most sense for your programming context is the hardest part.

It is astonishingly easy to accrue a tremendous amount of technical debt because you just chained up solution after solution into a grotesque mix of "works, but could explode any minute".

Because the job of a code editor is to get out of the way.

You get out of the way by emulating what people know to at least such a degree that they can filter it out easily and concentrate on the task, not the environment.

> Sure, one can think up use cases. But I never had one.

Welcome to your very own filter bubble.

To further specify: The GPL states that the recipient of the software has a right to also get the source. The public is simply not a recipient of the software.

The "limit" of my test is that it's sort of a worst-case scenario - Travis does have a couple of things set up that you may not find in the wild, but the entire purpose is to get speed ratings on a purposefully crappy system.

"and you get award-winning documentary shots right from your phone"

Please tone down the hyperbole.

I was testing with:

PHP 5.6.0beta4 (cli) (built: Jun 12 2014 14:13:53)

Zend Engine v2.6.0-dev, Copyright (c) 1998-2014 Zend Technologies

with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies

with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans

vs.

PHP 5.5.13 (cli) (built: Jun 12 2014 13:54:54)

Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies

with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies

with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans

...but, as I said - this is with very limited testing, basically just on Travis (which goes up and down in speed all day, but the difference between versions is pretty steady).

Unfortunately, judging from my own (very limited) speed tests, that result simply means that it is en par with PHP 5.5.

PHP 5.6 is not only not finished yet - it is, in my experience, also the worst performing version you could choose. Not sure that's a good idea.

If anybody is using dd to rescue a failing drive, I can very much recommend using the spectactular ddrescue instead.

I had a 2TB drive turn up five figure error rates (Raw Read Error rate ended up at 90k - when I started, it was already no longer possible to mount it, but it did show up in /dev) and thought I had lost an entire year of family pictures (mea culpa on not having a backup, of course). It took four months, 24/7 of meticulous work, but it ended up giving me a near perfect copy to an identical drive (save for ~20kb of truly dead sectors).

Amongst many other features, it has a logfile where it keeps track of the overall process - so that it can be killed or paused and restarted later.

I don't know that much about Haskell and I don't consider myself strong enough to make judgement calls on the theory side of systems architecture. That being said, here is what I was scratching my head about:

1. ("form over content comment", sorry) Not necessarily a criticism of the speaker as this is mostly a typical room mic issue, but the volume differences made this rather hard to follow. But in the delivery, it often seemed like the filler language was very loud and more in-depth details were mumbled into the screen.

2. I keep wondering "why?". It was just brushed over in the beginning, but I did not hear a compelling reason being presented on doing everything in Haskell. I do get that it is questionable to build this ever-growing API that does nothing but glue the client (javascript app) and server side to eachother. But isn't that what the internet is about? Having contained nodes that communicate?

And how is basically automatically generating the same sort of API... but now instead of a growing list of named end points (paths and maybe even GET variables), you have an RPC style protocol that directly adresses the internal code via the tree it sends back as part of the request ... better?

Later (around the 48 minute mark) the very valid question is brought up - isn't binding UI updates to server interaction very, very expensive? Expensive in such a way that encouraging it as a basic part of the systems design is a bad idea. And the speaker kind of makes a joke of it and says we can just throw more servers at it. Well maybe, but that seems to be a rather substantial error in the entire system design. It might solve some other problem and the problem created may have a simple solution, but... I just don't get how all that sums up to being a great idea.

3. Is this, in some sense, about avoiding to write an application in javascript? Because I have found a lot of people doing that - building the most incredibly colorful systems only to avoid to finally let go and just build a javascript application already.

In this particular instance, it seemed to be about trying - as much as you can - to do everything in Haskell. I have also seen people build frameworks on the idea of writing everything in XML files and interpreting them at runtime in PHP. It's possible and you can conjur up advantages, but at the end of the day, it's still not a good idea.

Nor is it compelling to other devs to join in, which brings it back to the LISP problem: an incredible potential for flexibility, but at the end of the day, it's just not very social. And thus, no matter how much nerds despise that conclusion, doomed to obscurity.

4. How can this ever "upgrade seamlessly"? It seems like this pushes the syncing issues down to the code level. I'm not sure that is an advantage to having syncing issues on the data level.