If you need to provide tools that cross security boundaries then […] a small web app is better [than sudo].

A web app? Effin really!!? 🤨

Fuck yea!

https://archive.ph/39CAN

I think you’re overstating the compute power […]

I don’t actually think so. A100 GPUs in server chassis have a 400 or 500W TDP depending on the configuration, and even if I’m assuming 400, with 4 per watercooled 1U chassis, a 47U rack with those would consume about 100kW with power supply efficiency and whatnot.

Running those for a day only would be 2.4GWh.

Now, I’m not assuming Amazon would own 100s of those racks at every DC, but they probably would use at least a couple of such racks to train their model (time is money, right?). And training them for a week with just two of those would be 35GWh, and I can only extrapolate from there.

So I don’t think that going to TWh is such an overstatement.

[…] and understating the amount of cardboard Amazon uses

That, very possibly.

I have seldom used Amazon ever, maybe 5 times tops, and I can only remember two times. Those two times, I ordered a smartphone and a bunch of electronics supplies, and I don’t remember the packaging being excessive. But I know from plenty of memes that they regularly overdo it. That, coupled with the insane amount of shit people order online… And yes, I believe you are right on that one.

Even so, as long as it is cardboard, or paper, and not plastic and glue, it isn’t a big ecological issue.

However, that makes no difference to Amazon financially, cost is cost, and they only care about that.

But let’s not pretend they are doing a good thing then. It is a cost effective measure for them, that ends up worsening the situation for everyone else, because the tradeoff is good economically, and terrible ecologically.

If they wanted to do a good thing, they could use machine learning to optimise the combining of deliveries in the same area, to save on petrol, and by extension, pollution from their vehicles, but that would actually worsen the customer experience, and end up costing them more than it would save them, so that’s never gonna happen.

IMHO the issue is two folds:

1. The makefile were never supposed to do more than determine which build tools to call (and how) for a given target. Meaning that in very many cases, makefile are abused to do way too much. I’d argue that you should try to keep your make targets only one line long. Anything bigger and you’re likely doing it wrong (and ought to move it in a shell script, that gets called from the makefile).
2. It is really challenging to write portable makefiles. There’s BSD make and GNU make, and then there are different tools on different systems. Different dependencies. Different libs. Etc. Not easy.

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.

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.

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.

The essence of that article can be summarised in:

• The Streisand effect is helping the news outlets that meta censored.
• We can all move away from meta, and they will essentially go away.

Honestly, if the makefile is well written, I will take that any day. Good makefiles are 😙👌.

They are extremely rare, tho…

I guess the solution would be a declarative language that compiles to makefiles. So that people don’t have to know the nitty gritty of writing good makefiles, and can just maintain a file of their dependencies and settings…

If you can’t count to 3, that’s a you problem, dude…

So, lemme get this straight. We fucked up the climate with industrialisation and uncontrolled capitalism, through energy consumption. Now, the #1 industrial company (that’s two for two, if you’re counting) in chip making is using one of the most energy (and there we go, 100% 🥳) intensive technology at our disposal to try and eventually have a shot at maybe keeping the climate in somewhat of a check… Am I the only one seeing this? 😶

That’s the energy equivalent of giving every kid and teacher guns to “stop school shootings”. 🙃

Better lzma performance with xz. 🤪

So fwiw, it has ChatGPT-3

Umbrella corp. That has to be satire. Right? Right??

If they are shocked by this, wait until they understand what meta does with their PII and behavioural information… I’m sure they will understand any day now. Any day…

Nice work. 👍

The ARM architecture does apparently (I’m no expert) have some inherent power-efficiency advantages over x86

Well, the R from ARM means RISC, and x86 (so, by extension, x86_64) is a CISC architecture, so they are not even in the same “family” of designs.

Originally, CISC architectures were more popular, because it meant less instructions to write, read, store, etc. Which is beneficial when hardware is limited and developers write in assembly directly.

Over time, the need for assembly programming faltered, and in the 90s, the debate for CISC vs RISC resurfaced. Most developers then wrote code in C and C++, and the underlaying architecture was losing relevance. It is also worth noting that due to a higher number of instructions, the machine code is more granular, and as a result, RISC code can inherently be further optimised. It also means that the processor design is simpler than for CISC architectures, which in turn leaves more room for innovation.

So, all else being equal, you’d expect Qualcomm to have an advantage in laptops with this chip, but all else isn’t equal because the software isn’t there yet, and no one in the PC market is quite in a position to kickstart the software development like Apple is with Macs.

Now, a key consideration here is that the x86 architecture has been dominating the personal computer market for close to half a century at this point, meaning that a lot of the hardware and software is accommodating (wrt functionality, optimisation, etc) for it specifically.

Therefore, RISC architectures find themselves at a disadvantage: the choice in Operating Systems is limited, firmware and drivers are missing, etc. Additionally, switching to RISC means breaking legacy support, or going through emulation (like the Apple M3 does).

However, in our modern ecosystem, the potential gain from switching to a RISC architecture is considerable (storage is cheaper than ever, RAM is cheap and fast, and seldom anyone is writing assembly anymore. Plus, those who do might enjoy the higher degree of control the additional granularity affords them, without having to do everything by hand, given the degree of assistance modern IDEs offer), and it will gradually become a necessity for every vendor.

For now however, the most popular computer Operating System worldwide has poor performance on ARM, and no support for other RISC architectures (such as RISC-V) that I know of.

The challenge here is in breaking a decades long dominance that originated from a monopoly: if you have paid attention to what Apple has been doing, they initially used large parts of FreeBSD to build a new Operating System that could run on their custom processors (Motorola 68k), and then built the rest of their Operating System (Darwin and Aqua) on top of it. This afforded them the possibility to switch to Intel CPUs in 2005, and back to ARM in 2020 with their M series CPUs.

The quality of their software (in large parts derived from the quality of free software and of staggering design work) has allowed them to grow from a virtually negligible share of computer users to the second place behind windows.

Now, other Operating Systems (such as Linux) have the same portability characteristics as FreeBSD, and can feasibly lead to such a viable commercial OS offering with support for several hardware architectures.

“All” that is needed is a consistent operating system, based on whichever kernel fits, to supplement MacOS in the alternative offering to windows.

Most software would be available, and a lot of firmware would too, thanks to ARM being used nearly exclusively in mobile phones, and most mobile phones running a Linux kernel.

Once we have a (or better, a few) Linux or BSD based operating system(s) with commercial support, consistent design, and acceptable UX for “normies”, such CPUs will become a very valid offering.

And they must be local rather than remote (cloud).

Also, always prioritise a common format served through filters (for example having all your data in postgres and minio, and serve that on demand as ICS, XML, etc) so that you don’t need to duplicate or lose data due to formats.

Now let’s get ISPs to run this!!