This is a home NAS with one user (myself) on this Linux client. Other clients will be Windows for other users.
My NAS user has full rw permissions across the NAS shares (but not admin privs). I’m not super comfortable with this config as it strike me as too permissive to mount on the home directory. Would love to hear better approaches.
Yes, there is a chance the NAS can be down when booting the Linux pc.
I set up the mount points in configuration as dynamic NFS volumes and added Bookmarks to nautilus. You can get to the volume either with cd command or right-click -> terminal here. You can shut down the NAS and only lose the share, which returns when the system goes online.
This is much better than WbDAV, which is fine for simple sharing or for devices that can’t handle NFS easily like Android phones.
Well, with multiple users you’d need to decide what the use case is for the whole NAS and then work down from there.
Are you sharing everything in the NAS with everyone? In that case your NAS setup is fine, just a little permissive, because with RW to everything, the end users can break everything.
If it were me setting this up, I’d have different mount points for different users. 1 mount for each user that only they can read/write (not even you should be able to see it), and 1 mount that everyone can read/write, maybe if you want to go a little bonkers, 1 mount that everyone can read, but only you can write to.
Then you’d mount those three to separate mounts in your /media, and you can link them from your home directory for specific use cases.
Obviously this is completely overkill, but you can take the parts that sound appealing to you and ignore the rest.
This actually makes it sound like Xorg will be supported longer than I thought.
I understood RHEL9 to already be Wayland based and so I was expecting the clock to runout on Xorg when RHEL8 went off support. RHEL9 does default to Wayland but it sounds like Xorg remained a fully supported option for those that wanted it. The move to Wayland only being proposed for RHEL10 did not happen on RHEL9.
RHEL8 goes off support in 2029 but RHEL9 is supported until 2032. The implications of this article are that Red Hat will not put much energy into Xorg after 2025 ( RHEL10 ) but they will still have to support their customers. This at least means security fixes but it likely means continued viability of modern hardware to a certain extent as well.
Regardless, this also highlights one of the “hidden”‘contributions of Red Hat and how much the entire ecosystem relies on them. This can be seen as good or bad but I wish the public debate involving them would at least accurately reflect it.
And even beyond that, because any distro that ships Wayland by default does so because it has XWayland as a backup, which is essentially running an X server inside Wayland.
Xwayland is likely to be with us a very long time. I do not see Motif adding Wayland support anytime soon for example. How long for GNUstep to hop on board?
Agreed ( on the code ). Wayland and Xorg also share libinput, libdrm, KMS, and Mesa.
The biggest difference is that Red Hat will stop bundling this stuff up together, testing it, and created releases. Most of the actual code will still be maintained though.
So X.Org fully dies on the 31st May 2035 with the end of Extended Life Cycle Support for RHEL 9. We have XOrg’s death day. Even if it will likely be on it’s death bed taking its final breaths for years before that.
I thought this as well but the more I think about it, the less true this seems. From an engineering point of view, it could last longer.
Xwayland is really just Xorg and Xwayland continues to be supported in RHEL10 and beyond.
Xorg and Wayland compositors have grown together in some ways. Both now use libinput, libdrm, and KMS for example. Those are not going away.
Xwayland is really just Xorg adapted to talk to Wayland instead of KMS and libinput. It is mostly the same code. So, Xorg will continue to benefit from the care and attention that Xwayland gets. Perhaps there may not be many new features but the code is not going to bit rot and security will continue to be addressed. While Xwayland does not use libinput or KMS, the Wayland compositor itself will, so those pieces are also going to be maintained including new features and new hardware support. Mesa is a common component as well.
So, while Red Hat may stop coordinating releases of Xorg at some point, a surprising amount of the code will still be actively maintained and current. It may not take a lot of work for somebody else to take over and bundle it up as a release.
What will probably kill Xorg is lack of demand.
Despite the anti-Wayland chatter, the migration to Wayland looks like it will gain substantial momentum this year and next and not only on Linux. Three to five years from now, the number of people that still care about Xorg ( as the primary display server - not as Xwayland ) may be very small indeed. Obviously it will be running on older systems for a long, long time but, ten years from now, installing Xorg on a new system is likely to be very rare ( like CP/M now rare ).
Red Hat may end up being one of the very last players that cares about Xorg after 2030. My guess is that most of the current never-Wayland crowd will have moved to it long before then.
Yeah, thank you for doing such a good explanation of it. I completely agree. Truth be told, the features I missed with Qtile on Wayland (some bugs that took a while to iron out, and are only fixed in qtile-git, as well as rounded corners, which are a work-in-progress, leaving me with only 1 issue with Qtile, that being how difficult Qtile Wayland is to install and set up, if only there was a working guide for doing so via pip, but pywayland and/or pywlroots via pip are usually broken), were all fixed by Hyprland, so I’m on Hyprland full time now, and I love it! There is only one minor issue I have (drop downs from Waybar’s systray are kinda broken on Hyprland, rendering weirdly, with strange black gaps between sections and rendering under, rather than over, windows).
Take a look at Minifree Ltd. For less than USD $500, you can get a decent ThinkPad with Libreboot and your choice of Linux distro (KDE Debian is installed by default).
Alright, so what else is needed until Wine on Wayland becomes as good as Wine on Xorg? Is there a checklist, or something? What’s left until Wayland gaming is as good as, if not better than Xorg gaming?
With this last merge you can start playing already. Except for shooters, there are a few more merges left to fix the edge cases. Around 4 or 5 merge requests
Wait, so It’s actually happening? Wayland gaming will be a thing soon? Plasma 6, releasing in the first half of 2024, has ironed out all but 1 of its “Wayland showstoppers”, actively working on the last one, as well as many bugfixes. XFCE 4.20, with Wayland support, is releasing in late 2024. Cinnamon, MATE, Pantheon, and Enlightenment, have all started working on Wayland support and will likely show early stages of it in 2024. AND WINE will hopefully be fully Wayland-ready in 2024. 2024 will be the year of Wayland!!!
Looks like a pretty straightforward install! And a fun project to have a personal message space with friends. It includes the ability to launch gameoso you could maybe set it up as a personal lobby for gaming buddies.
Wayland is just a protocol. The WMs, compositors and applications need to implement the features the X server used to provide.
Those that don’t will become useless when X is gone.
Right so I guess I should have over specified that I hope ALL the other bits that actually make it function the same will also catch up and for example something as basic as forwarding GUI programs will simply work without jumping through a bunch of tedious flaming hoops with pitfalls on either side. It doesn’t really matter to me that Wayland has decided it’s somebody else problem.
For many uses, Wayland has feature parity now or is even the superior option. That is how it can be the default on so many systems ( including RHEL9 as per the article ).
Compositors that do not provide the features that uses want will fail to compete ( what you mean by become useless I assume ).
That said, different users will want different things and, unlike X, Wayland allows competing compositors to address different communities. Some compositors will lack features some users want while offering features that other users need. A composite targeting embedded use cases may not need multi-monitor or fractional scaling features for example. A security focussed option may think that global hot-keys and external lock-screens are anti-features. I think the Wayland world could be quite interesting.
Well, for one, it’s network attached storage. If it’s not present in the network for one reason or another, guess what, your OS doesn’t boot… or it errors during boot, depending on how the kernel was compiled and what switches your bootloader sends to the kernel during boot. Second, this is an easy way for malware to spread, especially if it’s set to run after user logon.
I agree, for most cases just mount it via your File Manager of choice. If you’re using it as a backing storage for another server, then that’s a use case where fstab is fine.
It has to have a mount point somewhere. Just double click the desktop entry, that will mount it wherever you told it to and then you can copy to that location, easy peasy 😉.
In Nautilus, you can right click anywhere and click Open in Console, at which point it will open up a terminal leading to a gvfs mount directory.
In KDE, it is slightly more annoying because there’s no right click option to quickly open it in terminal, but like gvfs, there’s a mount directory that you can access at /run/user//kio-fuse-/smb/.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.