Personally, I’m looking forward to native Wayland support for Wine and KDE’s port to Qt 6.
Linux phones are getting closer and closer to usability every day. I don’t care that they’ll always be less polished than iOS or Android, I want a Linux phone.
Linux phones
Will we be able to use messaging apps such as WhatsApp and Signal on Linux phones?
Yes, since you can run Android apps on them. They will be slower and have some quirks though I’m sure.
I’ve been curious about Linux phones. Can you recommended any devices or operating systems to watch? Thanks.
Pinephone has a great active community, and the device itself is dirt cheap (also pretty low-specced). There’s a pro version with a much better specs in theory, but development state is much rougher. Not that the basic model is anywhere near daily driver material yet, but the progress is very appreciable every time i check in.
Linux phones for me. Really impressed by how these things have come in the last 3-4 years, and now we’re getting close to having at least one that’s usable day-to-day (with plenty of rough edges, obviously). As soon as that happens I hope more people will decide to take the plunge and really start pushing things forward.
Oh yea, I’m very excited to give Plasma Mobile a go in earnest
Plasma’s scalable applications paradigm has been around for coming up on 15 years. Gnome’s isn’t far behind.
A WINE type app but for OSX (or really just iOS) apps would be awesome to have both desktops and phone. Call it CIDER or something similar. I reckon the way Apple does their app stores these days it would be hard to actually get most software working, but I don’t think that alone is a showstopper.
Having both that and Waydroid on a phone would be pretty great. You might want to check out Darling for running Mac apps on Linux in the meantime, since its goals are similar to Wine’s (but it’s still early in development in comparison)
AMD is planning to release OpenSIL in 2027, which should, in theory, accelerate the development of Coreboot and Libreboot and bring them to modern AMD motherboards
I’m curious, will that work with Motherboards released until then, or just new motherboards from that point onwards?
New motherboards. Unless AMD collaborates with board makers to push updates to their BIOS/UEFI to include OpenSIL compatibility, which is likely not going to be the case in my opinion
-
More/better atomic distros, like Silverblue, Kinoite, VanillaOS, etc. Silverblue is already excellent, easy to use and extremely solid, but there are still some odd rough edges that I think would make it less appealing to new users. When we can offer newbies a personally unbreakable Linux system that does basically everything they want and more, then I think it’ll be easy to recommend. At this point it’s hard to imagine going back to a traditionally updated distro.
-
The next steps for PipeWire, which has improved and streamlined audio (and sometimes video) handling and production immensely. I can imagine a future where we can easily send, audio, video, midi, and all kinds of other data streams between arbitrary programs on Linux, easily routing things with GUI frontends, having connections establish automatically, etc. I don’t know how much this stuff is in the works, but I think PipeWire has a ton of potential left to be explored.
-
-
bcachefs; I currently use zfs and am not a huge fan of btrfs. Having another filesystem mainlined will be fun.
-
eBPF, particularly if somebody picks up after the presumably abandoned bpfilter.
-
Improved/matured support for rust written drivers. I’m not so fussed about in-tree work, but future third party drivers being written in a safer language would be a nice benefit.
-
long term: the newly introduced accelerator section of the kernel might make SoCs with NPUs and the like have better software support.
-
very hyped for plasma 6, and Cosmic both. I’ve got a lot of confidence in KDE devs, and Cosmic previews look very nice.
-
NixOS has been a really cool distro for a while, but it also looks to have a solid build system from which interesting derivatives will show up.
from which interesting derivatives will show up.
I don’t think that will happen and hope it won’t because NixOS can handle the usual preferences people might have internally.
Don’t like glibc? pkgsMusl is the entire package set but with musl instead of glibc.
Want static compilation? pkgsStatic.
Afraid of systemd? Well okay, we don’t have that right now but I don’t think anyone would be opposed to optional support for worse service managers. It’d just be an opt-in toggle that we could support with enough people interested in it.Nah, people always want to put their own spin on things and I welcome the diversity.
Arch can bring in all the necessary packages yourself, but Garuda exists and people enjoy using it. Horses for courses.
Garuda only exists because the only way to distribute a set of default configuration in regular distros is to create a whole new distro/installer. We don’t have that problem in NixOS because all configuration is declarative and composable.
In the NixOS world, Garuda would be a NixOS base config which users would import in their own config and extend with their own configuration. You’d still be using NixOS though.
If you’re packaging enough changes that somebody would say it’s a different experience, calling it the “X configuration” vs “X distribution” based on how it’s packaged is just splitting hairs.
Just to be sure, what’s wrong with ARC and L2ARC?
My issue is not with the ARC, it’s a few things:
-
kernel integration is iffy; I don’t want to attach a module to my system every time I compile the kernel and prey that the difference in pace between the release schedules of openZFS and Linux hasn’t caused issues, and because of the licencing issues my options of having a distro with zfs built in are very limited.
-
it’s performance isn’t excellent from a NVME standpoint. It’s not terrible, but it could be better.
-
it has a massive code base, making introducing things like performance improvements and new features quite a challenge (Though the openZFS team are doing a bang-up job despite this).
Ultimately if I was still holding on to 40+TB of important data, I’d be using ZFS and be happy about it. I want snapshots on my workstation, without all the strange issues I’ve had with btrfs. I’m sure bcachefs will have its own issues but it’s better to have options.
Sure, I understand the part about having to compile the ZFS module every time alongside the kernel. But that must be some heavy-lifting you’re doing if you’re regularly compiling your own kernel. I’d be interested in what you’re running that requires such efforts.
I don’t understand why you would need NVMe for ARC. Doesn’t it run in RAM only? Isn’t L2ARC what runs on storage devices?
Not really heavy lifting, I’m just running the Xanmod kernel, and need to turn on some features I need for eBPF development. I’m also keeping up to date with kernel releases, so every 6 weeks or so I need to rebuild.
The ARC runs in RAM, but is generally best when it’s given:
- A consistent amount of memory.
- An easily predictable workload.
- Long periods of time between restarts.
Conditions great for a server but not so much for a workstation. I don’t intend for my cache misses to go to spinning rust, so I have 2 2TB NVME drives. SSDs are cheap as chips currently.
The L2ARC is a victim cache of the ARC, and while it is persistent it’s still much more effective for me to just use a NVME drive for my pool.
Just went through Xanmod’s page: the list of features provided seem exciting, although I don’t really know much about some of them. Do you need these features for eBPF development?
Well, you’re right: ARC is best used in a server. What problems did you have with BTRFS that prompted you to switch?
I use Xanmod for gaming (fsync & related tweaks), but need other flags for development on the same machine.
My issues with BTRFS were mainly in their userspace tooling; ZFS volume management is just glorious, it felt like a significant downgrade to use BTRFS.
-
What’s eBPF?
It’s a technology that lets you run code through the kernel’s JIT compiler. It’s an extremely flexible way to run code in kernel space; the typical example is using it to build XDP programs for networking, which can deeply analyse network packets without having to incur the performance penalty for changing context to userspace.
-
Better tools for graphic design. Maybe a port of the Affinity suite or a big push towards GIMP, Inkscape, and Scribus development. GIMP… I feel like people dreamed for more than a decade for essential photo editor functionalities like CMYK support and non-destructive editing. At least the first one is coming in the next version(partially).
I switched my design workflow to FLOSS tools exclusively. Krita is a perfectly competent photoshop replacement, Inkscape has been developed at a breakneck pace in the past year, the workflow is different, but it’s every bit as good as illustrator, and Scribus is great once you get used to the workflow. If anything, Scribus’ workflow helps you plan and structure your projects better. IMHO FLOSS tools are absolutely ready for professional work, but you cannot expect the workflow to match
existingproprietary tools.Krita was developed for graphic design specifically. Gimp tackles other simpler use cases
HDR and HDMI 2.1 support would be nice.
Some TVs don’t have display ports eh.
And maybe we wanna enjoy 7.1 audio on our fancy ATMOS setups.
IIRC the next few Wayland updates this year will solve and improve a lot of problems.
IPFS has a ton of potential behind it, as it makes publishing, accessing and retaining content drastically easier than HTTP. The content-addressing also means you can basically sidesteps the whole act of “downloading”, no more need to download a file, extract a file, etc. You just access it directly in your file system by a unique name.
That said, I am also very pessimistic on it. IPFS suffer from “underspecification”. The protocol is completely focused on just moving bytes around. It doesn’t care about copyright or authorship, which becomes a huge problem due to content no longer having a real home in IPFS, everybody can pin, cache or share content on IPFS. It’s very much like Bittorrent in this regard, but worse as even Open Source licenses don’t help here. IPFS, unlike Bittorrent, doesn’t even guarantee that content will stay together, e.g. you can pin and reshare your favorite icon, without a hint of what license it is under or what icon theme you picked it from. For the time being everybody seems to just ignore the problem, but I think it will kill it if it gets popular before this problem is solved.
Another problem is that it’s just buggy and slow, especially when it comes to the fuse daemon that provides the /ipfs and /ipns directories. Though that at least is fixable on the client side. The copyright problem might not without some fundamental changes to the protocol itself.
It doesn’t care about copyright or authorship, which becomes a huge problem due to content no longer having a real home in IPFS, everybody can pin, cache or share content on IPFS.
Sounds like a feature, not a shortcoming
It means that using it properly is automatically illegal. I am not seeing how that’s a “feature”. It renders it completely unusable.
No it doesn’t. Maybe in some places? But not in most. You can break copyright laws with pen and paper, which don’t have any protection against it and are perfectly legal
I think that would go against the philosophy of ipfs. Sticking drm on top of it would crash with the intended self-archiving capabilities and censorship resistance, as well as with the whole point of a decentralized network since some entity or entities would have the power to block or delete content from it
Looking forward to seeing Cosmic get a alpha/beta release, I love what they’ve shown and since I can never get used to tiling window managers, it looks like a very nice middle ground between DE/WM. And seeing their Virgo laptop, I doubt I’ll get one since EU shipping is a nightmare (Though they’re supposed to open an EU warehouse soon-ish), but more repairable laptops, esp. one using GPLv3 for every bit, is amazing. Looking forward to seeing more about the FW16, not linux per se, but still cool.
Plasma 6, ofc. Way, way in the future (Probably) is seeing more DEs make their way to Wayland, like XFCE/Cinnamon/Budgie
deleted by creator
Functional fractional scaling on GNOME.
I moved to a 4k monitor and could never get an experience I was happy with, had to move back to Windows. I could use it at 150% scaling and get blurry apps, or 200% scaling and get no screen space.
Now, most programs did work fine or I could tolerate them (I don’t care if Spotify is a bit blurry). But gaming was just bad, GNOME told the games a fake resolution and then rescaled them, so they looked awful. The best solution I found was using a Python script to disable scaling before launching a game, but it was clunky at best.
Now, the new fractional scaling extensions did add the ability to have the app handle scaling by itself, so I’m really just waiting for an option to disable scaling for X11 programs or for Gamescope to add a “tell the compositor I will handle scaling but then don’t do anything” option so I can actually get full resolution for my games.
I’m also waiting for variable refresh rate, but I can live without that as GNOME Wayland doesn’t really get tearing ever.
Flatpaks seaminglessly supporting all apps plus cli applications and drivers would be the holy grail.
Unfortunatly i don’t think thats gonna happen. Due to how flatpaks work things like drivers wouldn’t work without some serius workorounds.
KDE Plasma 6 for the resolution of so many issues; COSMIC DE as a brand new choice in the future; Guix System to have KDE and more packages shipped because it’s literally the best designed distro as of now.
- At the least Nvidia hardware gets full support for Linux. Which in turn would help me run Wayland on daily bases.
- Ease at implementing secure boot for Linux.
- Torification/I2P being used as standard to use and adapt applications running on linux for internet access.
I2P by default would be a hilarious F U to surveillance
its Nvidias fault not Linux. Bitch to them
