Claiming our lives back from social media addiction - <AUTHOR> https://www.iafrikan.com/2017/12/11/social-networking-sites-may-be-controlling-your-mind/ <comment><USER3> As the father of a teenager daughter who is entirely too addicted to screens (they're all confiscated, spending the semester in my office), I highly recommend Catherine Steiner-Adair's book, The Big Disconnect: Protecting Childhood and Family Relationships in the Digital Age.

It's not just the kids' fault. You taught them to do it by ignoring them when they were little (because they were boring, remember?)

[https://smile.amazon.com/gp/product/0062082434/](https://smile.amazon.com/gp/product/0062082434/)

<comment><USER4> > killjoywashere

Name checks out.

In all seriousness, though, you're absolutely spot on. My youngest is almost 4 and I caught myself repeating the same mistakes with her that I made with my oldest. I'm much more strict with myself now than before, I aim to protect her from myself. Going back to correct missteps, such as taking my oldest daughter's iPad until she's older, has been very tough.

Without going into too much detail, I'd like to acknowledge the escapism epidemic in the United States.

Thank you for the book recommendation, too!

</comment></comment><comment><USER5> Social media and people on social media do not know us better than we know ourselves because all of us lie and try to look cool on social media. Like, can you think of the last time you saw someone clearly trying to act smart on a forum, maybe even... right here?

As far as I'm concerned, all social media knows is how to exploit us. It hones in on what gets us engaged. I think that is far worse than 'knowing us' \- I'd actually find that comforting, in some ways.

As an example, I don't think social networks really want to work on ending abusive behavior or harassment because often those behaviors create engagement. People logging on to argue at random people about whether or not you should've voted for $CANDIDATE vehemently all day long are people using the platform and showing up in the numbers. It's good business. Verifying an actual nazi on Twitter? People may have been angry but they expressed it _by using the platform itself_. Whether Twitter was right to verify them is up to you, but the reaction is undeniable.

But honestly, we're all bullshit artists. I would never go liking all of the stuff I like in real life on a Facebook in my name. Do I want all of my friends and future employers to know how obsessed I am with some subculture? Not really. I'd rather like things that make me look normal and fit in.

I haven't been on Facebook in a long time, but the Internet as a whole has felt worse since engaging socially as my real life identity. I felt it was more fun and genuine when it wasn't real life identities, although that ship may have sailed thanks to bots and vandalism.

<comment><USER6> I'm starting to think that the hyper-engagement of fighting over every $CANDIDATE, $CAUSE, and $OUTRAGE is going to drive people away from Social Media.

I started doing blackouts on Twitter and Facebook every time some major news event occurs because I just don't want to hear about it. And the one thing that I have noticed is a slow consolidation of my Facebook feed to just a narrow slice of hyper-engaged people who post multiple times a day about whatever the latest outrage is -- the broader spectrum of users haven't deleted their accounts, but most on my "Friends" list haven't posted in years. I suspect a lot of my friends are disengaged from the platform precisely because they have zero interest in fighting their loud, opinionated relatives of opposing political sides.

I miss the days where everyone was just avatars, nick-names, personalities. It still seems odd to me to be expected to mix my virtual and real identities, since the "internet culture" when I got online insisted that you do not share your real-life identity* and Facebook came along and turned that entirely upside down.

*It was common practice on some of the bulletin boards that I frequented in the late nineties for users to maintain multiple accounts under different nicknames and personas, and even have conversations with themselves.

<comment><USER7> > since the "internet culture" when I got online insisted that you do not > share your real-life identity* and Facebook came along and turned that > entirely upside down.

That has been my number one objection to Facebook right from the start. I was long out of school when Facebook was first established, but the second I found out about the "real name" policy I thought to myself, "This can't end well."

</comment></comment></comment><comment><USER8> I have a little project going for the last couple of weeks. Things I got to replace the screens with: an old typewriter, a world radio and an electronics kit with which you can make a large number of different devices.

Still in the works: an old fashioned wind-up alarm clock, a cassette or tape reel to reel recorder and a polaroid camera.

You can get all of those for pennies or even for free on Ebay or the local equivalent. The kids are absolutely fascinated with all this real world stuff that does only one thing.

And there is no 'app' for the kind of satisfaction you get from receiving a painstakingly type-written letter with a bunch of stuff crossed out or a morse code message just for you. Grandparents will likely much more appreciate one of those too far over and beyond a Facebook message. And what's more magical than to pull some Latin American station out of thin air?

Besides learning a lot about what makes stuff tick they _also_ learn about the evolution of technology and the old stuff is so much more real and easier to relate to that they freely start to figure out how they can do other things in a simpler and low tech way as well.

After that: tools to take things apart and to do some basic repairs on broken stuff that we find.

<comment><USER9> >And what's more magical than to pull some Latin American station out of thin air?

Pulling the entirety of Wikipedia and Youtube out of thin air?

That being said, I totally agree - I love books, my manual film camera, dream of owning a typewriter (but have no use for it) and love records.

<comment><USER10> I nearly broke myself at some point because I started to realise that just by typing on a computer I was broadcasting things through space, hammering rays of light under the Atlantic, and getting a reply back in miliseconds.

If I think too much about it, I almost can't do anything because that is magic, made _real_.

Another good way to break yourself is to go into any reasonably sized supermarket and look, really look, at all the different products and where they come from, then imagine the insane amount of work that goes into making that possible.

I mean a typewriter is pretty cool and all, but it doesn't really compare to sending messages through space, at the speed of light.

<comment><USER8> Fair enough but that part of the magic is so beyond what a young kid can understand without all the context involved that it is magic that can't be decomposed. The elements involved are closed off to inspection.

<comment><USER10> I think you may be underestimating your kid here. Try to walk him trough the steps and see if he can't grasp at least _some_ of the magic.

<comment><USER8> As good as we can, consider it done. But that's _still_ not the same as being able to trace the wiring or to follow the mechanical linkages.

What I found really interesting is that they have no problem understanding vacuum tubes but fail at understanding transistors which are essentially the same thing only going from a literally transparent glass tube with inner bits that you can see to a little black piece of plastic with three metal legs sticking out.

There's a lesson in there somewhere.

</comment></comment></comment></comment></comment></comment><comment><USER11> In my life some of the most interesting lasting friendships were made with strangers I met in hostels while traveling and at weddings. But my recent experiences with hostels and weddings and bus stops and pretty much everywhere (even in remote areas in the third world) is that instead of talking to each other everyone is giving their attention to their smartphones. Social media needs to start making its emphasis the creation of more real world social interaction. What about an opt-in geoaware app tied into or within FB (or other) that runs in the background and when it notes a critical mass of people nearby looks for common friends and interests in the crowd and after appropriate reactions to prompts, makes introductions or even proposes a flashmob activity from among those that some of these people have stored (in the app or somewhere that the app can access) in the hopes that just such a moment would arrive.

<comment><USER12> Perhaps. But I would never activate such a thing. I'd expect to run into weirdos that are impossible to get rid of.

It's a cliché to say that we as engineers look to solve all problems with more tech, even the problem of too much tech. But in this case I think it's really warranted.

I've had two experiences here in Copenhagen that were interesting to me. Once, I was on a bus that got stuck in a pile of snow. Everybody got out and helped push it. Another time, the ATM's collectively stopped working for a half hour or so. In both instances, people were almost delighted to have a reason to speak to strangers around them. The bus ride turned into a small party, and with the ATM situation I saw a person giving a stranger cash (not a lot, but completely out of the blue). Both times I had the feeling that it was like people were waking up from a zombie-sleep and I wonder if things were more like this in villages in the old days.

<comment><USER13> It seems true that comfort breeds alienation while adversity encourages interaction and interdependence, and, being that that's what we evolved for, many people seem to enjoy the latter. For my part, though, I'd like that limited to WoW guilds; communication greatly disrupts my comfort unless done in the most abstract and expedient environments possible, like cyberspace. The smartphone has done wonders to make meatspace more bearable for me.

<comment><USER14> There's a fantastic quote from Orwell about Hitler's rise that points out that the appeal of fascism was struggle and conflict itself. I'l see if I can find it, but it is something I wonder about from a sociological standpoint: When we have our basic needs met, how do we deal with the alienation that results? If we don't deal with that alienation, can we expect someone who promises adversity to arise?

Being poor, lacking healthcare, experiencing violence, etc are all terrible things, but overcoming them often strongly informs our identities.

If we manage, through politics and technology, to achieve a safe, post- scarcity society with all basic needs met, will we have to deal with a collective identity crisis (or millions of individual crises) and if so, how do we deal with it?

Found the Orwell quote:

 _"[Hitler] has grasped the falsity of the hedonistic attitude to life. Nearly all western thought since the last war, certainly all "progressive" thought, has assumed tacitly that human beings desire nothing beyond ease, security, and avoidance of pain. In such a view of life there is no room, for instance, for patriotism and the military virtues. Hitler, because in his own joyless mind he feels it with exceptional strength, knows that human beings don't only want comfort, safety, short working-hours, hygiene, birth-control and, in general, common sense; they also, at least intermittently, want struggle and self-sacrifice, not to mention drums, flag and loyalty-parades ... Whereas Socialism, and even capitalism in a grudging way, have said to people "I offer you a good time," Hitler has said to them "I offer you struggle, danger and death," and as a result a whole nation flings itself at his feet"_

<comment><USER15> Hitler promised a lot more and did not arise to power in the situation of good economy. He promised new land under theory that Germany is overcrowded, he promised power and went up as capitalism/democracy seemed to be failing. Hitlers popularity went down when economy was better and up when it crashed.

Another thing that played against socialists in Germany was knowledge of purge in Russia. Germans were scared that something like that will happen there unless there is strongman in lead. And to be fair, communists getting power would likely mean danger and killings.

People also hoped that Hitler in power will cause street violence go down.

People will trade identity and purpose for comfort, but in Germany it did not happened out of comfort. And it happened in violent already militaristic state that valued military a lot long before Hitler.

<comment><USER14> My wording was unclear by positioning it as "the appeal" as opposed to "one of the appeals".

Hitler promised a lot of different things to a lot of different people. The Nazi party was extremely cynical in its application of promises and even ideology. One of the the most interesting and disturbing pieces of Nazi propaganda was a poster of a banker and a communist holding hands, with the caption, "Marxism is the guardian angel of capitalism."

An absurd and nonsensical statement, it was instead appealing to a particular segment of German society's emotional rejection of both the banks and communist movements.

What Orwell is referring to is not the totality of Nazi appeal, because they positions themselves to have many, often conflicting with each other, but one particular appeal to a certain segment of society.

<comment><USER15> > What Orwell is referring to is not the totality of Nazi appeal, because they > positions themselves to have many, often conflicting with each other, but > one particular appeal to a certain segment of society.

What I want to say is that the amount of people who were throwing away comfort, safety and short working-hours in exchange of struggle was smaller then the quote implies. Their choice dont speak for humanity. German history does not give us reason to worry that alienation from having too good life leads to such catastrophe.

Struggle seeking segments of society had their own reasons to accept that deal and it was not that their all basic needs were well met. It was not collective identity crisis due to all problems being solved. A lot them were hurt, scared, damaged by WWI experiences, used to violence and inside country that was breaking down. They did not believed the comfort can be gained unless Germany gets to power again and destroys enemies.

And the wish for militaristic values did not came out of nowhere either - <USER2> boys were raised to be that way. There was a lot of social status to be gained by being in military plus guaranteed state employment (and whole state institutions being all ex-soldiers).

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> It's kind of the junk food or cigarettes equivalent for our brain (previously was TV but now it's back more addictive than ever)

