tl;dr the author never actually gets to the point stated in the title about what the “problem” is with the direction of Linux and/or how knowing the history of UNIX would allegedly solve this. The author mainly goes off on a tangent listing out every UNIX and POSIX system in their history of UNIX.
If I understand correctly, the author sort of backs into the argument that, because certain Chinese distros like Huawei EulerOS and Inspur K/UX were UNIX-certified by Open Group, Linux therefore is a UNIX and not merely UNIX-like. The author seems to be indirectly implying that all of Linux therefore needs to be made fully UNIX-compatible at a native level and not just via translation layers.
Towards the end, the author points out that Wayland doesn’t comply with UNIX principles because the graphics stack does not follow the “everything is a file” principle, despite previously admitting that basically no graphics stack, like X11 or MacOS’s graphics stack, has ever done this.
Help me out if I am missing something, but all of this fails to articulate why any of this is a “problem” which will lead to some kind of dead-end for Linux or why making all parts of Linux UNIX-compatible would be helpful or preferable. The author seems to assume out of hand that making systems UNIX-compatible is an end unto itself.
Seriously, I don’t understand the point of the article, if there is one.
It seemed more like a confused enumeration of systems which are POSIX conform and in the end it talks about Wayland.
Is the point that Wayland breaks compatibility with X11/X.org and is mostly a Linux thingy? (AFAIK FreeBSD is working on a Wayland port, but no one else.)
Anyway, I am a happy Wayland user for several years now, although I am of course unhappy about the split with the *BSDs, OTOH most 'NIX software nowadays uses so many Linux APIs, that Wayland is IMHO no big game changer when talking about portability anyway.
Is anyone even running anything besides maybe FreeBSD on desktops? Most advantages of BSD over Linux seem to be relevant for servers, but not really for typical desktop usage.
Additionally, apps use toolkits anyway, which provides backends for Wayland and X11. If at some point X really isn’t viable anymore, people will put in the work and port Wayland from FreeBSD to other BSDs.
In my impression OpenBSD is used at least as much as FreeBSD on the desktop, if not even more.
Nowadays I agree with your point, that for the ‘typical desktop usage’ the BSDs are not very viable (I try from time to time and always have to give up, because of missing hardware support or missing software.).
Still, IMHO it is a great loss that the BSDs are not really an alternative on the desktop for most users. BSDs are extremely good engineered, when hardware is supported, it just works™, the base system is clean and has great documentation.
FreeBSD isn’t working on a Wayland port, that’s already happened. The Plasma Wayland session has supported it for quite a while… KDE even runs a CI job on FreeBSD for every merge request, where kwin_wayland autotests are run.
Considering the amount of complaints we got when something broke recently though (which is to say, none), it doesn’t look like it has a lot of users
Today, the Wayland enthusiasts like to talk about how they are modernizing the Linux graphics stack. But Linux is a Unix, and in Unix, everything is meant to be a file. So any Wayland evangelists out there, tell us: where in the file system can I find the files describing a window on the screen under the Wayland protocol? What file holds the coordinates of the window, its place in the Z-order, its colour depth, its contents?
As far as I’m aware nobody has even considered extending the file metaphor to the graphics stack, and it sounds a bit ridiculous to me.
It also reminds me of this talk that suggests maybe trying to express everything as a file might not be the best idea…
Dennis Ritchie and Ken Thompson [...] ignored what the industry was doing, went back to their original ideas, and kept working on refining them. The result is the next step in the development of Unix
Plan 9 is clearly what the article is talking about. Odd that they don't name it.
They do, if you consider that this article doesn’t stand alone at all and read the blurb at the very bottom in italics acknowledging that it’s part of a bigger series
It’s nonsense. The author arbitrarily decides on some expression of the windowing model in terms of files. OK cool. Every author of a system that uses files decides how to represent their data. E.g. how many files to use, sockets, what data to flow through each and what format that data should be represented in. Like why not go to the authors of Btrfs and argue why the data format /dev/btrfs-control is the way it is why it’s a single file instead of 5. It’s an arbitrary decision. When not used for storing data files in POSIX-like OSes are a type of IPC mechanism. How many channels that IPC needs and what data flows over these channels is an arbitrary decision by the authors on one or both sides of that IPC. The OS provides the IPC mechanism. The software that uses it creates some abstraction on top of it which doesn’t have to conform to any lower level OS models. Could we model Postgres tables and rows like files in a dir structure. Sure. There are pros and cons to using that model. Might not be great for terabyte scale db performance.
/dev/fb0 is the framebuffer. So yes, you can feed data into the filesystem and you’ll see it on your display.
For Unixoids, being a file does not mean that this data is stored on a hard disk, but that all data, processes and hardware are accessible with the same toolkit. /dev/fb0, for instance, is part of the file-like interface of your graphics card.
/dev/fb is mostly one thing: deprecated. Also it is not really a interface of your graphics card, it is a legacy way kindly still provided for pushing fullscreen pixels to your monitor in an unaccelerated fashion for things that have not made it to kms drm (which at this point is pretty much merely the console emulation on the TTYs). It is not an interface to the graphics card, because it doesn’t provide any capabilities a graphics card has (like shaders etc). In fact for just pushing pixels you can leave any graphics card completely out of your computer if you connect your screen by other means (think stuff like SPI which is common in embedded devices; you can find many examples of such drivers in the kernel source at drivers/gpu/drm/tiny ).
Would it be possible to run parsec or moonlight on these? I tried parsec on cb++ in the past but it was missing some libra58 dependency thing for it to run
OK I got parsec running on cb++ by forcing parsec to install and ignore libjpeg8 following some reddit users comment. Perfect for my wyse 5470 thin client
i think what this redd subb is saying is that unless a person is involved in a stateoftheart/research project… the software isnt really valuable on an everyday basis ( compared to just using professional software that is the product of new research )
kinda demoralizing(in this context).
it would be cool if he could FOSS his way out of this one.
Been using cbpp for… a long time now, (honestly forgotten when I started) hoping u/computermouth has plans to move to wayland, but I can’t be arsed going back to reddit to ask.
Not had much luck finding a minimal stacking DE to replace it.
How good is the touch screen support in these two? I’m running a convertible for note taking, and I kinda depend on Gnomes pretty decent gesture support.
For me, Crunchbang was a great introduction to the possibilities of customizing your Linux experience. No giant, monolithic desktop environment, just a handful of programs that you could (and were encouraged to) tweak or replace to your heart's content.
I still run a Crunchbang-inspired setup on my vanilla Debian install—openbox, tint2, conky, nitrogen, gmrun, Win+Letter hotkeys for frequently-used apps, etc. While I've outgrown the need for a preconfigured distro myself, I'm glad to see these projects still providing an on-ramp for users looking to dip their toes into the deeper end of the Linux pool.
theregister.com
Hot