Ubuntu Linux Evaluating x86-64-v3 Based Build - AVX & Newer Intel/AMD CPUs

[ms178]

Yes, that's exactly what I'm talking about.

ms178 wants to force your company to switch distros or replace all of that customer hardware, just for the sake of unproven wins on a few binaries with the vector code compiled directly in that don't already have runtime dispatch (as anything with hand-coded SIMD already does).

Yes, I want them to change either to a distro that keeps supporting these ancient machines or even better, invest into something more modern. Corporate IT departments should know how to cope with such a situation and plan their budgets accordingly, if they can't, they failed at their job. After all they need to point out to their management that they cannot seriously expect to run these relics forever. And if they are one of these poor guys that invested into the wrong hardware that is still somewhat recent-ish, they should fire the people responsible for that purchase decision, too.

[Gabbb]

Canonical is listening to what their clients want & want to lower operating costs at the same time. For non-paying desktop users this is not the first and not the last bad decision they have made. (Ubuntu server and desktop are basically the same thing, I think it's a pipe dream to expect support for older hardware using their desktop iso)
I think It's about time normal people recognize the need to distance themselves from corporate distributions as much as possible.

[Gabbb]

And if they are one of these poor guys that invested into the wrong hardware that is still somewhat recent-ish, they should fire the people responsible for that purchase decision, too.

That's just a silly take, wow.

Also I'm amazed by how many people here in the comments want everyone to just throw away perfectly adequate working computers for no reason.

[TXTad]

That's just a silly take, wow.

Also I'm amazed by how many people here in the comments want everyone to just throw away perfectly adequate working computers for no reason.

I believe there are many in the computer industry who are not fully aware of just how much work is getting done every day on old equipment. If you work for some sort of an internet services company it is easy to get an unrealistic world view around the concept of just what constitutes "old" hardware. People who work for large computer companies primarily engage with cutting-edge hardware. This may cause them to be inadvertently disconnected from the reality that countless users continue to accomplish significant tasks on older machines. These machines serve as reliable workhorses for various purposes, from community projects to educational initiatives and resource-constrained environments. Discontinuing support for aging hardware risks alienating a substantial user base that depends on the accessibility and adaptability of our Linux distribution, and it's essential to underscore that progress should not come at the expense of leaving anyone behind in the dynamic and inclusive realm of open-source computing.

From an ecological point of view, retiring hardware that is more than sufficient for its designed task only because it's reached an arbitrary age is simply not ecologically sound.

Additionally, it's crucial to acknowledge the global diversity within the user community. Many of our friends around the world may not have access to the latest hardware due to varying socioeconomic conditions. Maintaining support for older machines not only respects the practical needs of these users but also upholds the inclusive ideals of the open-source community. Recognizing the economic diversity of the user base allows for building software that remains accessible to individuals with a wide range of resources, fostering a collaborative environment that transcends geographical and economic boundaries.

[ms178]

That's just a silly take, wow.

Also I'm amazed by how many people here in the comments want everyone to just throw away perfectly adequate working computers for no reason.

What a silly timing you've got on this comment, look at that: https://www.phoronix.com/news/Debian-Plans-Cease-i386

Yes, Debian gets rid of 32-bit relics soon, too. Throw that stuff away or donate it to a museum, it is not worth the electricity put into it from an efficiancy standpoint anyway.

[coder]

Yes, I want them to change either to a distro that keeps supporting these ancient machines or even better, invest into something more modern. Corporate IT departments should know how to cope with such a situation and plan their budgets accordingly,

Again, this is a narrow-minded, ignorant take. You seem to believe the only computers running as servers are those individually installed by an on-site admin. However, there are many "appliance"-type machines that a customer buys as a black box and simply installs on their network to serve a purpose. These machines must be maintained throughout the life of their service contract, which is often 5 to even 10 years.

So, if the vendor delivers a system in 2023, based on Elkhart Lake, then a normal service life would be through 2028. At the far end, we'd be talking about 2033. I gave the example of industrial control, but other examples might be physical security or monitoring of some kind.

if they can't, they failed at their job.

These applications often don't require a lot of CPU horsepower, and competitive pressures force vendors to use the lowest-cost hardware suitable for the task. It would be a failure at their job if they spec'd out more expensive hardware than necessary, as that will increase product prices and impact sales.

After all they need to point out to their management that they cannot seriously expect to run these relics forever.

You act as though there's a well-established precedent that support would be dropped for recent, popular CPUs. No such precedent exists, as far as I'm aware.

And if they are one of these poor guys that invested into the wrong hardware that is still somewhat recent-ish, they should fire the people responsible for that purchase decision, too.

Better yet would be for Canonical to fire the people responsible for amputating part of their customer base. Especially when good solutions like hwcaps exist as alternatives that could even benefit the customers on v4 CPUs.

What a silly timing you've got on this comment, look at that: https://www.phoronix.com/news/Debian-Plans-Cease-i386

Yes, Debian gets rid of 32-bit relics soon, too.

Apples-and-oranges comparison. The last non-64 bit x86 CPUs that shipped in any substantial volume are like 15 years old. In contrast, Jasper Lake and Elkhart Lake are still shipping.

[ms178]

Again, this is a narrow-minded, ignorant take. You seem to believe the only computers running as servers are those individually installed by an on-site admin. However, there are many "appliance"-type machines that a customer buys as a black box and simply installs on their network to serve a purpose. These machines must be maintained throughout the life of their service contract, which is often 5 to even 10 years. So, if the vendor delivers a system in 2023, based on Elkhart Lake, then a normal service life would be through 2028. At the far end, we'd be talking about 2033. I gave the example of industrial control, but other examples might be physical security or monitoring of some kind.

I understand this fully, it is not ignorance when pointing out that there is no relevance for Ubuntu Server to care about these boxes or for other more performance-oriented distros to care. This is what this thread has been about the whole time. If it was talking about the whole Linux ecosystem and every distro shifting to x86-64-v3 as their baseline, this would be yet another discussion where your point would have more merit. And as I understand it, there is still enough choice out there for these people to get by another decade on these boxes. Again, I fail to see a problem worth arguing about. OpenSUSE seems to implement your favored solution, by the way.

Apples-and-oranges comparison. The last non-64 bit x86 CPUs that shipped in any substantial volume are like 15 years old. In contrast, Jasper Lake and Elkhart Lake are still shipping.

AVX2 has been supported on Haswell i3's shipped with a TDP of 35W and newer since. The systems you talk about are not even relevant for the vast majority of Linux desktop users. You can't tell me that neither OEMs or system integrators couldn't design systems around these AVX2-capable CPUs instead (or their AMD low-TDP counterparts with AVX2). Also good luck with running the next Windows iteration on these boxes.

Underspeccing these systems from the start was the mistake in my opinion. The users of these systems now pay the price (either with newer hardware or a change in the OS down the road if they were using a distro that will change to v3 as a baseline, which I haven't heared of any yet).

[coder]

it is not ignorance when pointing out that there is no relevance for Ubuntu Server to care about these boxes

Why are you so sure about that?

as I understand it, there is still enough choice out there for these people to get by another decade on these boxes.

Why should Ubuntu Server not include coverage for embedded servers, like these? What if a product line that includes Elkhart Lake servers scales up all the way to Xeons? Why should there not be a single commercial distro that covers such a range?

And who are you to decide that it shouldn't?

OpenSUSE seems to implement your favored solution, by the way.

I already pointed this out. It's RPM-based, however. Migrating an appliance-type product from Debian-based Ubuntu to OpenSUSE is a nontrivial undertaking, especially if we're talking about automatically migrating tens of thousands of systems in the field.

AVX2 has been supported on Haswell i3's shipped with a TDP of 35W and newer since.

There's a big difference between that and Elkhart Lake, where you can get the SoC and board for cheaper than a current gen i3. Not to mention TDPs go as low as 7 W, which has implications on the cooling solution, airflow requirements, and PSU size & type. You talk as if you've never managed BoM costs.

The systems you talk about are not even relevant for the vast majority of Linux desktop users.

Heh, this is Ubuntu Server.

If we're talking Ubuntu Desktop, then you should also consider all the entry-level notebooks out there with Apollo Lake, Gemini Lake, and Jasper Lake SoCs.

You can't tell me that neither OEMs or system integrators couldn't design systems around these AVX2-capable CPUs

Today they can, because Alder Lake-N supports it. Prior to now, lack of AVX wasn't an issue. In business, you can't justify increasing product costs today, just to hedge against an imagined risk sometime in the future that may well never come to pass.

Also good luck with running the next Windows iteration on these boxes.

I'm not talking about machines running Windows.

Underspeccing these systems from the start was the mistake in my opinion.

They weren't underspec'd. If the OS vendor had telegraphed their intention not to support those CPUs past a certain date, then different plans could've been made. Absent such a limitation, the specs met the requirements. End of story.

[ms178]

Why should Ubuntu Server not include coverage for embedded servers, like these? What if a product line that includes Elkhart Lake servers scales up all the way to Xeons? Why should there not be a single commercial distro that covers such a range?

And who are you to decide that it shouldn't?

Who are you to dicide what Ubuntu Server should or shouldn't support? You want them to implement your favorite solution because you seem to care about these niche use case so much. But this is also a business decisison on how to spend their engineering time, you might need to show them the relevance of these systems to the Ubuntu support team to convince them to invest into that solution. You won't persuade me unless you show me or the Ubuntu executives in charge unless the market share numbers support their relevance.

I already pointed this out. It's RPM-based, however. Migrating an appliance-type product from Debian-based Ubuntu to OpenSUSE is a nontrivial undertaking, especially if we're talking about automatically migrating tens of thousands of systems in the field.

It is an annoyance and some work, for sure. But they could keep their hardware this way. They've brought all this FUBAR on themselves though.

There's a big difference between that and Elkhart Lake, where you can get the SoC and board for cheaper than a current gen i3. Not to mention TDPs go as low as 7 W, which has implications on the cooling solution, airflow requirements, and PSU size & type. You talk as if you've never managed BoM costs. [...] Today they can, because Alder Lake-N supports it. Prior to now, lack of AVX wasn't an issue. In business, you can't justify increasing product costs today, just to hedge against an imagined risk sometime in the future that may well never come to pass.

Please, this has no merit at all. It is all up to choice of the OEMs and system integrators. Of course there are physical limits in shrinking a 35 W TDP into a tiny custom form factor. But the Haswell-i3's I talked about were out there since 2014. No one forces companies to buy tiny and underspecced mini-PCs. As we see, the limitations of such mini-PCs have a cost and a risk associated to them that the people in charge of procurement have neglected. As a legal person that in his former life worke for a local hardware retailer where it was my job to advise people on such questions, I would have pointed such a limitation out to them. If they still wanted to save the last penny in the present, it is up to them to live with the risks that come attached with it tomorrow. But don't complain to me tomorrow that these systems have gotten obsolete faster than hoped. This is exactly what happened to people that are now burned when buying Elkhart Lake etc.

And as you bring Elkhard Lake up so often, this line was announced in September 2019 but only became available in volume in mid to late 2021. We had the first discussions about the x86-feature levels in the summer of 2020 already. So a reasonable person could have anticipated such a move when buying these systems as news about it was already out there. And as you haven't mentioned AMD's alternatives a single time yet, AMD brought their Ryzen Embedded V1000 Line with 12W-SKUs and AVX2 support to market in 2018. Hence there were plenty of capable alternatives out there already for every potential Elkhart Lake user which is why I stand by my rant to get the people fired responsible for such a short-sighted and uninformed purchase decision that now costs them either more effort or money down the road.

Heh, this is Ubuntu Server. If we're talking Ubuntu Desktop, then you should also consider all the entry-level notebooks out there with Apollo Lake, Gemini Lake, and Jasper Lake SoCs.

Again, show me their combined market share on Ubuntu Desktop, then you can try to convince me that these systems matter at all and are worth the engineering effort on Ubuntu's side.

I'm not talking about machines running Windows.

But I did, as Windows 10 IOT was a certified OS for these Elkhart Lake systems. There is no guarantee for anything newer than that and if Microsoft cuts support, they are left with e-waste if they want to stay in that OS ecosystem.

They weren't underspec'd. If the OS vendor had telegraphed their intention not to support those CPUs past a certain date, then different plans could've been made. Absent such a limitation, the specs met the requirements. End of story.

They cannot count on the fact minimum specs won't change over time. And where have you been over the past four years? I thought you were a close industry observer yourself, there has been talk about such a change in minimum requirements since 2019. I already pointed Florian's words out to you from 2020 which were more than a hint that this might happen sooner or later, as he was the author of a Fedora proposal that proposed such a change in CPU minimum requirements in 2019. There is a direct connection and clearly visible intent for all to see here. The blog post this thread is about is in line with these prior discussions and meant to gain such feedback. And even though you and three other people here cried out loud in this thread, my best guess is that it won't change their stance on this as there simply is no business case for Canonical to care too much about loosing these systems.

[coder]

Who are you to dicide what Ubuntu Server should or shouldn't support?

If they want to alienate existing customers, that's on them. However, the status quo supports those machines, and you're arguing against it.

You want them to implement your favorite solution

Nah, I was merely pointing out that debating whether to move the baseline is a false dichotomy.

because you seem to care about these niche use case so much.

Are they niche? You don't actually know. Appliance-type products might sell in fairly substantial volumes.

You won't persuade me

No, I don't care about that. You clearly aren't someone whose opinion matters, nor are you terribly data-driven in forming said opinions.

It is an annoyance and some work, for sure. But they could keep their hardware this way.

Ubuntu loses customers, though. Is that really a win?

As a legal person that in his former life worke for a local hardware retailer

The retail channel is nothing like doing custom system design. Irrelevant.

To carry any weight, you ought to at least have an MBA or accounting degree.

where it was my job to advise people on such questions, I would have pointed such a limitation out to them. If they still wanted to save the last penny in the present, it is up to them to live with the risks that come attached with it tomorrow.

This is exactly the problem with corporate lawyers. It costs them nothing to say "no" or "you probably shouldn't". However, at the end of the day, they're not the ones responsible for delivering on the financial targets.

And as you bring Elkhard Lake up so often, this line was announced in September 2019 but only became available in volume in mid to late 2021.

Because Intel's manufacturing division had such lousy yields on their 10 nm process.

a reasonable person could have anticipated such a move when buying these systems as news about it was already out there.

No, why? Distros had no track record of moving the baseline 64-bit ISA target, and doing so wouldn't affect the majority of software, anyway.

And as you haven't mentioned AMD's alternatives a single time yet, AMD brought their Ryzen Embedded V1000 Line with 12W-SKUs and AVX2 support to market in 2018.

Again, if these distros had telegraphed end-of-support for v2 CPUs, then that might have been an option worth considering. For someone already using Intel's E-core SoCs, there's a reasonable expectation that software support for new models would continue to resemble software support for the older ones.

Hence there were plenty of capable alternatives out there already for every potential Elkhart Lake user which is why I stand by my rant to get the people fired responsible for such a short-sighted and uninformed purchase decision that now costs them either more effort or money down the road.

As a "legal person", you should appreciate the value of precedent, here. With no prior precedent to point to, it's really hard to make the case that the risk is one worth mitigating against. Especially when doing so hurts the bottom line of device makers.

I already pointed Florian's words out to you from 2020

This is a developer discussing with other developers - not an official support announcement made by the OS vendor. Again, as a "legal person", you should appreciate the difference.

even though you and three other people here cried out loud in this thread, my best guess is that it won't change their stance on this

Unlike you, I don't have unrealistic expectations of the impact of a comment thread in the Phoronix peanut gallery.

Second, if you read the article, all they said was it's an unsupported repo. As far as I'm aware, their official stance hasn't changed. For all you know, they're just doing it to gauge interest and see which packages are worth using hwcaps to also build for a v3 target.

as there simply is no business case for Canonical to care too much about loosing these systems.

Again, you've failed to provide any data to support that claim.