Stay away from Digital Ocean - <AUTHOR> http://gsundeep.com/digitalocean.html

<comment><USER2> I work for large host here is my take on this

1) They shut down my servers and suspended my account without notifying me. If your server is doing 1Gbs outbound I would expect them to shut it down ASAP for many reasons. Likely a more senior person detected the issue and shut down the server, then passed it on to 1st line support to contact you.

2)After contacting them, they immediately accused me of "launching an attack from their platform". You launched an attack vs a sever you are responsible for launched the attack, it's semantics but the support agent could certainly have worded it better, but not a big deal in my view.

3)After they performed their "investigation", they refused to give me any details and kept my account locked and servers offline. The investigation probably wasn't any more than their networks team detecting very high outbound traffic originating from your VPS IP that was clearly malicious. In that case the only explanations are that you are deliberately breaking their terms or your server is compromised, there is nothing else to discuss. They should really have sent you some standard text helping realise the reality of the situation but it wouldn't have hanged anything.

4)They refused to give me a copy of my data which delayed getting it hosted elsewhere (had to get ssl certs reissued etc). This is not great but if your server is compromised you have to accept that you will need to work from backups. First line support probably don't have a way of getting the data without starting the machine which they can't do in the circumstances. I'm sure one of their sysadmins could mount the virtual machine as a disk image to get the data for you, but that's not part of the service they offer or you're paying for. They can probably get your data given time and/or if you pay them but it's not reasonable for them to do this as a priority, especially as they are a budget host.

</comment><comment><USER3> This was the poster's fault. They failed to secure their box and then neglected to take responsibility when it was compromised.

<comment><USER4> How was OP supposed to take responsibility for a compromised server without access to the server?

<comment><USER5> Why would Digital Ocean give them access to the server ?

If the server is compromised then it should be permanently shut down immediately.

<comment><USER6> Can somebody please comment on what the risks (security, legal or other) are for a service provider that prevent them from at least giving the customer his/her data back?

<comment><USER2> The reality is that unless you are a really big enterprise customer with your own legal team who has negotiated custom contracts and SLA's then the host can destroy your data at any time. You have no comeback unless they admit liability or negligence, that's one of the reasons the support agent could not discuss details.

</comment></comment></comment></comment></comment><comment><USER7> This post was really insightful, they shut down my servers and suspended my account too without notification. I thought that it only happened to me, but it looks like it's a communal problem. Thanks!

</comment><comment><USER8> Sometimes I wonder if people act hostile to support staff from the get go in order to get a response so that they can build up an interesting communication history for a blog post.

Seriously though, why not be nice first, and ask for the things you need, before saying you are gonna post publicly about something. You have to consider that maybe the person communicating with you is just a support flunky that doesn't know how to grab the data you need off of your disk images.

Think of the amount of skilled labor they would need to expend to get your data off the disk images. Even if its just an hour, most engineers cost $80-100/hour. If you are paying $5/month for your basic Digital Ocean instance, that means more than a year worth of revenue on your account needs to be spent to make you whole, because you fucked something up and allowed a third party to exploit your server.

If you don't make backups and don't administer your websites correctly, I think Digital Ocean will probably be happy to see you go, since you are probably a negative revenue customer in the long run. They send you to Amazon or Google with their blessings.

edit: they should definitely have emailed you to let you know that they were suspending your account though.

</comment><comment><USER9> This seems pretty much the same pattern as my issue with DO last month. Better to move your service to AWS or Linode.

In Case anyone wants to check.

