jabl

> I vaguely remember that they have trace caches (a cache of decoded micro-operations) to skip decoding in some cases. You probably don't make such caches when decoding is easy.

The P4 microarch had trace caches, but I believe that approach has since been avoided. What practically all contemporary x86 processors do have, though is u-op caches, which contain decoded micro-ops. Note this is not the same as a trace cache.

For that matter, many ARM cores also have u-op caches, so it's not something that is uniquely useful only on x86. The Apple M* cores AFAIU do not have u-op caches, FWIW.

A lot of the natural gas plants are combined cycle, which includes a steam Rankine bottoming cycle.

Uh? IT for higher ed is not that different from any other enterprise IT.

I used to work at a university, although I worked on the Linux/HPC side of things we did have regular contact with the IT department. So things the IT department used VM's for of the top of my head:

- Web servers. Yes, the official university web pages, with fronted servers, database servers and whatnot. But also a lot of departments had their own servers, even some research groups ran their own. To get rid of the zillions of ad-hoc servers running in closets here and there IT gave out VM's pretty freely to staff members.

- Email. Yes, this was before everyone + dog outsourced their email, so they ran their own in-house email servers.

- print servers

- (I think file servers were mostly non-VM appliances, my university used netapp's a lot)

- All kinds of management systems to manage the campus workstations and network. And things like Active Directory and other directory services type services which are critical.

- A zillion in-house applications for things like signing up for courses and other things necessary for handling thousands of students.

- A lot of bespoke systems given out to research groups for whatever purposes they needed, again in order to get rid of the zillion repurposed old pc's running in closets acting as servers or running some experiments etc.

- Critical services and some not-so-critical services as well had test environments to test changes before rolling out to production.

- Finance/admin stuff like payroll etc.

- Shell servers (ssh), RDP servers, VPN servers etc. to enable staff to access university services from outside.

All in all, it was hundreds and hundreds of VM's. Wouldn't surprise me if there were actually thousands.

Yeah, vsphere has a mile-long list of enterprise checkbox features that the sales managers can overwhelm the CIO's with on the golf course.

Kubernetes might have success, but AFAICS Kubernetes also sort of involves a new way of architecting applications (cloud native applications, 12-factor apps, microservices, etc.; whatever the buzzword du jour is). The idea with vmware was always to virtualize all those zillions of more or less idling physical servers, and get some snazzy management GUI to handle them all etc. etc.

There is a PWA you can install, with it's own icon and everything. Yes, it's a not-even-glorified-web-browser, but meh, it works (for some definition of works).

Not to mention when you had multiple devices you had to piddle with physical jumpers so no two devices shared an IRQ. Good ol' ISA.

Blast from the past! When I was a kid we had such a floppy tape device connected to a 386 or 486 computer my parents had. I think it was a Colorado Jumbo 250. I think the actual capacity was 125MB, but the drive or the backup software had some built-in compression, hence why it was marketed as a 250MB drive. Never tried to use it with the Linux ftape driver, though.

It wouldn't surprise me if the drive and the tapes are still somewhere in my parents storage. Could be a fun weekend project to try it out, though I'm not sure I have any computer with a floppy interface anymore. And I don't think there's anything particularly interesting on those tapes either.

In any case, cool project! Kudos to the author!

I recall Opel was owned by GM already before WWII? And iy was only relatively recently that GM got out?

(Ownership aside, Opel has been producing cars made in Europe for (mostly) Europeans for AFAIK the entire post-WWII era.)

Oh, right, yes. But that's just because 1/T occurs in many formulas and thus it's often convenient to work with it instead. No exciting new physics hiding there. ;)

Ah, but most natural unit systems don't measure time in seconds either. See https://en.wikipedia.org/wiki/Natural_units

This is to an extent a party trick to befuddle lay people. Physicists know perfectly well that temperature is not a well-defined concept out of equilibrium. And when in a population inversion experiment when "temperature" is determined to be negative (or "beyond infinite" if you will) it arises because for a short while you have a non-Boltzmannian distribution.

