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"
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.
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...
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)
Guessing you didn't read the article? This article is saying that when Tesla made those complaints, Edmunds reran the test the way that Tesla suggested and got the following results.
Sure, maybe its not a big deal that the cars come up a few miles short of the advertised range under these conditions, but the Tesla ones were the _only_ ones to do so, which is at least interesting.
I've certainly never been bottlenecked on date parsing :) However, many/most of the high performance python libraries are built in C code, and compiled down into something the python interpreter can use directly. There are lots of python bindings written in c++ to native c libraries as well, I know I have used ZeroMQ pretty recently. Rust is done the same way- the code is compiled down into objects that Python can use directly- its not like running a javascript interpreter in your code.
If you already have all of that working, why would you change? Containers are valuable for a couple things-
1. Packaging and distribution- it's very easy to set up a known good filesystem using docker images and reuse that. There are other solutions- dpkg plus ansible would be an example.
2. Standardized control- all apps using 'docker run' vs a mix of systemd and shell scripts can simplify things.
3. Let's you tie into higher level orchestration layers like k8s where you can view your app instances as a single thing. There are other solutions here as well.
4. Can use the same image on dev machines as prod instead of needing two parallel setup schemes.
If you already are happy with your infra, certainly don't change it. I think once you know containers they are a convenient solution to those problems, but if stuff is setup they already missed their shot.
I dunno what the law says. However, it is very easy to imagine a situation where someone LEGITIMATELY cannot decrypt the device. Is indefinite detention without even a criminal charge a valid punishment for that? We can make analogies all day "is it testimony? Is it like the code to a safe?"... But there is a real concrete fact that the government wants to be able to imprison someone indefinitely, without a jury trial, for claiming not to know something when there is certainly a reasonable doubt about them knowing it.
So, whatever they have to do with the analogies, this decision cannot go the way the prosecutor wants it to.
But... we understand EXACTLY why developers are paid so well. Economics (the same reason EVERY profession is paid the way they are). There are two factors that come into play for employee pay- 1. Supply/demand: When demand outstrips supply, prices rise. The demand for software so vastly outstrips the ability to produce it that salaries are being driven very high because 2. The marginal value that an employee can produce. This is a hard cap on the salary that any profession can charge, and is the primary driver for demand. So long as 2 is higher than the prevailing salary, demand will continue to rise, which will apply upwards pressure on salaries.
Of course, high salaries will attract more supply over time, which will put pressure back down on salaries. The current dynamic is SO out of whack though- there is a ton of slack in the system.
This isn't a boom/bust thing either. There is SO MUCH business value that could be had if there were programmers available to build the software. I don't think we're even scratching the surface of everything that could be profitably built yet. I think betting on a big bust in software engineer salaries would be a bad move.
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)