Wow, big memory trip! It was os/2 warp, I saw that package and knew it!
Dad worked for IBM in the 70s, no surprise. I also remember him having an OS box with a penguin on it but I don't believe he ever installed it. ~95ish.
Longtime Debian and Arch veteran here. I moved most of my workstations to Silverblue earlier this year (maybe 8 months ago now), and I’ve been very happy overall.
There is a bit of a learning curve if you aren’t familiar with Flatpak or container-based workflows, assuming you wish to embrace those elements, but the curve is nowhere near as steep or unconventional as NixOS.
I love the automated updates. The flexibility to rebase or rollback the core OS on the fly, without any extra work, is great too. For example, it’s very easy to test out beta releases, remixes, and preconfigured software bundles like uBlue.
I still use Arch for 99% of my command line tasks, inside a container managed by distrobox.
I strongly believe that Flatpak is the future of Linux software deployment, and although the format still has its kinks, it is already quite mature and will only get better as more and more upstream developers adopts its use.
Is the deer the Libreboot logo? Mine has a rabbit (Coreboot). I flashed Coreboot on my old Chromebook a couple of years ago and it’s been running different flavours of linux since without any fuss.
That view bug has been sitting around since 2009, from what I can gather. But a file manager giving false filesystem state to a user is a showstopper. It violates the main purpose of the program. And risks data loss. Users may make errors based on false information.
Batch renaming I use regularly by ingesting media from cameras, though typically at the command line.
Interesting take. I wonder if the amount of platform dependent bugs is generally that low for games. I’m a developer, but not a game developer. I would assume that platform dependent stuff comes into play a lot more, when using shiny new tech like direct storage, which is probably used more by AAA titles and less by indie games?
I made games primarily for Windows which we also compiled for Linux. It is mostly input/output stuff, aka hardware issues. That is, audio issues, input issues, storage issues, dependency issues. Modern game engine mostly handle the rest. It wasn’t such a big deal to fix, but most gamedev lacked experience with Linux, and most projects are already over budget and late, so fixing Linux for an extra 2-5% of sales didn’t make much sense at small scale. Proton kind off fixed all of this tho.
In my somewhat limited but relevant experience, the amount of platform specific bugs is indeed that low. I mean, there’s of course a layer of platform-specific low level stuff which is highly subject to platform specific issues, but once you go above that layer and into game code proper, most bugs are just bugs.
I didn’t fix 400 “Linux-only” bugs, but I did fix dozens of “seems Linux specific” and “only happened when at least one Linux client was connected” bugs, and a grand total of 2 were caused by platform differences. And of those two, zero were Linux specific. The platform difference in this case was about how different compilers optimise non-crashy types of UB.
Of course, we don’t want UB at all so the fix is to remove it.
The difference is money. Vulkan is an incredibly terse spec compared to dx12. You’d think that would make it much more consistent to work with, but really, it’s all it can do to keep up with msft and IHVs who pour money into coaxing AAA devs to use dx12. Then, even when the app gets something wrong and causes issues for end users, the IHV just makes a special case in the driver to correct it, because having a big important dx12 title run correctly on their hw is important to sell units.
Meanwhile, the same IHVs barely bother to support anything beyond the basic vulkan requirements, because it doesn’t gain them anything to do more. If a vulkan game experiences issues, IHVs don’t care because it won’t sell well anyway.
Yes, and the primary reason any of gaming on Linux is viable (steam deck, proton, etc) is due to Valve dumping money into it. AMD probably didn’t care about the miniscule number of chips they sold to Valve for the deck, valve just wanted a vendor who had the performance, and had decent Linux support.
But Valve is the one eating all the vulkan costs that msft normally eats on the dx side. To be clear, it’s never out of the kindness of their hearts, it’s purely because a msft dominated gaming ecosystem on PC is steam’s biggest weakness. They don’t want steam on windows to reach the point of EGS on the apple store.
For me this is Gnome with the pop shell extension. It’s so much better than plain i3 in usability and just as good with tiling. Using i3 for years made me appreciate the value of a proper modern desktop environment.
Does this “obviously” have to use AI? I can see a tool that sorts files into folders based on file extensions, modification dates and/or metadata could get the work done.
And if organising files by content (e.g. “my zoo trip”, “meetings with Xenia”) is that important, doing it manually seems like a better idea because accuracy is presumably important.
I don’t really see the distro hopping argument either. Even if you don’t share your home directory between installs, presumably you copy over your files as directories rather than individually pouring them into one super folder?
I think a lot of folks with very limited IT knowledge think AI will solve things that have been solved for decades.
The issue is availability and elitism. A noob user doesnt know how to find this stuff, google is so rotten that its not help anymore and pros often just shit on them instead of making a comprehensive wiki.
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.