A cool (ha ha!) solution was the old Cray XT3/4 supercomputers, which were air cooled. But instead of a battalion of tiny fans, each cabinet had a single huge fan at the bottom, blowing air vertically through the cabinet (the boards were mounted vertically). No redundancy, sure, but AFAIU it was reliable enough to not be a problem in practice.

> Or is it that wiring distances (1ft = 1nanosecond) make dense computing faster and more efficient?

Contrary to other posters, I'd argue this effect is relatively small. A really good interconnect fabric might give you ping-pong times on the order of 1 microsecond, which is still 1000 times larger than a nanosecond. Most of the delay will be in the switches and the end nodes, not in the signal traveling over the wire or fiber. Say for a large-ish cluster with a diameter of, say, 100 feet (something like 7 rows of racks, each row 100 feet long, give or take), if liquid cooling allows you to double the density, you could condense it to a diameter of 100/sqrt(2) = 70 ft (about 5 rows of 70 ft each). As a ping-pong involves a signal going both ways, the worst-case increase in signal delay would be (100-70)*2 = 60 ft or 60 nanoseconds (in reality somewhat more since cables have to be routed). So about a 6% increase if we assume the baseline is 1 microsecond. Measurable, yes, but likely very small effect on application performance vs. a ping-pong microbenchmark.

Now where it can matter is that by packing the components more closely together, you can connect more chips via backplane and/or copper connectors vs. having to use optics.

I suppose in some desert-ish climate the extra moisture given to the air doesn't rain down nearby but moves with the wind somewhere far away where it rains. So there might be an effect of using locally precious water even if it's a closed loop on a continent level.

Not sure what Google specifically is using here, but PG25 (25% propylene glycol, 75% water) is somewhat common in data center applications. The glycol takes care of avoiding microbial growth.

Intel should have split 15 years ago, ideally, but I'm not sure that splitting now isn't better than not doing it. If they fail to catch up to TSMC, it's possible that the manufacturing branch will drag the design branch down with it.

If they split, it's likely the fab side of the business will need a large infusion of cash in order to catch up (be it in the form of a government bailout or something else), or then they have to accept becoming a second-rate player. For which there is still a large market, so they might actually do decent-ish there. But that pretty much leaves TSMC in a monopoly position.

Sure, the details would certainly have been different, but my argument is that the end result would not have been that different from what we saw playing out.

My quick 5 cents for what might have happened in the interim:

- Without a separate high-end offering in the form of the Itanium, Intel is quicker to adopt x86-64, and produce high-end server chips with extra RAS etc. features.

- POWER and SPARC, being the last holdouts in the RISC market in our actual timeline and outliving Itanium, would likely not have been affected much wrt. Itanium existing or not.

- SGI with MIPS would likely have been the first one to fold. Would SGI have pivoted to x86-64 & Linux sooner than they historically did, or would the company have gone bankrupt first?

- HP/Compaq with PA-RISC and Alpha is perhaps the most interesting question. HP did a lot of early VLIW/EPIC research with an eye towards developing a successor to PA-RISC. Would they have thrown that R&D away and selected to focus on either PA-RISC or Alpha after failing to secure Intel as a partner in the Itanium? Or would they have tried to develop something Itanium-like without Intel?

Another interesting what-if, if Itanium didn't exist, would instead 3rd-party manufacturing of high end chips (similar to TSMC today) have been developed sooner than historical? Keeping in mind that a large reason for the Itanium was accessing the semi process R&D and chip manufacturing prowess of Intel, as the thinking at the time was that tight (vertical!) integration of the chip design and manufacturing was a requirement for the highest end CPU's. And it was the spiraling costs and volume required of chip manufacturing that was the boat anchor around the necks of the RISC vendors moreso than the chip design itself.

Sounds a bit like all those no true Scotsman defenses of communism

- Communism is awesome!

- What about countries X, Y, and Z?

- Oh, that wasn't "real" communism!

