Wow,*and wow again. I will never ever create files with strange letters, and I will rather create a file containing the list of the files and use sed/xargs or a script to do the job. I use file manager only if I'm drunk and cannot type a command in less than 30 minutes.
Sometimes if I want to manage huge amount of pictures, but without knowing their filenames I try to copy them with a file manager. But it looks like I'm offtopic again.

Re: lilo as an example of lack of need for constant updates

Yes but the very reason I avoid GRUB2 as a bootloader is because it does way too much when all I want is a ...well.. simple bootloader! There's just little or no reason to attack lilo as it has so little power worth exploiting.

As for movies, I like "Sneakers" way better, too. I was using "Hackers" as a derogatory term to connote clueless but overly romantic "script kiddies".... although actually (to paraphrase Angelina) "RISC might actually be the future", or at least a larger part of it. However she apparently had Zero Clue analog might be as well. :0

I used to do silly stuff like that from the command line ALL the time. We stopped using Windows apps and that problem vanished.
But if I had it to do now, I would not need a GUI file manager.

So that I could know better what I was talking about, I decided to give Wayland a try using https://docs.slackware.com/howtos:wi...ts_in_xwayland and recording my experience over the course of about 4-5 hours getting it set up. The versions on Slackbuilds are old, so I used the recent ones.

• wlroots needs seatd
• wlroots needs libdisplay-info
• wlroots wants libliftoff
• wlroots wants (needs?) wlr-randr
• seatd needs scdoc, a(nother) way to format man pages

You need set SUID root to seatd-launch (chmod 4711 /usr/bin/seatd-launch). Compared with X11, there's surprisingly few messages and no logs. When all was said and done, the packages installed:
I've built Xorg before and remember the nightmare that is, so this wasn't near as bad. As I chased around the bits of code, I got the feeling that it was only a guy or two working on a pet project on websites I never heard of (sr.ht?) for some of the smaller components. labwc is very barebones, which I guess is the idea. There's no seperate desktops or task bar/launcher. You have to edit the XML files to make a menu. First I ran it bare. I was pleasantly surprised by the clean, crisp look of the graphics. I wanted a screen shot of it, but keep reading below...

After that, I tried with Xwayland. I needed to change a few things in autostart.

Next I tested some things I use every day. RPCS3 (Playstation emulator) surprisingly worked, including my PS4 controller. MAME worked. SIMH SDL display shows up, but the mouse doesn't work making it unusable. QEMU, with GUI, works but the mouse doesn't like to get close to the edge of the screen. Mostly it's usable. Various X utilities (like xnetload) don't work bare, but do under Xwayland. Screen cap doesn't work on the root window, either with Xv or ImageMagick.

Switching from GUI to tty made Librewolf disappear. Sometimes simply moving the window made it vanish. It was still running...somewhere. I had to kill it (I'm writing this from Firefox now). I caught an XDM display with Xnest, but the windows inside can't be moved around, making it unusable. Same with using Xephyr as a display for a headless system over the network. VNC and/or RDP are simply not proper solutions. Not all systems I work with came out in the last 5 years.

Wanting something more, I tried to install Hyprland from SBo but the build assumes you have it built (???) and doesn't actually build it. Finally I figured out you need the binaries off their website, but lo and behold:

Maybe Hyprland can be built without systemd. I do not know, but the real deal breaker was my Wacom tablet. It would not work at all, but it does under X11. I need this for Gimp, Inkscape, and Krita.
The devs dance around the topic: https://developer-support.wacom.com/...068247-Wayland . Evidently you must use Gnome or KDE for tablets: https://github.com/linuxwacom/input-wacom/issues/327 . Labwc is wlroots-based but doesn't work. I read various articles on it, but most talk about changing settings and not what to do when it doesn't work at all.

Xorg lost that new smell years ago to be sure, but it works and works well. It's not broken. It does everyting I need it to. Having everyone switch to KDE or Gnome isn't going to make people happy. This reminds me of how systemd sunk its claws into just about everything (see Hyprland above). You're soft-forced to adopt it. I'm guessing most desktop users just browse websites under Gnome or KDE - for that it works, but if you start testing out functionality Wayland leaves much to be desired at this time. This doesn't seem to stop some people from trying to reinvent the wheel.

(I included an Easter egg in the image for the VAX hater in this thread)

Attached Thumbnails

 

6 members found this post helpful.

What I do in this situation:

1. Click on "Mount & Open" on the popup in KDE
2. Immediately close file manager which opens up
3. Open Konsole
4. Run mc, and use it to copy the files

Am I doing it wrong?

Nothing :-)
Hazel question was "Who needs a file manager?"
Which is obviously ironical, at least that's how I understood it
So my answer is ironical too

