This. I would add that role titles also exist for negotiation purposes. For example, a new employee may prefer to be called "research engineer" instead of "ML DevOps" to open up future career opportunities, even if the work done is the same.
What I don't understand about these scams is: It must be quite difficult and expensive to create shrink-wrapped modified devices. But the letter itself is so full of spelling and grammar mistakes that it can't be taken seriously. How is it possible that you can create these devices but you're incapable of having someone proofread the letter!?
> sent you a new device you must switch to a new device
> this *kinda* breach
> there is a manual inside your new box you can read that
The scammers probably live somewhere where it is "easy" to manufacture such a product (including packaging etc.). However getting access to someone who besides fluent English also "knows" western culture enough to use the right tone in the letter is apparently harder. As an example in an other comment I joked about a western company would never apologize for "our faulty security system".
So it's just a guess but with those two observations I would guess the scammers are from China.
That makes sense but I don't know if you can really draw a parallel between email and these devices:
(1) Sending email is nearly free, creating devices is not. Not sure if the economics match.
(2) False positive filtering matter because spammer need to manually reply to emails, creating more work. But with these devices this is not the case, it's all automated. There is no need to filter out smart people.
This only makes sense if the bad grammar is prior to the expensive part of the scam. In this case the expensive part of the scam was mailing the thing. So the funnel doesn't work.
I'm not convinced that argument makes sense in this context, they want you to plug the thing in. They're not trying to filter for gullibility, they want to be as convincing as possible.
Derivatives typically have mechanisms that forces them to stay pegged to the underlying asset. So it's not quite the same, even if you don't own the underlying asset. For example, perpetual futures (like those on FTX) have funding rates that vary based on price difference of the future vs underlying.
Docker, the company, is such a sad story. They have such an impactful technology but completely failed to monetize it and lost multiple revenue streams to competitors. Shows how hard "open source companies" are. Others OSS companies have similar problems. It would be nice to find economic models where impact is correlated with revenue.
I've been using Docker since 2014 and IMO they did a great job in terms of API stability from an end user's perspective.
Lots of CLI commands from 5+ years ago still work today and the upgrade story with Docker Compose has been gradual, painless and most importantly pressure-less for having to upgrade.
They got the developer facing API just right making containers accessible but their promised plugin architecture never did come.
There was an arms race between them and the community to lead the story on new functionality. For example flannel came out first before docker acquihired SocketPlane for networking, while Calico was also in the works.
There was pressure from the community for a stable plugin API to allow for external contribution, but I imagine that it was ultimately against their best interest
Agreed. Docker (actually, containers in general but docker tooling) made it so damn easy to get local, reproducible builds. It’s fantastic and made life so much easier for me professionally as a Software Engineer.
I remember the early days when Docker had just released, all devs were super excited but nobody had run containers “in production”. AFAIK I believe it was mesos that was used widely for orchestrating containers in production. Docker swarm/compose just took too long to get there and k8s just rapidly took over and became the standard.
Admittedly I didn't follow it super closely, but I did do fig when that was a thing, then tried initial docker compose, and then later did docker compose again.
All along it has always just felt way too imperative. It was too much of a sense that you were issuing commands at a system rather than declaring a desired end state. Kubernetes got this right from the get-go.
The history of the relationship between Mesos and Docker is definitely an interesting one. If memory serves right, Mesos was not keen of supporting Docker as a containerizer. The devs wanted to stick to improving the Mesos containerizer.
In the end, the community was so vocal about Docker being supported in Mesos that it happened, but the end result was not stellar by all accounts (and a bit of a nightmare to deal with on the framework side to boot).
I'm not privy to what was going at the time since I was just part of the larger Mesos community, but looking back, can't help but wonder what would have happened if they collaborated instead.
I'm still rooting for them, specifically for Swarm which is a breath of fresh air for small and personal deployments. Though tooling around Kubernetes has improved in the last couple of years and it's much easier to get started now, the system still has a steep learning curve compared to Swarm.
I'm currently learning both Docker Swarm and Kubernetes (at the same time) and I'm a bit overwhelmed by Kubernetes (VS Code's extension and Kube's documentation helps with that). I just want use the Azure Kube Service to deploy my Rails app...
I'm also trying to learn Docker Swarm mode and both the community and documentation are not as nearly comprehensive as Kubernetes'. And Docker's official documentation and tutorial has me provisioning 3 nodes on a cloud provider instead of just booting up a swarm on my local machine.
And then I see any # of combinations of Docker Swarm with tools like Terraform or Pulumi. It's just all so overwhelming.
I think I'm going to keep banging my head with Kube and its super verbose manifests until I finally get it.
It's been a while since I've read the Swarm documentation, but it was fairly comprehensive from what I remember. If you're referring to this tutorial[1], note that you don't need to use a cloud provider, and you can also do it with local VMs.
Actually you don't even need a cluster of machines. While Swarm can easily scale out, you can get started with a single machine and figure out the clustering later. Even on a single machine there are benefits of using Swarm over plain Docker (Compose): stacks, secrets, advanced networking. So you can test it out there and add more machines as you need it.
One thing I'd suggest is to first get familiar with Docker itself, since Swarm simply builds on these concepts and adds orchestration. Use `docker run`, understand volumes, images, permissions, user namespaces, cgroups, etc. Then move on to Docker Compose and get familiar with the configuration, services, etc. And then finally pick up Swarm, which even uses the same Docker Compose configuration file (with slight variations), so it should be fairly straightforward at that point.
Though honestly, learning Swarm in 2021 might not be a good investment, since Kubernetes is clearly the market leader, and I wouldn't be surprised to read a sunset notice about it, even though Docker Inc. is still supporting it. So you're probably making a good decision to stick with k8s.
> Of late he feels like all the activity of himself and his peers is just playing the Science Game: varying some variable with infinite degrees of freedom and then throwing statistics at it until you get that reportable p-value and write up a narrative short story around it.
The classic "we achieve SOTA on ImageNet by using a novel training procedure" where they just played with learning rate schedules until they got 0.1% over previous SOTA.
To be fair to there are a lot of smells in DL papers, usually you can tell whether an approach is worth your time by looking at code availability, lab, previous publications and the conference where it was published.
I don't think people consider the entire site spam. It's user-created content after all. But if 99% on a site is spam and your articles are not, you may want to consider posting them somewhere else, ideally your own blog, to avoid suffering from the site's bad reputation.
The same goes for medium.com. There are good articles on Medium, but 95% of it is low-quality or spam, so I generally avoid these links or come in with the expectation that an article is likely spam.
Interesting observation. I wonder if these are issues intrinsic to the sites themselves, or if instead there’s some fundamental law that states once a publishing platform reaches a critical mass of popularity, it ceases to yield high-quality content (on average).
I do wonder how Substack is thinking about this problem. They obviously have a different business model than Medium, but I think they are still susceptible to this issue.
This should have a (2017) tag. NieR:Automata is not just one of my favorite games, but for me it has the best soundtrack out of any videogame I have ever played. Here are some of my favorite tracks [0] [1] [2] [3]
The original NieR (just now re-released as NieR:Replicant) is also notable for having an amazing soundtrack with the lyrics being constructed from a totally made-up language. And the layering of the score as you go into and out of combat is nothing short of masterful.
The first game holds a special place in my heart and playing the remake now is bringing back a lot of good memories. It's kind of odd but self-aware and the characterisation of a talking book is utterly astounding.
Was the remakes soundtrack redone? I noticed that the NieR:Automata soundtrack works really well with Automata, but it doesn't really stand out in any sense to me, whereas the Replicant one just sounds beautiful.
So, the language is the same made-up ingame language? I've been wondering what language it could have been. It sounds a bit like a Germanic boy / children chorus.
Sad but I feel the same way. I still enjoy reading HN comments and there are occasional gems among them, but most posts on HN these days reflect the mainstream majority opinion, the same platitudes and topics over and over again. It's not people at the forefront of new technology. I guess it's the "crossing the chasm" effect.
I don't know any better place though. I find myself using specific small subreddits more and more recently even though I was never a big reddit user in the past.
Yes, you will always need humans to make human judgements but they don't need to be part of a court or central authority. With reputation and consensus incentive systems in place, these judgements can be made by trusted 3rd parties and feed back into the smart contract without the need for a single central authority.
The point isn't to get rid of humans or trusted 3rd parties. It's to get reduce the reliance on a single centralized entity that may be corrupt, inefficient, or malicious.
> Please provide a very specific example of something that happens now that a smart contract would fix. I can't think of anything.
They already did, asking again isn't going to get you the answer you want.
You described the renting market as having a high threshold for bias in order to be ineffective. I don't really think this is true, it's quite difficult in most states to go to court to seek damages for rental property. Even the eviction process is not straight forward and requires the participation of both a court and a marshal to serve notice. What smart contracts replace is a lot of the court mechanisms that are low hanging fruit. It takes some stress off of the system, but certainly not all, and that seems like it could be "good enough".
> They already did, asking again isn't going to get you the answer you want.
The person I was responding to gave only generalities.
> What smart contracts replace is a lot of the court mechanisms that are low hanging fruit.
What court mechanisms?
Let me give you a specific example.
I'm a landlord with a rental contract. In my state (as in many states), there are hundreds of statutes dictating the boundaries of this contract. There are also thousands of cases in common law that influence what I can and can't contract. For example, my tenant cannot contract away certain rights, even if they sign a legal document saying that they did it.
Scenario A: I use a smart contract stipulating that if there are damages, I can hold the security deposit.
Scenario B: I have a paper contract stipulating the same (although in many states there are statutes that say this, so the contract is just repeating existing law).
Now let's say I find "damage" and the renter disputes it.
How has the smart contract helped me? What difference did it make? In many situations, the smart contract enforcing itself without 100% understanding of the physical world or existing law would violate the law.
So that's how specific I'm asking you (or anyone) to be: give me a specific scenario where the smart contract enforces something in a reliable, efficient way that is significantly better/safer for either party.
> So that's how specific I'm asking you (or anyone) to be: give me a specific scenario where the smart contract enforces something in a reliable, efficient way that is significantly better/safer for either party.
And I'll doubt you'll get that specific of answers because those implementations are fairly new. You'll likely see proof of concepts developed to streamline or back up existing processes first, the underlying technology adjusted to fit the usecases, rinse, and repeat. All that to say, it's not going to holistically solve every problem for you up front, as the commenter pointed out.
What I can see is that it streamlines some of the mediation and court intervention processes. What our notable gains from that would be remain to be seen, but for my parents who are landlords that have had to evict tenants it could mean that simple cases don't require a court. Maybe they get some review by someone who would best be described as an auditor or mediator to check the outcome.
Actually, it's some rules in a spreadsheet. You get tenants out of your rental because someone is getting paid to do it - their salary is in some spreadsheet - and then their work is verified by someone else who is also getting paid to do that. These complex systems of incentives are currently managed by humans.
You could setup a similar incentive system as smart contracts. If your tenant does not pay, you could get him evicted much fatser and automatically, because another smart contract can pay the enforcer. And the overall fees are subsidized and tradeable.
Of course we're far away from doing that and both approaches have pros and cons, but it's arguable that the "human-managed" approach is clearly superior.
What do you mean by "That entity isn't the contract"?
Yes, the enforcer is not (necessarily) part of the contract. But if the right incentive system is in place and there is consensus that physical enforcement should happen - anyone approved could take that job/risk and be the enforcer.
With such a system you may not even need a physical enforcer since the risk of not getting the tenant out could be tradeable (like an insurance) and the owner would get his rent even if the tenant cannot be evicted immediately. In case of the tenant, there would be huge negative financial incentives to stay.
This is a spectrum similar to taking out loans and performing liquidations. If the person you are giving a loan too is sketchy you may refuse the loan or charge higher interest.
The same principle applies here as physical eviction is fundamentally about risk. There is an "auction" on the eviction and potential evictors can decide how risky the eviction is. More risky evictions will require a larger payout.
The point is that such a contract requires a central authority that must be capable of evicting the tenant. A "smart contract" which is just some code running on a computer certainly can't do that.
Why do you require a central authority? What you require is this:
1. An incentive to evict someone. Money. Someone needs to get paid to actually do the eviction because they are taking on some risk - physical in this case. It doesn't matter how they get paid. A smart contract can do that.
2. "Social/Legal consensus" that performing the physical eviction is the right thing to do. The person performing the eviction should not get punished for it. If the state and breach of contract is transparent on the blockchain this consensus could be achieved.
3. A way to confirm the eviction to pay the evictor.
Yeah, that should work very well. Say if the third-party (from your description, apparently a band of mercenaries) in charge of enforcing the contract is motivated by economic incentives, what stops any of the parties from providing a stronger economic incentive to the mercenaries so that they don't enforce the contract?
Also, you are ignoring the fact that, at least where I live, only one entity can legally evict a tenant - the county sheriff (in their role as an agent of the court). You cant just hire some random thugs.
You are giving for granted that there is a private someone that is payed to evict people from an house, but that's not how it works in many places in the world.
In Italy (and I bet in many other European countries) this is the public force that is in charge of doing this and there are a lots of exceptions (for instance, here, you cannot easily evict a family where there are children or sick people).
And if you involve the pubic force, then you are inherently accepting the concept of a central trusted authority, hence the decentralisation fails as a requirement.
