I used to be super excited about Wayland but it’s been 15 years, now I’m too old to care.
My favorite distro still runs on xorg and it runs so well that I don’t remember why we needed Wayland in the first place. (I am not saying that there is none)
Tearing videos and games have been fixed on xorg when Wayland was supposed to be the only solution.
I am sure Wayland will eventually make X completely obsolete and will be a much needed modernisation of the Linux desktop stack.
But I can’t help but notice that it is not there yet, is old enough to carry it’s own significant technical debt and might never bring the simplification and streamlining that it once promised.
It is a tiling Wayland compositor that is only a couple of megs in size. On Oasis Linux, I launched into Velox, opened a terminal, and checked the memory usage. It was under 30 MB of RAM. That is for the whole system!
That experience made me think differently about Wayland.
There was only one Xorg. For me, the evidence that it was big and complicated is best expressed by the fact that, over decades, the number of projects that competed to provide X had dwindled to one. There was loads of unhappiness with it and yet, there were no forks. Why?
Now Wayland. There are new Wayland compositors all the time now. I just saw one yesterday—Louvre. The basis for Velox above is SWC. There is Wayfire. There is Weston. There is of course wlroots. And both KDE and GNOME have made their own. I think somebody even wrote one for Haiku! For me, this is evidence in itself that making a Wayland compositor is easier than implementing X.
It also means that all these Wayland compositors can compete with each other and drive each other. It means that I, as the end user, can pick a super stripped down version when that is what I want and an all-singing, all-dancing version when that is what I want instead. In some situations I will be happy with, and thankful for, Velox and in other situations I will want GNOME.
It is taking a long time and the journey has not been smooth. That said, I am becoming quite confident that we are in a much better place. For normal uses, Wayland is in a good place now. The level of innovation is very high. Dev can start to shift from the basics to the extras. I fully expect that we are heading into an exciting time on the Linux desktop.
X has a singular fully functional implementation into which you can slot a wide variety of components. Because everything is a component that slots into the singular X implementation forking has both a low benefit and a high cost.
Wayland is just a protocol everyone must implement with a semi useless reference implementation that nobody would ever use. Nobody forks Wayland they just implement it as they must the X approach isn’t available.
It’s apples to oranges. A meaningless comparison. Its more just churn than innovation on the part of desktops.
That said, everything you said about the Xorg server could be said about wlroots. Nobody has to “implement Wayland because they must” anymore. The X approach is available in Wayland as you can build your window manager on top of wlroots and many do.
Seems fairly apples to apples to me.
Or you can choose a competing compositor library as there are now quite a few available. I think XFCE is looking at using Wayfire. Or you can control more of the stack directly and write your own as GNOME and KDE are doing.
Not only do you not have to implement Wayland to make a window manager, because compositor libraries are available, but people are writing Wayland compositors even though they do not have to. Louvre is a compositor recently released that seems expressly designed to make writing new window managers super easy.
As for innovation, there seems to be lots in Wayland. Valve just added HDR. GTK is looking at using dmabuf. There are already Wayland window managers that are not ports from X. There seems to be innovation at every level.
Building on top of wlroots is still a different scope of problem than writing a window manager for X. Pretending its the same thing doesn’t change the fundamentally different architecture even if it certainly makes it easier.
Out of all the libraries isn’t recent KDE the only fucking one that supports proper scaling of xwayland windows without turning it into a blurry mess? KDE which nice as it is lacks most of the nice tiling features of i3wm or the per monitor workspaces? Let me rip out and throw away a highly functional Nvidia GPU and come on down!
Don’t worry in another fucking 10 years all problems will be solved in the meanwhile I’ll just be fucking using non-beta software. Pardon me if I’m a little annoyed. Wayland has been the future for a while now.
Yeah, I don’t see a reason to use Wayland unless it’s a drop-in replacement for X.
I don’t have any issues with X. I’m glad it works and I don’t even know it’s there.
It doesn’t make sense for me to adopt something newer that works worse when I have something that works without issue right now.
I bet when Wayland reaches the maturity, adoption, and stability of X, people are going to be moving to the next broken thing that will be functional in 15+ years.
Well technically, if you’re using BTRFS, you might want to check out subvolumes. Here’s my subvolume setup:
Subvolume 1, named @ (root subvol)
Subvolume 2, named @home (/home subvol)
Subvolume 3, named @srv (/srv subvol)
Subvolume 4, named @opt (/opt subvol)
Subvolume 5, named @swap (which is - you guessed it - the swap subvol)
You then set up fstab to reflect each of the subvolumes, using the subvol= option. Here’s the kicker: they are all in one partition. Yes, even the swap. Though caveat, swap still has to be a swapfile, but in its own separate subvolume. Don’t ask me why, it’s just the way to do it.
The great thing about subvolumes is that it doesn’t do any size provisioning, unless specified by the user. All subvolumes share the space available within the partition. This means you won’t have to do any soul searching when setting up the partitions regarding use of space.
This also means that if I want to nuke and pave, I only need run a BTRFS command on my @ subvolume (which contains /usr, /share, /bin), because it won’t be touching the contents of @home, @srv, or @opt. What’s extra cool here is that I’ll lose 0% FS metadata or permission setup, since you’re technically just disassociating some blocks from a subvolume. You’re not really “formatting”… which is neat as hell.
The only extra partitions I have is the EFI partition and an EXT4 partition for the /boot folder since I use LUKS2.
Have you had any luck with hibernation with a BTRFS swapfile? My computer still does not start from hibernation, and I am not sure why, even though I followed the Arch wiki to set it up.
Can’t say I have. Haven’t used hibernation mode for years even. Sleep mode is just too good nowadays for me to use it, so I guess we could chalk that up to a fault of the setup.
According to ReadTheDocs (BTRFS, swapfile) it’s possible under certain circumstances, but requires the 6.1 kernel to do it in a relatively easy way.
In tools like lsblk? Nope. They appear as directories, usually in the top-level subvolume, which typically isn’t mounted anywhere in the system.
Then you just create mount entries in /etc/fstab just like you would with partitions, this time just using the subvol= option as mentioned above. I don’t know if there are any installers that do this for you. Archwiki – as usual – has good documentation on this.
So, it doesn’t sound like it would be useful for me, since the reason why I have separate partitions in the first place is so that I can re-install a distro or install a new distro without having to back up /home first.
These tentacular megacorporations are a problem. Amazon is OK as a merchant, MS as an OS developer, Google as a search engine… If they do vertical integration the market is corrupted.
Vertical integration is when you control the entire product, in consumer electronics Apple is the gold standard; they make the software, hardware, and processors then integrate them into iPhones and macBooks. Tesla is a good example in the automotive space, their goal with the mega-factories is "raw materials in, cars out" and they work to build as many of the parts themselves as possible.
Alternately Microsoft just makes a good enough OS that runs on good enough hardware from commodity vendors, so you get good enough computers. Most auto makers buy good enough components from 2nd and 3rd tier suppliers and integrate them into good enough cars.
That is a great explanation of what vertical integration is. I am not sure I see why it is inherently bad.
I guess a large vertically integrated option could make it hard for alternatives to compete. That is more of a monopoly problem than a vertical integration issue though.
I do agree with interoperability requirements though. I see nothing wrong with Apple offering a fully vertically integrated product. The issue is when I cannot run my own OS on the hardware, my own apps on their OS, or interact with hardware from other vendors.
But that’s exactly the problem. If the company is kind about it, or forced to play nice by effective regulation, there’s no issue. But if there’s no regulation and the company wants to, it tends towards monopolistic tendencies. And there’s nothing that incentivizes a company to play nice forever, in fact they’re incentivized to maximize profit. So Vertical Integration is bad without being checked.
Finally, my life is complete. We have achieved feature parity with Windows.
Seriously, the BSOD QR-code is a great way to have a more inclusive system. Hardened geeks can still sift through the boot log to find problems and newbies can just get help online. Win-win.
Really awesome. They’re all contained within my home directory too, so when I swap distros I can just copy my home dir and all my installed apps are carried over that way. Super useful feature that never gets mentioned! The downside to flatpaks is having to use them for cli in any way is a huge pain.
I do, that doesn’t keep packages installed between distro reinstalls or swapping between entirely different distros. I’m talking about the actual packages and app data themselves that are contained in home.
There’s literally no need. It’s auto installed because everything is portable and most applications that launch .desktop files know to look for it’s directory.
that doesn’t keep packages installed between distro reinstalls or swapping between entirely different distros. I’m talking about the actual packages and app data themselves that are contained in home.
It’s auto installed because everything is portable
Then you didn’t explain it very well. Your former comment clearly states that copying the files keeps the packages (so you don’t have to redownload?) and the data, but “doesn’t keep packages installed” (hinting that .desktop files don’t get found)
You already use an arch container that has access to the AUR, which has literally every package, available on linux.
Also, if anything, flatpaks are THE official (universal) packaging format for Linux, it’s the most widely adopted and most well integrated of the universal packaging formats. I’m not saying that homebrew is bad, just why bother with it when you’ve got 100 other packaging formats that are all better…
if anything, flatpaks are THE official (universal) packaging format for Linux
I don’t deny that, I make good use of a ton of flatpaks on my system. I also believe that it’s the best we have. And I would literally switch to Brave as a flatpak if it would satisfy the following:
Be official and thus maintained by Brave itself.
Not having to forego its own more powerful sandbox due to (hopefully) current restrictions of Flatpak. Yes, you read that correctly; while flatpaks are arguably the safest way to consume most applications, this doesn’t apply to apps that actually have stronger sandboxes which had to be ‘slimmed down’ when packaged as a flatpak. Thus, currently, for maximum protection, one simply can’t rely on flatpaks for their Chromium-based browsers. If you choose to do so and it has worked out for you wonderfully; that’s awesome, I’ve been there and enjoyed the experience as well. But, I can’t justify it for myself any longer.
Never implied that anyways. Official merely ensures that the amount of trusted parties can be minimized.
Bubblewrap is not insecure.
Bubblewrap, when properly applied is indeed excellent; perhaps the best utility to sandbox applications on Linux. I’m thankful that flatpaks makes use of bubblewrap, namespaces and seccomp to offer relatively safe/secure apps/binaries, I’m unaware of any other ‘(universal) package manager’ within the Linux-space that offers similar feats in that regard. Unfortunately, Chromium-based browsers just happen to have an even stronger sandbox -if properly configured- than flatpaks are currently capable of.
Okay true. I am not so much into this Browser sandbox thing and dont really get it. Its a different way than bubblewrap, as from Firefox RPM for example I can open any file and save anywhere. But its process isolation right?
as from Firefox RPM for example I can open any file and save anywhere. But its process isolation right?
For Firefox, the verdict on its native sandbox vs Flatpak’s native sandbox doesn’t seem conclusive. With -assumingly- knowledgeable peeps on both sides of the argument, which indeed does raise the question how knowledgeable they actually are. Nonetheless, for myself, I’ve accepted Flatpak’s sandbox to not be inferior to Firefox’ native one. Thus, I don’t see any problem with using its flatpak.
Apart from having all the nice KDE integration and things like Keepass integration, Fido2 keys, drag and drop and some more things…
Also afaik the Fedora Firefox has a good SELinux profile and it runs damn fast. I did a speed test and it was best, along with Mozillas all-together-binary.
I’m a sucker for GNOME :P , but I’ll keep it in mind.
things like Keepass integration
The flatpak does allow integration, but isn’t built-in unfortunately; so one has to fiddle a bit themselves to set it up.
Fido2 keys
I should rely more on those. Do you have any recommendations? I’ve been hearing good things about Nitropad and Yubico, but I honestly don’t know if they’re actually good and how they would fare amongst eachother.
drag and drop
Overrated anyways /s :P .
Also afaik the Fedora Firefox has a good SELinux profile
It’s probably better configured with the native package than the flatpak one indeed. I wonder if this will change as Fedora is interested to ship Firefox as a flatpak by default on Silverblue (and variants).
it runs damn fast. I did a speed test and it was best
I haven’t had the best internet speeds since I’ve been relying on free VPN. But that’s on me :P .
Fedora packages a Flatpak Firefox themselves, based off the RPM. So its good too, but lacks codecs with currently no way to enable them so yeah. They would need am extension of some sort hosted on Flathub. So simply using Firefox Flatpak from Flathub makes more sense.
I got a Nitrokey for Heads but for some reason it never arrived? I can say these things are very expensive. And Heads uses PGP and not others.
I rely on flatpaks for all non-firefox browsers and haven’t had any issues with them, I’ve used the brave flatpaks specifically for almost a year now and no issues…
If you choose to do so and it has worked out for you wonderfully; that’s awesome, I’ve been there and enjoyed the experience as well. But, I can’t justify it for myself any longer.
If you meant something else, then please feel free to correct me.
I am thankful that zypak exists so that Chromium-based browsers and Electron apps don’t have to explicitly flag –no-sandbox to continue functioning. However, it doesn’t undermine the fact that native Chromium’s sandbox is more powerful than Flatpak’s sandbox. As such, if one desires security, then one should gravitate towards the native installed one.
Unfortunately, you didn’t -to my knowledge- support nor retract your claim on Chromium using flatpak sub-sandboxes. Therefore, I find it hard to continue taking your words at face value.
I have enjoyed these interactions, so don’t get me wrong; but if I (possibly) catch you on spreading misinformation (even if unintentional), then I find it hard to keep engagement up as there’s no guarantee that anything else coming from you is actually correct.
I would love to be corrected on this though, so please feel free if I have misunderstood you or anything else that would revive this conversation. If not, then I would still like to thank you from the bottom of my heart for this friendly interaction we’ve had. Take care!
I linked the source but sure, I’ll link it more for you.
I am aware, but the same source seemingly contradicted your point^[1]^ regarding sub-sandboxing.
Wow, thanks a lot for the work you’ve put into this! It might take some time for me to go through this, but I’ll definitely take a look and perhaps I’ll return on this at a later point. Perhaps with this I will finally be able to install my Chromium-based browsers as a flatpak and don’t feel bad about it.
Once again, your engagement has been much appreciated! So please feel free to let me know if I can buy you a coffee or something 😊! Unfortunately, statements like “Thank you so much!” don’t quite capture the sheer magnitude of gratitude I feel towards you right now. For whatever it’s worth; I salute you, good human.
“It lets Chromium use flatpak sub-sandboxes” that you expressed in this comment.
The comment on there is odd, I’m not even sure what that issue is referring to. Not much exciting happened in that release for new features but there were subsandbox security fixes github.com/flatpak/flatpak/…/1.10.8...1.12.0
KDE gang rise up! Can’t stand GNOME and its design philosophy, in recent times it seems like it’s been trying its hardest to become the most off-brand macOS it can possibly be. Everywhere I look its more form over function. Urgh.
I use an 6900 XT and run llama.cpp and ComfyUI inside of Docker containers. I don’t think the RX590 is officially supported by ROCm, there’s an environment variable you can set to enable support for unsupported GPUs but I’m not sure how well it works.
AMD provides the handy rocm/dev-ubuntu-22.04:5.7-complete image which is absolutely massive in size but comes with everything needed to run ROCm without dependency hell on the host. I just build a llama.cpp and ComfyUI container on top of that and run it.
I don’t know what It was expecting but it wasn’t quite that. I was initially going to make a crass joke but decided to read it before… now I don’t want to make the joke.
His writing comes off very strange. Somewhat egotistical and at the same time radically apologetic. I’ve never felt so uncomfortable reading a “technical” writing.
To me, it sounds like a man who does not understand social interactions trying to emulate how he should act, as he’s been taught in therapy for the past however many years in prison. He will never come off as normal because he is attempting to do something that his brain isn’t capable of. It seems very in line with my impression of his past interactions online.
+1 for Syncthing, I use it a lot. However anyone have any methods of 1-way sync? I’d like to backup camera photos from my phone with it but not have a 2-way sync so I can delete the pictures off my phone, and not have it deleted on my server. At one point I found a discussion with the developers about this exact use case and if I remember right, they were kind or in the camp of ‘that use case extends beyond what we envision for the app and would introduce more complexities, so we’re not a big fan of introducing that feature.’
True but you could set up a schedule /cronjob to move the files from the shared folder perhaps. Would be a bit extra traffic I guess if pics are not deleted on main device regularly.
are you sure you would this something like that on your devices? Because I’m not sure if you reasoned enough about that monstruosity you randomly propose here :D
actually I’m not sure of the qualities you go looking for online, certainly not the solidity of solutions that you seem to be looking for 🤷but ehi, I’m not here to judge! Cyao :*
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.