side note: mc is a file manager, right ? ;-)

I need a file manager and prefer Dolphin. I even bought one for OS/2 back in the day. On some level it's probably from habit but I like having the long, wide view and with the "Open Terminal Here" option it feels like I have all views and options.

2 members found this post helpful.

Oui! The best kind = text based... I was a big fan of XTree Gold in the DOS days.

2 members found this post helpful.

I think I've found the answer for running window managers:
https://www.reddit.com/r/unixporn/co...ame=androidcss
https://labwc.github.io/

I hadn't come across labwc before in my reading, but it's a stacking wayland compositor designed to look like openbox. I suppose you could use it directly as an openbox replacement; add a taskbar applet and you would have something rather like fluxbox. That might be good enough for me. I remember using a setup much like this in Crux years ago.

But if you want a different desktop, say fvwm, you just run it inside a fullscreen XWayland window.

1 members found this post helpful.

I consider Dolphin as the best FM
And for a long time, Finder as the worst, until Gnome Files arise

Yes!.. setup an autofs/automount for it and skip steps 1 and 2.

1 members found this post helpful.

Just some reminders, since many posts in this thread keep veering into syntax/concept errors that make it impossible to actually discuss the question:

• Wayland == x11 - it is a protocol. Not a display server, and not a compositor. the protocols define what the x11 display servers or wayland compositors should do. There is NO SUCH THING AS WAYLAND (outside of the protocol), so you cannot say wayland should be a stacking window manager, that's like saying x11 should be KDE.
  
• X.org/Xfree86 etc are implementations of x11 protocol. There will never be an x12 protocol because development has terminated. There was going to be one, but not now. By happy chance, the reference display server for the x11 protocol is X.org, made by the X people themselves. There are other x11 display servers but nobody knows about them outside of followers of tech arcana.
  
• Window Managers per se are x11 concepts, and as far as I know, do not exist in wayland compositors. Thus no x11 window manager will be ported to wayland without becoming a wayland compositor. I just learned this, didn't realize window managers are specific to x11 display servers. They use X.org hooks to create the window managing.
  
• For most non desktops, I think the best way to think of wayland compositors is display server + window manager. For desktop compositors, a good way to think of them is like compiz, which replaces the window manager of the desktop, or Beryl for those who have long memories. Those are x11 compositors, which I suspect helped form the groundwork foundations for how wayland would work. I believe all x11 de window managers are also compositors at this point, though you can disable compositing in many. I think. So xfwm4 is a compositing window manager, so is kwin_x11, gnome-session (though gnome is harder to understand because of Mutter and that stuff). Enlightenment wm/compositor has the same name, which obscures the fact it has one. I believe they have switched over to wayland compositing now, and I do not know if their compositer actually supports x11 or not anymore.
  
• While I've read too much of the (frankly awful) wayland docs at freedesktop in efforts to actually understand this stuff, it's hard, so I don't claim to be an expert, I learn enough to get inxi stuff running and call it good. With this caveat:
  