We will probably look back at this period with the same sense of disgust at ourselves and at companies as we do now when we look back at the tobacco and junk food craze.

<comment><USER17> Is the junk food craze over?

<comment><USER14> In LA, there's plenty of people who are vegan, non-smoking yoga instructors who are glued to their phones.

It isn't yet an accepted idea that these things are addicting and bad for you, unlike junk food and tobacco.

</comment></comment></comment><comment><USER18> I feel like there's at least one article per day about this on the front page of HN.

Though it's good more and more people become conscious about the issues with social networks and addiction / attention loss.

<comment><USER19> I believe the reason the "problem" doesn't go away is because it's constantly framed in black and white terms: "Is social good or bad?" and usually supported with the same bleak facts: "it's makes use depressed, it gives marketers information about us."

It's a really a form of media control a la the Chomsky model of "allowing lively debate, but only within certain range of discussion." It's becoming tedious and conditioning us to stop considering how to bring our use of it under our control.

What would bring resolution (and great mental health) would be articles that talk more about how to use social media in a healthy ways. These comments are the ones the spring up in forums, including HN, where people have a bit of distance and self-reflection. For example, don't overly fetishize friendships from decades ago. don't give personal details. Don't give overly idealistic presentations of ones' self, etc.

<comment><USER20> > For example, don't overly fetishize friendships from decades ago. don't give > personal details. Don't give overly idealistic presentations of ones' self, > etc

Unfortunately these are the sorts of activities that social media sites encourage. The rush of dopamine from a flood of likes and comments is real and encouraged like a game.

As long as these sites operate as massive companies (selling ads), they'll keep encouraging the things that increase screen time.

> It's a really a form of media control a la the Chomsky model of "allowing > lively debate, but only within certain range of discussion."

I do agree with your point about increasing the scope of the conversation, but I'm not convinced that the healthy habits you mentioned are actionable for most users.

</comment></comment></comment><comment><USER21> I think of TV/gaming/internet/Facebook addiction as a generalized addiction to screens. You probably can't kick it cold turkey if your job involves looking at a screen. But you can do the next best thing: avoid all screens except your work screen. No smartphones, tablets, consoles, TVs... (A dumb phone is allowed.)

<comment><USER22> TV with no antenna and putting part of what used to be your Internet+services money to a dvd or two a month, and maybe a game every couple months on some older console, probably wouldn't be too bad. Or just using the library for movies. The Internet and its never-ending content are the main problem, IMO.

<comment><USER23> Main problem, how? Wouldn't doing what you say feel incredibly limiting since you know you could be enjoying so much more? Do you do what you describe?

<comment><USER22> > Main problem, how? Wouldn't doing what you say feel incredibly limiting > since you know you could be enjoying so much more?

More limiting in the sense that I would have fewer options for wasting time, yes. More limiting in that I'd be forced to engage with media I had on-hand, yes. More limiting in the sense that I'd somehow be worse off after, say, a year of that? I very much doubt it, and expect the opposite would be the case. Little of my use of the Internet is productive, what is productive is rarely more so than, say, reading, and mostly it serves to take time from activities that would at least not be any more a waste of time, and may well be more improving (including simply _sleep_ ).

> Do you do what you describe?

No. I'd cancel our home Internet _today_ if it wouldn't be incredibly inconvenient for my wife. She's a teacher, and she does and is expected to do way more work stuff online in the evenings and on weekends than I am as a developer, unfortunately.

</comment></comment></comment></comment><comment><USER24> I've read an article like this so many times... They called it "internet addiction" before, and accused people of persistent need to check their email.

What all of these authors seem to conveniently ignore is that "social media" is not television, not a single source broadcast, even though social media companies would really want it to be. Just a single chokepoint. Social media has real people on the other end. Mediated by social media companies, sure, but perfectly real otherwise.

Saying that people are addicted to it is largely equivalent to saying that people are addicted to other people.

<comment><USER25> _Saying that people are addicted to it is largely equivalent to saying that people are addicted to other people_

Think about it this way: a little sugar, salt and fat isn't harmful. In fact you need salt and fat as part of your diet to be healthy, and sugar was a rare treat - that's why they taste good. But if companies start adding more and more of these things to food, such that the consumers start to forget what real food tastes like, and then start making foods that are nearly all sugar and fat, well that is very bad for your health. That's what social media is. It's food without nutrients, and only the most shallow form of human contact.

<comment><USER26> I find the same in regards to Reddit. It is glorified trivia porn. Knowledge without nutrients, interesting but overall fleeting and forgotten in mere hours.

</comment></comment></comment><comment><USER27> I find the comments here depressing. Like everything, only a small portion of people are addicted to something. I use social media every day. Facebook, Instagram, Snapchat, etc. If I read the comments here, I should be alone in a dark room envying other people's lives. But last Thursday, I met some of my friends after work for a 5@7, Friday I had dinner with my wife and her friends. Saturday, a friend couple from another city came for an event in our city and we went walking and stopped to take a beer in an Irish pub. Then Sunday, 2 friends came home for brunch. Yes people checked their phone 1 or 2 times, but nobody was "addicted"...

Most people go on with their life while enjoying social media.

</comment><comment><USER28> Articles on social media detailing how to combat social media addiction or "the crisis of attention" or whatever clickbait title is the latest way that social media is capturing our attention.

<comment><USER29> yeah, do people not realize hackernews is "social media"?

</comment></comment><comment><USER30> "The 21st-century challenge will be how to live when others know us better than we know ourselves."

I think this is very well put.

<comment><USER31> I guess that would/could be correct. Though you have to account for the amount of 'propaganda' people post on their social media. It's not always sunshine as people portray on social media.

</comment></comment><comment><USER32> I've deleted my facebook account a decade ago, the last time I logged in when facebook revived the account and told me it was hacked.

I don't think I've ever really had the desire myself to reactivate it, my fellow students started posting into some shared group there but eventually everyone moved to whatsapp as that was more widely deployed and direct.

FB, for me, has no actual value other than capturing users like a venus flytrap.

<comment><USER33> _everyone moved to whatsapp_

Maybe the distinction is worthwhile to make if you try, but in general "I don't use Facebook, I use [thing that is also Facebook]" is not really a convincing argument.

<comment><USER34> While owned by the same company I don't think it traps you in the same way. Whenever I log into facebook it turns into a 10 to 15 minute thing that could have been one or two. I avoid that thing as much as possible, but that's not really a problem with whatsapp.

I do dislike the "status" feature they put in though...

</comment></comment></comment><comment><USER35> As a dude who doesn't use social media (no FB, linked-in, twitter, vine, snapchat, instagram, whatever I don't get the big deal.

People love writing angry posts on social media about social media. If you don't like it, don't use it, nobody is stopping you, quit the drama.

</comment><comment><USER36> We (with a friend) think that what people became with social media is really depressing. Nobody goes out anymore and everyone is connected online without really knowing nobody. Facebook, Twitter... made an awful society. The solution would be to connect these people more in real life. What do you guys think of a social media 2.0 that would connect people irl? We are working on something like that, a meetup like improved app. Would love to get feedbacks about the idea.

<comment><USER37> I miss the days when if you wanted to meet somebody you just went to a bar or coffee shop or started some sort of hobby and talked to people. Trying to push tech as a solution of a problem that was caused by tech to begin with...man, that's something.

<comment><USER36> I think that it would be realistic to think we will never get back to theses times. Tech has already been pushed too hard into new generations.

<comment><USER37> I can literally go do those things right now and meet people, I've made plenty of connections doing exactly those things. Not everyone you try to talk to will be into conversing with random folks, but some will, and that's fine. If you're too afraid to just talk to people, I don't know what people think an app is going to do to help.

<comment><USER36> I am agree with what you said, but the aim is to pull those who spend too much time on social medias (not necessarily afraid of talking to people) and make them go out ! btw, thanks for giving your opinion :)

<comment><USER37> If it helps someone actually socialize a bit, I'm all for it. I don't mean to sound like I'm shitting on your project or anything, it just feels so weird to me that it's necessary.

</comment></comment></comment></comment></comment></comment><comment><USER38> Every now and then, try to have an offline day. To me it has been very beneficial.

