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.
> in my experience [slackers are] rare (and 100% protected by management)
Can you give an example of how you see slackers being protected by management? I wonder if we have the same definition of the word slacker.
In my experience the people protected by management are not doing much in terms of daily work, but they work a lot to always stay on top when it comes to prestige and taking credit from other people's work. So from my perspective they are working hard, just not to improve the teams results. That's why I call them parasites. They suck out the value of the team for their own gain.
What I call a slacker instead tries to do nothing but reading facebook (or HN) all day. Most of the time these are people who have given up hope to improve their careers for one reason or another. In many cases it is connected to a parasite sucking too much out of them and them not being able to recover self-motivationally.
I bet at least before readign this post your understanding of slacker and my understanding of parasite would be similar, right?
Well, naturally every company has talent drain. The rockstars will not work long in one company and jump from one gig to the next. But if you have bad luck and hired some slackers, which will happen with the tightest of hiring schemes, then they will certainly stick around.
Thus over time you still have to re-hire people you really need, but get a bigger and bigger amount of people who are just there for the social benefits.
So what can you do to achieve your ambitious goals? Reduce the workforce and try to find a cutting point where you get rid of mostly parasites while keeping your ambitious work bees around.
Usually at the same time of the cut, some of the work bees also get raises and promotions, because then there's some free budget. So if you are an ambitious work bee, then "cutting staff" is actually also good news.
Finding the right cutting point is really the important point and hardest part. For instance you don't want to lay off people who really are performers but for some reason or another (e.g. they just got a baby) they don't perform right now. So at least in the companies I could look inside until now the cutting point is usually well inside the slackers group, so that the people who would recover and then start performing again have a chance to continue.
In the end, even the most tyranical ass-hole leader wants to have as many people as possible work as hard as possible to achieve his goals for him, in exchange for an amount of money that in most cases is peanuts for him. And not all leaders are even tyranical ass-holes.
I think it's the very best dungeon crawler when it comes to comfort of use and startability for new players.
And I would suggest it not just for gamers but for programmers as well. There is a lot one can learn about user interfaces, shells, coding, architecture, data management (items, races etc are all data) with the additional motivation to learn it while playing.
It's also not the first dashboard with this situation.
phpMyAdmin or what it's called, back in the days of LAMP stacks that was deployed almost everywhere without much security around. Not sure if it also had sql injection bugs etc, but just the low amount of security considerations most people gave this direct access to the database was probably enough to hack into most servers of that time.
https://www.youtube.com/watch?v=6kfgXoclrjk