For XP, the machine KVM presents as may be too new, but that isn’t an issue with non-virtualized QEMU.
For XP, the machine KVM presents as may be too new, but that isn’t an issue with non-virtualized QEMU.
TIOBE is weighted toward languages that have existed for a long time by virtue of counting lines written / skilled engineers etc. but the speed at which Rust is climbing that list is a better indicator. Also, a lot of the languages above it wouldn’t be appropriate for anything like a DE.
But you’re right, it’s hyped, I just think the hype is real.
This is a weird take. Rust is very popular and is the current heir apparent to C for systems level stuff. It’s a great choice to start a new DE/toolkit.
As for the rest, you’re right the end user doesn’t care about the language their graphical app is in, but the developers fielding their bug reports and making fixes/features sure do.
This better not awaken anything in me…
John Carmack, author of the Doom engine, is a long time Linux user and for a while the policy was to open source the idTech engines once they had moved on.
However, Doom was hugely popular on its own before this, and was actually more pivotal for making Windows a gaming platform (over DOS).
The reason it runs everywhere is a combination of it’s huge popularity, it’s (now) open source and it’s generally low system requirements.
Honestly, with Flatpak and immutable base systems this is a place Linux is really excelling now too. Being able to show a novice user a shared package manager with a search and a bunch of common apps and them actually install/remove them in a safe manner with a high likelihood they’ll work out of the box (since they come with all their deps in sync independent from distro) is kinda huge.
It does that everywhere, even on non .deb distros.
One thing I’d like to suggest is get most of their forward facing apps as Flatpak and let them install software that way instead of using the system package manager (even if it has a GUI). This jibes with others suggesting an immutable base system.
Obviously this may be more of a concern for older kids, but my kid started with Linux and it did fine… Right up until Discord started breaking because it was too old and they didn’t want to tangle with the terminal. Same thing when Minecraft started updating Java versions. Discord and Prismlauncher from Flatpak (along with Proton and Steam now) would have kept them happier with Linux.
As for internet, routers come with parental controls these days too, which have the added advantage of being able to cover phones (at least while not on mobile data). Setting the Internet to be unavailable for certain devices after a certain time on school nights may be a more straightforward route than DE tools.
For kernel dev it would be a disaster, there’s too much implicit action, and abstractions that have unknown runtime cost. The classic answer is that everyone uses 10% of its features over C, but nobody can agree on which 10%.
As someone forced to get up to date with C++ recently, at this point it’s a language in full identity crisis. It wants so badly to be Rust, but it’s got decades of baggage it’s dragging along.
In a world where Valve controls 90% of what is running on a device with immutable / containerized images, yeah I think Arch makes a lot more sense. A distro focused on rolling release is a lot less likely to hang you up when you choose to update.
Debian is great, but depending on where you are in the release cycle it can be a pain in the ass to stay up to date and, frankly, the last time I ran it, shit like apt/dpkg configuration and so many /etc files and structures just felt like mis-features or too complex for their own good.
This isn’t a benchmark of those systems, it’s showing that the code didn’t regress on either hardware set with some anecdotal data. It makes sense they’re not like for like.
I used (u)xterm for like 20 years before discovering that Konsole is solid and beautiful. My whole tiling setup is backed up with KDE apps now.
That’s an interesting thought. I’ve wondered this about Chrome’s market share in browsers too. How much of it is just that so much traffic is now from phones where, even if you have another browser installed, apps open links in embedded Chrome web views.
I’m also glad to see Wayland tools maturing. The hand wringing about lack of X forwarding was always FUD and a nonsense reason to cling to the fiction that X works well over a socket and justify all the shitty compromises X made to remain compatible with it.
The Windows scheduler is so stupid chip manufacturers manipulate the BIOS/ACPI tables to force it to make better decisions (particularly with SMT) rather than wait on MS to fix it.
Linux just shrugs, figures out the thread topology anyway and makes the right decisions regardless.
Nobody running a FOSS third party launcher is an average end user. Also, people routinely add flags to typical games even on Windows (e.g. -skiplauncher)… It’s really not that big a deal.
Really? I use Arch native Steam and Proton no problem. You either use steam-runtime (uses built in Ubuntu runtime) or steam-native (expects Arch packages) but there is a meta package for pulling the runtime deps. Both have worked for me.
That said, Flatpak has come in clutch for me as well on the Steam Deck, and for things like Prism Launcher (modded Minecraft launcher) where you want to juggle multiple Java versions without needing to run archlinux-java between switching packs.
I dunno about ethos, but I do know Pine can also make false claims. I bought a Rock64 years back and they touted it as 4k60 video capable with an integrated GPU and that wasn’t realistic at all. The software stack was still very immature on release. From their own wiki, years later, it still doesn’t work and key parts still haven’t been upstreamed.
High five, I also drove a manual '98 Civic that was my dad’s. Put another 150k miles on it, drove it longer than he did and, up until it’s transmission died, I never spent more than a couple hundred on repairs at a time. Ended up donating it a couple years ago, but damn good car indeed.
Right. GCC -f optimizations are basically like “how hard are we going to try to be clever” and are, I believe, orthogonal to the actual instructions used. Machine dependent args start with -m, like -march or -mavx etc.