e.g: to get into the habit of reading, exercise, etc.

You will naturally end up doing something better than browsing a feed.

</comment><comment><USER39> Its probably nothing in comparison to video games and we dont talk much about that.

<comment> yoz-y I disagree on both points. Human population spends less time in aggregate playing games that on social media. I don't have a quote from somewhere but just from the monthly active users from various social networks it is quite safe to say that almost everybody is on at least one social network.

The second thing is, that people do talk about the addictiveness and bad effects of games _all the time_ , and have been doing so since games existed.

<comment><USER15> Monthly active is nowhere near any kind of problem.

I know no one who would flunk the school cause he can't glue out of Facebook. I know multiple people who had huge problems in school due to being unable to stop playing or woke up multiple times during night to care about kingdom.

<comment> yoz-y I mentioned the MAUs only to give some importance to the scale. Social networks affect an order or two magnitudes more people than games. Social networks lead to anxiety, depression and have been instrumental in many disastrous cases of mob justice and harassment.

People do get influenced by games and it can lead to problems you have mentioned. However, I do not think that gaming can transform the society as a whole. Social networks have already done it, both in bad and good ways.

</comment></comment></comment></comment><comment><USER40> My predictably unpopular theory is that highly social people are really _afraid_ of other people. Perhaps not without reason if one regards other humans as potential predators. So they designate a group of people _friends_ and use it as protection against all the other people.

Yet they remain afraid, and this fear is what makes social interactions addictive (like gambling; the great the fear the greater the high on the occasions when you don't lose).

<comment><USER41> You may be using a very nonstandard of "highly social", but doesn't it usually also imply that you get along well with new people?

<comment><USER40> Yes they get along with new people and have a large number of shallow relationships. Whereas I think normies and aspies tend to have deeper relationships with only a few people. Btw, they're not aware of their motives -- they don't _feel_ afraid (though I suppose they may have felt so when the whole process began, at school).</comment></comment></comment>


US Healthcare is an Embarrassment - <AUTHOR> http://jackealtman.com/us-healthcare-is-an-embarrassment/

<comment><USER2> I don't have any personal hardships with the existing system, but whenever I see my statement of benefits where a doctor bills $X and insurance pays them $X/4, I always scratch my head and think, "This is normal? There has GOT to be a better way!"</comment>


Comparing Payment Systems in 2014 - <AUTHOR> http://www.referralsaasquatch.com/comparing-payment-systems-in-2014/

<comment><AUTHOR> I broke down some of the core features of payment systems and how 13 of them stack up against each-other. Open to feedback :)</comment>


Executive charged for leaking iPad to hedge funds - <AUTHOR> http://dealbook.nytimes.com/2011/07/05/executive-pleads-guilty-to-leaking-apple-secrets/

<comment><USER2> Misleading headline. The employee in question was not an Apple executive or even an Apple employee. The employee worked for Flextronics.</comment>


EpiPen CEO: Blame the 'broken' system, not me - <AUTHOR> http://money.cnn.com/2016/08/25/investing/epipen-cost-ceo-lowers-price-mylan/index.html <comment><USER2> I mean, considering the FDA pushed out their competitors and made it hard for new ones to come to market, she's got a bit of a point. They rose the price because they could. It's not capitalism. It's not anything besides a broken system.

</comment><comment><AUTHOR> "This system needs to be fixed. No one knows what anything costs," Heather Bresch, the Mylan CEO.

I mean the hypocrisy level is off the charts!</comment>


I have some code for a music video site i tried to get going a while ago.. - <AUTHOR>

it's in rails, maybe it could help a noob get their head around rails, anyway, i'm not doing anything with it, so you can download the zip here:
http://www.src-dev.com/will/rebuzzcaster.zip
(it scrapes blogs and shows what music vids the bloggers are posting -- a kinda hype machine, for music vids.)
hope it's of use to anyone. <comment><USER2> thanks a lot.

pretty useful for a noob like me ... cheers</comment>


LevelUp raises another $12M from From Highland & Google Ventures - <AUTHOR> http://techcrunch.com/2012/06/07/levelup-raises-12m

<comment><USER2> Big raise from these guys. Plus they've lowered their processing rates to 0%. It's a race not only against other mobile payment startups, but also against the Walmarts and Targets of the world.</comment>


Ask HN: Java 8 or Scala? - <AUTHOR> We are going to start on a new project. We will be 7-8 developers. 5-6 know Scala basics. We are deciding between choosing Play with Scala vs Play with Java. What do you think will help?<p>I personally like less verbose code and that's why prefer Scala. But considering team would be working and shipping the project, not sure whether Java 8 or Scala would help better. <comment><USER4> If your team is open to learning new things and comfortable with the occasional bout of feeling lost, then Scala is absolutely the better choice. The advantages of Scala is not it's lack of verbosity primarily, (Ceylon, Kotlin, F#, etc. are all similar in verbosity) but its support for functional programming. And I should add that 'lambdas' do not make a language functional, imho.

Scala's focus on immutability (case classes, std lib), monadic comprehension (for expressions), type class support etc. all make it a joy to be productive in. But it also has proper lambdas that just work right (Java8s lambdas are done poorly for sake of backwards compatibility).

You'll find less of a need to rely on frameworks (DI is trivial with just language features, you learn them once, you're good, no spring needed), you'll have less bugs, and it will be more fun!