Perhaps the government should have required Intel be split into a fab business and a chip design business (as Intel has planned to do itself but hasn't been able to, for reasons). The chip design part can survive on its own without subsidies. Then the government can pump money into the fab business for national security reasons without affecting the chip design market too much.

It works splendidly for all those MBA's with golden parachutes.

> Itanium was a flop from a technical standpoint but not from a business one. Intel spent roughly a gigabuck and effectively scared every competitor out the pool except for IBM and AMD.

Even without the Itanium, the economies of scale in the x86(-64) world would have driven the RISC vendors out of the game.

I suppose this is a FOSS solution for the roughly same space occupied by commercial tools like Origin, that are very popular in some scientific communities.

They can be useful if you have other tools (e.g. measurement software) that already produces the data you want, and you just want a GUI tool to create plots, and maybe do some simple things like least squares curve fitting etc.

If you already do a lot of data wrangling in something with a programming language and plotting libraries accessible from said language, like the ones you mention, yeah, this is not the tool for you.

To nitpick at least as of Apache HTTPD 1.3 ages ago it wasn't forking for every request, but had a pool of already forked worker processes with each handling one connection at a time but could handle an unlimited number of connections sequentially, and it could spawn or kill worker processes depending on load.

The same model is possible in Apache httpd 2.x with the "prefork" mpm.

What I've done is use the "podman kube play" similar to docker-compose when developing ("podman kube play file.yaml", "podman kube play --down file.yaml", "podman kube play --replace file.yaml", etc.) with the "file.yaml" in my working directory. Then when I'm satisfied and want to deploy to production I write a quadlet snippet referencing the kube file and put them under /etc.

> Isn’t that limited to a single node?

Yes. Though unless you have a very dynamic environment maybe statically assigning containers to hosts isn't an insurmountable burden?

If you're not wedded to docker-compose, with podman you can instead use the podman kube support, which provides roughly docker-compose equivalent features using a subset of the Kubernetes pod deployment syntax.

Additionally, podman has nice systemd integration for such kube services, you just need to write a short systemd config snippet and then you can manage the kube service just like any other systemd service.

Altogether a very nice combination for deploying containerized services if you don't want to go the whole hog to something like Kubernetes.

> Open source has been turned against us and used to build hyperscalers that effectively control modern computing.

> Pure open source is also not a sustainable business model. You have to be open core or non-commercial, otherwise anyone and everyone can steal your lunch.

Maybe, but beside the point. The point is "don't call whatever you're doing open source if it isn't open source (per the generally accepted definition which you can read e.g. at https://opensourcedefinition.org/ )". No moral judgement here whether open source is morally superior or not, or whether open source is for suckers because the hyperscalers will co-opt it, or whatever. If you don't want to do open source, then don't, but don't go and call it open source.

Indeed. Sure, lawns do have their place, like for playing sports or for kids to play around. But otherwise, what a waste. Just plant some local flowers or whatever and have a meadow.

As an example, at some point my father stopped bothering to mow his lawn all the time (basically only once per year). It's now a nice meadow with all kinds of grasses. Frogs, butterflies, dragonflies, bees like it.

An additional issue with robotic mowers is that they tend to kill hedgehogs.

My uncle used a semi-DIY lawn mower for many years where he had replaced the original broken engine with an old electric drill. Worked fine enough.

RISC-V has certainly managed to avoid obvious footguns like delay slots or register windows. OTOH there seems to be a lot of people who think RISC-V went too far down the "RISC purity" rabbit hole, and that relying on the C extension is not a good substitute e.g. for lack of more complex addressing modes. Those same people might instead suggest something like aarch64 as an example of a good general purpose ISA.

Secondly, for a high performance core, the consensus seems to be that the ISA mostly doesn't matter. The things that make a high performance core are mostly things that happen downstream of the instruction decoders. Heck, even the x86 ISA allows producing some pretty amazingly good cores. Conversely, for a simple in-order cheap core, the ISA matters much more.