7heo

Yeah, it is one of the least bad uses for it.

But then again, using literal tera-watts-hours of compute power to save on the easiest actually recyclable material known to man (cardboard), maybe that's just me, maybe I'm too jaded, but it sounds like a pretty bad overall outcome.

It isn't a bad deal for Amazon, tho, who is likely to save on costs, that way, since energy is still orders of magnitude cheaper than it should be[^1], and cardboard is getting pricier.

[^1]: if we were to account for the available supply, the demand, and the future (think sooner than later) need for transition towards new energy sources... Some that simply do not have the same potential.

I personally don't think we're getting anything. I always saw the "it takes time" point as a way to duck the issue until the community would forget about it entirely.

So, all in all, if you really want to get some answers, maybe wait enough time to give LMG more than enough time to investigate; so much so that using the "this wasn't a reasonable amount of time" defence strategy would be impossible, and then try to get the community to care again. And ask for answers. I personally do not see this happening, ever, but I hope I'm wrong.

The thing is, devops is pretty complex and pretty diverse. You've got at least 6 different solutions among the popular ones.

Last time I checked only the list of available provisioning software, I counted 22.

Sure, some like cdist are pretty niche, but still, when you apply for a company, even tho it is going to either be AWS (mostly), azure, GCE, oracle, or some run of the mill VPS provider with extended cloud features (simili S3 based on minio, "cloud LAN", etc), and you are likely going to use terraform for host provisioning, the most relevant information to check is which software they use. Packer? Or dynamic provisioning like Chef? Puppet? Ansible? Salt? Or one of the "lesser ones"?

And thing is, even among successive versions, among compatible stacks, the DSL evolved, and the way things are supposed to be done changed. For example, before hiera, puppet was an entirely different beast.

And that's not even throwing docker or (or rkt, appc) in the mix. Then you have k8s, podman, helm, etc.

The entire ecosystem has considerable overlap too.

So, on one hand, you have pretty clean and useable code snippets on stackoverflow, github gist, etc. So much so that tools like that emerged... And then, the very second LLMs were able to produce any moderately usable output, they were trained on that data.

And on the other hand, you have devops. An ecosystem with no clear boundaries, no clear organisation, not much maturity yet (in spite of the industry being more than a decade old), and so organic that keeping up with developments is a full time job on its own. There's no chance in hell LLMs can be properly trained on that dataset before it cools down. Not a chance. Never gonna happen.

Do bullets kill soldiers?

Infantry soldiers in the open, possibly. Soldiers in an APC? No.

Same applies to companies. A single sufficient bad review on a small, one-person company can take it out entirely. A single review of a big corporation? Not even one from a big shot like MKBHD.

This headline is dumb.

I would not call that a "privacy proxy", it is very disingenuous. It is a normal proxy, which replaces the technical metadata from your connection, so that automated tracking is harder. But it will not replace or remove any of your input. And you can easily be tracked that way too.

I see a proper keyboard in that picture. Where is the keyboard in my pocket, eh Ted? There was one thing that mattered above all, and that's the thing that's missing?? WHERE IS THE KEYBOARD IN MY POCKET, TED?

Yeah, I find the puzzle sliding JavaScript captchas the best as a user. Cognitively better than "training neural networks to recognise protestors", and still fast enough that it doesn't feel like a forced ad. Reliability might however vary a lot between implementations.

Plus, that way, you have a trail of invites. If something goes wrong, you can prune entire branches and mitigate most abuse.

I believe you're missing the actual causality chain here.

While it is actually proven that vendors will degrade your experience artificially to "motivate" you to buy new devices, in the never ending pursuit of monetary gain, there is no such potential incentive here: you aren't paying for new drivers.

And while others suggest biases, I do believe you are witnessing an effect that is at least partially real, if not totally, but not for the reasons you believe:

Most programs that leverage GPUs end up being GPU bottlenecked. Meaning that one can almost always improve the program's performance by using a better GPU.

But then, why does a new driver not improve performance, and rather, simply "bring a degraded performance back to previous levels"?

Well, that has to do with auto-updates, and the way drivers are distributed.

While, in a world where one would have to manually update everything, a new driver would almost certainly mean better performance for a given program, most programs in our world auto-update automatically (and sometimes even, silently). And the developers are usually on top of things wrt drivers, because they follow drivers updates closely, get early versions, etc.

Meaning that when a driver is updated, your apps usually are, too. In a way that leverage the new driver for more processing, rather than faster processing. But unlike your automatically updated apps, your drivers are updated manually.

And the consequence of such updates, when you are too slow to update your drivers, is a degraded experience.

Not because anyone artificially throttled your device's performance, but because you lag too much behind expected updates.

And Docker initially used Ubuntu. They explicitly and specifically switched to Alpine in 2016 for performance, to minimise the overhead.

Note: this comment is long, because it is important and the idea that "systemd is always better, no matter the situation" is absolutely dangerous for the entire FOSS ecosystem: both diversity and rationality are essential.

Systemd can get more efficient than running hundreds of poorly integrated scripts

In theory yes. In practice, systemd is a huge monolithic single-point-of-failure system, with several bottlenecks and reinventing-the-wheel galore. And openrc is a far cry from "hundreds of poorly integrated scripts".

I think it is crucial we stop having dogmatic "arguments" with argumentum ad populum or arguments of authority, or we will end up recreating a Microsoft-like environment in free software.

Let's stop trying to shoehorn popular solutions into ill suited use cases, just because they are used elsewhere with different limitations.

Systemd might make sense for most people on desktop targets (CPUs with several cores, and several GB of RAM), because convenience and comfort (which systemd excels at, let's be honest) but as we approach "embedded" targets, simpler and smaller is always better.

And no matter how much optimisation you cram into the bigger software, it will just not perform like the simpler software, especially with limited resources.

Now, I take OpenRC as an example here, because it is AFAIR the default in devuan, but it also supports runit, sinit, s6 and shepherd.

And using s6, you just can't say "systemd is flat out better in all cases", that would be simply stupid.

Devuan + xfce.