[johnklos]

You'll see a whole bandwagon of people saying things like, "supporting old hardware is BAD! It takes time and money that nobody has!", as though someone needs to be hired to sit around and do nothing but pore over code and constantly rewrite code for old hardware.

There's plenty of evidence to the contrary, but since when has evidence mattered when it comes to defending the right of big business / big distro to do whatever they want? ;)

Really, this is just laziness and sloppiness on the Linux distro makers' part. Any amount of testing would catch this. Thanks, Rachel!

[JonChesterfield]

Your stance is:

    1/ Old hardware is free to support because the software for it just keeps working

    2/ Lazy Linux people didn't test the software that stopped working on old hardware

Those two things you believe to be true are inconsistent with one another. For example, in this context.

What you're missing is that code changes to do new stuff and sometimes those changes are incompatible with old hardware or operating systems. If noone is testing said old systems and the developer doesn't remember said eccentricities, the old systems will break when the new stuff lands.

If anything it might be better to spend the resources deleting the support for old hardware (probably at the point where people stop testing on it) so that people using the old stuff get a much clearer message that they also need to use old tools with it. It's hard to get sign off to do that either, leaving the probably broken stuff lying around is the spend-no-time-now choice.

[johnklos]

You're generalizing, and doing so with poor assumptions. Supporting old hardware isn't about cost. If one wanted to compare the cost of simply maintaining code with the cost of adding features, supporting new hardware, and so on, it'd be hard to even measure maintenance.

The Raspberry Pi Foundation should be running two Pis of every kind with the newest version of their official OS and the next older one, running automated tests. This isn't hard, nor is it time consuming after it's set up.

The real issue is that people change things in ways that affect older hardware, which is fine, but they should test those changes. If they don't want to, they shouldn't be making those changes. Period.

[bee_rider]

Big distro. These fat-cat volunteer kernel devs are just trying to keep us down by giving us so much free software that we collapse under the weight of it.

[zmgsabst]

Aren’t a lot of kernel devs paid by large corporations?

Eg, this article.

https://thenewstack.io/contributes-linux-kernel/

[Shish2k]

Corporate developers are typically paid to solve corporate problems. Sometimes a company will hire a big-name OSS developer and tell them “continue maintaining your project in whatever way you think best”, but that’s by far the exception rather than the norm.

[yellow_lead]

> You'll see a whole bandwagon of people saying things like, "supporting old hardware is BAD! It takes time and money that nobody has!

> Any amount of testing would catch this.

Who is paying for the testing? I'm not suggesting supporting old hardware is bad, but we must recognize it takes some effort to uphold backwards compatibility. Stuff gets broken accidentally always, and testing isn't free.

[Elucalidavah]

> sit around and do nothing but pore over code and constantly rewrite code for old hardware

In case of refactoring / restructuring, that's exactly so.

But "drop support for this old hardware" is meant to be an intended decision with a clear deprecation warning, not accidentally.

[atemerev]

The bazaar doesn’t work like this. There are no incentives to support old hardware. If there are enough people with old hardware, their activity might be enough to do something. Otherwise — puff, gone.

Open source is already a miracle. The fact that something works somewhere is a miracle. I don’t tempt the powers and I don’t demand even more miracles to satisfy some perfectionist urges.

[woodruffw]

This has nothing to do with the distro; it looks like an upstream LLVM bug. And it does demonstrate the problem: old code doesn’t change, but interfaces and invariants do. Those external changes do represent maintainer burden.

Armv6 isn’t really “old hardware” in the “disused, actively rotting” sense. That’s reserved for things like Itanium or HPPA, which distributions (and upstreams) would do perfectly well to remove unless paid buckets of money by their respective corporations.

[livrem]

Raspberry Pi Zero (W) are still great. There will be millions of them around in use for decades to come. I will probably always have a few in some drawer. Sad to hear that anyone even considers deprecating support for that hardware. Not to mention all other ARMv6 hardware still around. We need some baseline hardware types that just will always be supported, to add some friction to software rot and bloat in general.