• you cannot run a wayland compositor without a drm kernel gpu driver. Unlike X.org, which has a stack of drivers, gpu hardware > X.org display driver (and dri drivers, which I can't remember how fit in), wayland uses the drm kernel driver, so that is one area of vast simplification. If you've ever dealt with the random chaos that is each X.org display server driver (which inxi does), you will understand that this is not a minor simplification, wayland protocol simply dumps this entire part of the stack, and there is one driver, the gpu hardware driver. No more layered calls from desktop to kernel/gpu, if the kernel has the drm driver, wayland protocol should work.
  
• This means that all old drivers that are not DRM compatible, don't ask me what these things mean exactly, I want to say Display Rendering Manager, but that's probably wrong (I'm going to write this off the top of my head since I don't like re-researching the display stack). Kernel, unlike freedesktop, has great docs, and moving the entire core stack to the kernel is one thing I think is a big improvement in a realistic development sense. The kernel already has all this stuff running, so X.org display server and its drivers were basically duplicating a lot of work which is now gone, except in Xwayland, which keeps using that stuff.
  
  So basically all the DRM functionality is builtin to the kernels that ship, and the wayland compositors talk to that directly, more or less anyway. I believe this is one reason there is no network transparency, there is simply no layer that does that, and that is by design, it's a feature, not a bug. I would guess that's the display server part of X.org: x11 dictates protocols for a display server which then listens to requests, and it's agnostic to if those requests come over network or from client the server is running on. Think of a display server as a web server, only it's serving up your desktop or window managers windowing. And handling mouse and other inputs.
  
• Anything in your x11 window manager is talking to X.org which sends the data to its display drivers, which then talk to the kernel gpu drivers. Unlike wayland compositors, many x11 window managers can run without drm drivers in the kernel, but they probably cannot composite. For example, my Fluxbox on X.org using neomagic X.org display driver is taling to the gpu driver, which is not DRM capable.
  
• I think I have this one right: because X.org abstracts away almost everything your window manager does, you can make truly tiny window managers, I think there are some under 100 lines, DWM is at its base under 2000 LOC. That's because it is doing nothing except talking to X.org, which is doing all the work. This is why 'rewriting an x11 wm to wayland' is not a thing. What actually would happen there is the features of the wm would be carried into a new compositor, the way kde carried the kwin_x11 features into kwin_wayland, and I assume will call it fully ready for prime time when kwin_wayland is roughly feature complete. But that is a totally different beast, since it has to include the compositor talking to drm drivers. They may have been able to leverage the kwin_x11 compositing to kwin_wayland. There's also a guy who, and I agree with thim, thinks this duplication of efforts (the equivalent of every DE writing their own x11 display server) re compositors is a mistake, and he has written an attempt (kwinft) to remedy this, by using the sway/wlroots compositor library instead. I doubt it will catch on, but he has the right idea.
  
• While no means exhaustive, here is inxi's current list of wm-like wayland compositors, ignoring the DE ones. Note that many of these are stacking compositors, the trick is to pick the project that will survive long term. labwc is a good bet, maybe waybox, and of course, if openbox creates a port wayland compositor that emulates the features of x11 openbox, that will feel very similar, but these things aren't hard to do, so there is almost certainly a familiar feeling stacking wayland compositor project that has a good future already.
  
  Code:

  asc
  awc
  bismuth
  cage
  cagebreak
  cardboard
  chameleonwm
  clayland
  comfc
  dwl
  dwc
  epd-wm
  fireplace
  feathers
  fenestra
  glass
  gamescope
  greenfield
  grefson
  hikari
  hopalong
  [Hh]yprland
  inaban
  japokwm
  kiwmi
  labwc
  laikawm
  lipstick
  liri
  mahogany
  marina
  maze
  maynard
  motorcar
  newm
  nucleus
  orbital
  orbment
  perceptia
  phoc
  polonium
  pywm
  qtile
  river
  rootston
  rustland
  simulavr
  skylight
  smithay
  sommelier
  sway
  swayfx
  swc
  swvkc
  tabby
  taiwins
  tinybox
  tinywl
  trinkster
  velox
  vimway
  vivarium
  wavy
  waybox
  way-?cooler
  wayfire
  wayhouse
  waymonad
  westeros
  westford
  weston
  wio
  wxr[cd]
  xuake

  Note that this list, like the inxi x11 WM list, is not complete, nor can it ever be. There is a website dedicated to listing every x11 wm, and there are many hundreds, mainly because it's so easy to do it when X.org is doing all the heavy lifting. wlroots wayland compositing library will serve as a similar tool for wayland, and already is. gnome-session, enlightenment, kwin_wayland, are all evolutionary dead ends and will just be what they are, for only their DE. Xfce is I believe using wlroots in their tests with xfwm4 wayland, but I don't follow the details.
• Weston is the reference wayland compositor, but unlike X.org, the reference x11 display server, nobody uses it outside maybe a kiosk vendor or two, and maybe as a codebase for new compositor projects to give them a start.

With this said, and I really suggest if you fall in the camp of 'wayland should be like my current wm/de', take the time to at least half absorb the concepts. I watched a long video, very embarrassing, by an older ex IBM guy who was trying to explain wayland, it was really unpleasant since he just could not grasp the concepts, and kept mixing up terms and ideas and technologies. Maybe excusable for a layperson, but certainly not for an ex IBM guy. It's like confusing kernel virtualization with virtualbox. This is common.

Bad freedesktop.org wayland docs are certainly in part to blame, they need to take lessons from the linux kernel doc team on how to present clear explanations of what things ARE, and what they DO, and HOW THEY DO IT. I do not blame people for getting confused, but if you find yourself confusing x11, wayland, X.org, any wayland compositor conceptually, just pause, and realize, hey, I don't understand this, I need to get the core concepts before making statements about it. I speak as someone who has to do this all the time, and I don't even like or care about this stuff at all, I just have to keep inxi in the loop and ready for wayland, so I'm stuck, I have to learn the minimal basics, so I appreciate how confusing it can be. Here's some more list items:

• GLX is, the X is the giveaway, X.org only. Anything with X in its name is that, like xrandr, xdpyinfo, X, glxinfo. If you run glxinfo on a system with Xwayland, you get the info from your xwayland session, which is NOT the info from your wayland compositor.
• think of Xwayland, the only active X server branch, as a short term hack, like multibooting with windows, or using a windows vm when you switch to GNU/Linux. The less you rely on it, the better, since it has no future really either, nor probably does the x11 program that runs in it. I hate this because it's a massive waste of finite and precious developer time and energy, but that's how it is. Think of using Xwayland as using WINE, maybe a necessity, but nothing core should count on it in your workflow, or you should stay with x11 wm/de until it can be done nativiely on wayland.
  
  I believe though don't quote me that Xwayland basically acts like a window between you and the wayland compositor, and it contains a barebones set of x11 protocol features that let it talk to the compositor. I am sure I have this wrong at least in part, but technically I don't care since I understand that using a shim is only a short term fix and should be avoided in general if possible. My strategy is to wait until it almost all 'just works' natively, and the shim is almost never needed. Again, yes this sucks for 30 years of x11 software, but it sucking doesn't alter anything.
  
• This point I want to highlight: I personally think that all the stakeholdes in current x11 protocol programs and features should get together and actually see if it's possible to work on X.org and move it forwards, or if hte devs who know it best are right, and it is simply too difficult to fix. Without organized and connected work, there is imo ZERO chance of any fork attempt to work, X.org is too hard, it has too many pieces, and the odds of any volunteer collection of people without the necessary hardcore display server skills being able to pull for example all the X display drivers into the future are so close to zero as to be virtually a pure fantasy. You know the drill: oh, 'tney'' should just fork it! That they of course does not include the person or people who say it should be forked, and if we are objective, all the core people who do know the codebase all roughly agree it should not be moved forwards, and are no longer working on X.org. So that's a HUGE learning curve.
  
  I personally think this would be a fantastic project, but it could work if and only if all the interested parties actually sat down, found a P. Volkerding type of person to be BDFL, and avoided anything even remotely resembling governance by consensus. That has no more chance of working long term than the Linux kernel, and it's probably similar complexity level. While not naming names, I've seen some distributions go for consensus model, and I have watched their code, features, programs, etc, swirl down the drain as the lack of discipline becomes self evident. Some stuff just is not fun to do, and someone has to be there to say, hey, forget eye candy, the amdgpu display driver has issues with this specific set of AMD gpu devices, fix it.
  
  Consider the reality of moving X.org forwards, or a forked version, say, Y.org, as quite similar in scope to forking the kernel and moving it in a different direction. that would last, what, a month? two?

11 members found this post helpful.

While I miss kde4 (somewhat) and recently xfce has become my favoured daily driver, I see almost NO advantage to Wayland, and much trouble, turmoil, and discord ahead courtesy of Mr. Pointless Schtick from Planet Soiboi. Wayland doesnt seem to be Way.

1 members found this post helpful.

This is so good, it really ought to be moved into permanent storage, either as a blog or in the wiki. Then we could always reference it in future threads on this topic. It's a sin to let it just roll off the top of the screen and be forgotten.

info: I believe DRI stands for Direct Rendering Interface and refers to applications drawing directly on the videocard ram themselves (with the help of the card's firmware, libdrm and the kernel) rather than leaving everything to Xorg. Which means of course that there is that much less for the server to do.

Incidently, it seems to me that this distribution of labour is much more in accordance with Linux's basic philosophy than the X model. Managing hardware is the kernel's job.

1 members found this post helpful.

Excellent post, h2-1. And the DRM you were looking for, for those who are interested:
https://en.wikipedia.org/wiki/Direct_Rendering_Manager