Reasons not to use Scala would be the lack of tooling (you're IDE will annoy you more than if you pick java), your team may get frustrated at times and need to ask the mailing list or IRC channel for help, and new developers who don't have scala experience will need a bit more handholding.

We're finding for some cases we get a 100x LOC reduction coming from C#. This is not a joke, and it's not about us writing extra terse impossible to read scala and fitting too much on one line. The type system just allows us to reuse a few abstractions EVERYWHERE. We are getting insane code reuse, even between teams.

<comment><USER5> I code Scala in IntelliJ and it's an absolute pleasure :-)

<comment><USER6> Agreed. I'm using IntelliJ Community Edition with Scala plugin. It works really well. Only settings I've changed were setting the font to Source Code Pro and turning off spell checking.

I'm absolutely loving Scala right now. I was writing a lot of stuff in Go until I started a new project that needed to leverage some Java libs. I had been wanting to try Scala, so I went with it instead of Java (or Clojure, etc).

I liked Go for it's elegant concurrency, ease of deployment, and fast compiler, but Scala's type system and composition with for comprehensions is really nice.

Java interop is pretty seamless so far. Scala has nice primitives for wrapping null and exceptions in safer ways and eliminates a lot of ugly x != null checks everywhere.

Coming into it, I'd heard that Scala was hard to learn, but I didn't find that to be true. I was only vaguely familiar with pattern matching, monads, traits, ADTs, etc from playing with Rust, but I found plenty of good resources for learning Scala.

I really found this series of blog posts to be helpful: [http://danielwestheide.com/scala/neophytes.html](http://danielwestheide.com/scala/neophytes.html)

</comment></comment></comment><comment><USER7> From my experience, Java while more verbose offers better tooling, standards, documentation and support. Scala certainly is more concise but there is a cost that you will incur later when trying to debug or maintain s large fast moving code base. Sbt blows, ide support for scala is spotty and good luck defining a code convention and standard that you can automatically lint and format. To me it's c++ for the jvm (not a good thing ☺).

The next thing I'd advise is to not use play but to consider dropwizard or better yet spring boot. You may be thinking "ugh spring.. Isn't that so heavy?" Possibly but it's a lot simpler to use, extremely powerful and well documented and supported. Play just doesn't have that maturity and support going for it that a spring or dropwizard have.

<comment><USER8> I tried ScalaIDE once and I hated it. I've also used the IntelliJ plugin for Scala and it was a pleasant experience. Would you explain what you're missing with the IntelliJ plugin?

<comment><USER9> It depends on when they used the IntelliJ plugin. I've been using it for a few years and it is much better now than it was when I started.

</comment></comment></comment><comment><USER10> Scala for sure. It is a more expressive language that leads to less bugs down the road. Encouraging lots of immutability is huge, as well as a bunch of other benefits.

There will be a transition time for non-scala devs, but it should easily pay for itself down the road.

<comment><USER11>
       It is a more expressive language that leads to less bugs down the road. Encouraging lots of immutability is huge, as well as a bunch of other benefits.

Deja vu. I use to talk just like you. My colleagues would too.

I miss Java's verbose-ness. It's hell, but for large codebases and tooling - <USER3> wish I had a bottle of JDK 8 right now.

I heard a lot of this "prescription"-like talk, it'll buy us a lot X down the road. I blame our "this or nothing" attitude toward scala.

We would unconsciously, I think, immediately cast aside any contrary information. We thought ourselves as using this perfect tool and were condescending to anyone who used other things.

We wrote everything in it. We fired 2 node/python coders.

We're too invested and afraid to admit reality, it's a flawed language. Too complicated. Too many idioms for the lexer to handle.

Frankly, the only scala engineer who ever admitted it (they outright ban scala detractors on the mailing list and freenode) was Brad Phillips. Don't take my word for it, I recommend looking him up.

<comment><USER12> I assume you mean Paul Phillips, the co-founder of typesafe? It's true that he admits scala is too complicated; but it's also true he keeps working in it and himself admits he hasn't found a suitable replacement.

</comment></comment></comment><comment><USER13> How well does the team know the domain in which the project rests? If it's a well trod domain, going to a new language (Scala) would do well to keep interest high, while not getting bogged down in the challenges of solving a known problem.

If, however, the problem domain is relatively unknown, I would recommend Java8, so you and your team aren't fighting two unknowns at the same time.

</comment><comment><USER14> My preference is Java 8 because I find the Scala tooling to be so-so. I really don't like sbt. I find Java 8 to be "good enough."

If you do like Scala, I recommend Martin Odersky's Coursera class. I took it a few years ago and it was great! Really fun and I learned a lot. He is a great lecturer.

One way that Scala does win big is supporting a repl style of development. One great example of this is the Spark repl.

If you live in the JVM world, Clojure (which I use more than any other programming language) and JRuby are also worth a good look.

</comment><comment><USER15> I work at a company that exclusively uses Scala for the backend of our applications/services, and I found that if developers are willing, it's almost never a problem to have them learn Scala within a reasonable amount of time, if they come from a Java background.

We found that it's very hard to find Scala developers when hiring, so we basically dip into the Java pool and look for strong and talented developers there, that are eager to try and learn Scala. We then train them on the job, which almost never takes more than a couple of weeks before they really become productive.

So I'd say, if you're confident in your team as far as their quality as developers goes, then go for Scala. The time lost in learning, will be made up in productivity once they get the hang of Scala and the start experiencing the productivity boost that a more functional approach can give you.

</comment><comment><USER16> The strange part of that question is you appear to have decided on the framework before the language. Strange because having used Play quite a bit, it's really not all that great in many ways, not good enough to be a default choice anyway.

I might consider taking a step back and reconsider your decision making steps to this point.

If for some reason you _have_ to use Play then the only sensible choice is Scala.

<comment><USER17> What would you recommend instead?

<comment><USER11> For a website?

Why scala? Because LinkedIn and Twitter use it?

I have had great experience with Django in the past 8 years. Nice tooling. Nice template engine. Nice ORM. Mature. Scalable. Robust.

The main detractor you'll hear about it is performance. You're just building a website. Even in situations where I'm recompiling LESS (bootstrap), with all debug tools on, and rendering images in the same pageload, it takes 200ms.

Since python is interpreted, you just refresh the page. No 10 minute compiling just because you had a typo.

One thing about django I don't like though is you never get the "snappy" feeling of just loading a page like lightning fast. Java / scala / golang gives the impression.

<comment><USER18> Account-created-2-hours-ago, did you ever use Scala, or are you just trying to troll (badly)? :-)

Edit: Oh, right. After reading your other comments, it's obvious that you haven't used Scala.

</comment></comment></comment></comment><comment><USER19> Scala. The integration with play is much better since it is written in scala. The Java api is just an added layer that doesn't really deliver.

</comment><comment><USER20> _5-6 know Scala basics._

Where will the team get Scala expertise?

Where will it get Java expertise?

What is the buy in to Scala from the team as a whole? What is the buy in for Java?

What is the level of expertise with Play?

What languages and frameworks has the team used previously on successful projects? What has it used on unsuccessful ones?

What matters more in this decision are the human factors, not the technology. That's why you're not considering Clojure among alternatives. If the team is split over language, that's a team problem and the solution can only come via working to get buy in from those who feel they have something to lose if Scala or java is the way forward.

Finally, if the long term goal is to transition from Java to Scala, Play with Java is a good first step. It gets Scala in the door, but keeps it out of the way as people are in the early stages of onboarding.

Good luck.

</comment><comment><USER21> Java is the right choice.

Before I get into that, you may want to not focus on the framework so much, at least not before you choose the language!

Scala is great for the right purpose, it's powerful and should make you productive much faster. Yes, Scala is much less verbose which seems like it would be much more efficient. Enter one Scala developer who has small stylistic inconsistencies and you have set everyone back quite far (especially when using other sources to answer a problem).

Java is super easy to find answers if you need to and super, super easy for one developer to inherit the code of another.

But then again, Scala might be the right choice if you HAVE to use Play, as Play was written in Scala.

<comment><USER11> Doesn't Play have documentation / API for Java?

<comment><USER22> Yes it does. But even after knowing some basic Scala, I find it significantly easier to work with Play on the Scala side. It feels more of a first-class citizen. However, this is just my personal opinion.

<comment><USER11> Can any scala package be accessible via Java? What are the catches? Could you go into detail?

</comment></comment></comment></comment><comment><USER23> Scala is more flexible (for better or worse) and less verbose (for better or worse).

Because of this, it's possible to be much more expressive in Scala _and_ it's possible to be much more terse/obtuse.

I like Scala's powerful type system -- I just have a hard time reading most other people's Scala.

If you're sure you can get a consistency of style and approach in Scala among your team, sure, by all means. But if you believe that you're likely, at least in the short term, to have stylistic inconsistencies among your team, I'd lean a little more towards Java (just on "worse-is-better" principle).

<comment><USER11> What do people mean when they say "powerful type system"? Does that mean it could potential be a downward spiral where everyone creates their own DSL?

I use Ruby on Rails and Django - and in ruby and python, it's interpreted on the fly.

How will a type system, let alone a "powerful type system", help improve ruby or python's web apps?

<comment><USER23> By "a powerful type system", I mean a type system that allows you to flexibly express more-complex constraints in a way that the platform (either compiler or runtime) will catch.

For example, Javascript's type system (such as it is) is not, in my opinion, as powerful as Java's -- since there's no compile-checking and the runtime coerces stuff all over the place and does basically no checking at any point.

Python's is somewhat better: there's runtime-checking, but it's duck-typed -- so you could call some array methods on an instance of, say, "FootballField" just because the FootballField has a "__len__" property and the runtime wouldn't catch it.

Java's type system is a tiny bit more powerful -- the compiler does a lot of checking for you (so you can enforce that a method must take an array or a List<something>), but it's not as flexible (until JDK8, there was almost zero type inference, so you _had_ to be super-explicit _everywhere_ ).

Scala's type system is more powerful still; traits allow you to describe similar classes in a duck-typed-esque way (without the classes themselves having to opt-in), and there's really good type inference.

I'm not an expert in Scala, so I could be wrong about some of its features in particular, but that's the sort of thing that I mean by "powerful type system".

</comment></comment></comment><comment><USER24> Scala.

Checked exceptions make Java 8 lambdas basically worthless.

Play is a Scala project first and foremost.

</comment><comment><USER25> In my personal experience, Java 8 is a safe bet. Yes, it is more verbose which I don't like either. If you avoid the over engineered frameworks in Java-land its not that bad. You mentioned Play, which as others have pointed out is a Scala first framework. I prefer modern Java frameworks like Dropwizard or Vertx.

I tried to evaluate Scala after getting to know some basics & was thrilled at how concise code becomes in Scala vs Java. However, Scala does have a steep learning curve. I found that there were many different ways of implementing the same thing, which is time consuming in the beginning. There is opinion that it pays off later, I was not able to get to that stage because of initial impediments.

As somebody else mentioned, using Spark API in Scala was a joy. Same code in Java becomes several times more verbose.

At the end of the day you need to evaluate your team & develop a consensus. Your team might have some valuable opinions too.

</comment><comment><USER26> In .NET as a similar choice, _very subjectively_ , I would pick C# over F#, because:

1) succinct != readable

2) ReSharper and Roslyn IDE support makes a difference

3) there is no work opportunity to learn it

4) learning it in spare time would mean not implementing something else - <USER3> would prefer to solve domain problems rather than language AND domain problems

<comment><USER27> This doesn't really make sense to me. C# is oriented towards imperative programming while F# is oriented to functional programming. The style of programming that best solves the problem and fits your teams' expertise should dictate the choice.

<comment><USER26> Are you sure you are replying to a correct post? Your statement is correct, but so are my points.

</comment></comment></comment><comment><USER28> If your devs are bright and want to learn something new, go for Clojure. If you already have strong Java skills and need to deliver fast, go for Java 8.</comment>


Building a Riak Cluster On Brightbox cloud - <AUTHOR> http://brightbox.com/blog/2012/01/04/riak-cluster/

<comment><USER2> Direct link: <http://docs.brightbox.com/guides/cli/riak-cluster/>

</comment><comment><USER3> Very good writeup. This specifically covers setting up the firewall rules to only allow inter-group communication. This is very important to understand when working with a Riak cluster because Riak itself has very little to no internal security mechanics. You must proxy Riak through some middleware or somesuch for any real world usage.

Something to keep in mind is the multi-zone/geographic clustering. Brightbox specifically mentions they have a low latency link between their zones. I would test throughly. Riak is built on Erlang, which at its core is a message passing language. Riak by extension is very sensitive to the speed, throughput and latency by which those messages are passed amongst its members. Again, test throughly, YMMV.

</comment><comment><USER4> Does it make a lot of sense to build a Riak cluster in a virtualized environment?

The clear win for Riak that I can see is being able to easily replicate some of the characteristics of AWS on in-house hardware.

<comment><USER3> AFAIK, the official stance from Basho is to not use a virtual environment. That said, Joyent does officially support Riak in their environment. The thing to look out for is not slow i/o but variable, unpredictable i/o which is what you get with virtual machines... unless they are your virtual machines in a private cloud.</comment></comment>


RobustIRC - <AUTHOR> https://robustirc.net/ <comment><USER2> [https://medium.com/@aji/robustirc-is-a- regression-a1e9b6c966...](https://medium.com/@aji/robustirc-is-a- regression-a1e9b6c966c5#.ug8r834u2) \- "RobustIRC is a regression"

<comment><USER3> I wish people who write these posts would tell us, the RobustIRC authors, about it, and would ask us for proof-reading.

> For the entire duration of the partition, users on the smaller half will be > paralyzed

No. RobustIRC nodes that are not part of the majority will cancel long-running GetMessages requests and refuse any other requests. The client will switch to a different node.

This is even mentioned as a possibility in a later paragraph:

> I'll leave the reader to think through some scenarios, such as establishing > a temporary domain of consensus on the smaller half, or forcing users to > reconnect to the larger half.

Given this piece of information, I'm not sure what the article's point really is. At least for the current deployments, the RobustIRC design works well in practice. Sure, strictly speaking, RobustIRC cannot _entirely_ eliminate unavailability (nothing can), but in practice you can work around unavailability really well.