The Blog Post : [http://serdardogruyol.com/?p=122](http://serdardogruyol.com/?p=122) The HN Thread : [https://news.ycombinator.com/item?id=6438761](https://news.ycombinator.com/item?id=6438761)

</comment><comment><USER10> Coming next month: this guy gets banned from Google and Google refuses to explain why.

</comment><comment><USER11> I agree with "you get what you pay for" sentiment. With their margins, I can't see them having the support for any more than what they did. I think the takeaway here should be:

1\. Backup your data offsite.

2\. Monitor your servers or at the very least, your sites. If a site is important enough to pay for hosting, I would think it would be important enough to monitor for uptime. Bonus points for monitoring server resources as well.

3\. Trust noone. Who's to save Linode, Amazon, or Google would act any differently if they detected a compromised server on their network.

These things should be done regardless of how much you are paying for your hosting.

</comment><comment><USER12> As with so many other computer disaster stories, the moral of this one is, _always keep backups_. Even if your data lives in the cloud, you still need off-line backups.

<comment><USER6> Couldn't agree more.

Coincidentally, early this morning, I received a notification email from a droplet i own. It(my security agent process) had noticed repeated attempts to login and that it had blocked the offending IP address. When i traced the IP address, it was from Digital Ocean's network!

I am getting unnerved with all of this. Looks like DO is now a popular target for hackers. I would think the vast majority of droplets (despite their owners trying to keep things secure to the best of their knowledge) don't have much of a chance against a sustained attack by a capable and determined hacker.

So yes, I agree that keeping as near to real-time backup as possible seems to be the only takeaway from all of this (assuming that we would want to continue with such a discount hosting provider).

</comment></comment><comment><USER13> Sundeep was almost immediately hostile to the support people. While DO clearly could do a better job communicating to him, he's not helping himself with his attitude. Support folks often do not have the privilege to go off-script and make a positive difference for a customer, but they can always stick closely to the script and "regret any inconvenience" while being unhelpful, which is what I see here.

</comment><comment><USER14> Did they provided more info about this ? I'm still very worried, I posted a question about this situation including a link to your website and this post and I think it's not available in their website. So, not sure if I should trust them or not, I use it for personal use and been advising my company and we have lot's of projects running there, client work, etc... : X

</comment><comment><USER15> Even if Sundeep were at fault, at the bare minimum, D.O could've informed him that they are shutting him down. Also allowed him to get his files back. Neither of this is hard to do, even for a $5 host.

</comment><comment><USER16> I have been thinking about using Digital Ocean (moving from Linode) but I have heard a few stories like this that really make me second guess that decision.

<comment><USER17> Do you really expect a $5 VPS to be allowed to continue a heavy DOS attack? I wouldn't want to use a provider that _did_ allow that.

<comment><USER18> I would expect them to email me and let me know at least, particularly if I was paying them hundreds of dollars.

I think they're probably inundated with novices who don't do basic securing of their VPSes and experiencing a lot of abuse as a result.

</comment></comment></comment><comment><USER19> Not sure what you expect for $5 a month.

</comment><comment><USER20> Just curious, what were you actually trying to do that made them think you were launching a DOS attack?

</comment><comment><USER21> Is that the last message they sent?

<comment><AUTHOR> Yep, I haven't received a response to my last message. I've rehosted elsewhere though so I am not worried about not getting my files back.

</comment></comment><comment><USER22> <s> Guilty until proven otherwise! </s>

</comment><comment><USER23> Very troubling. I will not be signing up with DO.

</comment><comment><USER24> They work on razor thin margins so they shoot first and ask questions later. They don't have the resources to provide top notch customer service or investigate in depth, or prices would be much higher.

So you get what you pay for, I wouldn't move my money making sites to a service like that.</comment>


Getting to Docker 1.0 - <AUTHOR> http://blog.docker.io/2013/08/getting-to-docker-1-0/

<comment><USER2> I'd like to see a "docker for web developers" post / guide.

I want to know how to write a dockerfile (?) that I can run a command against, and have a dev environment materialize. Something I can track in source control along with my "main" source. Something to replace the difficult-to- recreate and outside-of-source-control LAMP and Flask environments I have now.

And I'd like to know how my sites' source code or untracked files (e.g. .sqlite file, mongo dump files) fall into that, while still being accessible to the docker container.

I imagine this would cover a huge percentage of people interested in Docker.

<comment><USER3> Perhaps ShipBuilder is right up your alley.

ShipBuilder is an open-source Heroku-esque PaaS which uses Go, Git, LXC, and HAProxy, with Docker support coming soon!

The Shipbuilder codebase is super easy to understand, and aims to make it fast and easy to deploy arbitrary web-applications.

Get total control over all aspects of your staging and production environments.

More info:

[http://shipbuilder.io/](http://shipbuilder.io/)

[https://github.com/sendhub/shipbuilder](https://github.com/sendhub/shipbuilder)

<comment><USER4> Has anyone tried this other Go-based Paas? [http://globocom.github.io/tsuru/](http://globocom.github.io/tsuru/)

<comment><USER5> I looked at it but it seems overly complicated, I got ShipBuilder up and running in a flash

</comment></comment></comment></comment><comment><USER6> Stating a roadmap is never easy, but hugely important for keeping the Docker team accountable. I believe that getting to a 1.0 release with the same fervor from the community will be a great indicator of future viability and success. That sets a pretty high bar.

<comment><USER7> No question it's a high bar. Then again, I would have never predicted the rate at which Docker has matured already. Color me optimistic.

<comment><USER8> We are pretty much forced to set this high bar because of the rate at which organizations large and small are adopting Docker. We will do everything we can to live up to the expectations!

</comment></comment></comment><comment><USER9> "August 7: Introduce this new architectural approach to the community, and provide a developer preview"

Where can we find this?

<comment><USER10> Sorry--typo on my part (since corrected). We introduced the approach today, and will make the developer preview available on August 15.

</comment></comment><comment><USER11> With a stable API it would be nice to have an API client for Windows for developers building software on that platform but deploying to Linux.

It would be great to be able to do a docker import from a checked out codebase in Windows.

<comment><USER6> Have you seen docker-py[1]? Bindings for other languages also exist, but the main theme is that the docker host can be controlled (if configured that way) by external machines.

1: [http://www.github.com/dotcloud/docker- py](http://www.github.com/dotcloud/docker-py)

</comment></comment><comment><USER10> Important news for Docker developers. Please let us know what you think.

</comment><comment><USER12> It's unfortunate that it requires a 3.8 kernel, as getting those to work on most machines has been in my experience rather difficult. I had to downgrade back to 3.2 on a Ubuntu server because it wouldn't boot with 3.8. I was able to get it to work on a DigitalOcean fresh VM, but unless I want to migrate everything to a fresh VM, which I don't, I don't see myself using it for a while.

<comment><USER6> Just an FYI - tryrethink.info and my blog (nick.stinemat.es) are both running on 3.2.0-48. While it is not the recommended configuration, I haven't had any kernel related issues.

<comment><AUTHOR> FYI - memcachedasaservice.com:

      ubuntu:~$ uname -a
      Linux ip-10-85-147-7 3.2.0-36-virtual #57-Ubuntu SMP Tue Jan 8 22:04:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
      ubuntu:~$ lsb_release -a
      No LSB modules are available.
      Distributor ID:	Ubuntu
      Description:	Ubuntu 12.04.1 LTS
      Release:	12.04
      Codename:	precise

Pretty stable so far (200 docker containers running on the box)

</comment></comment></comment><comment><USER13> Great plan !

Anybody knows if making docker run natively on Windows is possible ? (is there any sort of LXC like feature in Windows ?)

<comment><USER14> If this was going to be possible with Windows, it would have to be done by Redmond. And given that they'd be out of a Windows license by allowing containers w/in Windows (as opposed to VMs), I doubt that will happen.

Unless you're talking about running this as a Linux VM on a Windows host, in which case, sure - why not?

</comment></comment><comment><USER15> I would love to see an ARM port of Docker (LXC supports ARM).

<comment><USER10> We definitely want to see this too, and it is something being investigated for post- 0.8. In the meantime, you may want to read [http://kencochrane.net/blog/2013/05/running-docker-on-a- rasp...](http://kencochrane.net/blog/2013/05/running-docker-on-a-raspberrypi/)

</comment></comment><comment><USER16> little off topic. can someone of the Docker team comment on what its been like to work with GoLang on a big project like Docker?

<comment><USER6> You should start contributing[1] and let us know :). More seriously, it's a great topic for the mailing list and I encourage you to post it.

1: [http://github.com/dotcloud/docker](http://github.com/dotcloud/docker)</comment></comment>


From conservation of energy to the principle of least action: A story line - <AUTHOR> http://www.eftaylor.com/pub/energy_to_action.html <comment><USER2> Date: 2003</comment>


Report Predicts Foursquare Will Fail This Year - <AUTHOR> http://socialtimes.com/report-predicts-foursquare-will-fail-this-year_b115684

<comment><USER2> A bit unfortunate. FS grew too far too fast and too much at the whims of her VCs. The product now stands at an amorphous juncture between yelp, path, and Facebook, confusing users. I still believe strongly in the need for a mobile foursquare type product and community but I've lost my faith in foursquare as a company being able to satisfy that need.

</comment><comment><USER3> It's crazy to me that a company like that is worth even $1 million.</comment>


Show HN: Came up with a way to solve Rubik's Cube with 10 numbers - <AUTHOR> http://safecrackermethod.com/ <comment><USER2> Perfect! Been trying t solve these for years. Thanks!</comment>


Revisiting the NSA Suite B Announcement - <AUTHOR> https://www.fredericjacobs.com/blog/2016/01/27/NSA-QC/ <comment><USER3> Pre Snowden, I didn't believe in the conspiracy theories. However, it is by now apparent that not only were the conspiracy theorists right, but it was worse than anyone believed.

When you combine the Suite B announcement with the fact that the Director of the NSA (Mike Rogers) - as well as the former Director (Michael Hayden) - <USER2> both publicly taken a pro-encryption stance (1) in opposition of nearly every other three-letter agency in existence, you have to wonder what they are and aren't scared of.

a) They clearly have very little concern with today's conventional encryption.

b) They clearly are very concerned about upcoming developments, to the point that they are publicly asking the industry to skip Suite B entirely in favor of spending their R&D on implementing post-quantum algorithms.

I, really, -really- hate to be that guy, but these guys are in the know, and it doesn't seem like much of a stretch that we either have functional quantum computers running shor right now today, or the R&D is basically done, and we're a few months-years away from being able to.

(1) [https://theintercept.com/2016/01/21/nsa-chief-stakes-out- pro...](https://theintercept.com/2016/01/21/nsa-chief-stakes-out-pro- encryption-position-in-contrast-to-fbi/)</comment>


Show HN: Good Music to Work - <AUTHOR> https://github.com/victorqribeiro/radio <comment><AUTHOR> Always open to new stations to add or new visualizations. Friendly reminder that the app works on the background too.</comment>


Bill Gurley: startups seeking funding are starting to lower their expectations - <AUTHOR> http://www.wsj.com/articles/venture-capitalist-sees-signs-of-caution-in-private-tech-arena-1445366864 <comment><USER2>
      He said low interest rates have encouraged many investors
      to pour capital into private tech investing, fueling high
      valuations. If interest rates "stay at zero, rather than
      seeing a hard correction, you might start seeing volatility."

VCs are investing in private tech companies expecting 10-100x returns on about 20% of their fund. Which works out to at least 20% return per year on a 10-year fund.

It doesn't make sense to me that an investor who would choose a VC fund as their vehicle would suddenly choose a Treasury note when interest rates go up 1-3%. A VC fund should still outperform that.

<comment><USER3> Low interest rates are forcing asset allocators who have high (7-8%) nominal return targets into PE/VC

I go over the logic of this here, many seem to miss it: [https://medium.com/@emad/asset-allocation-not-share- prices-w...](https://medium.com/@emad/asset-allocation-not-share-prices-will- drive-vc-funding-723c0591d77c)

(my background: hedge fund manager/strategist with clients like those mentioned in article)

<comment><USER4> In your experience is the risk of the real money managers unconstrained? It seems odd these guys have to hit these rates of return, no matter what.

This same type of behavioral nuance comes up when looking at low vol strategies: empirically, low vol outperforms per unit of risk than high vol due to managers seeking high rates of return in combination with being unable to leverage.

<comment><USER3> Yes, the returns are set due to actuarial liabilities to repay the pensioners. Only other option is to hugely increase premiums for current workers & most of these funds are already hugely underfunded.

As they follow Swensen's endowment approach risk theoretically diminishes as they "diversify".

</comment></comment></comment></comment><comment><USER5> > Mr. Gurley said the root of many of Silicon Valley's problems is a > resistance to taking companies public. By staying private for longer > periods, startups have eluded the scrutiny of public-market investors that > is needed to help companies mature and become sustainable, he said.

A lot of Silicon Valley's high-flyers are not yet great IPO candidates. Of those that could be taken public, many would face much lower valuations in the public markets, forcing them to raise less capital or sell more of themselves to raise equivalent amounts of capital to what they're raising in the private market.

As such, one could argue that the startups have been acting completely rationally by taking advantage of the willingness in the private markets to invest at exorbitant valuations. Sure, the late stage valuations are all engineered and companies will pay a hefty price if they can't deliver the returns they're increasingly having to promise late-stage investors, but I think a lot of these startups have made a calculated decision to raise as much capital as they can selling the least amount of equity, and worry about the consequences later.

It's not surprising the traditional VCs aren't thrilled with this.

<comment><USER6> This seems so odd to me. It's like working the odds to stay as VC-funded as possible and basically avoid growing up - and most of them must understand that profitability simply doesn't exist in their model (before they pivot to being another advertising billboard).

The first step is admitting you have a problem, and as long as people keep giving you money, there's no need to admit anything.

Heck. As long as people keep giving you money, is there really a need to make money in another way?

<comment><USER7> The flip side of that coin is that some companies, under pressure to "grow up", become misguided—destroying their core product and user base in the process.

I would argue some business models aren't necessarily suited to generating significant or otherwise self-sustaining levels of revenue. However, that doesn't preclude these businesses from being incredibly valuable to larger, more established corporations with sizable cash reserves.

Of course, publicly admitting you're building for an exit is tantamount to suicide in the present climate, so it's no wonder the current situation is what it is.

<comment><USER8> >The flip side of that coin is that some companies, under pressure to "grow up", become misguided—destroying their core product and user base in the process.

If your core "product" is massively unprofitable, it's not really a product at all.

<comment><USER7> > _If your core "product" is massively unprofitable, it's not really a product > at all._

Tell that to Instagram or Snapchat.

<comment><USER9> > Tell that to Instagram or Snapchat.

This is no longer true for Instagram. It should generate $595 million in ad revenue this year, and is expected to reach $2.81 Billion in annual ad revenue in 2017. (Remember: this company was purchased for $1 Billion.)

So, to recap, Instagram was "massively unprofitable" for five years, after which it started bringing in revenue most easily measured billions.

In other words the notion that a product isn't "a product" until it's profitable is farcical.

</comment></comment></comment></comment></comment></comment><comment><USER10> Easy money is not necessarily all that it seems: It drives salaries up and creates an arms race for scarce talent that is crippling to many startups. It also creates a hype/hockeystick contest which is also largely unhelpful.

<comment><USER11> But if there were no easy money then those startups would have less money to spend on salaries as well. If we believe that easy money benefits established companies more than it does startups (not sure) or funded startups more than bootstrapped ones (almost certainly) then the net effect might be bad.

But an 'arms race for scarce talent' probably benefits a large proportion of the readers here, and harms a much smaller proportion.

<comment><USER10> It surely does benefit many HN readers, but overall the culture is harmed by so many people jumping into software development just because of the money. It has also lured many who would have chosen banking, etc.

And in spite of the better developer salaries, many startups can still not afford to let developers be makers and creators, and must instead focus on deadlines and other business metrics driven by fundraising.

If the runway for startups were longer, then longer-term thinking and strategy would be more prevalent. Easy money reduces the penalty of a failed startup, and makes it easier for anyone involved (including investors) to jump ship.

Since a startup is a stance about the future, this constrains startups who can get funding to those that are able to show traction after about a year, since there is little incentive to continue beyond that, and even a big series A won't pay for much talent in the valley anymore.

I think there is just an inevitable tension between investment as a visionary stance about the future vs investment as fuel for a machine that is hungry to grow. Both are essential aspects of the startup ecosystem, but inflated prices and easy money benefits the growth stage startup much more by crowding out the kind of environment needed for ambitious future stuff.

<comment><USER11> "but overall the culture is harmed by so many people jumping into software development just because of the money. It has also lured many who would have chosen banking, etc."

You've got this backwards. People who would have chosen banking are the ones who are attracted 'just because of the money'. IMO most people who become developers do so because they're interested in software/tech, but most people who become bankers do so mainly/exclusively because of the money (and perception of prestige).

"...and must instead focus on deadlines and other business metrics driven by fundraising."

This is not an issue for bootstrapped startups. For funded/fundable startups, being beholden to funding cycles is the flip side of getting access to capital.

</comment></comment></comment></comment><comment><USER12> Doom and Gloom. Tech shorting cycle has been initiated by the Borg.

<comment><USER13> Gotta push the market down before the next round of buy-low-sell-high!

</comment></comment><comment><USER14> full article: [https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c...](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB8QqQIwAGoVChMIxvS3_-7UyAIVGOJjCh3soQ5K&url=http%3A%2F%2Fwww.wsj.com%2Farticles%2Fventure- capitalist-sees-signs-of-caution-in-private-tech- arena-1445366864&usg=AFQjCNGo0ySDopngKnDdSt1IPgfmL00_XQ)

<comment><USER15> Thank you! Got hit with the subscription message.

<comment><USER16> I made an extension the other day (that does not ask for any permissions) that helps in these cases [https://chrome.google.com/webstore/detail/news-paywall- acces...](https://chrome.google.com/webstore/detail/news-paywall- access/adpfpconnigelofkfenblmdhbnlaafkg)</comment></comment></comment>


Tesla launches new Model S with updated design - <AUTHOR> http://techcrunch.com/2016/04/12/tesla-launches-new-model-s-with-updated-design/ <comment><USER2> Does _anyone_ else find the Tesla design to be its worst feature? I want to want one. Really, I do. But when I look at them (this update included) it just looks like a Lexus from 2005 or something. Not that I have something against the Lexus owners out there - it's just that the look doesn't seem to represent what's _inside_.

I wish it weren't true, but I think design is going to keep me burning fossil fuels for a while now. Am I the only one?

<comment><USER3> You might be, anecdotal evidence but I've taken mine to quite a few car shows. Overwhelmingly the feedback has said that their design is something people like as opposed to something crazy like the i3.

<comment><USER2> Yeah, I'm not really in the market for the i3. But if the Model S looked like an S3 or an M3 I'd be perfectly happy. I can't quite put my finger on why though.

Since I'm getting downvoted above, I'll take that as evidence that I _am_ in fact the only one. Ha!

<comment><USER3> Yeah, to be fair the design of the S is to have one of the lowest cD of any production car. A traditional grill generates a ton of turbulence so that's a contributing factor to the nosecone/grill-less design.

<comment><USER4> The S has a small grill for battery cooling, as do the X and the 3.

<comment><USER3> Yup, and articulated louvers on either side for extra cooling(always fun to hear them open up and the fans go full tilt at 120kW supercharging).

</comment></comment></comment></comment></comment></comment><comment><USER3> There were rumors that we were going to see a 100kWH battery with this refresh but looks like that will be for another time.

</comment><comment><USER5> The HEPA filter won me over.</comment>


Earth is missing a huge part of its crust. Now we may know why - <AUTHOR> https://www.nationalgeographic.com/science/2018/12/part-earths-crust-went-missing-glaciers-may-be-why-geology/ <comment><AUTHOR> I'm the first author of the relevant study [1] (open-access) so I'm biased to think this is cool. The unconformity certainly isn't everywhere (in some places there is no missing crust or time at all), but it can be found on just about every continent, and there has been surprisingly little previous quantification of this. Happy to answer any questions if anyone's interested.

[1] [https://www.pnas.org/content/early/2018/12/26/1804350116](https://www.pnas.org/content/early/2018/12/26/1804350116)

<comment><USER2> I also have a question. the article references the discovery of the new crater created by meteorite hitting Greenland

[https://www.nationalgeographic.com/science/2018/11/impact- cr...](https://www.nationalgeographic.com/science/2018/11/impact-crater-found- under-hiawatha-glacier-greenland-ice/)

would the erosion caused by glaciers, have enough time to erase the planet- wide evidence of that hit as well?

What conditions need to be there for the erasure to work quickly?

<comment><AUTHOR> Ah yeah. That crater is about 30 km wide, which is pretty big. Most craters follow roughly a 1:10 scaling between depth and diameter [1], so we can approximate a 3 km initial depth for this new new Hiawatha Crater. This crater is quite young (12 ka to 3 Ma est.), but if it had existed 720 Myr ago, then our estimates suggest it would have been borderline -- probably erased unless it got lucky and landed in one of the regions with little or no Neoproterozoic glacial erosion

The number one condition for fast glacial erosion is what's called "wet-based ice": if pressure and temperature at the base of the ice sheet (warmed by geothermal heat flow) is near the melting point, then ice tends to slip against the rock and erode rapidly; if it's too cold, then the ice will flow internally instead and not erode very well. Coupled climate-icesheet models so far [2] suggest it's possible to get wet-based ice even in a "hard snowball" state with limited precipitation from sublimation alone (though not under all parts of the icesheet at once).

[1] [https://agupubs.onlinelibrary.wiley.com/doi/pdf/10.1029/JB07...](https://agupubs.onlinelibrary.wiley.com/doi/pdf/10.1029/JB076i023p05683) [2] [https://www.sciencedirect.com/science/article/pii/S0012821X0...](https://www.sciencedirect.com/science/article/pii/S0012821X02011524)</comment></comment></comment>


Yanis Varoufakis: My plan for Europe can succeed where Macron and Piketty failed - <AUTHOR> https://www.theguardian.com/commentisfree/2018/dec/13/plan-europe-macron-piketty-green-new-deal-britain <comment><USER2> "Instead, it suggests that national governments agree to raise €800bn (or 4% of EU GDP) through a harmonised corporate tax rate of 37%, an increased income tax rate for the top 1%, a new wealth tax for those with more than €1m in assets, and a C02 emissions tax of €30 per tonne. This money would then be spent within each nation-state that collected it – with next to no transfers across countries."

Sigh -- it becomes awfully depressing to even try and become successful if you read these proposals. Might as well not even care and just go and live in a cabin in the woods somewhere.

</comment><comment><USER3> It boggles the mind how a demagogue who routinely failed to perform when given the chance and even jumped ship to avoid being hit with the fallback of his initiatives is still given any form of attention.

Snake oil salesmen have no place in the world stage.

</comment><comment><USER4> But Macron and Picketty haven't failed.

I guess we must read all about it on his new book... caviar communists...</comment>


Show HN : beautiful minimalist animations in Canvas - <AUTHOR> http://www.spintank.fr/spinlab/spin/

<comment><USER2> Thanks for sharing!

Make sure to check out the work of the talented developper we had the pleasure to work with — [http://grgrdvrt.com/](http://grgrdvrt.com/)</comment>


Show HN: With great power comes great responsibility - <AUTHOR> https://gist.github.com/1037209 This is for turntable.fm. I can't be the only one who has tried, because I've been beaten a few times by other "clickers." :) <comment><AUTHOR> I can't be the only one who has tried this because I have been beaten a few times while using it. I usually get a dj spot in the largest channels on turntable.fm pretty quickly, though. If only I knew what dubstep was then maybe I'd have some dj points. :)</comment>


Ask HN: How do people do remote pair programming? - <AUTHOR>

I am currently using skype/hangout screen sharing which sometimes can be really frustrating. Plus code don't synced (we have to constantly push-and-pull). So I'm curious how do people do remote pair programming? If there is no other alternative, are you interested in having something like google docs but for coding and sync with repo? <comment><USER2> I've been remote pairing for a while, and either use a Google Hangout or an RDP connection depending on latency and pair preference. RDP allows both parties to control the host, but seems to have higher bandwidth requirements and can lead to some other confusion when pairing (e.g. moving the mouse in the RDP window by mistake). The Hangout doesn't allow for remote control, which I prefer (it makes pair responsibilities very clear), and further, seems to share a screen more clearly than RDP.

I would not recommend trying to constantly push-pull to keep code in sync when remote pairing: you're cluttering the hell out of your repo and making "good" commits much harder to see.</comment>


Rockstar axes Red Dead Redemption team - <AUTHOR> http://arstechnica.com/gaming/news/2010/07/rockstar-cleans-house-red-dead-redemption-team-axed.ars <comment><USER2> Isn't firing a majority of the developers a normal thing to do for game development after the title is released?

<comment><USER3> Yeah this is pretty standard procedure for the game industry.

</comment></comment><comment><USER4> I know it's the original article title, but it's misleading. They didn't axe, the team, they cut 40 of 180 after the product launch. What is so extraordinary about that?</comment>


Serverless Takes DevOps to the Next Level - <AUTHOR> https://www.infoq.com/articles/serverless-takes-devops-next-level <comment><USER2> My real problem with serverless (right now) is that it just destroys your ability to have an efficient development workflow. Unless you want to use the really specific nodejs serverless framework, you're really in trouble. (As far as I can tell, [https://github.com/dherault/serverless- offline](https://github.com/dherault/serverless-offline) is the only offline- API-gateway).

If AWS really wants to drive adoption of their more-proprietary cloud tech, they're going to have to drive harder on local dev workflows. Google is doing better here (e.g. [https://cloud.google.com/functions/docs/emulator](https://cloud.google.com/functions/docs/emulator) and [https://cloud.google.com/pubsub/docs/emulator](https://cloud.google.com/pubsub/docs/emulator)) As someone who cares greatly about productive developer environments (it's a reasonable portion of my day job), I wouldn't touch serverless right now. Things slow down way too drastically if you have to push to the cloud to test what you're building.

I looked into starting a new app using serverless tech just yesterday. I don't really want to use nodejs on the backend (as I can use any language on the backend, and JS is not the pick of the litter), so that left me totally optionless unless I want to build up a bunch of infrastructure on my own (and sometimes I enjoy that, just not my goal right now).

As usual, the death of devops is greatly exaggerated, the role will evolve like any other. As the boring stuff gets easy, application complexity will grow. There's really still a lot of boring stuff that isn't automatically solved for you.

<comment><USER3> > [Development] slows down... drastically if you have to push to the cloud to > test what you're building.

This is accidental complexity, not essential complexity: We can keep our source in the cloud and edit it there. We can move change sets between servers, not whole files. (I get it that my current process, and probably yours, rely on working locally, but that's just an artifact from a different time.)

Amazon recently bought Cloud9, which is a browser-based IDE that edits remote files. [1] It's also possible to to use an old-fashioned remote-session. (It tickles me that eventually this will feel exactly like editing files in place on the production server.)

[1] [https://c9.io/blog/great-news/](https://c9.io/blog/great-news/)

<comment><USER4> > I get it that my current process, and probably yours, rely on working > locally, but that's just an artifact from a different time.

You say this, but... it's more of situation, "Do I trust all time and experiences to date, vs. something relatively new?"

Every dev has a local, with current setup. So, does ever dev need an instance of Lambda? It'll get crazy expensive to work on a team. We still need various environments for code review, QA, content entry, hardening, UAT, etc. All we're cutting out with Lambda is performance testing, right? (We trust AWS will be perfect and if it's not perfect we call them instead of trying to do anything about it ourselves.)

Dev, QA, Prod... those are your three basic levels everyone is familiar with for every project. Seems like AWS just found a way to bill me for all three... Hooray! =P Said mostly tongue-in-cheek...

I like the concept... but I'm hesitant to switch clients over to serverless until it's a little more mature. I pay for the cycles, right? What if one of the functions I upload to dev is just a poorly written loop? Whereas the dev would catch that on his local, now I think I have to catch it in my monthly bill... we still need tools to be able to verify the code we are putting out before it hits the cloud.

<comment><USER2> > What if one of the functions I upload to dev is just a poorly written loop

Fwiw, timeouts are at least partly a solution to this already. Seems right now you pay for invocations (at least on lambda), and lambdas are capped at 60s

<comment><USER4> Fair... still what about unintentional loops? I meant to update one record, but oops now I'm churning through the entire DB?

A lot of tools out there are great... I think WordPress, and HubSpot, and Marketo are great for what they do... but they all have an element of "use this and you won't need a dev!" And it's just wrong. The number of just horribly setup sites and email campaigns and personalization options that were set up by non-devs that just don't work... or worse, sort of work but then break in catastrophic and unrecoverable ways... I think this number is still pretty high when people fall for the "we don't need a dev" line.

Anyway I mostly dislike the title of this post... DevOps won't be going anywhere, we'll still need people who intimately know the systems and services in order to achieve enterprise-grade performance. Small businesses can dive in and think they are saving money... maybe it'll work for simplistic stuff, but realistically you'll still need technical folks for any edge case situation or scale.

Another small story... once I had one hour to meet with an angel investor, a guy out in West Texas who had a bunch of oil wells. He wanted to meet at a coffee shop near his house... Bunch of pickup trucks out front, no wifi, and poor cell signal so I couldn't really use my phone hotspot. If I didn't have a local instance, "Hey sorry it's all choppy and junky, it's the connection I swear..." I wouldn't want to say that.

</comment></comment></comment></comment></comment><comment><USER5> Say goodbye to mediocre programmers; ai is around the corner to write your avg crud app.

Serverless is going to significantly reduce costs that were needed to make mvp, prototype and so on. No sane business is going to rely on a single solution hosted by gce or amazon. Yes you can be fearless you can try it and maybe you can succeed but 90% of other businesses will still need to integrate with thousands of components and infrastructure parts. Devops is not going anywhere. In fact the demand will only increase.

<comment> FLUX-YOU >Say goodbye to mediocre programmers; ai is around the corner to write your avg crud app.

Oh yes, somehow only terrible and/or very large companies only manage to hang on to very old technologies and projects. I mean, there are virtually no sites using vulnerable frameworks and ancient password storage techniques any more. Those were killed off as they were introduced, and the programmers who did it the old way were sacrificed to some god or another. Mediocrity is apparently the bleeding edge.

<comment><USER6> AI was around the corner when I learnt LISP and analogue processor arrays 20 years ago. Still not here.

<comment><USER7> That's because they considered AI a nearly solved problem, so the brightest minds stopped working on it. I can't find a reference to that statement, but I recall reading it from someone credible.

<comment><USER8> Complete nonsense. I've worked for the Pentagon since the middle 80's, it was and still is by far the biggest consumer of AI. The brightest minds of the 80's just couldn't deliver a working AI system, despite the government investing billions in LISP and Ada projects.

The same happened in Japan and Europe, their best CS people failed to deliver the promised Prolog AIs.

</comment></comment></comment></comment></comment><comment><USER9> No this should be: say Hello to ServerlessDevOps. From what I have seen with disruptive technologies you basically start retraining or hiring people that can manage both onprem and cloud. Serverless is just another strategy but most blogs attempt to say "Oh this is a DevOps Killer". I remember heroku and google app engine were supposed to do this and so far its just another tool.

But as a tool you can really do great things with it. It is a great match for voice interfaces or notifications or even mobile backends. Also, inference for deep learning networks.

<comment><USER10> You are correct - Serverless DevOps.

Serverless actually makes DevOps fun and challenging - and especially if you work on multiple cloud platforms.

</comment></comment><comment><USER11> With Google Cloud, Serverless has been a reality from 2015! And welcome to Serverless to those coming from AWS.

Here is how Google Cloud achieves serverless. Ingesting Data: PubSub. Scales to millions of messages instantaneously, no need to spin up and spin down the capacity/shards (like as in Kinesis), exposes RESTful interface for ingesting messages from anywhere (web/mobile ... ). If you want a high-performance interface, you get gRPC as well. With RESTful interface to consuming messages, you can connect PubSub to anything you want or trigger Cloud Functions / write to storage / ingest to Stackdriver (Monitoring system) using managed services.

Querying Data: Big Query. No need to spin up a single server. Just write your query in SQL and watch the magic of a thousand servers being spun up to serve the query in a fraction of second and process a petabyte of data in a couple of minutes. btw ... you can ingest data into Big Query in real-time and analyze results within in seconds.

Process Data using Dataflow: For workflows that are more complex than SQL queries to ones that need to be running continuously on streaming data. Dataflow is the serverless version of Spark. No more running our of memory errors, much fewer hassles with hotkeys, no more manual performance tuning of buffers, no more cleaning up log folders. If you are using Spark, but have not tried Dataflow, you are missing some serious magic.

Google Cloud ML for Machine Learning: Cloud ML is a hosted solution for running TensorFlow jobs. No more manual hyperparameter optimization, no more spinning up GPUs, no more scaling up the cluster size. It's all taken care for you.

Container Engine: Hosted version of Kubernetes. I am sure, everyone is aware of what K8 is and its capabilities.

I am from a Data / Analytics / ML background. The above was my reality of Serverless since 2015. Google Cloud has serverless options for Web (App Engine) / Mobile (Firebase), and other purposes as well.

Having done PhD in Cloud Computing and Big Data and I don't find Infrastructure/Big Data a sexy problem anymore. To a large extent, it's a solved problem. Building a data platform with a team of 3 people that can handle 10+ petabytes of data is easy. What is on the horizon and unsolved yet, is AI!

Would love to see if there are any other better/compelling Serverless options.

<comment><USER12> > Having done PhD in Cloud Computing and Big Data and I don't find > Infrastructure/Big Data a sexy problem anymore. To a large extent, it's a > solved problem.

This kind of sounds like you've never managed a production system, sorry.

There's also the whole "how do you process and manage lifecycle for an exabyte of classified/sensitive data" thing that nobody's nailed down yet. "Serverless" is not the panacea people make it out to be; as usual, it's marketing-speak for outsourcing ops, which isn't always feasible.

People who talk about "data platforms" in terms of size are like people who judge coder productivity in lines of code. I guarantee your 10pb "data platform" will choke and die the minute someone shows up with 10gb of historical data and you have to get the timezones right.

<comment><USER11> > This kind of sounds like you've never managed a production system, sorry.

Don't be sorry. Instead, challange me with specific problems you have and I will show you how to build solutions.

> how do you process and manage lifecycle for an exabyte of > classified/sensitive data

The infrastructure for storing/processing data is in place. If you doubt me, please go ahead and give the above-mentioned tech stack a try and let me know if you still have any problems. Or give me a detailed description of what you have to do and I will tell you how to do it.

> People who talk about "data platforms" in terms of size are like people who > judge coder productivity in lines of code

Let me be more clear. I know how to build the infrastructure for that scales of data. I am not saying that I will write the code for processing data. That depends on what kind of data you got and what you want to do with it.

> I guarantee your 10pb "data platform" will choke and die the minute someone > shows up with 10gb of historical data and you have to get the timezones > right.

See my above comment for the answer.

</comment></comment></comment><comment><USER13> > Everybody is a cloud engineer

Sure - but does everyone want to be? I'd much rather have 2 people on my team get AWS certified than 10 people with google manage my AWS account.

Also want to point out that any kind of Infrastructure that needs to be HIPAA compliant can not process any PHI in Lambda. Naturally, Amazon will overcome that hurdle, but they just started signing BAAs for RDS Postgres this year.

</comment><comment><USER14> Isn't "serverless" the (slow) realization of Sun's agent-based grid computing?

I bought into Sun's vision. So much so I was gobsmacked by AWS' strategy. Which is genius in its own way:

Virtualize _every_ interface. Versus deploy self contained mobile code called "agents".

Watching "cloud" computing evolve into "grid" computing reminds me of the quote:

"Every sufficiently complex 'C' program reinvents LISP, poorly."

<comment><USER15> The last line is a paraphrase of Greenspun's 10th Law[0]:

"Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."

[0] [http://philip.greenspun.com/bboard/q-and-a-fetch- msg?msg_id=...](http://philip.greenspun.com/bboard/q-and-a-fetch- msg?msg_id=000tgU)

</comment></comment><comment><USER16> To be honest: it's a fad for startups.

Serious enterprise, with a need for data durability, consistency, auditing, real IT security, regulatory conformance etc. won't touch that stuff with a 10-feet-pole.

Also, once you choose your provider, you're locked in into this vendor (be it Amazon, GCE or Azure), while you can move your bare metal servers around to whichever colo/DC fulfills your requirements.

<comment><USER17> I think it is lemming stupidity. Building one's own "cloud" is easy, and can be one in a tiny fraction of the expense any cloud provider charges. The mindless march to the cloud is a huge competitive advantage for anyone "brave" enough to buck the propaganda and run their own hardware.

There is a breed of developer that is doing REST in C++, building services that live in only a few hundred K, and a single physical server can concurrently host thousands of such services for an expense of $75 a month, running 24/7 with 16 cores and 16 GB RAM. The same capacity on a cloud provider is exponentially higher for a single server.

You know that "fake news" idea? I think it has been manipulating developer opinion for a while. The cloud does not make sense, unless you are a cloud provider with a reason to sell that lie.

<comment><USER18> Exponentially higher does not even cover it.

You pay several orders of magnitudes more.

I've run the numbers several times, going from

colo -> rented dedicated -> rented VPS -> cloud VPS (think EC2) -> containerized cloud (think heroku) -> serverless (think AWS lambda)

is, on each step, at least a 2x or 5x increase in cost for the same computational power.

I started out a few years ago with my hobby projects on Heroku, migrated them to Digital Ocean, from there to OVH' VPS, and now migrated them last year to rented bare metal.

Every migration multiplied my available resources at the same cost, and it's definitely been worth it.

I did a price comparison of VPS and some bare metal providers over at [https://gist.github.com/justjanne/205cc548148829078d4bf2fd39...](https://gist.github.com/justjanne/205cc548148829078d4bf2fd394f50ae) and the result is pretty much just that. For 16$ a month I can get enough performance to run services handling tenthousands of concurrent users if I go with bare metal, or I can't even handle a few hundred if I go with the "cloud".

<comment><USER17> A few years ago, I got a deal on a cabinet at a colo, and then when one of the research labs at USC dumped their servers for the cloud, and they gave me 17 servers. I'd previously custom built a 32 core, 32 gig server just out of hacker interest, and between the USC servers and my previously owned hardware I put together a 196 core cluster with 3 redundant ( dev, staging, live ) environments for my own playground, and similar setups for hosting clients. Adding to and modifying the system for a few years, I had what would have cost $96K a month at AWS, but was only $600 a month to me.

</comment></comment></comment></comment><comment><USER19> I don't see how this is "goodbye" to DevOps. This seems to fit reasonably well into the DevOps methodology in that it makes it even more plausible for the people doing the dev'ing to do the ops'ing.

</comment><comment><USER20> I love these kind of articles. Serverless? Some commenter here stated "Even the network is software now" and a variety of related nonsense. Lambda and everything like it runs on - gasp - servers. Networks have _always_ been "software", running on some specialised hardware to make the packets linger less in the boxes they pass through.

Serverless as a name is hokum. Serverless, or rather FaaS, as a concept is extremely interesting though. However, if you are trying to sell it to me as "now you don't need anymore sysadmins or devops, or servers" you missed the mark. Most of time when I look at this stuff I come away with the distinct feeling that what is actually being sold is just another way to lock you in to a specific provider that has aggressively abstracted away the actual server, giving you significantly less control and significantly higher costs, for non- existing security.

I am not anti-cloud (I have been accused of that here a few times) and in fact have happily embraced cloud technologies since day one. I was deploying VMWare GSX Server in production around the time the twin towers came down, when everybody told me I was an idiot, and it would never work.

However, servers are not going anywhere for the time being, whatever the latest dev-fad is. Neither are sysadmins, or Devops. These magic functions still need to run _somewhere_ and wherever that is, it will, by its very definition, still be a server. The more something is dressed up in re/misdirecting language, the wearier I am of it.

</comment><comment><USER21> Every devops guy I know is really excited about serverless. I don't think it's because they think it's going to get rid of their jobs.

</comment><comment><USER22> The serverlees concept is also being applied to other types of services, like databases and data warehouses.

In this post below the company I work describes the reasons for a serverless data warehouse and the trends:

[https://blog.slicingdice.com/why-a-serverless-data- warehouse...](https://blog.slicingdice.com/why-a-serverless-data-warehouse- ae3b00146c26)

(Disclosure: SlicingDice employee here)

</comment><comment><USER23> Oh man, can't wait until this takes off so we can clear out all the data centers and use that space for something else.

</comment><comment><USER24> devops isnt going anywhere, its just learning a nee set of skills. you think any front end developer is going to have a strong enough understanding of AWS or Google Cloud to build and scale a serverless product? absolutely not. and most backend developers won't either.

</comment><comment><USER25> It's not serverless, it's just not your server

</comment><comment><USER6> Serverless does not make DevOps obsolete. It just make less of a must for everyday team. Do you want to enter to Russian, Vietnamese, or an African country in general? Then you will likely need devops.</comment>


If statements considered harmful - <AUTHOR> https://blog.deprogramandis.co.uk/2013/03/20/if-statements-considered-harmful-or-gotos-evil-twin-or-how-to-achieve-coding-happiness-using-null-objects/ <comment><USER2> Pardon my ignorance, but I don't even understand his point. I wouldn't even have bothered with a class at that level of abstraction.

If I find repeating if statements throughout my code I put them in a method, end of story. Pseudopython:

      def logging(logger, message):
        if null == logger:
          return
        if null == message:
          return
        logger.write(message)

I don't understand why the author would even bother with more than this, given his example. Also note that I used two return (disguised goto's) as guard statements to check the conditions before I do anything.

</comment><comment><USER3> I'm really waiting for the ultimate "Programming is considered harmful" article.

</comment><comment><USER4> This is a case of employing OO to circumvent a problem in OO languages. There's two potential problems with if statements: 1) non-locality 2) fragility.

1) can often be dealt with by changing the code, or parameterising. But in general, you want to be able to specify your own interface and specify how specific classes handle it. The article misses out one important detail, because the average OO language doesn't handle it: you might want to do this to someone else's class 2) You can make fragile code in any language, but the absence of pattern matching with totality checking makes it much worse.

Of course, there's a third problem that's implicit throughout the article: the inability to verify something's not null through the type checker.

The ideas in the article are good, but they're patterns for circumventing problems in your programming language. There's languages with no OO whatsoever that avoid the problems.

<comment><USER5> The problem identified has nothing to do with OO. Look at this code:

        logFile.write(message);

We might as well replace `logFile.write` with `fprintf(logFile...)`, and get the same result in C. So we don't need OO to experience this pain.

Conversely, this is only a "problem" if `logFile.write()` results in SIGSEGV or NullPointerException or whatever. But some OO languages (Smalltalk, Objective-C, others?) dodge this by making null a message black hole. Confusing, but terribly convenient.

One last point: notions of "pattern matching with totality checking" or "verify something's not null through the type system" presupposes exhaustive knowledge of the environment in which your code will run. Maybe that's correct: google.exe on Google owned hardware in Google-owned data centers will behave very precisely.

But sometimes it's _not_ correct. Your JavaScript code is running in a yet-to- be-written browser on an ancient version of some OS on random hardware. Your code's typechecking environment is unrelated to its runtime environment. Totality checking requires predicting the future. In this highly dynamic universe, languages like Haskell have no good solutions.

<comment><USER4> You're right, you could certainly experience the pain in a non-OO language that silently allows invalid values to creep through the system. However, it's an error _every_ OO language makes. Smalltalk, Objective-C and Clojure dodge it, but they don't dodge it for long: the nulls can now propagate further through your program, making it harder to track your problem down.

I'm not sure your last point buys us anything. I mean, any runtime environment can have bugs, and any future system can have cases you haven't handled. This will break your OO code just as fast as pattern-matching. Because OO dispatch is really just a special case of more general mechanisms.

Have a chat to some purescript guys about when they have trouble with JavaScript nulls. I bet the answer is "when we interface with raw JavaScript code and don't define our types correctly".

</comment></comment></comment><comment><USER6> In this case, I prefer FP-style destructured pattern matching (e.g. [https://doc.rust-lang.org/book/patterns.html#destructuring](https://doc.rust- lang.org/book/patterns.html#destructuring)) to OOP-style method overloading (FTA). In the FP style, the compiler can make sure you handle all possibilities.

<comment><USER7> It's worth noting you can implement something similar in OOP languages using Church encoding: [http://blog.higher-order.com/blog/2009/08/21/structural- patt...](http://blog.higher-order.com/blog/2009/08/21/structural-pattern- matching-in-java/)

</comment></comment><comment><USER8> tl;dr: OOP is sometimes good.

<comment><USER9> polymorphism is very good, but not handcuffed to OOP.

Clojure protocols, Haskell typeclasses (and many other examples I'm sure) provide the same functionality "a la carte" without the rest of OOP's features coming along for the ride (to paraphrase Rich Hickey and Stuart Halloway). More eloquently explained details in this talk at around the 21 min mark [0].

[0] [https://www.youtube.com/watch?v=cidchWg74Y4](https://www.youtube.com/watch?v=cidchWg74Y4)

<comment><USER5> One big missing feature in typeclasses is overriding. You can't "call into super."

A concrete example: you make a new type in Haskell, and you derive Show so it can be printed. But the default output isn't quite right - you want to add something to it. In an OO language you might "call into super" and append to the string. But in Haskell this isn't possible: you either get the default implementation, or you do it all from scratch.

More generally, typeclass default implementations are a lame replacement for overriding, and existentials are anemic compared to dynamic binding. This pushes Haskell interfaces towards rigid, static designs. That's fine if that's what you want, but let's not pretend it's equivalent in power to OO polymorphism.

<comment><USER9> that sounds a lot like sharing code by inheritance as opposed to composition. which is unrelated to dispatching by the type of the first (or implicit) argument.

i personally would prefer to code to interfaces and keep hierarchy separate from behaviour

<comment><USER9> perhaps I haven't felt your pain of rigid static designs because i mostly work in clojure, ymmv</comment></comment></comment></comment></comment>


Show HN: I scraped planetPython.org and got 10 years worth of Python history - <AUTHOR> http://python-station.etlsh.com/#/ <comment><AUTHOR> Also feel free to check out the building process: [http://etlsh.com/2017/09/04/scraping-planet-python-and- getti...](http://etlsh.com/2017/09/04/scraping-planet-python-and-getting-the- history-of-python-blogs-and-projects/)</comment>


Why I Do All This Walking ... (by Nassim Taleb) - <AUTHOR> http://www.fooledbyrandomness.com/whyIwalk.pdf <comment><AUTHOR> From the article: "Let me explain. If you consider your diet and exercise as a simple energy deficits/excesses, with a straight calorie-in, calorie-burned equation, you will fall into the trap of misspecifying the system into simple causal and mechanical links. Your food intake becomes the equivalent of filling up the tank of your new BMW. If on the other hand you look at food and exercise as activating metabolic signals, with potential metabolic cascades and nonlinearities from network effects, and with recursive links, then welcome to complexity, hence Extremistan. Both food and workout provide your body with information about stressor in the environment. As I have been saying throught, informational randomness is from Extremistan. Medicine fell into the trap of using simple thermodynamics with the same physics-envy and with the same mentality and the same tools as economists did when they looked at the economy as a web of simple links. And both are complex systems."

</comment><comment><USER2> So let's setup a system whereby a customized email is sent to users every morning: "Today was a great day! You walked 25 miles before a thrilling and ultimately triumphant encounter with an aged caribou that took 30 minutes of fierce running. Clean water was extremely scarce, but you managed also to find some grubs along the way. Feast away, the meat rots in 24 hours. Injuries included minor laceration to the left quadriceps and some blistering of the feet. Your search for a mate goes empty handed."

It's left up to the user to replicate the salient details in reality. Although perhaps with a mobile device, this app could be real-time.

</comment><comment><USER3> Venkatesh Rao (ribbonfarm) came to a very similar conclusion here: [http://www.ribbonfarm.com/2009/02/10/health-and-the-happy- ha...](http://www.ribbonfarm.com/2009/02/10/health-and-the-happy-hamster/)

 _"I wander around the Metro DC area as I work, covering as many coffee shops as I can, attempting to work up to the ranging average of 10-30 miles per day of our hunter-gatherer ancestors."_</comment>


Debian putting everything on the /usr - <AUTHOR> http://www.theregister.co.uk/2016/11/24/debian_testing_merged_codeusrcode/ <comment><AUTHOR> This was already submitted - [https://news.ycombinator.com/item?id=13041361](https://news.ycombinator.com/item?id=13041361)</comment>


Ask HN: Alternatives to Google, PayPal, Amazon, etc. - <AUTHOR> With bigtech treating customers and employees like crap, being involved in shady business practices, and whatnot, it's time to think about alternatives for their services.
Here are some alternatives I'm rather happy with:
Amazon (retail): Independent ecommerce stores as well as local and regional ecommerce websites such as Lazada
Amazon AWS: DigitalOcean, Hetzner, etc.
Google: Yandex for mail, Matomo for analytics, DuckDuckGo for search, Zoho for Docs, OwnCloud for Drive
PayPal: TransferWise, Stripe, Payoneer
What are yours? <comment><USER2> (Caveat: I'm in a major US city)

Amazon (retail): Target, Walmart, and BestBuy. Prices are the same as Amazon, selection is just as good, and it's much easier to return products. Infiltration by rotating throw-away Chinese brands is minimal, and the "in- stores" products are a good indicator of quality.

AWS: Unfortunately haven't found an alternative for this. Most people I work with demand a major cloud. Mostly we use Azure these days because the UI and DevOps integration is much better.

Google Search: They're all terrible, including Google. Google is the least-bad for me. I find the others unusable. I wish we had something better for this.

Gmail: You use Yandex? If leaving the US for mail, I would never go to a more authoritarian country... Fastmail is good in the sense that it works well and isn't ad-supported, but being headquartered in Australia is a problem a lot of people have.

Google Docs: Unfortunately, there are no great options here. The combination of best features and least-bad company seems to be Microsoft.

</comment><comment><USER3> I wouldn't feel comfortable recommending Stripe as an alternative at the moment, unless you're doing enough volume that you can skip L1 support.

Their English is often limited and their training on their products is often limited, so you can't really get answers on chat without 30 mins of incorrect random guesses (yes, I do know what a color picker is, but that's not the source of my question, Stripe agent), or spend a couple days on back-and-forth emails.

There's a Stripe person here on HN who's absolutely amazing and a major asset for the company. But as effective & professional as he is, relying on catching his attention on HN is not a viable long-term strategy for interacting with Stripe.

If Stripe were to raise the quality of their L1 support back to what it was even a year or two ago, I'd have no qualms about recommending them again.</comment>


Paul S. Otellini has died - <AUTHOR> https://newsroom.intel.com/news-releases/paul-s-otellini-1950-2017/ <comment><USER2> Wow. Saddens me. I had the opportunity to meet Paul a couple of times when I worked at Intel. Paul always impressed me as a great executive and a great person.

I have long believed that Paul is the best post-Grove CEO that Intel has had. Otellini was as good of a CEO as Grove, better in certain ways (consumer marketing instincts). His tenure was not as long as Grove's and is under- appreciated for that reason only.

</comment><comment><USER3> I remember Paul said his biggest regret was not working with Apple on the iPhone.

I wonder how different Intel would be today if that occurred.

<comment><USER4> Intel had an ARM chip division for Phone CPUs called XScale from 2002 to 2006 when they sold it to Marvell to focus on the more profitable x86 series.[1] He may have believed the x86 Atom chips could replace the XScale.

Xscale was widely used in Palm Treo's, Sony Clie's most Compaq Poquet PC's and the original Amazon Kindle.

His "biggest regret" comment is pure rewriting of history.

He made the wrong decision to get out of phone CPUs.

This is probably one of the biggest blunders in Intel's history.

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

<comment><USER5> What's odd is they still have an ARM Architectural license. They could jump into the fray if they really wanted to.

Probably would be pretty hard to justify, though.

</comment></comment></comment><comment><USER6> He was a very nice person who I greatly liked but as an alumni I'm saddened at the architectural missteps that plagued the company such as the Pentium 4 architecture changes that otherwise cost billions of shareholder value. There was a vocal part of engineering who were disappointed a finance guy was in charge for the first time.

<comment><USER7> This might be trying to put a post facto positive spin on a disaster, but I always heard from people involved with NetBurst that they learned a lot of lessons from that debacle that were applied to make Core as good as it was, and that without those it wouldn't have been nearly as good. Again, take that all with a grain of salt, but maybe the P4 was a necessary step to get all the pretty-good chips that came afterward.

Besides, if you're looking for screw-ups that hammered Intel's shareholder value, I don't think the P4 is even in the top 3. Selling XScale and missing the boat on ARM was much worse.

<comment><USER8> I still dot get that. I can see how they made that move based on the situation at the time, but if not with the iPhone then by 2010 at least with the iPad launch they must have seen how much things had changed. It also was far from too late to pivot back into ARM. Look what Apple managed to do in just a few years starting from scratch. It's not as if Intel worked out an alternative strategy either, if so where is it now? They've still effectively got nothing worthwhile in the mobile space after a decade.

<comment><USER9> Some people have speculated that selling low-margin phone SoCs would be worse for Intel than doing nothing.

<comment><USER8> I can see that from a margins perspective. Even if it were profitable it would depress Intel's ASP, but the strategic risk is also an issue. Apple now ships more processors than Intel. ARM chips have already appeared in Chromebooks and are feeling for a toehold in data centres. All I'm saying is Intel needs a counter to this threat.

</comment></comment></comment></comment></comment><comment><USER10> I interned at Intel in 2002. We (all the interns) were invited to hear him speak. At the time, I didn't know who we was, but he was some exec and, well, it's always cool to listen to execs.

I don't remember much of his speech, but when I remember most was bumping into him in the stairwell on my way to the speech. My eyes landed on his badge, and I said something like, "hey, I'm about to go listen to you talk."

We had one of the most friendly conversations I had.

</comment><comment><USER11> [https://youtu.be/1CgAKBf4bbU?t=59m3s](https://youtu.be/1CgAKBf4bbU?t=59m3s)

</comment><comment><USER12> Only 66? What was the cause of death?

</comment><comment><USER13> This is going to sound really heartless: Imagine working for the same company your entire adult life, retiring and dying 4 years later.

The thought of that, as a 26-year old, terrifies me.

<comment><USER14> That is if working literally means; working.

Steve Jobs died soon after he retired. And working at (nearly) the same company / dreams his entire adult life. Or more like he was forced to retire due to his health.

But Apple Park. As if He wasn't gonna let death get in the way of his Dream.

From reading books and listening to his talks he gave on life, I am sure he didn't regret it one bit.

"I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something." - Steve Jobs.

<comment><USER15> > "I have looked in the mirror every morning and asked myself: "If today were > the last day of my life, would I want to do what I am about to do today?" > And whenever the answer has been "No" for too many days in a row, I know I > need to change something." - Steve Jobs.

I agree with the sentiment, but it's also very easy for someone as financially secure as Jobs to make that call.

</comment></comment></comment><comment><USER16> He seems to have led a winderful and impactful life but it's a little shocking when so many people in the news, who seemingly led healthy lives, pass away in their 60s . :(

Why is this happening?

<comment><USER17> Totally unscientific, but I think it's conspicuous that is right around retirement. Maybe people who are living on sheer determination lose their purpose. Maybe people who need to be busy are suddenly bored out of their minds. Maybe work kept them moving, and without it they tanked quickly.

I have no real proof, but I'll be prodding my father to find a side job or volunteer work or a really deep hobby as he approaches retirement.

<comment><USER18> If what you say about deaths rising after retirement is true, it could be the loss of a routine. I suspect (and I also have no evidence for this) that a routine, honed over many years, is important to health. Also, loneliness is highly correlated with increased chance of death. The end of work life could significantly increase loneliness.

<comment><USER19> or you know, it could have nothing to do with these handwavy claims and instead, he may have had a terminal illness, in part triggered by years of extreme stress and super hard work.

</comment></comment></comment></comment><comment><USER20> 66!? Wow... That's sad in 2017. Not old at all.

<comment><USER21> Same age as Tom Petty; in fact they were born within 8 days of each other.

</comment></comment><comment><USER22> This might be a tad off-topic for HN, but the dates seem like an odd coincidence: I am noticing that, per Wikipedia, Otellini was born 8 days before Tom Petty, and they died on the same day.

Edit: it may be a silly observation I have made, but hn users are really silly to downvote this.

<comment><USER23> We simply don't know what exactly is your point. Lots of people have died the same day as Otellini.

<comment><USER22> And born a week and some change apart? In a first world country where 66 is certainly no spring chicken but considered just a tad too young to die?

I disagree with your assessment. I think this place is just full of people who are too easily offended by non tech topics appearing, and think perhaps that if they were at their own deathbed they'd look back and be glad they moved to discourage some random dope that casually compared the day's news to another headline. Very smug and lacking in social perspective.

</comment></comment></comment><comment><USER24> Second paragraph dives straight into corporate quarterly bonus bullet point bullshit! What about the human! This is easily the worst in memoriam I think I've ever seen. Written by some HR droid? What an embarrassment, I think I just discovered why I'd never, ever work for Intel

<comment><USER25> Getting outraged over a paragraph detailing someone's professional accomplishments in their professional obituary...It's Intel's article on their former CEO's death, what's it supposed to do, detail his personal life?

<comment><USER24> An obituary should detail a man and /his/ life rather than his relationship to a company, I understand how some people think this is justifiable, but I also just find it grotesque in every way. I know nothing more about him than I did prior to reading, or whether he achieved any kind of satisfaction in his personal life, which I think is kinda the point of these things.

Quarterly OKRs for a millionaire? I really hope they weren't the entirety of his existence, otherwise we're all doomed</comment></comment></comment>


What's wrong with Git? A conceptual design analysis - <AUTHOR> https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-conceptual-design-analysis/ <comment><USER2> The issue here is that git is:

1) A tool for managing collaborative work through a beautiful distributed graph theory tree model[1]...

2) ...with a very, very difficult to use UI. Unfortunately:

3) A good, intuitive UI for manipulating the underlying model without ignoring edge cases or removing functionality is extremely difficult, and indeed, nobody has done it yet.

So you periodically see these articles pop up decrying the UI, but nobody ever makes a great UI that wraps the underlying tools. This article talks positively about gitless, and it's a great tool, but it gets a good UX only be hiding/disabling large chunks of functionality. And like most tools...

4) Git suffers heavily from the 80/20 rule[2].

I'd say 95% of the time, I'm using maybe 5% of git's features. But the other 5% of the time, I'm using another 1% of git's features _but it 's always a different 1%_. I might go weeks without needing to cherry pick a commit, but when I need to, I _really_ need to...and gitless doesn't support it (or most other "complicated" features). But the reason git beat out the competition isn't git's excellent UI or large marketing budget, it's that those features actually provide significant value.

And so we get a slow drip of articles like this. "Man, it would be nice if there was a better git UI that had all its features!" It would indeed.

[1]: [https://xkcd.com/1597/](https://xkcd.com/1597/)

[2]: [http://www.joelonsoftware.com/items/2006/12/09.html](http://www.joelonsoftware.com/items/2006/12/09.html)

<comment><USER3> This article isn't complaining about the UI. They are very specifically attacking the /concepts/ that git uses – see the quote I posted further down in this thread.

It appears as if the complexity of git has created a sort of Stockholm- Syndrome, where people mistake the flaws of the system for symptoms of its magnificent power, and dismissing all criticism with an attitude of "let the hobbyists have something with a shiny GUI, this a tool for professionals".

But what people are asking for is /not/ a shiny veneer hiding the complexity, but a rethinking of the concepts that git uses. "Concept" here means mostly the mental model people form of how git operates, but that is often linked to the terms used and the internal structure.

As an easy-to-grasp example, filesystems generally operate with the "tree" concept. Note that there's nothing mandating such a structure – you could create a fs that's based on tags instead. Or weaken the tree metaphor by allowing cross-connections (i.e. linking). But given the choice of one concept, it creates certain assumptions about how to operate the system. And when those break down, people rm -rf and start over. Way to often.

<comment><USER4> True that they focus on concepts. The thing is, the overview diagram of git concepts on that page (which is in turn taken from the gitless paper) doesn't even mention _commits_ as a separate concept even though they are one of the most important concepts of git (and the ability to quickly juggle commits is crucial to the original git workflow).

That makes me a bit sceptical about whether the authors really thought through all the various use cases of git, i.e. those 5% that the GP comment talks about, and about their conclusions.

</comment></comment></comment><comment><USER5> > the elimination of staged versions;

So you can't selectively stage hunks and discard others? Or stash them after making a commit of the ones you staged?

> the elimination of the concept of Stash, and stashed versions;

This eliminates the possibility of quickly putting away work in progress to do an impromptu demo at your desk, or answer a co-worker's question about the current master, or (for git newbies) working effectively with git-svn (in companies where SVN is used) without needing to learn about local branching or rebasing.

> Thus, it is as if there are multiple working directories (one for each > branch),

So...like Subversion? Ew.

Does git have sharp edges? Absolutely. It's a tool meant to be used by professionals (or skilled hobbyists) to do work and build things.

I'm all for making things simpler to use, but putting training wheels (or guardrails) on a product meant for an expert user seems...counter-productive to me. To me it's like saying "Gee that cockpit has an awful lot of dials and instruments and things, we could probably take out a lot of the complexity if we assume that pilots will never have to deal with a stall" (I know nothing about planes)

I am also willing to admit that perhaps I'm too wedded to the time investment I've put into learning git and therefore assume that anything that attempts to make git simpler is flawed in some way. Maybe gitless really is the future of git.

<comment><USER6> _So you can 't selectively stage hunks and discard others?_

As other people have pointed out, most new version control tools can do this _without_ a staging area.

 _This eliminates the possibility of quickly putting away work in progress to do an impromptu demo at your desk,_

No it doesn't, and they explain how. With combined branches + stashes, you'd do a checkout of a new branch from the commit before your stashed changes.

 _So...like Subversion? ... putting training wheels (or guardrails) on a product meant for an expert user seems...counter-productive to me._

Did you even read the article or the original paper?

<comment><USER7> The latests iteration of hg crecord which is an interactive selection tool for chunks (see it in action here: [http://g.recordit.co/BfbSa7cMXn.gif](http://g.recordit.co/BfbSa7cMXn.gif)) Is far far better than git staging area. Intuitive to use, i can submit hours of code in few nice selective chunks really easy.

This sole function built in is a game-changer in mercurial for me.

<comment><USER8> It strikes me there's nothing inherently mercurial specific to this tool. This could very well be ported as a UI for git add -p.

<comment><USER7> I think GIT staging area wouldn't make it so nice to use in the end. Unless the whole thing is abstracted more, but then we get into the gitless discussion again.

<comment><USER4> I think it already exists as a graphical tool for Git, check out `git gui`.

</comment></comment></comment></comment></comment></comment><comment><USER9> The interesting thing about git is, that while it is heavily criticised for begin difficult, it is such a huge success.

Most of the time, criticism of git can be summarized as "Bad user experience", which is often blamed on git exposing its implementation details. I.e. most git criticism proposes that the backend of the VCS should be "private" and the user should see a carefully designed UI, that is optimized for workflows.

I think we don't need to redesign git in such a way, for the mere fact, that we already have a mature, distributed version control system that has a carefully designed UI and has a core that is opaque to the user: mercurial

In fact, given mercurial's age, the availability of github-like hosting services (bitbucket offered mercurial hosting for years) raise a very important question, that I would like "git-reformists" to answer as part of their critique: _Why has git won more market share than mercurial?_

My feeling is, that part of what makes git hard to new users is a "killer feature" for intermediate and advanced users. I.e. having a basic understanding of how git manages its data makes hardly leaves me with situations and repository states that I cannot resolve. Whereas in mercurial, I feel pretty much lost when I want to do something that has not been an implemented workflow.

Maybe, now that we know a lot more about DVCS workflows than we did at the time when mercurial and git were young, a new workflow-oriented VCS might make better workflow choices. Until then, I happily stay with git.

<comment><USER10> > Why has git won more market share than mercurial?

Because Git is used by Linux and was designed by Linus.

Those facts alone are good enough for most people to choose git over something else, not the technical ones.

Just like UNIX and JavaScript, technically better is not always what wins.

<comment><USER11> UNIX and JavaScript?

<comment><USER6> They're (counter)examples. Bad things that won.

"Worse is better" etc.

<comment><USER12> Genuinely curious: which OS ought to have beaten UNIX?

<comment><USER13> The Unix team created Plan 9 to supercede it, so that's the logical choice. BeOS had a lot of fans, too.

(Completely unrelated, I just discovered that the Plan 9 logo bears a striking resemblance to the Go logo [see the Wikipedia link]. Given Rob Pike's influence, I'm sure that is not a coincidence.)

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

</comment></comment></comment></comment></comment></comment><comment><USER14> Most of the comments here are missing the point. The functionality and architecture of git aren't what's being criticized, but the way this functionality is presented. In fact, gitless if built on top of git's architecture.

As far as I can tell, gitless still embraces git's distributed and incremental core. It just packages it in a way that's easier to digest. If you're a veteran and know your way around native git flawlessly, gitless probably presents little value. But if you're a notice just learning the tool, gitless can probably accelerate your learning curve without sacrificing functionality—you can still bypass gitless's abstraction layer when you need it.

<comment><USER6> I'm not sure that combining stashes and branches wouldn't be handy for advanced users either.

<comment><USER15> Why would I commit my breaking, work in progress experiments to a branch? Isn't that what stashes are for?

<comment><USER16> Because sometimes stashes are longer lived than we expect, and they're hard to work with if you need to do anything more complicated than popping. (Like resolving conflicts.)

I find that making a work-in-progress commit, and then resetting later ends up saving a lot of hassle overall. Having support for this beyond aliases (including putting that commit in a new branch) would be nice.

<comment><USER15> Okay, points taken. But git enables me to commit expermiments to a branch anyway _if_ I decide to. Gitless' lack of stash would force me to commit experiments to a branch.

</comment></comment></comment></comment></comment><comment><USER17> I personally think Git's staging concept is one of its best features. Yes it is different and increases the learning curve somewhat, but it also provides a lot of flexibility in what you commit. For anyone that thinks Git is too complicated, consider using Mercurial.

<comment><USER18> If my repo contains modifications I don't want to commit, I git-stash those modifications. I find it to be a lot safer: at least I can run the build + testsuite on what I'm actually going to commit, allowing the prevention of an incomplete commit (which means in practice, I nearly always use "git commit -a", and I find the index pretty annoying).

<comment><USER19> Haw can you partially stash a file?

<comment><USER8> git stash -p

</comment></comment></comment></comment><comment><USER20> Git only started really clicking with me when I started thinking of most of my actions as graph building and traversals. It also helps to realize that for most intents and purposes, commits in git are immutable and "destructive" actions such as rebase don't _actually_ rewrite history, but rather create a new path in the graph and moves your branch pointer to it, leaving all previous commits intact (though potentially hard to reach and subject to garbage collection).

</comment><comment><USER21> This reminds me of a well known comic: [https://xkcd.com/1597/](https://xkcd.com/1597/)

<comment><USER22> Thats really funny, because that's exactly how I use git. But I only blame myself for never finding time to read up a bit and understand its concepts.

</comment></comment><comment><USER23> recent discussion of the gitless project, which is presented as in this paper: [https://news.ycombinator.com/item?id=12621837](https://news.ycombinator.com/item?id=12621837) (300+ comments)

</comment><comment><USER24> The blog author doesn't understand Git that well:

        git add foo.rb
        // continue working in foo.rb
        git commit foo.rb

will commit the latest version of foo.rb.

That's because git commit handles its arguments by add-ing them to the index (staging area) before doing the actual committing.

I'm not so sure about the conceptual graph from the paper, either. The stash is a commit, it doesn't have anything to do with file states.

<comment><USER16> No, the author is correct. The add command adds that version of the file to staging, so subsequent changes will need to be added as well if you want them in the commit.

<comment><USER25> No, you can read the following in the man page of git commit:

3\. by listing files as arguments to the commit command, in which case the commit will ignore changes staged in the index, and instead record the current content of the listed files (which must already be known to Git);

<comment><USER16> Oh indeed, you're right. This didn't occur to me because I've never had a reason to use `git commit [path]`.

And I don't know if I'd call this error evidence of the author not understanding git, as much as I'd call it further evidence of the inconsistency they're highlighting.

</comment></comment></comment></comment><comment><USER26> This presentation of gitless makes it attractive. I'll give it a try.

One of my problem for which I didn't find a satisfying solution yet is to efficiently see the changes in commits and reshuffle and merge them.

Actually, when I do a change, I offten see and fix typos and other bugs or refactor code in the same step. So my commits tend to be a compilation of unrelated changes instead of clean atomic commits. It is a boring work to split these commits into nice and clean commits.

I know I should commit frequently (small changes), and then afterward merge related commits. But that is not easy with git and I suppose gitless too. So I tend to do big commits which is bad. Any suggestion how I could improve my commits ?

<comment><USER16> This might already be what you're using, but just case (and for other people's benefit) `git rebase -i` is _very_ helpful for reordering and combining a bunch of small commits. (I mention it because you're referring to "merging" rather than squashing or fixups.)

It opens a text file listing your commits prefixed with a command, which you can reorder and edit to change the history in one go. It's not completely painless, and I still prefer to do operations one at a time with it in case there are any conflicts, but it's still better than the alternative. (I'm not even sure what I do instead...)

<comment><USER26> Thanks. I saw that gitless has the option -p that is documented as allowing to select parts of a file to commit. I'm curious to test that. It seam possible to reshuffle commits using `gl fuse` which is a kind of `git rebase`, but there is no interactive mode as with rebase.

Just found a limitation in gitless. I can't publish tags.

</comment></comment></comment><comment><USER27> _Just some git love_ Didn't read, but there are so many articles out there... i started working with git from console ( when i didn't use the console that much ) and still compared to tfs, subversion etc. it felt like haven. I currently have to use SourceTree at Work... damn it makes git feel so slow... Somebody experience with [https://www.gitkraken.com/](https://www.gitkraken.com/)? Any point in trying it out? All the best

</comment><comment><USER28> While Gitless is a positive effort to rectify some of the shortcomings of Git, I wonder why the authors found it necessary to construct a veneer over Git instead of simply forking it entirely. While the veneer is nice on a trial basis of such functionality, to continue in that fashion for production use would require constant maintenance to remain in sync with any core changes to Git and its surrounding tool chain. A fork would be cleaner, yet interoperable with Git repositories and separate.

</comment><comment><USER29> This is a really cogent description of what I've felt about fit for a while but was unable to articulate. It's also written in an non-combative way.

</comment><comment><USER30> I feel about git the same way I feel about emacs.

In the time it takes to master git/emacs, one could have accomplished something seriously impressive.

Of course, this analogy doesn't completely hold because the basic functionality of git is pretty easy to use (especially with gui tools).

</comment><comment><USER31> Just my IMO - takes a bit to learn the basics but it's good enough, move on to more important problems such as privacy, security etc...

</comment><comment><USER32> The "problem" with git, imo, is that it's designed for hackers more so than professionals. Most people simply don't grok that. As someone with a background in Linux (for which it was designed, not the trendy "hacker" OSes like OS X), as someone who's willing to dig in and understand the internals, I find it beautiful. If I made a VCS from scratch it would end up being pretty similar to git.

<comment><USER3> The problem with so-called "professionals" is that they sometimes, when their egos are running a bit dry, they feel the need to dismiss others as "hackers" or "hobbyists" or "amateurs" or "hipsters".

It's mostly a problem for them though, because it makes them an easy mark. You can get them to spend a significant chunk of their time on earth patching kernels to get their ethernet cards working, and they'll gladly do it and feel really quite manly and professional and not lonely at all, no.

<comment><USER32> I'm not dismissing anyone in the way you think. I'm not passing negative judgement on the people I'm talking about - I just don't think they're hackers. I don't think they couldn't become them, either. What I'm saying is this: git is easier to understand with the context you have from being the kind of hacker I'm talking about. People only ever written rails or node from the comfort of Atom and their four favorite shell commands simply don't have the experience to easily understand why git works the way it does. That's not an inherently bad thing, but it does make git more difficult to understand.

</comment></comment></comment><comment><USER33> From a very quick read, yet another UI takedown without mention of underlying content-adressable arch.

As it turns out I do think both the porcelain and plumbing commands both suck, but I rather read a takedown by somebody who's learned all the layers.

<comment><USER34> > _yet another UI takedown without mention of underlying content-adressable > arch_

I'm wondering how nice architecture under the hood can be an excuse to have an Boeing-747-cockpit-style UI?

</comment></comment><comment><USER35> I suggest using a more commercial tool, like Microsoft Visual Source Safe. There is nothing wrong with Git (at least not at conceptual design level, or it would not have become one of most successful piece of software of all times - like top3, alongside with Linux, another masterpiece of the same creator).

<comment><USER36> _Microsoft Visual Source Safe_

Maybe Perforce or something, but recommending VSS in 2016? Hope it works out for you!

[http://www.highprogrammer.com/alan/windev/sourcesafe.html](http://www.highprogrammer.com/alan/windev/sourcesafe.html)

</comment></comment><comment><USER37> TL;DR: author blames his lack of understanding of the git concepts rather than the git concepts themselves.

<comment><USER38> The author clearly understands the git concepts.

<comment><USER6> Most git users commenting on the other hand seem unable to grasp that partial commits and staging areas are different concepts.</comment></comment></comment>


YouTube-Google Supports YT Video Thief-When Will It Stop? - <AUTHOR> http://www.vancesova.com/youtube-google-supports-yt-video-thief-when-will-it-stop.php <comment><AUTHOR> A horror story about how YouTube video thief is making money with stolen and re-uploaded videos to YouTube and how nearly impossible it is to contact YouTube-Google who share in the profits from such stolen videos with the thief. There is a partly happy ending to the story but what is sad is how intransigent and uncommunicative YouTube and Google are.

<comment><USER2> > A horror story about how YouTube video thief is making money with stolen and > re-uploaded videos

What is a video "thief"? Really? Why the video was created and released? So that the people can watch it, right? The "thief" is advertising the video and the things in that video, what's wrong with that? If the "thief" is getting more hits showing your video than you are getting with your delivery system, then I think something is wrong with _your_ delivery system. And I also think you are certainly not losing anything when somebody is watching your video - you are just getting more popular. Now try and monetize it instead of blaming those "thieves" who are working for you for free.</comment></comment>


GitHub Repo with nothing on it and a ton of likes and stars - <AUTHOR> https://github.com/forwardmiami/robinhood <comment><USER2> Seems to be this app

[https://www.reddit.com/r/Entrepreneur/comments/fcvn65/for_fu...](https://www.reddit.com/r/Entrepreneur/comments/fcvn65/for_fun_and_profit_we_made_a_robinhood_bot_that/)

"Please be patient as we prep the code for release. This may take a few days." "Go watch/star this GitHub repo, when we push you'll be notified."

<comment><AUTHOR> Interesting.</comment></comment>