erikb

Don't use the form. Use the legal way to quit any contract in your country. For instance that means sending a paper letter to their offices with the postal service confirming that the letter was received. If your contract has a quitting period pay the 3 months or what. Then stop and ignore all the annoying emails and letters they send you. They will not sue, because they would lose.

Might cost you $5 for the special letter type, and might cost you 3 more monthly fees than you would be willing to pay otherwise. But this is 100% save in all countries with a working legal system. Of course if they come after you with baseball bats or car bombs, then you probably can't quit their "services" anyways. ;)

For some reason kubernetes community doesn't like docker. I'm not sure why, though. Afaik Docker was what started the whole container hype, and docker-swarm having some nice features like dependency tracking that I'm personally missing in kubernetes (there's probably a project for that already which I haven't tried out yet, tho).

I think the bigger point in the future will be not AI beating known gambling activities (gambling in the sense that you put in money and have a random outcome about whether you get money back, let's not have a discussion about poker being gambling or competitive sport). The bigger point will be AI creating gambling activities that are even less resistable than our existing options. There might be digital drugs.

This is more about historical AI challenges. When Chess was beat people realized painfully and happily that they can't beat Go with the same approach. Therefore it was the new Mount Everest.

And Starcraft is a competition because SC1 was a game that was easily adaptable for AI hobby coders and competitions. A little like they have this Robo Soccer world championship for Robo builders. It's part of the domain culture I guess.

Which is not much, if you could've gotten $500M more in investments.

My experience is the complete opposite of Tim Ferris Wisdoms TM. If you are where the money is at, you have vastly more opportunity to participate on the receiving end of money flows as well as information flows. So if you are a keen developer in SF you will not live on $60k for long, but rather quickly bargain your pay up the food chain to $120k or $150k. And then check out how well you can live on $120k in Thailand, you know?

There are two exceptions to this rule of following the money, though.

Exception 1: When you hit the ceiling. It might be much higher than you initially thought, but there is one. And when you hit it, it might be more reasonable to try to stabilize on that level and find a more peaceful and cheap environment to live in.

Exception 2: When the current location is over hyped. Bay Area might still be in that phase where prices really are too ridiculously high. If you spend more than $60k/year on rent alone then maybe it's not wise to go there for $120k. But it might still be worth an internship or finding customers there.

> It's not just safety and security that must be provided, but social inclusion as well

Isn't it curious that we need to provide this as external source of safety? I'm not disagreeing, I also think so, but it's still surprising.

If we think about that "the machine" is objective, and that it can look into our hearts, that it wants to reach as many of us as possible, and wants to convince us to do its bidding by positive feedback loops, then why doesn't provide safety and security as a default?

Makes me wonder if our feedback loop is somehow "buggy" and that the feedback loop and our needs are not really correlating that much.

Have I missed it or are there no results in the article? First he has a long intro, which is nice. Then he goes way over board explaining his data and code. Then he talks about his mattress. If you've seen results can you point them out to me? Thanks.

Well, it's always a trade-off. When you inline stuff that is in separate functions you certainly increase the debuggability and readability and maybe even the performance of that one usecase you currently think about. If your goal is rather straightforward and your code is unlikely to be reused in high percentages in later developments (i.e. if you are coding a game in C++) then it might be a really good idea.

But if you work for instance on MS Word your goals will change 2-4x a year, you will have a list of hundreds of goals, your code might be reused in MS Excel without people even telling you, etc. In such kind of situation it is much, MUCH more important to encapsulate everything in classes and methods and functions (methods changing states, functions not) in a way that it can be treated as a black box. So in that kind of situation you are rather building lego blocks and hope that they can be connected easily enough to build the house that the little child, which is your boss, wants. In that case your lego blocks each need to be very testable and very connectable.

And the truth is that most of us live somewhat in the middle. We have a clear, highest goal that needs to achieved asap, while at the same time having loads of competing medium-priority goals that change all the time. So, while John's insides might be awesome by itself if you haven't thought about this topic before, please don't go full steam in that direction for a few years now. The best result is usually a little unclear and in the middle between two extremes.

you can try to find likeminded people on Mastodon (also currently on HN front page, an open source, federated twitter clone) or scuttlebut (imo more decentralized even, but quite focussed on solar punk in New Zealand) I guess. Also the Pirat Party (actual political party in case you don't know) uses a similar system IIRC.

And you can probably just start with the community around Decidim and work your way outwards to a wider community by participating in discussions and learning to know people.

Until now the destruction of jobs through progress has never reduced the amount of work we needed altogether. For instance think about how the development of transportation created dozens of new jobs actually, and brought us in many regards onto new levels that wouldn't have been even imaginable before. I wouldn't worry too much about something that might not be just-bad and instead try to figure out what can be done with the changes that we already see. E.g. all this nice virtualization and automation means it's so much easier to share code and changes and ideas, and helps us communicate over borders, language barriers, etc.

Storage and network stability is much higher if you run it on top of Openstack. k8s on baremetal is a pain in the butt. Disadvantage is that you have even more layers of abstraction.

I think you can have both situations. I still remember a talk from a Google person maybe around 2010 where he showed clearly that if you try to make the data "better" but in general have way too little data points, then it can't be useful either.

It's just now that we had almost a decade of pushing towards more IoT and more Big Data, that many companies have huge data lakes that they don't know how to make use off.

So instead of applying one of these lessons it's probably best to see where one is lacking (quantity or quality) and work on resolving that specific problem accordingly.

It seems like the dissonance you felt from reading comes from the article being written more in a business style of writing and thinking rather than a technical style which you are more used to.

For instance the "velocity data" and "but over a decade it makes a difference" parts. From a technical perspective it's awesome if you know that thanks to the data science you can outcompete others over a decade. But in business terms thinking is quarter based (i.e. three month) for short term and yearly for long term. The current leader that has to spend his budget on data science or other stuff has to find an advantage in it in the next few weeks after implementation, because usually making it happen takes already a quarter or two.

You might think they are idiots for thinking that short term, but their goals are also set in this way. So if they invest heavily in a topic and don't see any results for 3 quarters they might be replaced.

So if you say algorithm X will cost him 80% of his budget to implement but only shows results ten years later, for him that's the same as "no results". It's just the game he has to play to stay in the game.

I personally think this is part of why companies will not be able to make a drastic change in their DNA and instead will be replaced by the next generation of companies who comes out of start-ups, or be replaced by companies who already actively participate in the market in other areas and have the right DNA to take on the market. For instance Amazon is already more data driven than the traditional super market chains, therefore they now can attack that space with their modern technology.

> And again he is contradicting himself. Because if you make an analogy from student to a learning algorithm he now gives TWO orthogonal metrics to optimize for.

Loving that part. I bet few people have combined his advise for student learning with his advise on how to do ML earlier.

Shortly after 2008 till around 2017 was when Silicon Valley, HN, and the start-up world in general surged heavily.

Now I think most people agree it's behind it's ceiling point. (most != all)

Of course before the first internet bubble also companies succeeded, but then when the bubble burst there was a dry phase.