[shadowgovt]

Yeah, I can see the benefits.

Are you volunteering to be the one that runs exhaustive regression tests on every distro release? The open source community only thrives as much as people are willing to dedicate volunteer time into making it thrive.

[livrem]

I test my own open source code on a RPi Zero when applicable. I can report bugs to other projects if I happen to notice something is missing, but I can't decide what platforms they should support or not. I can hope that as many as possible can see the value in having some standard fixed, low-performance, high-priority, default targets that are "never" deprecated. But the only thing that would scale is that every project find their own volunteers to make it happen.

[woodruffw]

> Sad to hear that anyone even considers deprecating support for that hardware.

I don’t think anybody has. This appears to have been entirely an accidental regression.

[livrem]

This was a comment in the thread on distros deprecating ARMv6 support, not the clang issue.

[account42]

> This has nothing to do with the distro; it looks like an upstream LLVM bug.

Wrong: https://news.ycombinator.com/item?id=38505879

[jenadine]

The thing with free software is that you are in no position to demand anything. If the maintainer don't feel like supporting your hardware, they don't have to.

But the beauty of free software is that you can always do it yourself. (Or pay someone to do it)

[shadowgovt]

If anything, this can be read as, while an inconvenience, an open source success story.

All pieces of the puzzle were open enough that the author could track down the problem and correct it. That, not indefinite support for no-longer-manufactured hardware, is the benefit of open source. It's the thing that enables the other thing.

And thanks to the magic of the internet, blogs, and search engines, now that one person has solved the problem there's a cracking chance that the next person to have the problem will find the solution.

[_chu1]

This is true for Windows. Free software has helped keep operating systems like Windows XP and 7 still modern and secure, and many applications have been patched to work on these older systems. Here is for instance a port of Firefox Quantum to XP and a fork of Chromium maintaining support for 7, but I like to stick to the last Ungoogled Chromium version because I hate Google.

https://github.com/Feodor2/Mypal68 https://github.com/win32ss/supermium

[wmf]

I think RPi has struck a reasonable balance where the mainstream Linux community doesn't really support ancient ARMv6 so RPI themselves maintains forked software (e.g. Raspbian). This way the cost of legacy is borne by those who benefit from it, not everyone.

[deaddodo]

Raspbian existed well before ARMv6 support dropped off. It's been their main distro from the outset, but mainstream distros with ARM builds only removed support for ARMv6 in the last 1-3 years (depending on distro).

[account42]

Pretty sure Debian's armhf images have always required ARMv7 or at least for much longer than 3 years. There are also armel images but those don't use hardware floats which makes them much less performant than what the original Pi is capable of. Pretty sure that that mismatch is why raspian exists in the first place.

[kaba0]

> when it comes to defending the right of big business / big distro to do whatever they want? ;)

Anything else about your alternative reality?

Also, why don’t you go and take on support for this given target, if it’s so important for you? Or pay for someone to do it? I’m sure the project wouldn’t mind supporting it if someone would have stepped up, but I’m sure it’s still not too late.

[bregma]

> You'll see a whole bandwagon of people saying things like, "supporting old hardware is BAD! It takes time and money that nobody has!", as though someone needs to be hired to sit around and do nothing but pore over code and constantly rewrite code for old hardware.

It has been my experience, over the last 6 decades or so, that it almost always boils down to "doing anything except what I want is a waste of time and resources".

When it comes to free software, you do what you do and learn to ignore the "but what about ME!" demands from those who contribute nothing else. Or you move on and put your energy into something else.

[zozbot234]

Typically, support for old hardware is added as part of the "experimental" featureset. Meaning that it's expected to break from time to time as the underlying codebase changes, until the folks who care about that support come around and fix the breakage. If that maintenance stops altogether and the code stays broken, that's when it gets removed.