pbecotte

That's like- the whole point. If you as a manager set a goal, those three choices are all the choices the people under you have to meet the goal, and you often set it up so that the preferred choice (actually make things better) is impossible. Its saying that decision makers need to be aware of this and adjust your behavior.

Like you said, if they don't, the people dealing with it have no choice- so, it'd be impossible to offer advice for those people, since they have no way of actioning it (unless its convincing the decision maker of that point)

JVM can run apps _compiled_ for it. WASM has the _exact same_ limitation.

Someone put in the effort to get Postgres to compile for WASM. That's great :) Maybe someday every application will compile to WASM as the preferred choice over the linux interface.

Compiling apps for different targets is VERY MUCH not a simple, low effort task though. Something like a database that must have an incredible number of optimizations in the way it makes syscalls, will have to a full stream of work to keep each target running well.

It can be done. But if "one of these thigns is not like the other" with your three things- Docker is the odd duck out.

It can run "anything" ... so long as someone has set up that project to correctly compile to a wasm target. "docker build" lets you build a package out of any software, without having to know much about it. "setting up a compiler for a new project, given the source code and maybe a separate toolchain for some other target that works", is a much more involved task.

There is no world where people are just grabbing an existing app and saying "hey, I'm gonna drop this into my wasm runtime real quick"

I don't think the statement "fairly simple to compile an arbitrary program" hasn't been true for any ecosystem, ever.

no, you're right. Terraform/Pulumi are much more focused on provisioning resources, while Ansible has its sweet spot in configuring a machine once its running.

Was a generator technician before I got into programming. Even the 2 megawatt systems could start up and take full load in 10-20 seconds. It sounds basically like starting your car with your foot on the gas.

The "when" shouldn't really matter- Diesel engines aren't a new thing. Warming them up isn't really a thing either- they'll have electric warmers hooked up to the building power to keep them ready to go.

The weird thing is- it could be a scam that is not actually a scam. If they have somehow acquired the legal right to use the author's name to release books, they don't need to swindle the ghost writers- they would probably be able to actually sell a decent number of books. The victim of the scam would be the author and her publishing company.

The author of the article had a great point. Developers often DO treat me as an IT person. The number of times I've taught a developer what an SSH key is or how to install a python virtualenv on the dev box blows my mind.

On the other hand, everything else he says is wrong. Devops isn't "ops gets out of the way and lets developers do crap and nobody owns it when it breaks" its... dev and ops WORKING TOGETHER. If you don't know what their app is doing YOU ARE NOT DOING YOUR JOB. (On the same note, if they don't know anything about how the system is deployed or the like, they're also not doing their job). The rest of the article is literally about complaints about that. The point that you can't monitor an app you don't understand, and developers don't want to push out crappy code, is the whole reasoning behind devops. The people no longer being in their own silo, but instead working together as a more holistic team to own the thing from end to end. If you stay in your silo but add automation, you are 100% going to have pain. There is another pattern they could try, thats the platform model. In that case ops can stay in their little silo and present a platform with apis that developers can build on. Its what you're talking about here, and that can ALSO work. But its a different model. The old style of ops they would do as they were told, while trying to restrict anyone from changing anything. As a platform team, now they're delivering a product. They should be talking to users, and judging throughput, and iterating quickly, and being customer focused... basically, acting exactly as the developers are supposed to be. I am a strong beliver that the platform team should have product owners and customer metrics the same as the developers- heck, if they like QA, they can come up with a QA process. But yeah, I've seen a lot of low effort finger pointing in orgs that pretend to do devops from inside their functional silos. That point, the one in the title, is a great one.

Even in 2016, I had been running production services in Docker successfully. Its interesting to me that they see the problem "Docker isn't designed to store data" without also seeing the solution "the docker copy-on-write filesystem isn't designed to be written to production- but volume mounts are". I hadn't seen docker crashing hosts (still haven't) - but I'm guessing that was caused by using the storage drivers.

The complaints about their development practices are valid (and haven't really improved), but even then the technology worked well so long as you understood its limitations.

A little. The thesis behind 'trickle down' sorta makes sense if you think about it. Less taxes = more money to invest = more investment = more economic activity. I did kind of expect to see SOME impact, though have felt for a while that the financial markets have become so disconnected from actual investment behavior that the impact would be marginal...and looks like this study concludes its even less then that.

Just because a company has SOME open source software, probably doesn't mean that all of their software is.

Yeah, I'm all on board with trashing the company. Those emails were terrible.

The emails from the company make it clear that at least one party to the dispute believed that they did use Replit's internal design decisions. Commercial companies approaching the same problem certainly would offer similar feature sets. But an employee reading the source code and then starting a git repo that makes a working version of the product freely available is a pretty big deal. It doesn't have to be copy-pasted to be valuable intellectual property. (though, I do agree that THIS was unlikely to actually be valuable IP haha)

This wouldn't be an issue of non-compete, but of intellectual property - and I can't imagine there was no intellectual property agreement signed. I've never had a job that didn't have one...

I...am on the side of the company here? wierd...

An employee of a company left, and then made an open source clone of the company's software. The fact that the software was easy to clone or that others had done it previously doesn't seem really relevant. Several times I have left a company, and I could replicate a good percentage of it in a couple days too, not because it was easy, but because the months/years of experience I had building it the first time.

Whipping out the lawyers and bragging about his funding is idiotic and childish, but I think asking for the project to be taken down is completely reasonable. (on that note- I kind of think at this point that you have to be a megalomaniac to be a funded startup founder)