<comment><USER4> I'll admit that there's a lot of gaps in my knowledge of how RobustIRC works, I tried to make that clear in the post. I was just enumerating the obvious problems with using strong consistency with IRC, RobustIRC being the most prominent implementation, and explaining how working around those problems ultimately leads to something only marginally better than what IRC currently is. (I apologize for the admittedly sensationalist title.)

<comment><USER3> I totally agree that RobustIRC is only marginally better than IRC, but that's exactly what we were going for. We wanted to have IRC, just without these annoying netsplits :).

</comment></comment></comment></comment><comment><USER5> It took me a while to actually figure out what this does. There's no clear "how does this thing work" documentation without diving into the RobustIRC protocol.

<comment><USER3> Did you read [http://robustirc.net/docs/adminguide.html](http://robustirc.net/docs/adminguide.html)? I thought it has a good description of what RobustIRC does.

There's also a presentation and presentation slides on [http://robustirc.net/docs.html](http://robustirc.net/docs.html)

If you have a suggestion as to how to make it more clear/more succinct (?) what RobustIRC is, I'd be happy to hear it and improve the documentation.

</comment></comment><comment><USER6> But what if robustirc goes down? :P

<comment><USER7> Then there's the systemd-provided socket which buffers any request while systemd's watchdog restarts the service. In the meanwhile systemd writes a coredump to the journal to which later gdb can be easily attached by running 'coredumpctl gdb $(which robustircd)'.</comment></comment>


Ironruby Release: 1.0 - <AUTHOR> http://ironruby.codeplex.com/releases/view/25901 <comment><USER2> Hmmmm. I'm wondering will this run on Mono?

<comment><USER3> It does. I've been writing a windows application with it, but I've been running the test suite and doing development using Mono.</comment></comment>


This Chicago Startup Sold Its Protein Bar Company for $600M to Kellogg's - <AUTHOR> https://www.inc.com/robbie-abed/this-chicago-startup-sold-its-protein-bar-company-for-600-million-to-kelloggs.html <comment><USER2> Previous discussion, different article. [https://news.ycombinator.com/item?id=15488492](https://news.ycombinator.com/item?id=15488492)</comment>


Wirecard's No. 2 Was Key to the Firm's Rapid Rise. Then He Disappeared - <AUTHOR> https://www.wsj.com/articles/wirecards-adventure-seeking-no-2-was-key-to-the-firms-rapid-rise-then-he-disappeared-11593798856 <comment><USER2> Wonder if he got on the wrong end of travel restrictions.

<comment><USER3> He's suspected to have checked for interpol warrants by faking travel to the philipines</comment></comment>


Git Is Simpler Than You Think - <AUTHOR> http://nfarina.com/post/9868516270/git-is-simpler <comment><USER2> If you don't understand git, then don't mess around with 'rebase', 'push -f', or any other command that tries to edit history. These commands assume that you have a strong mental model of how git works, and this is how the author of the article got into trouble.

It's possible to build a very successful git workflow using only the following commands:

        git clone git:...
        git add path/to/new_file
        git commit -a
        git pull
        git push

(Yes, commit before pulling, rather than vice versa.)

If you want to use branches, you need to add:

        # Showing branches.
        git branch -a
        gitk --all

        # Checking out branches.
        git checkout some_branch

        # Creating and pushing a new branch.
        git checkout -b new_branch_name
        git push -u origin new_branch_name

        # Checking out an existing branch.
        git checkout -b some_branch origin/some_branch

        # Merging a branch into your current branch.
        git pull origin some_branch

This workflow is extremely safe. At worst, you might need to resolve a merge conflict.

But if you start digging around under the hood, and you start editing your commit history, you'd better be prepared to understand what you're trying to do.

<comment><USER3> Why the -u on push?

<comment><USER4> It allows you to use `git pull/push' without specifying the remote. see: <http://mislav.uniqpath.com/2010/07/git-tips/> Section "Push a branch and automatically set tracking"

</comment></comment></comment><comment><USER5> The whole "downloading history of the repository onto your machine" thing about git is what makes it unworkable where I work. A normal checkout from SVN is over 3GB in size just for our team's tree. There are a number of binaries that get pulled in and updated for various reasons (SDKs, platform-specific binaries) and they are versioned for repeatable and automatable builds across branches, all self-contained with minimal dependencies. I dread to think what the entire history would take - it must be many 100s of GBs at least. It would certainly rule out the whole "working disconnected" idea on laptops, for one.

<comment><USER6> git-clone --depth 1

<comment><USER7> Shallow clones are essentially read-only, they can't push nor be fetched from. Unless you're prepared to regress to emailing patches around, a shallow git clone is actually less useful than a svn checkout.

</comment></comment></comment><comment><USER8> Thanks -- great article. This is the most readable and straight-forward explanation of git's internals that I've seen (and I've read a bunch of articles/books/etc. looking for resources to help others learn git).

I'd also recommend The Git Parable ([http://tom.preston- werner.com/2009/05/19/the-git-parable.htm...](http://tom.preston- werner.com/2009/05/19/the-git-parable.html)) for anyone who hasn't read it. Different focus, but also helpful for understanding git's philosophy.

<comment><USER9> I found git to make a lot more sense personally after reading <http://eagain.net/articles/git-for-computer-scientists/> . The git parable is also very good.

<comment><USER10> So if I have branched from master, onto experimental, and made several experimental changes that I want to actually use, then I can simply type:

        git merge master
        git branch master

from the tip of my experimental branch, and master will be moved up to the tip of the tree?

<comment><USER11> Not at all. Where did you come up with that? That would merge in any commits in master not already in experimental and the next command would fail because a branch 'master' already exists.

To do what you are describing you would do this (or something similar:

        git checkout master; git merge experimental

<comment><USER10> Thanks, obviously I'm missing some concept somewhere.

<comment><USER12> The checkout command moves you off the experimental branch and back onto the master branch.

The merge command then takes the commits in experimental that aren't in master and puts them into master.

<comment><USER10> Thanks, I think I may have been misusing

        git branch [some name]

I'll take a look at some of the suggested tutorials again. Thanks all. That said, I pretty much do straight-ahead main-line development, so this isn't a huge problem right now. I do most of my development after midnight, so there isn't a huge cognitive headroom left...

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> No, actually, it's not. And that post proves it.

You can do some things to make it easier on yourself (and others) but it's not simple. You find out how un-simple it is when you hit one of those magical corner cases.

Don't get me wrong, I love Git. I far prefer it over SVN and CVS. But it's not simple.

<comment><USER8> I think the author's point is that the git internals (i.e. the .git folder) are simple; I don't think the author is disputing that the commands sitting on top of the git internals are sometimes horribly complicated.

The fact that the contents of the .git folder can be explained in ~2000 words (10 min of reading) is impressive--this would be impossible with a more complicated data model.

FWIW, compare:

[http://www.google.com/search?q=what%20is%20in%20.svn%20folde...](http://www.google.com/search?q=what%20is%20in%20.svn%20folder)?

with

[http://www.google.com/search?q=what%20is%20in%20.git%20folde...](http://www.google.com/search?q=what%20is%20in%20.git%20folder)?

All the results for the svn search are about getting rid of these folders -- nothing explaining their contents.

<comment><USER14> > All the results for the svn search are about getting rid of these folders -- > nothing explaining their contents.

That would be because there's little to no content in the svn folders, and _none_ of it is user-consumable: all the metadata manipulation is done via svn's properties[0] and their cli interface (proplist, propset, propget and propdel).

Apart from these, the content of the .svn folders (at least before 1.5) is pretty much only duplicates of your checked-out files. All the brains live in the (remote) repository, not in the .svn folders. I've never seen any case where somebody would go muck around with the content of the .svn repos, the only direct manipulation of them users have a use for is stripping them for exports or because somebody did not `svn export` and sent .svn folders where they did not belong.

Oh, and svn has had a full-featured client library[1] (and bindings for most popular languages[2]) for a very long time, so people have rarely needed to essentially reverse-engineer the interaction process from a checked-out working copy.

edit: now that I think about it further, your very observation is proving the complexity of git, or at least of git's UI: it's not expected that users of svn ever go muck around with their .svn (and as I explained there really is no reason to), so there is no wondering or audience about that, whereas not only is it __expected __that git users understand the content of their .git, it's pretty likely it _will become necessary_ at one point in your usage of git, because you'll have no other way (learning the plumbing by rote is not an option until you've even done that, since it can only be understood if you know how git's store works, you'll just end up learning both anyway)

[0] <http://svnbook.red-bean.com/en/1.1/ch07s02.html>

[1] <http://svn.apache.org/repos/asf/subversion/trunk/subversion/>

[2] [http://svn.apache.org/repos/asf/subversion/trunk/subversion/...](http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/)

</comment></comment></comment><comment><USER15> Having used Mercurial and Git, I have to say I vastly prefer the interface of Mercurial. It still has its quirks, but overall I find it much easier to use, especially on Windows. Git was very clearly built as a Unix solution first, with Windows support hacked on later.

<comment><USER16> i tried to learn git and hg and i found that hg was so much more friendly to work with. when things go wrong in git, cryptic error messages are spawned and i have no idea what to do. when i do things in hg, error messages are actually helpful. even when things don't go wrong, hg constantly gives me helpful advice at the command line. example: after you do hg pull, it tells me that i need to do hg update. why can't git stuff like that?

<comment><USER17> I used both, too.

From the mercurial docs: "If you felt uncomfortable dealing with Git's index, you are switching for the better."

To be honest, after a few years with git, I feel uncomfortable _without_ the index.

</comment></comment></comment><comment><USER18> When git was born, many people complained about its poor usability and some people created friendlier "porcelain" scripts. Eventually, git itself became "good enough" and maintaining porcelain scripts became too much work to keep up.

Is it too late for an improved git user experience? With so many online tutorials and books, a new porcelain interface would have a tough time capturing much mind share (while still calling itself git).

For those looking for something simpler than git, I recommend _eg_ (EasyGit), a one-file Perl wrapper:

<http://people.gnome.org/~newren/eg/>

<comment><USER19> Personally, I think github is trying to become that simpler interface. We'll see how they do, but so far it is promising.

</comment></comment><comment><USER20> I would have really liked it if the author had mentioned exactly how the co- worker in the beginning had got into the "3-way merge" state, and some how got onto a non-existent branch. I don't know what it means, and I've never got there, so I'd love to know how it happened.

(or maybe the author did mention it and I missed it?)

<comment><USER21> It's the result of a merge conflict (e.g. after attempting a rebase). If you work regularly with other people you end up seeing this a lot (or rather, whenever you both edit the part of the same file at the same time).

</comment></comment><comment><USER22> Although I love Git, this whole thread exemplifies the way in which Git horribly fails my one success measure for good tools: you don't talk about them very much.

<comment><USER23> Totally agree. We switched from SVN to Mercurial around 6 months ago and I have to say I am annoyed that I have to spend so much time messing around with the tool rather than coding.

<comment><USER11> You can say the same with almost any non-trivial development tool. Vim, emacs, Eclipse, VisualStudio, etc all require time spent "messing around with the tool rather than coding.

Another fallacy is that "writing code" is the only "useful" thing one can do. Creating clean logical history and good commit messages (or other documentation) does not invole writing code, but that doesn't mean it is not important.

<comment><USER23> Where did I say that that coding is the only useful thing?

The point I was trying to make is that tools are productivity aids and if a tool gets in the way and distracts you from your main activity (or activities) too much it can be counter productive.

I use both Eclipse and VisualStudio and find those tremendous! A good tool hides unnecessary stuff from you and works in a clear predictable way. A tool is bad for me when it does the opposite.

<comment><USER11> The point I am trying to make is that all "productivity aids" have a learning curve and will require time spent "messing around" before they confer any benefit.

In my experience, once you understand how git works it gets out of your way entirely.

</comment></comment></comment></comment></comment><comment><USER24> I wonder what would happen if we'd take the git object model, totally as-is, and redesign a coherent set of commands to manipulate them. With simple and consistent switches, good command names (if at all possible), closely related to the concepts in the object model.

Would that be very different from what git is now? My underbelly says yes, but really I'm not knowledgeable enough to tell. Any ideas?

</comment><comment><USER25> Git is very powerful and I do like it more than SVN, but I felt like I had more trouble switching to it from SVN than if I had learned git from a clean slate. Switching my mindset from SVN-style centralized repos to decentralized git was the hardest part, as certain things in SVN didn't translate to git. Git is simple, but switching is not.

<comment><USER26> There true, it's hard to transform the concept in SVN/CVS to git world.

I remember when I was migrating from CVS to git, it's ok to understand cvs update is git fetch & git merge now, committing is the same, additionally I need to push the commits to share with co-workers. The hardest part to understand rebasing and branch management. But it worth to learn all these concepts, it make version control more flexible. It's pretty cool to use git reset and git push -f to modify the commits history (make sure you know what you are doing).

</comment></comment><comment><USER24> > _If you're anything like me, you probably wondered why you were the only > stupid person on the planet who didn't intuitively get Git already._

Spot on! I really thought I was the only one.

</comment><comment><USER27> (a bit off-topic)

Oh no! I now see cognitive dissonance everywhere. I realized that it's the same with git: maybe we like it so much because it took such a hard time to master. I still don't feel like I master it. However, reading some books on git and understanding the philosophy did make it feel simpler.

</comment><comment><USER28> Love the concept of the article but right out of the gate comparing it to a Model T and saying you must be a mechanic to operate it will likely result in a high bounce rate, and possibly just serve to re-affirm someones belief that git is, indeed, complex.

<comment><USER29> Git is intended as a tool for programmers, which are precisely those "mechanics" he mentions. Any programmer who's scared away by that doesn't understand what they do.

<comment><USER23> Err - Maybe we just resent having to spend so much time on the mechanics of the tool/s rather than our main activity which is writing code.

<comment><USER29> Oh, I agree. But if the net result is something that works better, the fact that it needs some internal tinkering shouldn't scare programmers away.

</comment></comment></comment></comment><comment><USER30> So what was the cause of the original error and how did you fix it?

<comment><USER31> There was a conflict while rebasing. In this situation you generally do one of:

1\. Resolve the conflict and continue rebasing.

2\. Drop the conflicting change and continue rebasing.

3\. Abort the rebase operation.

</comment></comment><comment><USER32> I read through the article waiting for the explanation of the "Falling back to patching base and 3-way merge?" line but unfortunately it wasn't explained. Git didn't become any simpler after all. :(

<comment><USER33> This line is irrelevant debugging information. The problem is that there's a merge conflict. This would happen with any version control system; it's not something unique to Git.

</comment></comment><comment><USER34> Great, entertaining writing style. Probably the most readable intro to Git I've ever read.

<comment><USER35> Yes, for someone who has never use Git is a very nice introduction to it.

</comment></comment><comment><USER36> _I made the executive decision to leave our comfy world of Versions because it seemed clear that Git was winning the Internet._

I ADORE git and can't imagine NOT using it now that I've switched, but the little sentence above packs a whole lotta lame in it.

 _Executive decision_? Gross. There are good reasons for them, but not many. If you can't win your team over you probably don't have a good argument for the change... which brings me to the next problem I have with that sentence: _winning the Internet_? That's a great reason to look into something. Not a great reason to switch your team to it.

Also, no. It's not simpler. It's pretty much just as complicated as You think it is. It's actually kind of a big pain in the ass to start using git.. but boy is it worth it.

</comment><comment><USER37> I wish the author would've explained the motivation to move from SVN to Git, other than 'it was winning over the web'. Was SVN just not working for them, for some reason? Are there things that he and him company wanted to do that wasn't possible with SVN, but was with Git?

<comment><USER38> Quite frankly there's no more reason for "why we moved from SVN to Git" topics anymore. It's been beat to death.

Better to keep up while the team is small than to try to move even more people over later and turn into mega-corp still using CVS.

Learning something new isn't necessarily a bad thing. I question people that are unable to try to learn something new every day. It takes a few minutes of your time and you can learn something. Sure, git might take more than a few minutes… but why not TRY?

As for requesting why they switched from subversion to git… yea, as I said, you have a billion articles written out there by now about WHY. There aren't more needed. The benefits are pretty clear if you read any one of those other articles.

Of course, this more leads into "why git and not mercurial (or any other DVCS)?" Which again, has a billion other articles written up on it.

</comment></comment><comment><USER39> The sea parted for me when I caught Scott Chacon explaining git.

      http://www.youtube.com/watch?v=QF_OlomyKQQ

It really is better in so many ways and once you understand how it works, you may say, like me, "Ahh, YES!"

And, yeah, he warns you about rebase.

<comment><USER40> For me it really clicked when I watched: <http://blip.tv/scott-chacon/git- talk-4113729> (also by Scott Chacon).

Once you understand the internals -- I remember being amazed at what .git/objects/ really was -- nearly everything about the git ecosystem becomes measurably easier to understand.

Once you understand how your project looks _in the eyes of git_ , it becomes a breeze to manage.

</comment></comment><comment><USER41> I read this, and think: cryptographic hashes are just too damn cool.

</comment><comment><USER42> This article was EXACTLY what my little brother needed! I've been trying to convince him to jump over to git for nearly a year now.

</comment><comment><USER43> Nice, you'd be surprised of how many people would start using Git because these kind of articles. No complications.

</comment><comment><USER44> If only promoters of Git put as much effort into fixing Gits usability as they do posturing about how everyone is wrong and how easy Git is, we'd have a better tool.

</comment><comment><USER45> ...and you are an idiot. WHY did you use rebase? If you are a noob, why won't you use the great GitHub for Mac app? It is even prettier than Versions. <http://mac.github.com/>

</comment><comment><USER46> No thanks, I think I will wait for another couple of years until the next fan- boy tool comes along.</comment>


Vehicle Control with Neural Networks - <AUTHOR> http://www.gamedev.net/reference/articles/article1988.asp

<comment><USER2> In early 90s CMU developed an autonomous vehicle steered by a neural network (search for ALVINN). The neural net had a single hidden layer with only 5 nodes. The running joke was that you only needed 5 neurons to drive a car.

[edit: here's the link to publications [http://www.ri.cmu.edu/research_project_detail.html?type=publ...](http://www.ri.cmu.edu/research_project_detail.html?type=publication&project_id=160&menu_id=261)]</comment>


Why would a normal person build its own spatiotemporal database? - <AUTHOR> https://blog.mireo.hr/why-would-a-normal-person-build-its-own-spatiotemporal-database <comment><USER2> Why would a normal person use the word "it" to refer to a human being?

<comment><AUTHOR> Nice one :) I suppose being a non-native speaker is not a good excuse?

<comment><USER2> On the contrary -- being a non-native speaker is an excellent excuse!</comment></comment></comment>


AWS Graviton2 - <AUTHOR> https://perspectives.mvdirona.com/2020/01/aws-graviton2/ <comment><USER2> (I work for AWS. Opinions are my own and not necessarily those of my employer.)

I've been doing some initial M6g tests in my lab, and while I'm not able to disclose benchmarks, I can say that my real-world experience so far reflects what's been claimed elsewhere.

Graviton2 is going to be a game changer. It's not like the usual experience with ARM where you have to trade off performance for price, and decide whether migrating is worth the recompilation effort. In my lab, performance of the workloads I've tried so far is uniformly _better_ than on the equivalent M5 configuration running on the Intel processor. You're not sacrificing anything by running on Graviton2.

If your workloads are based on scripting languages, Java, or Go, or you can recompile your C/C++ code, you're going to want to use these instances if you can. The pricing is going to make it irresistible. Basically, unless you're running COTS (commercial off-the-shelf software), it's a no-brainer.

<comment><USER3> It is surprising, because I was under impression that Java has so many optimizations for x86 and ARM was so new that it's almost impossible to beat x86 without very significant investments. It's nice to hear that I was wrong.

<comment><USER4> x86's age and complexity give it a significant disadvantage. Both the cache coherency model and the instruction set incur a lot of overhead to do at speed.

<comment><USER5> That's very interesting. Could you elaborate?

<comment><USER6> A lot of the most commonly run software out there doesn't use the large, complex instructions offered on x86, so a bunch of pristine silicon goes to waste. Use the space taken by AVX512 etc to make more, simpler cores, and you get more performance for the same price, or less cost for the same performance. Simpler cores are easier to clock higher with less voltage, and less likely to have defects that would pull down yields.

<comment><USER7> The big vector units aren't the problem though. They're a consequence of the big complicated schedulers that most x86 cores are designed with. As long as the core has to be huge anyway, you might as well spend some space on more powerful math units.

It's possible to design an x86 chip with much more priority on throughput per square centimeter, with many more simple cores working together, but I have no idea how it would work out.

<comment><USER4> There's a lot of logic and complexity on decoding, fusing, etc.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> > Here's comparative data between M6g and M5, the previous generation instance > type

Instead of comparing the 7nm Graviton2 processor against an 14nm Intel processor, I'd like to see its performance compared to an AMD Epyc 2 processor, which would be a more apples-to-apples comparison as both are "7nm" parts. Unfortunately Epyc 2 processors aren't available from AWS yet (but are already announced: [https://aws.amazon.com/de/blogs/aws/in-the-works-new-amd- pow...](https://aws.amazon.com/de/blogs/aws/in-the-works-new-amd-powered- compute-optimized-ec2-instances-c5a-c5ad/)).

<comment><USER9> If Epyc CPUs aren't available, then it isn't apples to apples.

A customer doesn't care about nm. They care about what's available. The apples to apples comparison is The best x86 available vs the best ARM available.

<comment><USER10> You can buy Epyc v2 CPUs from Newegg. It's just that AWS doesn't have instance types that use them.

<comment><USER11> > It's just that AWS doesn't have instance types that use them.

AWS offers instance types with Epyc CPUs

[https://aws.amazon.com/ec2/amd/](https://aws.amazon.com/ec2/amd/)

<comment><USER10> Yeah, but not second generation Epyc.

Their blog says the instance type will be called C5a: [https://aws.amazon.com/blogs/aws/in-the-works-new-amd- powere...](https://aws.amazon.com/blogs/aws/in-the-works-new-amd-powered- compute-optimized-ec2-instances-c5a-c5ad/)

Right now, according to the official C5a page, they are "coming soon".

</comment></comment></comment></comment></comment><comment><USER12> There are some interesting implications for widely deployed processors that are literally never publicly seen because they spend their whole life in a highly locked down data center. I wonder if things like Meltdown could have ever been discovered if researchers could only poke at the chips via EC2.

<comment><USER13> I believe the "metal" variants expose the processor extensions you'd need to discover Meltdown.

<comment><USER14> Also, AWS processors use off-the-shelf Arm Cortex/Neoverse cores, and stuff like Spectre is core-level.

</comment></comment></comment><comment><AUTHOR> * [James Hamilton] believe there is a high probability we are now looking at what will become the first high volume ARM Server. More speeds and feeds: >30B transistors in 7nm process 64KB icache, 64KB dcache, and 1MB L2 cache 2TB/s internal, full-mesh fabric Each vCPU is a full non-shared core (not SMT) Dual SIMD pipelines/core including ML optimized int8 and fp16 Fully cache coherent L1 cache 100% encrypted DRAM 8 DRAM channels at 3200 Mhz

* ARM Servers have been inevitable for a long time but it's great to finally see them here and in customers hands in large numbers.

<comment><USER15> What really stands out for me is "100% encrypted DRAM".

How efficient is this? Can different cores have different encryption keys, so that different VMs under a hypervisor can't benefit from breaking the hypervisor's protections?

<comment><USER16> Some Intel chips can encrypt memory with different keys for different VMs. This sounds great for marketing but adds basically no security whatsoever. The feature is called MKTME.

What's going on here is that "different keys for different VMs" does not actually improve isolation without a considerable amount of hardware or microcode enforcement. AMD has this type of tracking of which VM is which. Intel does not. I don't know what AMD does.

In any case, exception makes little difference. Cores aren't bound 1:1 to VMs, so the core can access any VM's data if it wants. And actually clearing the key on a context switch would require flushing caches and require that there is no cache shared between cores. The performance hit would be extreme.

<comment><USER17> In fairness to Intel they also have SGX which has encrypted RAM and also a lot of isolation logic, as well as working RA, recovery, versioned sealed data and a lot of other things that AMD's equivalent just doesn't do well or at all.

<comment><USER16> This is true, but you can't put a VM in SGX without massive software hackery. Also, SGX has been broken so many times in the last couple years that it's silly.

<comment><USER17> SGX has been broken by totally new classes of attacks and has been successfully renewed via microcode patches every time.

SEV was broken once, completely (at least on EPYC) in such a way that it could not be fixed. From what I understand.

So I'll give Intel a break here. Their performance is much better than AMDs.

The whole point of SGX is that people tried making an entire VM the security surface. That was the prior generation of tech (Intel LaGrande/TXT) and it didn't work. There's far too much code in an entire OS like Linux to make it secure or auditable (and without auditing none of these schemes mean anything).

Enclaves are a design idea that says, shrink the amount of code you have to trust and read to the smallest size possible. Only then do you have a chance of security.

It's unfortunate that this lesson has been learned and is now being lost again.

<comment><USER16> > SGX has been broken by totally new classes of attacks and has been > successfully renewed via microcode patches every time.

As far as I can tell, it's only "successfully renewed" if you have HT off. If HT is on, SGX is dead.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> [https://web.archive.org/web/20200125180037/https://perspecti...](https://web.archive.org/web/20200125180037/https://perspectives.mvdirona.com/2020/01/aws- graviton2/)

</comment><comment><USER19> Amazon will dominate cloud computing with these server CPUs. Who can compete with vertical integration at the sheer scale of AWS? AWS usage patterns tell them exactly _what_ to accelerate with silicon. A process that has been largely driven by Intel will be replaced by a process driven by the customer workloads themselves. These processors will only get better with time.

<comment><USER20> That is basically Amazon scale playbook 101 (aka flywheel), if there is an efficiency that can benefit the customer (e.g. lowering prices), they will chase it.

It doesn't matter if that means designing Graviton2 or challenging Fedex by trying to build the biggest delivery network in the USA.

</comment></comment><comment><USER21> I wonder when and how Azure and Google Cloud will compete with AWS in this market.

They could buy ARM processors available in the market, but I doubt they will be able to get them as cheap as AWS who builds their own.

<comment><USER22> Does Microsoft make any of their own silicon?

It feels like Google has been directing their in-house designs on ML/TPUs while Amazon went all in on ARM. It will be interesting to see how those bets pay off.

<comment><USER14> No, but Microsoft bought some off the shelf Ampere and Cavium/Marvell servers. But they keep them for internal use only for now :(

Huawei makes their own silicon and servers with that silicon — also only internal, not available on huaweicloud :(

The only other player is Scaleway who bought first gen Cavium ThunderX's way back when. And Packet of course but that's bare metal only, no cheap small VPSes.

<comment><USER23> Huawei Cloud does have Kunpeng ARM servers available in some AZ (at least I know Bangkok AZ2 has some). They also run managed Redis on ARM so cheap that it will cost more to run it yourself on Intel VM.

I'm excited to see the price drop when Elasticache moves to ARM.

<comment><USER14> huh! I see now that they are mentioned on the Chinese Mainland website, but not on /intl.

</comment></comment></comment></comment></comment><comment><USER24> This is good news. Are Linux server distributions for ARM64s yet on-par with their PC counterparts? Getting base layer software is not going to be an issue?

<comment><USER13> Been using Ubuntu on one for a few weeks; the only things I missed was a few Docker containers that weren't built, and aws-vault didn't have an ARM binary. I built my own, and aws-vault shopped a new release with ARM support 20 minutes after I whined about it on Twitter.

Everything else has been flawless.

</comment></comment><comment><USER25> Are there any security fears with virtualization on ARM (think Meltdown and Spectre)? I'd think it's been less studied than Intel's x86-64 chips.

</comment><comment><USER26> What services are people using to run continuous integration for ARM? I see Travis CI has an alpha. Azure Pipelines doesn't host ARM instances I think.

<comment><USER2> AWS CodeBuild supports ARM builds: [https://aws.amazon.com/about-aws/whats- new/2019/11/aws-codeb...](https://aws.amazon.com/about-aws/whats- new/2019/11/aws-codebuild-adds-support-for-arm--gpu--and-x-large-compute-typ/)

</comment></comment><comment><USER27> This is great news. Except that a ton of software doesn't support ARM.

When I was trying to shift all my current infrastructure onto a couple of RPI's, many of the Docker containers didn't support ARM (qeumu and buildx aren't reliable) and other software didn't support ARM either.

Unless there's a good way to go from AMD to ARM, I'm not entirely sure how great Graviton or other competitors will get.

<comment><USER28> Back in the late 90's and early 00's, there were a ton of cpu platforms around: SGI MIPS, DEC Alpha's, Intel, Sun SPARC, etc... while I will admit it was a colossal pain working somewhere that had all of those, it was often possible to recompile from source to get things to run. I'm not suggesting it's trivial, but given the incredible investment in ARM in the mobile space, the wind is at least at your back today. It certainly has got to be much easier than it was in the days of being the only person in the world trying to recompile an obscure open source scientific computing package for DEC Alpha. Commercial software is a different beast, but even there, the incentive will be high to do a port if lots of people start migrating to this.

<comment><USER25> Windows NT 4 supported x86, Alpha, MIPS, and PowerPC. Yikes.

<comment><USER29> All have eight bit bytes with 2's complement, same availible word sizes and float formats (with some complexity on the Alpha due to VAX compat). C code will mostly not care beyond endianness. The PDP is the strange one.

</comment></comment></comment></comment><comment><USER30> I guess the real benchmark is whether they'll put it to use with Lambda, Fargate etc.

<comment><USER31> I think Amazon mentioned they intend to use their own chip on All of AWS except their IaaS / EC2 offering, where you still get to choose Server running on x86.

That is why it was mentioned as the fall of x86 on Servers.

<comment><USER30> Sounds interesting, where did they say it?

<comment><USER31> _And AWS ' initial strategy is to move its internal services to Graviton2-based infrastructure. Graviton2 required significant investment, but AWS can garner returns and improve its operating margins due to the ability to cut out middlemen involved with procuring processors, power savings due to Arm and efficiency gains from optimizing its own infrastructure.

AWS services like Amazon Elastic Load Balancing, Amazon ElastiCache, and Amazon Elastic Map Reduce have tested the AWS Graviton2 instances and plan to move them into production in 2020._

Normally I try to find Primary sources rather than secondary like Zdnet [1]. But I think those exact wording was quite widely reported at the time.

They say they are not Anti-Intel or AMD. Which is true. ( They are only Anti x86. ) And they say the same to UPS and Fedex at the time.

[1] [https://www.zdnet.com/article/aws-graviton2-what-it-means- fo...](https://www.zdnet.com/article/aws-graviton2-what-it-means-for-arm-in- the-data-center-cloud-enterprise-aws/)

</comment></comment></comment></comment><comment><USER25> Out of curiosity, what's the state of Jazelle on modern ARM? Would it help server-side ARM, or has the world (and JITs) moved on?

<comment><USER32> Jazelle is dead. The v8 version (or maybe even v7; I forget) of the 32-bit architecture basically mandated that only 'trivial' Jazelle (which is the not- actually-there version) could be implemented, and 64-bit has never had anything like it. It was at best a technology of its time (when phone Java implementations were mostly interpreted, not JITs). It would be useless to a modern Java implementation.

</comment></comment><comment><USER33> When can I buy something similar for a homelab?

<comment><USER34> You can buy Cavium Thunderx2s off ebay. They're last gen ARM server chips. The performance won't be as good, but if its just for playing around with, they're more than adequate.

</comment></comment><comment><USER35> > believing that massive client volumes fund the R&D stream that feeds most > server-side innovation.

What does he mean here?

<comment><USER36> Intel/AMD design laptop/desktop (client) cores then put those cores into server processors. Because vastly more PCs are sold, they effectively subsidize server processors. Arm has a similar advantage, designing cores for phones/tablets and repurposing/extending them for servers.

<comment><USER35> Ohh I see, thank you!

</comment></comment></comment><comment><USER37> I'm curious about what languages or types of projects are already running on ARM servers in the cloud (and actually benefiting!)

</comment><comment><USER38> Annapurna, the goddess of job security.

</comment><comment><USER39> Damn has anyone tried ruby on of these CPU's is it really 20% perf improvement on nginx? These sound too good to be true

</comment><comment><USER40> This is great, but I'd be _really_ excited if we could go out and buy the chips ourselves instead of having to pay the Amazon tax and run our code on untrusted systems in the cloud. Of course, Amazon has little incentive to sell the chips, since it gives them a competitive advantage against other cloud providers.</comment>


Review requested for Django string signing - <AUTHOR> http://groups.google.com/group/django-developers/browse_thread/thread/297e8b22006f7f3a

<comment><USER2> This appears to be timeable. Rack and Rails just fixed a similar bug. Over LANs, attackers can figure out the correct MAC for any message.

Also, what the heck is a "salt" on an HMAC-SHA1 signature? If you lose the secret key, you've lost the verifier. You shouldn't be using HMAC signatures in so many places that keying them individually is a problem.

<comment><USER3> Thanks - this kind of feedback is exactly why we're putting this out for review.

Can you provide pointers or a bit more information as to how the timeable issue works, and what the workaround is?

Is there a more technically correct term we should be using instead of 'salt'? And is that feature a total waste of time? Remember, we're building a framework for other developers to use - so saying "you shouldn't be using HMAC signatures in so many places that keying them individually is a problem" assumes that developers using Django (who may have no crypto / security knowledge at all) will understand that. Is this something we should cover in the documentation?

<comment><USER2> You appear to have the same vulnerability as Google Keyczar had:

[http://rdist.root.org/2009/05/28/timing-attack-in-google- key...](http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar- library/)

Which leads to the question: why aren't you simply using Keyczar?

<comment><USER3> We try to keep Django's dependencies down to the Python standard library + a database adapter, so I'm pretty limited on which underlying crypto libraries I can use.

How big a deal is that timing attack? Would it be appropriate to ignore it by default, but provide people who are concerned about it the option to swap out the sha1 signing for something using an external library that isn't affected by it. Or even just drop an optional "time.sleep(random.random() * 0.01)" line in to the code that generates the signatures?

<comment><USER3> Forget the dumb time.sleep() idea, I just looked at the keyczar implementation of constant time string comparison. I'll roll that in to the library, thanks.

<comment><USER4> hello,

I just tested the keyczar routine, and it can still be found.

The sleep needs to be long enough, and random enough that it makes the other variance statistically insignificant.

cheers,

<comment><USER2> What version of Keyczar did you test?

Here's the current code:

[http://code.google.com/p/keyczar/source/browse/trunk/python/...](http://code.google.com/p/keyczar/source/browse/trunk/python/src/keyczar/keys.py)

From the code:

        correctMac = self.Sign(msg)
        if len(sig_bytes) != len(correctMac):
          return False
        result = 0
        for x, y in zip(correctMac, sig_bytes):
          result |= ord(x) ^ ord(y)
        return result == 0

This code performs the same ALU ops on every byte of the MAC, and does not perform any bytewise comparisons if the MACs aren't the same size. It's not timeable.

<comment><USER4> It is quite easy to time for yourself. Try timing it many times with a sig_bytes off by one(only one character changed). Then compare that with the correct one. You'll notice the (small) difference.

There are no tests for it in the keyczar that I could find. I doubt they tested it.

The reasons are many... but this is python, so each operation is much more complicated than C/asm. There are lots of branches, memory usage and cache effects - so code is much more input dependant - especially the integer ops used here. Take a look at this code to see one of the reasons why this python code has variable timing depending on input(like most code does).

x,y = 3,3

id(x) == id(y) # python shares ints in different variables

<comment><USER2> The only data-dependent comparison you've got to work with is a comparison between two register-scale fixed-width integers. I think you're doing something wrong.

Perhaps whatever you're doing to create the "off by one" case is disrupting the cache, and you're just seeing the effects of that.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment> brown9-2 I just want to say that it is really refreshing and awesome to see a framework developer/author/team reaching out to the community as a whole for this kind of review, rather than requesting feedback from a small group of committed contributors.

</comment><comment><USER5> I can tell you're pushing for terseness in the signed text (every character does count), but I'd definitely consider explicitly describing the cryptosystem and version you're using in each cookie.

Also, is there some code elsewhere ensuring that the separator character is always escaped during signing? I don't see anything explicit, but I could definitely be missing something; I haven't messed with Django internals much..

<comment><USER2> This is a pointless feature and Django shouldn't implement it.

If Django-signed messages are being persisted long-term in something other than an HTTP cookie, Django developers are abusing the feature. The sliver of code that's been published is not sufficient to protect long-term persisted data.

If Django-signed messages are simply being used for cookies and token URLs, then it doesn't matter whether they're forward/backward compatible. They have no long-term value. Applications should fail gracefully when unintelligible messages are presented. In 99.999% of proper cases, this simply means bouncing the user back to the login prompt to get a new cookie.

This isn't just pedantry. A fair subset of all cryptosystems have failed in later revisions because of negotiation vulnerabilities. Along with the "automatic key rotation" misfeature, this idea is as likely to burn you as it is to protect you.

<comment><USER5> You're right that it should just fail gracefully, and that people shouldn't use the data for anything long-lived. I'm not so sure the latter won't happen often enough for compatibility to become an expected feature, though.

What I'm afraid of is the future hypothetical case where the scheme changes in the future and a Django developer decides to add in backward compatibility anyway--by having the verifier check the presented text against both the old scheme and the new one.

If your main point is "don't reinvent the wheel, use an established system," though, I totally agree.

<comment><USER2> Negotiation in cryptosystems is usually a bad idea. It's a bad idea here. Anything that would make that feature useful would be an abuse or a threat.

One of the worst ideas Simon is getting from Reddit right now is that he needs to make this system _more sophisticated_. Version the cryptosystem! Use truncated SHA256! Revoke messages on MAC failures! Use random sleeps! Automatically expire keys! Look at this NIST standard I found!

What they need to do is _what every other web framework does_ , because every other framework has been inspected already.

</comment></comment></comment></comment><comment><USER6> Anyone know the status of OWASP for Python?

Here is a link to their unimplemented encryptor.py class:

[http://code.google.com/p/owasp-esapi- python/source/browse/es...](http://code.google.com/p/owasp-esapi- python/source/browse/esapi/encryptor.py)

</comment><comment><USER3> There's some really good discussion of this going on on programming.reddit: [http://www.reddit.com/r/programming/comments/ald1m/calling_c...](http://www.reddit.com/r/programming/comments/ald1m/calling_crypto_security_experts_help_review_the/)

<comment><USER2> OW MY BRAIN. No, don't truncate SHA256 to SHA1 sizes. No, don't use MD5 to make your URLs shorter. No, DO NOT clear all of a user's signed cookies when an HMAC fails --- these aren't passwords, they're crypto secrets.</comment></comment>