I had been Windows user since Windows3.1. More than 3 decades straight. After a few years of working with Linux, installed Debian on home PC about a year ago and couldn't be more happier since then.
I briefly test-drove Windows 2, but have been a solid Windows user since 3.1 too.
I have been forced to use Windows 11 on a succession of work PCs, but I stayed 10 at home due to the lack of a movable task bar and the terrible right-click menu in 11.
When Microsoft started pushing hard against remaining on 10 this year, I made the switch - to MacOS. It was an easy decision, since I was finally able to get a MacBook for work, too, so no context-switching required. I run a copy of Win11 in a VM for apps that need it, but find that I rarely have to spin it up.
As a product manager, I cannot image the decision-making behind building a product update so shitty that you drive away 35-year customers.
I've been trying out different distros, but still using windows 10 ltsc as my main OS. I've got 2 additional partitions containing popos with cosmic and kde fedora that I've narrowed it down to, but both need just a little more bugfixing to to become perfect for me. LTSC is still supported for a while, but if my computer stopped working, I feel like macOS would be a no-brainer for most people.
Is it a normal mic, or bluetooth? I think, Trixie have some regressions in bluetooth stack of Cinnamon - it worked nicely in Bookworm, but I had weird issues on Trixie that just disappeared once I switched to KDE (didn't try Gnome).
My dog (Briard) isn't just addicted to play fetch with balls.. Since he knows that when another dog enters the dog park, the ball will be removed/hidden from him (to prevent the dogs clashing trying to get the ball), he becomes hostile to the dog entering the park, actively trying to prevent them from doing so! This happens only if we started to play with balls. If not, he'll be totally friendly... What an ass!
The problem is that your "good enough" is someone else's "woefully inadequate", and sticking to the old feature sets is going to make the software horribly inefficient - or just plain unusable.
I'm sure there's someone out there who believe their 8086 is still "good enough", so should we restrict all software to the features supported by an 8086: 16-bit computations only, 1 MB of memory, no multithreading, no SIMD, no floats, no isolation between OS and user processes? That would obviously be ludicrous.
At a certain point it just doesn't make any sense to support hardware that old anymore. When it is cheaper to upgrade than to keep running the old stuff, and only a handful of people are sticking with the ancient hardware for nostalgic reasons, should that tiny group really be holding back basically your entire user base?
Ah, com'on, spare me from these strawman arguments. Good enought is good enough. If F-Droid wasn't worried about that, you definitely have no reasons to do that for them.
"A tiny group is holding back everyone" is another silly strawman argument - all decent packaging/installation systems support providing different binaries for different architectures. It's just a matter of compiling just another binary and putting it into a package. Nobody is being hold back by anyone, you just can't make a more silly argument than that...
But it isn't good enough. SIMD provides measurable improvements to some people's code. To those people what we had before isn't good enough. Sure for the majority SIMD provides no noticeable benefit and so what we had before is good enough, but that isn't everybody.
Are you SURE that nobody has figured out how to have code that uses SIMD if you have it, and not use it if you don't?
Your suggestion falls flat on its face when you look at software where performance REALLY matters: ffmpeg. Guess what? It'll use SIMD, but can compile and run just fine without.
I don't understand people who make things up when it comes to telling others why something shouldn't be done. What's it to you?
ffmpeg is a bad example, because it's the kind of project that has lots of infrastructure around incorporating hand-optimized routines with inline assembly or SIMD intrinsics, and runtime detection to dispatch to different optimized code paths. That's not something you can get for free on any C/C++ code base; function multiversioning needs to be explicitly configured per function. By contrast, simply compiling with a newer instruction set permits the compiler's autovectorization use newer instructions whenever and wherever it finds an opportunity.
OTOH, if software wants to take advantage of modern features, it becomes hell to maintain if you have to have flags for every possible feature supported by CPUID. It's also unreasonable to expect maintainers to package dozens of builds for software that is unlikely to be used.
There's some guidelines[1][2] for developers to follow for a reasonable set of features, where they only need to manage ~4 variants. In this proposal the lowest set of features include SSE4.1, which is basically includes nearly any x86_64 CPU from the past 15 years. In theory we could use a modern CPU to compile the 4 variants and ship them all in a FatELF, so we only need to distribute one set of binaries. This of course would be completely impractical if we had to support every possible CPU's distinct features, and the binaries would be huge.
In most cases (and this was the case of Mozilla I referred to) it's only a matter of compiling code that already have all support necessary. They are using some upstream component that works perfectly fine on my architecture. They just decided to drop it, because they could.
It's not only your own software, but also its dependencies. The link above is for glibc, and is specifically addressing incompatibliy issues between different software. Unless you are going to compile your own glibc (for example, doing Linux From Scratch), you're going to depend on features shipped by someone else. In this case that means either baseline, with no SIMD support at all, or level A, which includes SSE4.1. It makes no sense for developers to keep maintaining software for 20 year old CPUs when they can't test it.
> It makes no sense for developers to keep maintaining software for 20 year old CPUs when they can't test it.
This is horribly inaccurate. You can compile software for 20 year old CPUs and run that software on a modern CPU. You can run that software inside of qemu.
FYI, there are plenty of methods of selecting code at run time, too.
If we take what you're saying at face value, then we should give up on portable software, because nobody can possibly test code on all those non-x86 and/or non-modern processors. A bit ridiculous, don't you think?
> You can compile software for 20 year old CPUs and run that software on a modern CPU.
That's testing it on the new CPU, not the old one.
> You can run that software inside of qemu.
Sure you can. Go ahead. Why should the maintainer be expected to do that?
> A bit ridiculous, don't you think?
Not at all. It's ridiculous to expect a software developer to give any significance to compatibility with obsolete platforms. I'm not saying we shouldn't try. x86 has good backward compatibility. If it still works, that's good.
But if I implement an algorithm in AVX2, should I also be expected to implement a slower version of the same algorithm using SSE3 so that a 20 year old machine can run my software?
You can always run an old version of the software, and you can always do the work yourself to backport it. It's not my job as a software developer to be concerned about ancient hardware unless someone pays me specifically for that.
Would you expect Microsoft to ship Windows 12 with baseline compatibility? I don't know if it is, but I'm pretty certain that if you tried running it on a 2005 CPU, it would be pretty much non-functional, as performance would be dire. I doubt it is anyway due to UEFI requirements which wouldn't be present on a machine running such CPU.
There's the issue. You think that Windows is normal and an example of stuff that's relevant to open source software.
If people write AVX-512 and don't want to target anything else, then fine. But then it's simply not portable software.
Software that's supposed to be portable should be, you know, portable.
The implication is that you can decide to not support 20 year old CPUs and still have portable software. People who think that are just ignorant because if software is portable, it'll work on 20 year old CPUs. The "20 year old CPUs" part is a red herring, since it has nothing to do with anything aside from the fact that portable software will also run on 20 year old CPUs as well as different CPUs.
As an aside, instead of making up excuses for bad programmers, you might be interested to learn that software compiled with optimizations for newer amd64 didn't show any significant improvement over software compiled for all amd64.
Also, you have things backwards: code written and compiled today and run on 2005 CPUs wouldn't be "pretty much non-functional, as performance would be dire" unless you're talking about Windows. This is a problem with programmers and with Windows, and targetting the newest "features" of amd64 doesn't fix that. Those things aren't even related.
It's interesting how many people who either don't understand programming or who intentionally pretend not to want to make excuses for software like Windows.
It's not clear how the author controlled for HW caching. Without this, the results are, unfortunately, meaningless, even though some good work has been gone
TBH, such a low price for so many working (!) features is an amazing achievement if not subsidized! What bothers me here, however, is...a provenance. Let me guess, it asks from your smartphone access to your location, contacts, calendar, SMS archive, email, medical records and political views and attitude towards CCP and then does some shady syncs with .cn servers "just to keep you data safe in case a meteor hits you"... Sad.
ADDED: Oh, seems like some people like to pretend that the results of "some other" companies getting this information are totally, totally the same.
Why is it so hard for americans to accept that china makes great tech without coping about "le CCP spyware!" - it seems so absurd, like why would the CCP want to know the heart rate of the type of guy who buys a 16 pound smartwatch? Why dont americans create 16 pound smartwatches?
No more safety and environmental regulations. Children can work full time. Union bosses get sent to the gulag. Forced labor camps for the homeless and criminals.
Because sinophobia, or put in a more crass way, racism, imperialism, and patriotism.
Why should I care if the Communinst Party of China is spying on me? They can't get at me. I have no connection to China. I have no property there and don't know anyone there. What are they going to do to me?
Bottom line is that everyone on the planet should be concerned with their own government's intelligence angencies more than any others. It's the people who can get at you in meatspace that you need to worry about.
China hopes that if they sell enough some will end up on the wrists of military or intelligence personnel, or more likely the family members of such people.
The comment is flagged and killed and I'm now posting them a warning, but you should email us, not tag. You should also avoid swipes like "The mental gymnastics i read on HN is mind boggling stupid", which was obviously an attack on the parent commenter and the broader community, if you want to demonstrate that you care about the guidelines.
The difference between Apple and the CCP is that CCP is the one running the slave labor to make widgets, and Apple is the one paying for it and puts the sticker "Designed in California" to wash it off.
Implying all US electronics don't ask from your smartphone access to your location, contacts, calendar, SMS archive, email, medical records and political views and attitude towards the US and Israel and then does some shady syncs with .com servers "just to keep you data safe in case a meteor hits you"... x)
The thing is that in practice, if China knows my secret, they can't do much with it, first because I don't criticize China (I don't live there, I don't know there, why then ?), and the second, is that it is a rather isolated world. Unless you speak Chinese, they don't really care about you. So it's in some way "safer" (unless they resell the data to americans or israeli companies for 'advertising' purposes)
> Let me guess, it asks from your smartphone access to your location, contacts, calendar, SMS archive, email, medical records and political views
Like every app made by a US corporation does?
And before someone cries "whataboutism", I'm genuinely curious why as someone who isn't Chinese, and has no intention of visiting China, I should be more worried about the CPC than the CIA.
I absolutely love 3 dimensional nature of the game and how carefully many images are chosen to allow for a precise spacetime localization with a bit of a research. Super enjoyable experience in startling contrast with geogessr, which I don't even want to open.
Thanks a ton!
