 DistroWatch Weekly |
| Tip Jar |
If you've enjoyed this week's issue of DistroWatch Weekly, please consider sending us a tip.
(Tips this week: 0, value: US$0.00) |
|
|
|
 bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Extended Lifecycle Support by TuxCare |
|
|
| Reader Comments • Jump to last comment |
1 • simple wayland demo? (by J.D. Laub on 2025-05-19 02:23:11 GMT from United States)
The Q&A brought to mind a question. Years ago, I used to fire up xeyes if I wanted to test X - a simple little program. What simple little Wayland program do folks use for a quick test?
2 • Filesystem Makeover (by Penguinx86 on 2025-05-19 04:31:09 GMT from United States)
I voted NO for the filesystem makeover. The current filesystem meets POSIX standards. Renaming directories with non-POSIX-compliant names would cause compatibility issues and break everything. Then, some poor sysadmin would have to piece together hundreds of symbolic links from the old directory locations to the new ones, in an attempt to fix what broke. Then, installing an update could wipe out all the links and break everything again. I think a filesystem makeover is a bad idea.
3 • File system names (by Keith S. on 2025-05-19 04:36:26 GMT from United States)
I frankly can't imagine changing the file system directory naming conventions in Linux / BSD. Not hard to learn, and pretty easy to sort what goes where. When I have to use Windows, I almost always have a hard time finding what I'm looking for. Longer names do not equal better names. Then when I think I have it figured out, suddenly I realize that I might have to look in the 32-bit directories to make sure I haven't missed something. Ridiculous.
4 • Filesystem make over. (by SNH on 2025-05-19 06:19:53 GMT from Australia)
Why does Linux seem obsessed with alienating old users just to accommodate new users. The file system is not difficult to understand. If someone is not willing to learn a new system why move to linux or any other system in the first place. It sounds like Windows, lets rearrange the deck chairs and paint the walls so the newcomers can feel comfortable. Its ridiculous. Thinks will probably evolve just fine naturally over time as they have in the past. BTW Gobo probably would have been better off to continue snoozing in a already way over crowded linux universe. Just my 2 cents.
5 • Filesystem makeover (by Brünhilde on 2025-05-19 07:41:19 GMT from Czechia)
> It is not obvious to new users what usr, opt, var, and etc mean [...]
Just as it isn't obvious how to drive a car if you haven't learned it (and learning to drive requires way more time than learning the basic directory structure). Most users can get away with not knowing the filesystem layout (as has been the case for 10+ years), and those who need to know it should learn it; it really isn't a big effort.
6 • GoboLinux filesystem (by Kazlu on 2025-05-19 08:05:31 GMT from France)
Os the GoboLinux filesystem makeover a good idea? Yes, I think so, it makes manual interventions easier (however rare, they still exist) and with a carefully built series of links it does not break the traditional way.
It it needed? Not so much. I do not dig very often in a filesystem. A file structure like that may have resulted in a slightly faster way to solve a problem here and there, but I don't think it would ever have been a make or break solution for me.
Do the developpers need to stop working on it? Absolutely not. At the risk of sounding repetitive, the GNU/Linux community is not a pool in interchangeable developper resources. Most of GNU/Linux devs like the ones in Gobo work on it on their spare time, because they are willing to do something they are interested in, sharing the results with the community. One cannot tell them to stop doing that and work on Linux drivers for example. Because, well, they chose alone what they do with their spare time. So I am grateful to any developper bringing something to the table, whether it is very or remotely useful, for sharing their work. Maybe this will bring something positive to the community, maybe not. The only way to know is to try.
7 • @3 file system names (by Kazlu on 2025-05-19 08:20:04 GMT from France)
"Then when I think I have it figured out, suddenly I realize that I might have to look in the 32-bit directories to make sure I haven't missed something. Ridiculous. "
Is it more ridiculous than searching for a binary in /bin and /usr/bin only to realize that you haven't looked in /sbin and /usr/sbin? I don't think so. Personnally I find this mind numbing. There might be a good reason for that, but the end result is very complicated and I seriously wonder if it's worth it.
Every approach will necessarily have pros and cons. One cannot only point the pros of one versus the cons of the other. In the end I am convinced that the pros/cons balance is so... well, balanced, that breaking everything would be a big effort for little overall gain, if any. But I fail to see how the traditional GNU/Linux filesystem hierarchy would be inherently so much better. I learnt only the basics, enough to do what I need, but it has always sounded overly and unnecessarily complicated to me.
To be clear I don't think a change is really *needed*. Things work today, it's not that cryptic, things are doable, and it would be a bad idea to change for the sake of change. But the Gobo approach is interesting, to have something clearer to dig in while retaining traditional compatibility through links. Not perfect, sure, but interesting.
8 • @7 file system names (by Karsten on 2025-05-19 08:50:49 GMT from Germany)
I totally agree with you and could not have written it better. Thank you :-)
9 • Would the Linux filesystem benefit from a new naming approach? (by Jake on 2025-05-19 09:32:24 GMT from United States)
I voted no. Someone would try to make it like the Windows filesystem, and I want Linux to be like Linux not like Windows, which I dislike.
10 • Linux filesystem (by Dave on 2025-05-19 09:56:49 GMT from Australia)
I voted yes, change the file system. It would be a big deal for compatibility, but not everyone would change instantly, and many would never change at all. So there'll alway be the option to not do it if you don't like it.
The current standard is not intuitive, people are just used to it. If you had to design a file structure from scatch now, no-one would come up with what we have at the moment.
I like when people do new things, even if it doesn't catch on, giving it a go is a good idea.
11 • openSUSE YaST (by César on 2025-05-19 10:59:56 GMT from Chile)
Sad!
Very sad!
The news i read here (about the end of this wonderful tool) is very disappointed, a swiss knife really, one of the most complete in Linux world, past away...well...i rememer when i started with Suse in the 2000's, and i liked this tool, no other distro has something like that (maybe Mandriva in the beginning).
In the other side, i waiting for Debian Trixie, i hope works like the Bookworm, without issues.
Saludos desde Santiago de Chile.
12 • Linux filesystem & yast (by kc1di on 2025-05-19 12:01:05 GMT from United States)
I too old to change the file system besides it working fine the way it is.
Sad to hear about yast. Was synonymous with SuSE for a long time. Won't seem the same
13 • @7 & 8 Filesystem (by crayola-eater on 2025-05-19 12:58:45 GMT from United States)
"Is it more ridiculous than searching for a binary in /bin and /usr/bin only to realize that you haven't looked in /sbin and /usr/sbin?"
That's why before I go blindly, I run 'whereis' and it tells me where to look.
Simple, like KISS Linux should be.
14 • file system (by wally on 2025-05-19 13:11:47 GMT from United States)
Yes, the Linux filesystem can be puzzling at times, but in my opinion Windows filesystem is worse and should not be a model.
There is room for improvement in Linux filesystem but at what cost for what gain.
One of the finest tools in Linux is [P|S]locate. A lifesaver for when you are looking for something but not quite sure where/what, and I think for forgiving that 'whereis'.
15 • file system -oops (by wally on 2025-05-19 13:14:32 GMT from United States)
bad fingers!
meant to say "I think more forgiving than 'whereis'".
16 • YaST (by Kazlu on 2025-05-19 13:20:49 GMT from France)
I do not really understand. In my opinion, YaST is on of the strongest pros of openSUSE. Weird to remove it. And what is supposed to carry on the tasks it was doing? A collection of other tools? A replacement? I feel like some information is missing. Like, if Fedora annouced they would be removing GNOME, they would say what DE they are using as a replacement, right?
17 • YaST (by Jesse on 2025-05-19 13:28:49 GMT from Canada)
@16: "I do not really understand. In my opinion, YaST is on of the strongest pros of openSUSE. Weird to remove it. And what is supposed to carry on the tasks it was doing? A collection of other tools? A replacement? I feel like some information is missing."
The context I think you're missing is that openSUSE has been trying to phase out its old tools and branches for a few years. That's why they keep announcing the end of Leap (version 16 is the third time it has been the "last" version of Leap). They are also phasing out tools like YaST in favour of immutable flavours where low-level configuration of the root filesystem doesn't work.
There isn't a replacement for YaST, exactly, because the replacement is to get people using immutable systems with add-on modules for services.
18 • Look into the Linux folders should not be necessary (by Flavianoep on 2025-05-19 13:41:07 GMT from Brazil)
In twenty years of using Linux, there were two kinds of situations when I had to look into the directories under /: fixing a problem or getting some unusual functionality. Inexperienced users don't do that. And even if they do, the names of the Linux directories are the least of their problems. What is the point of you changing the name of /etc for something more user-friendly, if a beginner shouldn't even care what this directory is? The only folders that must have user-friendly names are the ones in the user directory and they already have user-friendly names.
19 • Gobo LInux File System (by Slappy McGee on 2025-05-19 13:53:56 GMT from United States)
There are screenshots of the GoboLinux file system hierarchy at their website. Interesting, but I honestly can't see it as any sort of solution, as I really do not perceive the Linux typical file system as being in need of change. There are choices from (parent) distro to distro.
Some seem to see a need, thus the existence of the different ones like Gobo.
20 • Location, location, location (by vmclark on 2025-05-19 14:33:15 GMT from United States)
You don't have to "dig" anywhere to find anything. Use the find command for locations. That's what its there for.
21 • Finding something (by Kazlu on 2025-05-19 14:55:34 GMT from France)
Using the find, locate or whereis command to find a binary is fine... If you can point directions in the first place. Oh, sure, you can search the whole tree, starting from /, but then the command will look in all your personal data, every mounted partition, which will take an enourmous and unnecessary amount of time. So, we're back to having to look in 4 different locations, ie run fin/whereis/locate 4 times in /bin, /sbin, /usr/bin, /usr/sbin. That is, of course, if you've remembered all that.
Is it that hard? No! Is it unnecessarily complicated? Yes. And, to circle back to my original point, not easier than having to look in C:\Progam Files and C:\Progam Files (x86).
And, finally, *why* are there so many commands to look for something? I use them so seldomly I inevitably mix up the syntax between them everytime I need them.
22 • @17 YaST (by Kazlu on 2025-05-19 15:02:55 GMT from France)
"There isn't a replacement for YaST, exactly, because the replacement is to get people using immutable systems with add-on modules for services."
This sounds to me like there are changes happening under the hood. YaST is, as I understand it, a GUI tool, as in graphical *user interface* tool, therefore it serves as an abstraction layer the user can interact with to configure bits of the system. I understand some low level aspects may become irrelevant, but not everything. For example, package management will change, but we will still need updates. And many other aspects of the system will be unaffected, like printer management, power management, etc. I mean, if I want to set after how much time being inactive my system shoud go to sleep, a change in the underlying system, however massive, should not change the user interface bit where I do the setting. This is where I don't understand how things should be carried out without YaST in openSUSE.
23 • Gobo (by netfun81 on 2025-05-19 15:04:32 GMT from United States)
Tried Gobo in the past, It was unique and a simple file system but when it came to any issue I spent more time trying to make it work than a normal linux filesystem.
Jesse wrote "Most users never need to touch a command line", I find that a bit hard to believe as I am using a terminal almost every day in Linux. Possibly, if you don't install much software and mainly use a browser you can avoid the command line, but using Linux as primary OS, trying out various programs, updating often, or using a bleeding edge distro, its nearly impossible to never touch the command line.
24 • finding tings (by Jesse on 2025-05-19 15:06:16 GMT from Canada)
@21: "Using the find, locate or whereis command to find a binary is fine... If you can point directions in the first place. Oh, sure, you can search the whole tree, starting from /, but then the command will look in all your personal data, every mounted partition, which will take an enourmous and unnecessary amount of time. So, we're back to having to look in 4 different locations, ie run fin/whereis/locate 4 times in /bin, /sbin, /usr/bin, /usr/sbin. "
You don't need to do all of that. You can just run "which" or "locate" once, which will be instant, and filter based on type. For example, if I wanted to know where "nmap" is located, I could run:
$ which nmap
/usr/bin/nmap
Or if I wanted to find all commands which contain "nmap" in their name I would run:
$ locate nmap | grep "bin/"
/usr/bin/nmap
The above will find all commands in /sbin, /bin, /usrbin, /usr/sbin, /usr/local/bin, and /usr/local/sbin. No need to remember all the places, no need to wait, no need to sift through your personal files.
"*why* are there so many commands to look for something?"
Because they work different ways and make sense in different situations. "which" finds the location of commands you already know. "locate" finds any file immediately, as long as it is not brand new. "find" locates any file, including new ones, at the directory of your choice.
25 • YaST and command line (by Jesse on 2025-05-19 15:12:00 GMT from Canada)
@22: "YaST is, as I understand it, a GUI tool, as in graphical *user interface* tool, "
YaST is a collective name used by both the command line version and the GUI version of openSUSE's admin tool.. You can run it from the command line, for example, when working on servers.
@23: "Jesse wrote "Most users never need to touch a command line", I find that a bit hard to believe as I am using a terminal almost every day in Linux.
But you aren't most users. You're one user. Most people never touch a command line. Unless you are a techie or a hobbyist, there isn't any reason for people to use a command line on a Linux distribution.
> Possibly, if you don't install much software and mainly use a browser you can avoid the command line, but using Linux as primary OS, trying out various programs, updating often, or using a bleeding edge distro, its nearly impossible to never touch the command line.
None of the functions you just mentioned require a command line. Also, again, you're describing a niche situation specific to you (and tech enthusiasts) not _most_ users. Most users just need a web browser, office suite, maybe a music player. Most users don't constantly install new software ,experiment with bleeding edge packages, or constantly try out new applications. They just use the browser and a few apps their system came with.
26 • Gobo Linux (by RetiredIT on 2025-05-19 15:27:54 GMT from United States)
Regardless of what Gobo is currently doing, a distro that has been around for more than 23 years should have solved most, if not all, the problems mentioned in the testing review. Who would ever want a daily driver that only has a 5.7 visitor rating? There are so MANY much better distros to choose from!
27 • GoboLinux.... (by Marky V. on 2025-05-19 15:51:41 GMT from The Netherlands)
NixOS is the "new" GoboLinux.
28 • @26 Gobo (by Kazlu on 2025-05-19 15:56:11 GMT from France)
Apparently, Gobo has seen changes in its dev team. Especially since the last version. So I assume the first order of business is *getting the distro to work again after updating the packages*. I sounds as if it has been more or less dormant for a while. That could explain that the distro has today more problems than before. Hopefully these will get ironed out.
However, I think no one intends, even their creators, to run GoboLinux as a daily driver! It looks more like an experiment, a concept distro, that *could become* a daily driver distro with time. But, indeed, people looking for a daily driver distro have no reason to settle on this one...
29 • YaST (by vw72 on 2025-05-19 16:24:47 GMT from United States)
First, the YaST decision came from SUSE. It is a burden to maintain and their users don't use it much. openSUSE is free to continue maintaining it, but that would take developers to step up and devote time to do it, but that would take resources away from other projects they work on. There was a lot of angst on various forums about the deprecation of YaST but very few if any people stepping up to maintain it. As such, eventually it will go away.
The good news is that while Yast is going away, its functionality isn't. Myrlyn handles installing software quite well and Cockpit covers much of what else was in Yast.
There are still some things lacking in Cockpit, but that doesn't mean old YasT modules won't be converted to Cockpit. All it takes is somebody to step up and do it.
30 • Where are the files? (by Oracles on 2025-05-19 16:42:03 GMT from United States)
So, you're a noob and install GoboLinux. You have some issues and are poking through "Data" or whatever to find a config file. You get stuck so ask your friend who has been using Linux for years. They look at the system and are completely perplexed, "Where the fock is /etc?" Poor noob can't get help from experienced users, so they're on their own. Sounds like a really great experience to me...
31 • @30 noob experience (by Kazlu on 2025-05-19 17:02:20 GMT from France)
This is probably what Linux noobs experienced in the early 90s, while any friend would be asking "Where the heck is C:\?"... One has to start somewhere.
32 • linux noobs (by netfun81 on 2025-05-19 17:14:47 GMT from United States)
the biggest issue i had going from dos/win3.1 to redhat 4.0 was after install it had FVWM window manager which was a gui but you had to configure the gui with config files. That was quite different than normal gui environments at the time.
33 • FHS should be simplified, not superceded (by mrnoname1000 on 2025-05-19 17:36:43 GMT from United States)
I think the current filesystem hierarchy should be simplified, but in a way that conforms to FHS. I love the three-letter, all-lowercase directories so capitalizing and spelling them out does not appeal to me. What kind of name is /Data? That could include literally anything.
The usr merge and sbin merge that several distros have done is very convenient. On those distros, I know for a fact a system executable lives in /usr/bin and I can use /bin as a shortcut. Sure, you can use a command to search for something, but that's a whole extra step when you might be in the middle of something. If all system binaries were in one place, you wouldn't need to locate them, you would instantly know their location. IMO the package manager should put files in the most ergonomic place since it tracks every installed file anyway.
Debian has done the /usr merge but still has separate bin and sbin directories, which compounds the fragmentation and seems really arbitrary to me. Under the default PATH config, it's so annoying to have to run an sbin command with its full path or as root just to see its help output.
34 • Filesystem Makeover (by Jack on 2025-05-19 19:20:11 GMT from Switzerland)
After all these years the Linux filesystem is still what it was more than 50 years ago! For sure evolution is not in the DNA of the Linux microcosm. With 50 % of pollsters thinking that the filesystem is fine as it is, it's hard to see Linux becoming mainstream (for the masses).
If you could install apps and ignore what happens under the surface like in Android the world would be a fine place. In Linux this is clearly not the case!
35 • MiniOS Toolbox (by Simon Plaistowe on 2025-05-19 22:16:27 GMT from New Zealand)
Glad to see MiniOS has at long last been included in the DistroWatch database! I've been using the Toolbox edition on my utils USB-stick for a while now, it's a good one-stop for partitioning, system image backups, etc.
36 • GoboLinux needs an AUR (by Happy_Phantom on 2025-05-19 22:35:18 GMT from United States)
Installing software from source shouldn't be that had. Maybe GoboLinux needs a ports system like the BSDs have, or, better yet, and system like Arch Linux's AUR that basically makes installing recipes from source doable with much less frustration..
37 • GoboLinux and FHS (by picamanic on 2025-05-20 09:30:03 GMT from United Kingdom)
GoboLinux and FHS: whilst the so called /usr merge has been adopted by many distros, the last time I looked, Debian retained the /bin and /sbin distinction, for what I can only think are security reasons. I prefer that all executables are located in /usr/bin, with symlinks to /sbin, etc.
What the GoboLinux team have done to re-imagine the Linux file system, keeping the files for each package in one location, is an "interesting", but, I think, unnecessary distraction. Capitalisation of directory names is the last straw.
38 • Gobohide security risk? (by dob on 2025-05-20 10:44:43 GMT from United Kingdom)
could the symbolic links used by gobo be a potential ‘blind spot’ to conventionally configured intrusion detection and prevention systems?
Has any security auditing been carried out to understand the different attack surface and risk?
39 • #38 gobo symbolic link = “dirty cow” style exploit? (by dob on 2025-05-20 10:54:19 GMT from United Kingdom)
https://www.cyberly.org/en/how-do-attackers-escalate-privileges-using-symbolic-links/index.html
40 • Gobohide an APT toolkit in the wrong hands… (by dob on 2025-05-20 11:32:19 GMT from United Kingdom)
https://lwn.net/Articles/194376/
41 • @4 Filesystem make over (by Geo. on 2025-05-20 13:19:32 GMT from Canada)
"seem obsessed with alienating old users just to accommodate new users?"
How far back do you want to go? Christian reformation? Horse over foot? Bronze over stone? Agriculture over forage? Change for the sake of change is foolish, but if there is a genuine improvement then I support it. Great respect to my line command friends, but I'm not giving up GUI.
42 • @39 gobo symbolic link = “dirty cow” style exploit? (by Kazlu on 2025-05-20 15:37:12 GMT from France)
All the attack strategies suggested involve the *creation* of a symbolic link by an unprivileged user, who can then ecalate privileges. This does not correspond to the situation here, where Gobolinux's links are already here and are (I presume !) owned by root. Therefore an unprivileged user has no control over them.
Not to say that there is no risk invovled, I am not qualified to claim that. But this family of attacks does not seem to apply here.
43 • File System Hierarchy (by JKL on 2025-05-20 15:49:53 GMT from United States)
The Gobo style file structure and hiding etc bin and such is exactly what macOS does, except macOS uses etc usr and such for system files that the mac user shouldn’t touch. This is better than using symbolic links which can be used for deceptive malicious purposes.
I like the original style because:
- each are three letters long which are easy to type in a console
- once you know where each goes it’s relatively straightforward
- No capital letters which are annoying on the terminal on a case sensitive file system (mac and windows are case insensitive, so they can get away with it)
Some inconsistencies with distros have something to do with if configs are in usr/share instead of etc, or bin is symlinked to /usr/bin (most do this because of systemd wanting it). sbin is set up differently on each distro as well (meaning some programs are in there on some distros while other distros put less or more in there), and can only be accessed and tab completed as root.
Other than that there is a reason why the file system is set up like this and the new structure is assuming that everything will be desktop oriented, not general purpose like Linux is designed to be.
44 • Case sensitivity (by Flavii on 2025-05-20 16:28:36 GMT from Brazil)
@43 "mac (…) [is] case insensitive"
You just gave me one more reason never to buy a Mac. :-)
45 • Filesystem organization (by Robert on 2025-05-20 16:31:59 GMT from United States)
I do think that Linux would have benefitted from a filesystem organization like Gobo's. I even tried to do this myself many years ago, though I failed at the time.
I think this is one thing that Windows actually got right - keeping applications self-contained in their own directories, not spread out all over semi-random directories. Of course it's a littler messier now with the appdata directories, but that's a necessary compromise for per-user application settings.
That said, it is far, far too late to change it now. There would be a prolonged period of breakage with some programs never making the transition. Would be far more painful than older migrations such as the switch to 64-bit and supporting multilib, or the /usr merge than some distros have done.
46 • YaST (by techfun on 2025-05-20 23:18:55 GMT from Australia)
retiring YaST - "Yet another Setup Tool": perhaps cryptic software names have fallen flat for the digital generation.
47 • @7 & 8 Finding files in GNU/Linux and MS Windows (by Ottomane on 2025-05-21 07:38:06 GMT from Germany)
Yeah, the POSIX file system scheme looks weird if you come from MS Windows. The MS Windows file system scheme looks weird if you come from any POSIX-using distribution.
In POSIX I have a chance of finding files by browsing to the place where things are defined to be, you don't. You may have a chance on MS Windows -- where is the executable? C:\Program Files (x86)\, C:\Program Files, C:\%USERPROFILE%\%APPDATA%\Local or LocalLow, some custom place like C:\MyHotProgram or D:\MyPortableApps\MyHotProgram\? -- I don't. It's just a matter of familiarity.
So you have to pop out "whereis", "find" or "locate" in Linux and I have to pop out "Everywhere" in MS Windows or look at $PATH and go prowling (because MS Windows has no built-in useful file search tool).
So, yeah, It sucks to be a MS Windows User and having to work with Linux machines -- and vice versa. That's the way it is.
48 • It's the 21st century by now (by Ottomane on 2025-05-21 07:52:53 GMT from Germany)
@34 Hey Jack, you probably missed out on the last 20 years of Linux desktop developments. There is a group called freedesktop.org, where the major players of the Linux desktop environments, and most of the minor ones, get together and standardize the stuff needed to run a GUI. A user of a Linux system will never have to leave $HOME, will not see the system's directories, and can configure anything graphical with GUI tools, down to the appearance of the login manager and the bootloader (but why would a user care?)
If you happen to come along at a current Linux distribution for desktop use and fancy to show hidden files in your file browser you might notice in your $HOME directories such as .config, .local and so on. ~/.steam is where your games live ;) This is where your user settings are saved and you wouldn't have found them 25 years ago. It pretty much %USERPROFILE%/%APPDATA%/ with human readable names.
49 • file system change (by Trinidad Cruz on 2025-05-21 13:26:49 GMT from United States)
Longer file names are an absolute nuisance to work with scripting or changing lib in deep fs hierarchies. It's bad enough you can get six returns deep in one line of code. It's fine to have longer more explanatory names at the very top, but beyond that level it only leads to eye strain and typos. In fact shortening file names at every level below the top directories is better, and file tree explanations in help panels for new users. Anyway, it's Linux where everybody thinks they are very smart and so often have to deal with self-inflicted expectations of innovation and creativity. Perhaps the introduction of some kind of shorthand for file naming will become a neccessary in the end, and secretaries to translate. I can see it already... nicely dressed young women piling off the El and heading into the Merc... actual pools of them again... ah nostalgia.
TC
50 • Options (by Michael T on 2025-05-21 18:10:14 GMT from United States)
I think that some people miss the point. First and foremost a Linux distro is a hobbyist system. Second, it is a developers system where people can try new ideas or change existing ones. This is part of the beauty of Linux systems. Are these changes necessary? No. Are they required? Ony for the process using them.
One major benefit of the current file system layout is consistancy. There are very few distros that don't follow the standard file system layout which makes things easier for programmers and sysadmins. Knowing where things belong in the file system makes it much easier to do many tasks such as maintenance, program development and configuration. As we have seen from various distro changes putting things in an unusual location can cause confusion. This is something to be avoided on a multi-user system that must keep the downtime to a minimum. Sure, it might seem unnecessary on a single user system, but keep in mind that Linux OS's are multiuser systems by design.
There is a frequent compaint about too many available distros, which I personally find rather silly, There is a reason that they exist. Creating a distro, even if it is never shared, is the best way to learn about Linux. Not the everyday usage of it, but how it is put together. This knowledge is crucial for system administrators and some application development. It may be debatable that all of these distros are available for anyones to access and use, but not distributing them makes it harder for another person to understand any changes made to the system or problems that may occur during regular usage.
There is a lot of history with Unix, and thus any systems based on its ideals, Decades worth of development have made the OS easy to use. Consistancy makes it easier to maintain.
51 • @50 (by Simon on 2025-05-22 01:59:23 GMT from New Zealand)
"First and foremost a Linux distro is a hobbyist system"? No, first and foremost a distro is a distro: it's a distribution of free software, published on the Internet for real people to use. Some distros take that responsibility seriously and make an effort to ensure that what they're distributing to the world is actually worth the world's time. Others follow social media's "the world needs to know what I ate for lunch!" example, and release their little hobbyist systems as "distros", claiming for them the same status as the likes of Debian, rather than keeping them as the personal hobbies that they ought to have remained.
If you've made a snazzy new wallpaper, share it on a wallpapers site. If you've swapped a few packages out of a proper distro's selection of tools, blog about it, if you must. Just don't waste everyone's time by making a few changes and slapping a new wallpaper on it and calling it a "distro".
52 • @51 Simon (by vmclark on 2025-05-22 04:36:15 GMT from United States)
Spot on Simon!
@50Linux as a "hobbyist" I can do my taxes, keep tabs on my banks and portfolio, work on my spreadsheet. Hobbyist vs WHAT?
53 • Wow (by Woodstock69 on 2025-05-22 05:04:04 GMT from Australia)
It's been a long time since I've seen such useless arguments put forward for this and that.
Just remember; Linux =/= Windows, and before Windows, there was UNIX.
54 • Filesystem Revamp? (by Trevor on 2025-05-23 06:16:17 GMT from Canada)
If it isn't broken - why fix it?
55 • Gobo filesystem (by Muthafckr on 2025-05-23 11:40:57 GMT from Argentina)
Whats is the problem in want to change the filesystem?. Are you guys contributing the project un some way?.
There is command to show or hide the traditional directores, it is called 'gobohide'.
56 • Changes (by Slappy McGee on 2025-05-23 18:04:43 GMT from United States)
@41 "How far back do you want to go? Christian reformation? Horse over foot? Bronze over stone? Agriculture over forage? Change for the sake of change is foolish, but if there is a genuine improvement then I support it. Great respect to my line command friends, but I'm not giving up GUI."
I deploy those sentiments from time to time. But only wrt changes I perceive as an advancement from the old way(s). This Gobo deal does not strike me as such an advancement, but only as an alternative at best.
Alternatives are fine, that is what open source developing is about, at its core. But the Gobo Filesystem solves a problem that does not exist, imo.
Number of Comments: 56
Display mode: DWW Only • Comments Only • Both DWW and Comments
| | |
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Archives |
| • Issue 1159 (2026-02-09): Sharing files on a network, isolating processes on Linux, LFS to focus on systemd, openSUSE polishes atomic updates, NetBSD not likely to adopt Rust code, COSMIC roadmap |
| • Issue 1158 (2026-02-02): Manjaro 26.0, fastest filesystem, postmarketOS progress report, Xfce begins developing its own Wayland window manager, Bazzite founder interviewed |
| • Issue 1157 (2026-01-26): Setting up a home server, what happened to convergence, malicious software entering the Snap store, postmarketOS automates hardware tests, KDE's login manager works with systemd only |
| • Issue 1156 (2026-01-19): Chimera Linux's new installer, using the DistroWatch Torrent Corner, new package tools for Arch, Haiku improves EFI support, Redcore streamlines branches, Synex introduces install-time ZFS options |
| • Issue 1155 (2026-01-12): MenuetOS, CDE on Sparky, iDeal OS 2025.12.07, recommended flavour of BSD, Debian seeks new Data Protection Team, Ubuntu 25.04 nears its end of life, Google limits Android source code releases, Fedora plans to replace SDDM, Budgie migrates to Wayland |
| • Issue 1154 (2026-01-05): postmarketOS 25.06/25.12, switching to Linux and educational resources, FreeBSD improving laptop support, Unix v4 available for download, new X11 server in development, CachyOS team plans server edtion |
| • Issue 1153 (2025-12-22): Best projects of 2025, is software ever truly finished?, Firefox to adopt AI components, Asahi works on improving the install experience, Mageia presents plans for version 10 |
| • Issue 1152 (2025-12-15): OpenBSD 7.8, filtering websites, Jolla working on a Linux phone, Germany saves money with Linux, Ubuntu to package AMD tools, Fedora demonstrates AI troubleshooting, Haiku packages Go language |
| • Issue 1151 (2025-12-08): FreeBSD 15.0, fun command line tricks, Canonical presents plans for Ubutnu 26.04, SparkyLinux updates CDE packages, Redox OS gets modesetting driver |
| • Issue 1150 (2025-12-01): Gnoppix 25_10, exploring if distributions matter, openSUSE updates tumbleweed's boot loader, Fedora plans better handling of broken packages, Plasma to become Wayland-only, FreeBSD publishes status report |
| • Issue 1149 (2025-11-24): MX Linux 25, why are video drivers special, systemd experiments with musl, Debian Libre Live publishes new media, Xubuntu reviews website hack |
| • Issue 1148 (2025-11-17): Zorin OS 18, deleting a file with an unusual name, NetBSD experiments with sandboxing, postmarketOS unifies its documentation, OpenBSD refines upgrades, Canonical offers 15 years of support for Ubuntu |
| • Issue 1147 (2025-11-10): Fedora 43, the size and stability of the Linux kernel, Debian introducing Rust to APT, Redox ports web engine, Kubuntu website off-line, Mint creates new troubleshooting tools, FreeBSD improves reproducible builds, Flatpak development resumes |
| • Issue 1146 (2025-11-03): StartOS 0.4.0, testing piped commands, Ubuntu Unity seeks help, Canonical offers Ubuntu credentials, Red Hat partners with NVIDIA, SUSE to bundle AI agent with SLE 16 |
| • Issue 1145 (2025-10-27): Linux Mint 7 "LMDE", advice for new Linux users, AlmaLinux to offer Btrfs, KDE launches Plasma 6.5, Fedora accepts contributions written by AI, Ubuntu 25.10 fails to install automatic updates |
| • Issue 1144 (2025-10-20): Kubuntu 25.10, creating and restoring encrypted backups, Fedora team debates AI, FSF plans free software for phones, ReactOS addresses newer drivers, Xubuntu reacts to website attack |
| • Issue 1143 (2025-10-13): openSUSE 16.0 Leap, safest source for new applications, Redox introduces performance improvements, TrueNAS Connect available for testing, Flatpaks do not work on Ubuntu 25.10, Kamarada plans to switch its base, Solus enters new epoch, Frugalware discontinued |
| • Issue 1142 (2025-10-06): Linux Kamarada 15.6, managing ZIP files with SQLite, F-Droid warns of impact of Android lockdown, Alpine moves ahead with merged /usr, Cinnamon gets a redesigned application menu |
| • Issue 1141 (2025-09-29): KDE Linux and GNOME OS, finding mobile flavours of Linux, Murena to offer phones with kill switches, Redox OS running on a smartphone, Artix drops GNOME |
| • Issue 1140 (2025-09-22): NetBSD 10.1, avoiding AI services, AlmaLinux enables CRB repository, Haiku improves disk access performance, Mageia addresses service outage, GNOME 49 released, Linux introduces multikernel support |
| • Issue 1139 (2025-09-15): EasyOS 7.0, Linux and central authority, FreeBSD running Plasma 6 on Wayland, GNOME restores X11 support temporarily, openSUSE dropping BCacheFS in new kernels |
| • Issue 1138 (2025-09-08): Shebang 25.8, LibreELEC 12.2.0, Debian GNU/Hurd 2025, the importance of software updates, AerynOS introduces package sets, postmarketOS encourages patching upstream, openSUSE extends Leap support, Debian refreshes Trixie media |
| • Issue 1137 (2025-09-01): Tribblix 0m37, malware scanners flagging Linux ISO files, KDE introduces first-run setup wizard, CalyxOS plans update prior to infrastructure overhaul, FreeBSD publishes status report |
| • Issue 1136 (2025-08-25): CalyxOS 6.8.20, distros for running containers, Arch Linux website under attack,illumos Cafe launched, CachyOS creates web dashboard for repositories |
| • Issue 1135 (2025-08-18): Debian 13, Proton, WINE, Wayland, and Wayback, Debian GNU/Hurd 2025, KDE gets advanced Liquid Glass, Haiku improves authentication tools |
| • Issue 1134 (2025-08-11): Rhino Linux 2025.3, thoughts on malware in the AUR, Fedora brings hammered websites back on-line, NetBSD reveals features for version 11, Ubuntu swaps some command line tools for 25.10, AlmaLinux improves NVIDIA support |
| • Issue 1133 (2025-08-04): Expirion Linux 6.0, running Plasma on Linux Mint, finding distros which support X11, Debian addresses 22 year old bug, FreeBSD discusses potential issues with pkgbase, CDE ported to OpenBSD, Btrfs corruption bug hitting Fedora users, more malware found in Arch User Repository |
| • Issue 1132 (2025-07-28): deepin 25, wars in the open source community, proposal to have Fedora enable Flathub repository, FreeBSD plans desktop install option, Wayback gets its first release |
| • Issue 1131 (2025-07-21): HeliumOS 10.0, settling on one distro, Mint plans new releases, Arch discovers malware in AUR, Plasma Bigscreen returns, Clear Linux discontinued |
| • Issue 1130 (2025-07-14): openSUSE MicroOS and RefreshOS, sharing aliases between computers, Bazzite makes Bazaar its default Flatpak store, Alpine plans Wayback release, Wayland and X11 benchmarked, Red Hat offers additional developer licenses, openSUSE seeks feedback from ARM users, Ubuntu 24.10 reaches the end of its life |
| • Issue 1129 (2025-07-07): GLF OS Omnislash, the worst Linux distro, Alpine introduces Wayback, Fedora drops plans to stop i686 support, AlmaLinux builds EPEL repository for older CPUs, Ubuntu dropping existing RISC-V device support, Rhino partners with UBports, PCLinuxOS recovering from website outage |
| • Issue 1128 (2025-06-30): AxOS 25.06, AlmaLinux OS 10.0, transferring Flaptak bundles to off-line computers, Ubuntu to boost Intel graphics performance, Fedora considers dropping i686 packages, SDesk switches from SELinux to AppArmor |
| • Issue 1127 (2025-06-23): LastOSLinux 2025-05-25, most unique Linux distro, Haiku stabilises, KDE publishes Plasma 6.4, Arch splits Plasma packages, Slackware infrastructure migrating |
| • Issue 1126 (2025-06-16): SDesk 2025.05.06, renewed interest in Ubuntu Touch, a BASIC device running NetBSD, Ubuntu dropping X11 GNOME session, GNOME increases dependency on systemd, Google holding back Pixel source code, Nitrux changing its desktop, EFF turns 35 |
| • Issue 1125 (2025-06-09): RHEL 10, distributions likely to survive a decade, Murena partners with more hardware makers, GNOME tests its own distro on real hardware, Redox ports GTK and X11, Mint provides fingerprint authentication |
| • Issue 1124 (2025-06-02): Picking up a Pico, tips for protecting privacy, Rhino tests Plasma desktop, Arch installer supports snapshots, new features from UBports, Ubuntu tests monthly snapshots |
| • Issue 1123 (2025-05-26): CRUX 3.8, preventing a laptop from sleeping, FreeBSD improves laptop support, Fedora confirms GNOME X11 session being dropped, HardenedBSD introduces Rust in userland build, KDE developing a virtual machine manager |
| • Issue 1122 (2025-05-19): GoboLinux 017.01, RHEL 10.0 and Debian 12 updates, openSUSE retires YaST, running X11 apps on Wayland |
| • Issue 1121 (2025-05-12): Bluefin 41, custom file manager actions, openSUSE joins End of 10 while dropping Deepin desktop, Fedora offers tips for building atomic distros, Ubuntu considers replacing sudo with sudo-rs |
| • Issue 1120 (2025-05-05): CachyOS 250330, what it means when a distro breaks, Kali updates repository key, Trinity receives an update, UBports tests directory encryption, Gentoo faces losing key infrastructure |
| • Issue 1119 (2025-04-28): Ubuntu MATE 25.04, what is missing from Linux, CachyOS ships OCCT, Debian enters soft freeze, Fedora discusses removing X11 session from GNOME, Murena plans business services, NetBSD on a Wii |
| • Issue 1118 (2025-04-21): Fedora 42, strange characters in Vim, Nitrux introduces new package tools, Fedora extends reproducibility efforts, PINE64 updates multiple devices running Debian |
| • Issue 1117 (2025-04-14): Shebang 25.0, EndeavourOS 2025.03.19, running applications from other distros on the desktop, Debian gets APT upgrade, Mint introduces OEM options for LMDE, postmarketOS packages GNOME 48 and COSMIC, Redox testing USB support |
| • Issue 1116 (2025-04-07): The Sense HAT, Android and mobile operating systems, FreeBSD improves on laptops, openSUSE publishes many new updates, Fedora appoints new Project Leader, UBports testing VoLTE |
| • Issue 1115 (2025-03-31): GrapheneOS 2025, the rise of portable package formats, MidnightBSD and openSUSE experiment with new package management features, Plank dock reborn, key infrastructure projects lose funding, postmarketOS to focus on reliability |
| • Issue 1114 (2025-03-24): Bazzite 41, checking which processes are writing to disk, Rocky unveils new Hardened branch, GNOME 48 released, generating images for the Raspberry Pi |
| • Issue 1113 (2025-03-17): MocaccinoOS 1.8.1, how to contribute to open source, Murena extends on-line installer, Garuda tests COSMIC edition, Ubuntu to replace coreutils with Rust alternatives, Chimera Linux drops RISC-V builds |
| • Issue 1112 (2025-03-10): Solus 4.7, distros which work with Secure Boot, UBports publishes bug fix, postmarketOS considers a new name, Debian running on Android |
| • Issue 1111 (2025-03-03): Orbitiny 0.01, the effect of Ubuntu Core Desktop, Gentoo offers disk images, elementary OS invites feature ideas, FreeBSD starts PinePhone Pro port, Mint warns of upcoming Firefox issue |
| • Issue 1110 (2025-02-24): iodeOS 6.0, learning to program, Arch retiring old repositories, openSUSE makes progress on reproducible builds, Fedora is getting more serious about open hardware, Tails changes its install instructions to offer better privacy, Murena's de-Googled tablet goes on sale |
| • Issue 1109 (2025-02-17): Rhino Linux 2025.1, MX Linux 23.5 with Xfce 4.20, replacing X.Org tools with Wayland tools, GhostBSD moving its base to FreeBSD -RELEASE, Redox stabilizes its ABI, UBports testing 24.04, Asahi changing its leadership, OBS in dispute with Fedora |
| • Issue 1108 (2025-02-10): Serpent OS 0.24.6, Aurora, sharing swap between distros, Peppermint tries Void base, GTK removinglegacy technologies, Red Hat plans more AI tools for Fedora, TrueNAS merges its editions |
| • Full list of all issues |
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
| Random Distribution | 
StartOS
StartOS was an independent Chinese Linux distribution with the GNOME desktop tweaked to resemble Microsoft Windows XP. In the beginning it was based on Ubuntu, but starting from version 4.0 it adopted custom package management (called YPK) and system installer, though the underlying live medium was still built using Ubuntu's Casper tool.
Status: Discontinued
|
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
|
• 
• 
• 
• 
• 
• 
• 
