I'm bit puzzled, isn't VRR more for low powered hardware to consume less battery (handhelds like steam deck)? How does it fit hardware that is constantly connected to power?
Variable refresh rate is nice when your refresh rate doesn't match your output. Especially when you're getting into higher refresh rates. So if your display is running at 120hz, but you're only outputting 100hz: you cannot fit 100 frames evenly into 120 frames. 1/6 of your frames will have to be repeats of other frames, and in an inconsistent manner. Usually called judder.
Most TVs will not let you set the refresh rate to 100hz. Even if my computer could run a game at 100hz, without VRR, my choices are either lots of judder, or lowering it to 60hz. That's a wide range of possible refresh rates you're missing out on.
V-Sync and console games will do this too at 60hz. If you can't reach 60hz, cap the game at 30hz to prevent judder that would come from anything in between 31-59. The Steam Deck actually does not support VRR. Instead the actual display driver does support anything from 40-60hz.
I have a dual pentium pro 200 that runs gentoo and openbsd, but rust doesn't ship i586 binaries, only i686+. So I would need to compile on a separate computer to use any software that is using rust.
There is already an initrd package tool I can't use since it is rust based, but I don't use initrd on that machine so it is not a problem so far.
The computer runs modern linux just fine, I just wish the rust team would at least release an "i386" boostrap binary that actually works on all i386 like all of the other compilers.
"We don't care about retro computers" is not a good argument imho, especially when there is an easy fix. It was the same when the Xorg project patched out support for RAMDAC and obsoleted a bunch of drivers instead of fixing it easily. I had to fix the S3 driver myself to be able to use my S3 trio 64v+ with a new Xorg server.
This sounds like it's fun. However, I have to ask, why should the linux world cater to supporting 30 year old systems? Just because it scratches an itch?
You can grab a $150 NUC which will run circles around this dual pentium pro system while also using a faction of the power.
You obviously have to do a lot of extra work, including having a second system, just to keep this old system running. More work than it'd take to migrate to a new CPU.
I grew up without money, it makes me laugh when I read comments like this. You can just, yeah when you're fortunate enough to have a strong support system; you can.
My understanding is that the systems are not meaningfully common, and are hobbyist archs. But the idea that dropping support is fine because you can just throw money at it is so incredibly divorced from reality that I actually feel bad for anyone that believes this.
I deeply believe that if you don't like what a maintainer of FOSS code has done, you should fork the project. Admittedly that's a very onerous suggestion. But more important than that, you should help people when you can. If you're deciding to drop support for a bunch of people because it makes your job easier or simpler, when you don't need to. You're the bad guy in the story. That's the way this announcement has been written, and most reasonable people object to that kind of behavior. Selfishness should feel a bit offensive to everyone.
I have plenty of relatives without money or resources and $150 is something they can all afford.
It's not even the floor of the amount of money needed (Here's a used NUC for $30 [1]), but rather just showing that a new system can be had for a lot less than many people expect.
You are the one divorced from reality if you think there's an army of poor orphans running modern linux on pentium pros.
Affording rent and health insurance is a FAR bigger issue than being able to throw a little money towards a new computer once every 10 years.
The situation today is very different than what it used to be when people actually used 386 or Amigas because they had no other options (BTW, Rust supports m68k, just not AmigaOS specifically).
Today even crappiest old PCs that you can fish out of a dumpster are already new enough to have Rust/LLVM support. We have mountains of Rust-compatible e-waste that you can save from landfill. Take whatever is cheapest on eBay, or given away on your local FB marketplace, and it will run Rust, and almost certainly be orders of magnitude faster and more practical than the unsupported retro hardware.
Using actual too-niche-for-Rust hardware today is more expensive. Such machines are often collectors' items, and need components and accessories that are hard to obtain, or need replacements/adapters that can be custom low-volume products.
Even if you can put together something from old-but-not-museum-yet parts, it's not going to make more sense economically than getting an older-gen Raspberry PI kit or its Ali Express knock-offs (there are VGA dongles more expensive than some of these boards).
It's fine to appreciate SGI and DEC Alpha, have fun using BE OS, or prove that AmigaOS is still a perfectly fine daily driver, but let's not pretend it's a situation that people are in due to economic hardship.
> but let's not pretend it's a situation that people are in due to economic hardship.
I'd encourage you to not strawman my response. Because I already said myself that it appears to me it's only hobbyists who are losing support.
My objection isn't to the argument that it's dropping support, my objection is that it's dropping support without cause. Other than, the assumed this would be more comfortable for me.
Maintainers are absolutely not required to support everything for ever, but I recall a story where someone from Linux paid for a user to upgrade, not because that was required, because more because that would make dropping support for that floppy driver feel ethical.
This is the level of compassion everyone should expect from software engineers in critical positions of power.
I have no sympathy for people who lack the compassion to expend the effort to help others. I do have sympathy for people who have to watch the world that they, even if it's them alone. Have to watch their world get worse, so that others can avoid a trivial amount of perceived discomfort.
Should this solo maintainer (who understands C) be required do things exactly the way that I want? Of course not, but I'll be damned if everyone expects me to remain silent while I watch them disrespect other people who were previously depending on their support.
By alluding the switch to Rust was "without cause", and bringing up concerns of floppy users and retro-hobby hardware, you seem to be seeing the change only from a very narrow perspective of interests of very specific group of users.
There are lots of other users, and lots of other ways to care about them. Making software less likely to have vulnerabilities is caring about its users too. Making software work better and faster on contemporary hardware is caring about users too, just a different group (and a way larger one, and including users who really can't afford faster hardware).
Sometimes it's just not possible to make everyone happy, and even just keeping the status quo is not always a free option. Hypothetically, keeping working support for some weird floppy drive may be increasing overall system complexity, and cost dev and testing effort that might have been spent on something else that benefitted a larger number of users more.
Switching to a language with a friendlier compiler, fewer gotchas, less legacy cruft, and less picky dependency management can also be a way of caring about users - lowering the barriers to contributing productively can help get more contributions, fewer bugs, improve the software overall, and empower more users to modify their tools.
It'd be fine to argue which trade-offs are better, and which groups users should be prioritized, but it's disingenuous to frame not accommodating the retro/hobby usecases in particular a sign of lack of compassion in general. It could be quite the opposite - focusing only on the status quo and past problems shows lack of care about all the other users and the future of the software.
The system is actually running fine standalone since I have been able to avoid rust software.
As to why it should cater to it, it's more that there is no need to remove something that already works just to remove it.
It is possible to compile rustc on another system so it supports i586 and below. Just a small change in the command line options. And it doesn't degrade the newer systems.
I have plenty of faster machines, I just enjoy not throwing things away or making odd systems work. It's called having fun :)
> it's more that there is no need to remove something that already works just to remove it.
There actually is. Support for old systems isn't free. Mistakes in the past are hard to fix and verify on these old systems. Particularly, the fact that there's not a whole lot of devs with access to dual pentium pro systems to verify changes which would affect such systems.
That means that if there's a break in the kernel or elsewhere that ultimately impacts such system they'll hear from a random retro computing enthusiast which takes time from everyone to resolve and review patches to fix the retro computer.
Time is precious for open source software. It's in limited supply.
I get doing this for fun or the hell of it. But you do need to understand there are costs involved.
Yes, sorry I remembered incorrectly.
The rust compiler claims to be i686 and the CPU is i686 too, but the rust compiler is using Pentium 4 only instructions so it doesn't actually work for i686.
Edit: I see from the sister post that it is actually llvm and not rust, so I'm half barking up the wrong tree. But somehow this is not an issue with gcc and friends.
> "We don't care about retro computers" is not a good argument imho,
It absolutely is. If you want to do the work to support <open source software> for <purpose> you're welcome to do so, but you aren't entitled to have other people do so. There's some narrow exceptions like accessibility support, but retro computing ain't that.
I would expect the same number of laypeople to know about NetBSD and Debian (zero). Which gets neatly to an argument that I like for this kind of thing: Don't be so quick to throw out the long tail, because you're on it.
In Europe we have the PSD2 open banking [1] directive which essentially gives developers a standard api access to banking operations on behalf of a user.
It is a requirement for banks to implement this and the FSA will be on your neck if you are not compliant with the standard.
To access that API you need a license as an authorised third-party provider (TPP), don't you? So in practice it is only for businesses capable of pushing through the bureaucracy.
I suspect the apparent reduction in price on these devices is a lot less than what they earn from the slimy stuff.
But the premium devices (especially TVs) are starting to do this too now via software updates. I had to turn off a bunch of crap in the settings on my LG CX TVs some time ago. Now they are just off the internet and can only connect to my NAS.
It's to avoid the dutch decease, but the "oil fund" revenue is now paying for 20% of the state budget so it's getting close.
The total tax level for Norwegians are only in the middle of the chart when compared to other OECD countries so it is not really that high comparatively.
The main issue with the "wealth tax" is that it is also taxing active capital (company values, stock etc) even if that capital is not making a profit.
On another note, as a Norwegian, I happily pay my taxes even if I am in the top bracket. It is for the most part spent wisely.
It is nice to feel that your taxes in your country are being spent wisely.
I know it’s subjective so different for everyone but here in Australia I feel like it’s been a long time since we had actual leadership and we’ve had lousy middle management steering the ship.
For reference, I picked Frankenstein, Alice in wonderland and Moby dick as sources and I think they might be larger than necessary as they take some time to load. But they still work fine.
There also seems to be a bug in babble.c in the thread handling? I did "fix" it as gcc suggested by changing pthread_detach(&thread) to pthread_detach(thread).. I probably broke something but it compiles and runs now :)
reply