Ya, but you’re overlaying all that stuff, codecs, nvidia, etc. ublue works out of the box and updates are quicker due to not having to re-overlay everything. It’s just less friction. Also it comes with automatic updates enabled which is really nice (and safe in an immutable, intrinsically rollbackable environment)
Overlaying isn’t bad. It’s kind of what we’ve done the past years anyway.
Does the speed of updates matter in any way? Unless it’s not days, there’s no reason for me to complain update the duration since everything is done in the background.
What’s the difference to the auto update in silverblue?
Ootb fedora doesn’t even have gnome extensions installed. We have to adjust our systems anyway
Personally, I’ve been enjoying uBlue over vanilla Fedora Atomic for what they offer in terms of system management.
To give you a better idea on what I mean; just a month ago an update to Podman caused breakage and people weren’t able to use their containers created with Distrobox/Toolbx^[1]^. Sure; a rollback is accomplished relatively easy and I’m sure some would even be able to fix it themselves. Regardless, every Fedora Atomic user that relied on Podman would have been interrupted to some capacity.
Which, of course, begs the following questions… Isn’t it very inefficient for everyone to fix this issue themselves? Wouldn’t it be easier if somehow Fedora forced some fix upon all of us so that just one entity is burdened instead of all of us? Heck, wouldn’t it be better if Fedora just withhold the update until it’s fixed? Is this perhaps some pipe dream that will never see the light of day? etc…
The interesting part, though, would be how I (a ‘uBlue-user’) didn’t even notice Podman was causing issues in the first place. “How?” you might ask, well… The uBlue devs noticed the issue, applied some magic so that I and many other uBlue users like me just went on with their day like they would otherwise; without being interrupted because Podman just had a bad update. (Did the supposed pipe dream actually already exist in some form or fashion?)
This is just the most recent example of this. But in the last year or so, out of the top of my head, there have been a few more times in which uBlue users didn’t even notice a thing while the others either had to rollback or fix their issues themselves. If you enjoy this interruption and/or are willing to deal with it for the sake of whatever, then please feel to continue to do so. However, I prefer to have a system I can rely on at all times and uBlue offers me just that while remaining very close to vanilla Fedora Atomic.
You won’t have fedoras signatures anymore.
It depends if you have the luxury to rely on them in the first place.
If setting up your workflow (or whatever) requires you to get to the nitty gritty of things and change those parts of the system that strictly speaking isn’t well supported by just rpm-ostree, then -for almost a year now- your best bet would have been to (instead) experiment with (what’s been referred in Fedora’s Wiki as) Ostree Native Containers.
Finally, let’s not forget that uBlue is even endorsed by Fedora (or at least by whoever maintains its documentation). Heck, even the inception of uBlue was due to an interaction between Jorge Castro (one of uBlue’s maintainers) and Colin Walters (one of the masterminds behind the whole rpm-ostree-ecosystem).
P.S. If I hadn’t made it clear, it’s totally fine to continue to rely on Fedora Atomic directly without any interventions from third parties for system management or whatsoever. I just wanted to elaborate why I, personally, prefer to use images provided by uBlue.
So you convinced me, and not being a novice, I didn’t read the install instructions and just went for it. It wrecked my dual boot efi partition. No worries, been there done that before, spent all morning trying to get the eufi shell and grub sorted out. After a few hours of failing, I’m like hey I planned for this, I’ve got a USB recovery for windows, and my actual data is all backed up via syncthing (thanks to this community). Why am I bothering with this nonsense.
Omg… Recovering windows takes foreeeeever. So then I’m reading the kenoite instructions and it calls out that dual booting doesn’t work, here is a suggested partition scheme… Ffs… Anyway for anyone that doesn’t want to waste an entire day on this, rtfm.
FWIW, I’ve put some effort into explaining how a dual boot of Windows 10 and Fedora Atomic (read Silverblue/Kinoite/Sericea etc) can be achieved. While it’s far from exhaustive, it should be fine as long as your specific installation of Fedora Atomic doesn’t require special attention (which happens sometimes with owners of an Nvidia GPU*). After Fedora Atomic is successfully installed, proceed with following the instructions found on the following parts of uBlue’s documentation: here, here and finally pick whichever uBlue image you’d like to install from this list; specific instructions are found directly underneath the text boxes for each individual image, but ensure you’re installing the one with the correct Fedora version (37/38/39/stable/latest etc (which are accessed via tabs)). If you can’t decide on which version you’d like to install, then just go for 39.
KDE has been a treat for me after having used Gnome so long, I like both and in fact I still keep Gnome on the laptop, especially for the smooth gestures.
On the desktop I’m keeping KDE as it feels more suited by default, for that I suggest Fedora Kinoite because I honestly can’t ever imagine running a mutable system anymore, unless it is strictly for tinkering and, since it seems you’re looking for something that has to just work, that will be a great fit!
::: ..Now to talk about what hasn't just worked for meI used to experience freezes and crashes, but don’t see them happening anymore (maybe it was my hardware being too new?); containers (mostly distrobox), I don’t know what the heck is happening behind the scenes, but I think I’ve seen my containers breaking for the third or fourth time across updates this year, luckily it’s not a tragedy as you can usually roll back the system temporarily (OSTree rocks!) and/or remake them from snapshots or apply fixes that are mentioned in the issue trackers and whatnot when they pop up, the podman devs and others folks are fast and responsive.
All in all, these being the biggest issues for me, this distro is one of the most rock solid there are!
Seems like Fedora Kinoite is getting several votes. Maybe I’ll give that a go for myself. I also like the idea of Fedora more since they are starting to offer their own Laptops with pretty nice hardware it seems.
The idea of buying new laptops that all just have proper OS support seems, novel.
Yeah, now try adding components to it in order to make it a bit more modern, decent RAM, nvme, I’m at 1900. Pass. But hey, I support them and if I had that kind of money, I’d buy it.
You took the words out of my mouth, that’s what I felt with most, if not all, “Linux laptops” I’ve seen up to now: concept is great, hardware is great, price is, well, greater.
I do hope that everyone that can afford System76, Slimbook, Starlabs, etc. (hey, I’m noticing an unusual pattern here 🤔) will buy from them because I’d love to see both more adoption and makers that can improve Linux as a whole thriving
Be careful with these containerized distros. I would read bit more before jumping into something not standard as of now. In particular, making changes to the root image by installing packages works a lot differently than good old Linux distros.
Otherwise Fedora’s KDE spin is quite good, too. They include a lot of extraneous packages, though.
I think we may be looking at these wrong. Yes there’s a visible throughput/latency improvement here but what about other factors? Power savings? Cache efficiency? CPU cycles saved for other co-running processes?
These are going to be pretty hard to measure without an x86_64 simulator. So I don’t fault them for not including such benches. But there might be more to the story here.
I’ve owned a Thinkpad A485 with touchscreen for years and had several Linux distros on it including Manjaro and Linux Mint which I am currently using.
Never had any issues, touchscreen always works out of the box without me having to do anything extra. In fact, with a few distros, I’ve had issues with certain wireless mice, but my touchscreen always has worked. So I’ve actually had slightly better luck with the laptop touchscreen than some external mice lol.
Now a qualifier: I rarely use the touchscreen, and when I do, it’s always just to click something or scroll on an article or file list. I don’t do any special gestures or fancy touch functions, so I can’t speak to support from that perspective.
woops my bad, I mean to link this github.com/…/wayland-x11-compat-protocols it’s a repo of going to be protocols, to fill in the gap instead of pretending the issue doesn’t exist
I did and quite frankly it’s trash, XDG portals are a clunky and quite frankly terrible and poorly thought out api. I’m not the only one that disagrees with this sentiment as multiple people are trying to get protocols like ext-screencopy-v1 for screen recording and ext-foreign-toplevel-* for window management upstreamed into wayland so that xdg portals aren’t necessary for these use cases. I don’t mind the reliance on pipewire too much, but I too think that It shouldn’t be necessary for screen capture.
IMO It is one of nate’s worst takes of all time if not the worst. Usually I agree with most things he writes, but not this, xdg-portals is a travesty, pipewire is nice and all, but I don’t see why we should need an entire media system for basic screen capture capabilities. and clearly im not alone on this sentiment
And that’ll shake out in the time it takes for X11 to go away. I get what you’re saying, although I don’t share your opinion about portals from a user perspective: I’m just happy that Firefox finally uses the Plasma file picker.
I have a couple of issues with portals. One is that we’re putting too much eggs in the basket of something that is designed for containers. XDG portals Have rejected features that people have requested because they don’t want to expose that functionality to a container and they are allergic to permission prompts apparently.
I also have other issues with the portals for instance video capture. It requires you to have a camera portal. It requires you to have a desktop capture portal. It also requires you to have an app to app, video, portal, which doesn’t exist yet. All of these things require pipewire pretty much in most cases, so why can’t we just have a single pipewire portal? It may not scale well in the future, but it doesn’t scale well now anyways. If you want just a generic pipe wire stream, you’re not gonna be able to have it, you’re going to have to conform to one of the standards anyways. For a case in point example, the OBS pull request for Game Scope Capture is the perfect example of this over reliance in XDG portals.
I’m showcasing this just to highlight the fact that the XDG portals are incredibly poorly thought out, and I don’t think that it’s a reliable method for the future going forwards.
PS. Please pardon any oddities in this, I had to use speech to text, since my RSI is acting up.
I think having separate standard APIs for screenshots, screen capture, and video capture that aren’t married to one implementation makes sense.
I partially agree about the focus on containers/sandboxes. Yes, it makes sense to criticize that something designed for a different use case results in different trade-offs. But on the other hand, are the use cases really that different? We’re talking about standalone desktop apps, they need some common building blocks no matter if they’re containerized or not, right?
Otherwise I don’t know enough about the standards to comment there, you’re probably right!
I think having separate standard APIs for screenshots, screen capture, and video capture that aren’t married to one implementation makes sense.
The idea of a using a separate thing for it is fine, in itself, but necessitating it is an issue to me. There are a LOT of wayland compositors now, for all sorts of systems, each one also new needs a compatible xdg portals implementation (or whatever third party tool you like), in the case of xdg portals this also means pulling in things like dbus. It actually becomes a lot to build a “Minimal but fledged out” ecosystem. something which should otherwise be possible.
we’re talking about standalone desktop apps, they need some common building blocks no matter if they’re containerized or not, right?
sure but then you have xdg-portals denying actually useful a11y protocols because they “don’t want to expose it to containers” -_- apparently they never heard of a permissions system? but this also highlights why the wayland ecosystem right now is so poor for select individuals (and why they get heated when told that they need to swap to wayland)
I actually just went through this exact situation in the last month and I switched to LMDE6 on my 2-in-1 lenovo touch screen. Auto rotation didn’t work right out the gate, but iio-sensor-proxy fixed that. In general, I’ve noticed that the touchscreen default setting for some apps (eg, firefox) treats touches as a mouse click, so rather than scrolling it would select text. But I’ve found this AskUbuntu fix worked for me. Been a good experience since then.
Wayland has fixed so many head-scratching issues I would get running 6 monitors on 2 GPUs under X11. I’d often end up with missing monitors, placed in wrong spots that I’d have to rearrange every reboot until an update would come through that would fix it again for a few months, then all over again.
Since I moved to wayland, everything just works. When it doesn’t, it’s not a display server issue, it’s something physical. I just had a couple monitors fail to show up and thought “oh hell, it’s back to this, eh”. But I open the tower, seat the offending GPU better, and everything comes up like normal, and all the screens are in the right position, it just remembers.
Anyone that thinks X11 is still superior probably runs on a laptop with a single screen.
I mean I’m fully with you on the fact screen autodetect isn’t stellar on X but there’s no need to exaggerate with “2 or 3 scripts”. It’s one xrandr command.
Ive seen several devs do that, and also some of my gaming friends have 3 monitors.
I barely know anyone who only has a single display. Most people I know have one high refresh rate monitor, and one office monitor for discord and the likes.
I have 2 75hz and a 240hz. It’s been alright for me on kde and x11. Although, I do want to give this Wayland thing a shot after hearing it being brought up so many times
Over on Nate's other blog entry he indicates this:
The fundamental X11 development model was to have a heavyweight window server–called Xorg–which would handle everything, and everyone would use it. Well, in theory there could be others, and at various points in time there were, but in practice writing a new one that isn’t a fork of an old one is nearly impossible
And I think this is something people tend to forget. X11 as a protocol is complex and writing an implementation of it is difficult to say the least. Because of this, we've all kind of relied on Xorg's implementation of it and things like KDE and GNOME piggyback on top of that. However, nothing (outside of the pure complexity) prevented KWin (just as an example) implementing it's own X server. KWin having it's own X server would give it specific things that would better handle the things KWin specifically needed.
Good parallel is how crazy insane the HTML5 spec has become and how now pretty much only Google can write a browser for that spec (with thankfully Firefox also keeping up) and everyone is just cloning that browser and putting their specific spin to it. But if a deep enough core change happens, that's likely to find its way into all of the spins. And that was some of the issue with X. Good example here, because of the specific way X works an "OK" button (as an example) is actually implemented by your toolkit as a child window. Menus those are windows too. In fact pretty much no toolkit uses primitives anymore. It's all windows with lots and lots of text attributes. And your toolkit Qt, Gtk, WINGs, EFL, etc handle all those attributes so that events like "clicking a mouse button" work like had you clicked a button and not a window that's drawn to look like a button.
That's all because these toolkits want to do things that X won't explicitly allow them to do. Now the various DEs can just write an X server that has their concept of what a button should do, how it should look, etc... And that would work except that, say you fire up GIMP that uses Gtk and Gtk has it's idea of how that widget should look and work and boom things break with the KDE X server. That's because of the way X11 is defined. There's this middle man that always sits there dictating how things work. Clients draw to you, not to the screen in X. And that's fundamentally how X and Wayland are different.
I think people think of Wayland in the same way of X11. That there's this Xorg that exists and we'll all be using it and configuring it. And that's not wholly true. In X we have the X server and in that department we had Xorg/XFree86 (and some other minor bit players). The analog for that in Wayland (roughly, because Wayland ≠ X) is the Compositor. Of which we have Mutter, Clayland, KWin, Weston, Enlightenment, and so on. Which that's more than just one that we're used to. That's because the Wayland protocol is simple enough for these multiple implementations.
The skinny is that a Compositor needs to at the very least provide these:
wl_display - This is the protocol itself.
wl_registry - A place to register objects that come into the compositor.
wl_surface - A place for things to draw.
wl_buffer - When those things draw there should be one of these for them to pack the data into.
wl_output - Where rubber hits the road pretty much, wl_surface should display wl_buffer onto this thing.
wl_keyboard/wl_touch/etc - The things that will interact with the other things.
wl_seat - The bringing together of the above into something a human being is interacting with.
And that's about it. The specifics of how to interface with hardware and what not is mostly left to the kernel. In fact, pretty much compositors are just doing everything in EGL, that is KWin's wl_buffer (just random example here) is a eglCreatePbufferSurface with other stuff specific to what KWin needs and that's it. I would assume Mutter is pretty much the same case here. This gets a ton of the formality stuff that X11 required out of the way and allows Compositors more direct access to the underlying hardware. Which was pretty much the case for all of the Window Managers since 2010ish. All of them basically Window Manage in OpenGL because OpenGL allowed them to skip a lot of X, but of course there is GLX (that one bit where X and OpenGL cross) but that's so much better than dealing with Xlib and everything it requires that would routinely require "creative" workarounds.
This is what's great about Wayland, it allows KWin to focus on what KWin needs, mutter to focus on what mutter needs, but provides enough generic interface that Qt applications will show up on mutter just fine. Wayland goes out of its way to get out of the way. BUT that means things we've enjoyed previously aren't there, like clipboards, screen recording, etc. Because X dictated those things and for Wayland, that's outside of scope.
That’s my problem with this. It tries to be a desktop display server protocol without unifying all desktop requirements. Sure, X11 is old and have unnecessary things that aren’t relevant anymore, however, as someone who builds their own DE, (e.g.: tiling window managers) I see it as the end of this masterrace. Unless everybody moves to wlroots. Flameshot, for example, is already dealing with this, having at least 5 implementations only for linux, and only wlroots and x11 are standards.
Also, imo, having windows in windows is useful when you want to use your favourite terminal in your favourite IDE. But as you said DEs can implement it simply. Let’s say wlroots will implement this but others can decide otherwise. And for those the app won’t run.
Another example, that affects my app personally, is the ability to query which monitor is the pointer at. Wayland doesn’t care having these so I doesn’t care supporting wayland. And I"m being sad about this because X is slowly fading away so new apps will not run on my desktop.
Moreover with X11 I could write my own hotkey daemon in my lanuage of choice, now I would have to fork the compositor.
Also, imo, having windows in windows is useful when you want to use your favourite terminal in your favourite IDE.
The wayland way to do that is to have the application be a compositor, they made sure that nesting introduces only minimal overhead. And that ties in with the base protocol being so simple: If you only need to deal with talking to the compositor you’re running on, and to the client that you want to embed, a wayland compositor is indeed very small and lean. Much of the codebase in the big compositors deals with kms, multiple monitor support, complex windowing logic that you don’t need, etc.
Oh and just for the record that doesn’t mean that you can’t undock the terminal: Just ask the compositor you’re running on for a second window and compose it there. You can in principle even reparent (client disconnecting from one compositor and connecting to the other) but I think that’s only standardised for the crash case there’s no standard protocol to ask a client to connect to another compositor. Just need to standardise the negotiation protocol, not the mechanism.
Errrm, could they please leave some memory to other processes? KDE already takes about 1.5GB of VRAM on my RX7600 8GB just running a desktop (dual head 4k + 1440p displays). Yes, things can get swapped out to main memory, but that becomes choppy. I’d rather run single buffered, get the odd screen tear, and have the VRAM back for real work.
It says in the article that triple buffering only activates if your GPU struggles to render the desktop. That means old and weak iGPUs are getting this. For your desktop card nothing should change.
I’ve been using fedora on a surface go 3 and it’s been a good experience - auto rotate works and osk mostly works. In general Gnome seems to be the best DE for touchscreens, especially if you use it in tablet mode a lot. You’re gonna at least want something up to date and probably using Wayland, so I wouldn’t go with mint.
One option is to use something like Fedora or Arch for both PCs, but use a different desktop environment (gnome on the 2-in-1, kde on the desktop).
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.