And network management >/Resources/Network/Mounted ||Domain1 ||Domain2/System ||etc...
Directory name length need not bee an issue for serious sysadmins & devs, these standard names could be shortened to "sys" & "app" & "dev" & "cfg" etc.. as long as everything is isolated but centralized at the same time to promote security while similarly increasing user-friendlyness with substituted name length aliases through optional packages that edit the central system settings.
Also options for a virtual file system that create symlinks and virtually merged directories so that you can create a root folder like /Devices that point directly to a merge of /System/Devices & for each "/Devices" in /Resources/Shared/Network/DomainName/System
The amazing possibilities for a SANE and well thought out file hierarchy are endless and can be improved and innovated but no. We're stuck with the same old posix hierarchy crap from the past. We have retarded stuff like
/usr/local/share/.kde3/opt/config/menu.list while another file is littered ALL OVER THE HOME FOLDER like /home/user/.kde3/opt/config/menu.list and other obscure sewers of the system like /etc/kde and get left behind after bad package management.
Package Managers, Security and Broken systems from updates setting changes are not really the big problem of themselves, shitty file hierarchy philosophies are
You are not allowed to talk negatively about Linux here.
Luis Morales
because you don't know enough about operating systems to appreciate this elegant layout.
the reason windows can conflate unrelated things is because they have a really shitty solution called the Registry™, which is the primary reason why windows crashe(ed)s all the time, and why you have to reboot it constantly just to keep it running
Kayden Sanders
and also why you have to wipe and reinstall the whole OS every 6 months to a year just to keep it as performant as the day you installed it.
unix like OSes don't have these problems because they don't use a registry
Gavin Hall
Sound like it's better if you step away from he GNU/Linux distros and go back to Windows.
Nolan Reed
It's too late you can't change it, we're stuck this way
Liam Perez
because people just kept bolting on stuff all the time and we're now stuck with this the shells are awfully inelegant too at least we have most stuff in a well-defined place though
Brandon Mitchell
"Resources"? Why stop there? Why not "PiecesOfDataThatMightBeAPointOfFrustrationToThePersonTypingAPath"?
John Powell
tab completion makes this a non-issue
Adam Anderson
/usr was only ever meant to be what /home is now it's still beautiful
Josiah Nelson
you still have unreadable crap as paths
just use windows if you want to use windows
Michael James
A lot of the mess comes from the late 70s and 80s, when the FHS had to account for some stuff that's not much seen today.
One, splitting a bunch of shit out into separate filesystems. What do you use separate FSes for today? Usually just /home, and /boot iff you're using full-disk encryption. That's pretty much it/. Way back when /usr, /var, /tmp, and some others would be on different disks. Both because disks then were tiny and slow, and because some of this stuff they wanted to use NFS mounts for, because having each system keeping its own copy of /usr was wasteful, don't you know.
Two, different architectures. Nowadays there's x86 and a few flavors of ARM and that's 99.9% of everything. Olden days you might have mips and sparc and alpha and others all in one shop. And some of the dirs were split up along the lines of "shared within one architecture" and "shared across architectures", again to enable them to keep the fewest copies of shit between systems, because disks were small and expensive.
Third, some of it was just a kludge. /media really doesn't need to be around, strictly speaking, but some people used /mnt for mounting things instead of /mnt/subdirectory, and I think there was some permissions fuckery too. So they just added a new directory.
Then again if you think this is bad have a look around the corners of a Windows installation directory, it looks positively organized by comparison.
Jonathan Rivera
less is more
Andrew Diaz
Tell me what's wrong with Registries and what's wrong with the layout I suggested. I want to see the reasons in detail. I've googled shit but all they come up with is stupid crap like "because it's terse better to dump shit all over the place to improve security and stability"
Jose Williams
grub can boot from an encrypted boot partition now not that there's much point
Ethan Walker
There's no point in longer then necessary names if all you do is memorize the first three letters and whack TAB. More elegant to actually use these short mnemonics as names.
Luke Cook
>because they don't use a registry Prove it. And even if they do, there has to be a better solution that to dump shit all over the place and let the server accrue storage rot from bad config leftovers over time.
Maybe a centralized registry is a good idea, but the way winshit implements it is wrong. Or maybe you can still have a non-centralized configuration style like gnu/linux & other unix distros without needless dumping shit all over the world. Nix for example, excels a wee bit in this regard. But only a wee bit, because de-centralized configurations still imply storage and buggy configuration rot
Jason Thomas
it's kind of user-hostile
Thomas Barnes
using the registry is dumping shit all over the place, except you now have another layer of obscurity and you have to use a special viewer to edit settings, and every lookup is slow
if programs would actually follow the unix installation path scheme (kde doesn't) you'd know damn well where everything is
Luke Ramirez
>and let the server accrue storage rot from bad config leftovers over time. hahaha you're fucking saying that in defence of a registry
>Or maybe you can still have a non-centralized configuration style like gnu/linux it is centralized though: on linux system-wide configuration is in /etc and user-specific configuration is in /home; on unix system-wide configuration is in /lib (if i recall correctly) and user-specific configuration is in /usr
so you know where to look
Parker Hernandez
>"Resources"? Why stop there? Why not "PiecesOfDataThatMightBeAPointOfFrustrationToThePersonTypingAPath"?
Dumbass read what I wrote: >"Directory name length need not bee an issue for serious sysadmins & devs, these standard names could be shortened to "sys" & "app" & "dev" & "cfg" etc.. In the case of a default for resources you could have something like /res with a sysadmin & userfriendly virtual nametag than gives both the user and sysadmins and programs devs a better picture of the overall structure and hierarchy of where to put each files in a NEAT and ORGANIZED and EFFICIENT way. It's not even about naming, it's about efficient filing architecture and exuding an architecture that can help all types of people and programs not get confused and muddle to shit when filing things.
Also >being messy and terse is a virtue and shows how smart & devcool I am Die
Michael Rivera
Well, if you can't figure out that /dev/ is short for /device(s)/ then you shouldn't be in that directory anyway.
Connor Baker
>windows has a simpler file hierarchy than linux
Gavin Scott
>it is centralized though: on linux system-wide configuration is in /etc and user-specific configuration is in /home; on unix system-wide configuration is in /lib (if i recall correctly) and user-specific configuration is in /usr
That's not true in the LEAST. And even then, devs can't into proper filing conventions for each program they make, because they JUST CAN or have to make compromises for whatever other standard their project is trying to achieve. And even THEN, that structure is still JACKSHITTING all over the place, /usr used to be the ancient /home/user, now it seems like /home/user will just be another messy posix diareaha shitting hole for config rot
Anthony Fisher
Unix is simple, but you have to be a genius to understand its simplicity.
Zachary Murphy
Universal system resources. Learn unix you cretin.
Tyler Flores
>if programs would actually follow the unix installation path scheme (kde doesn't) you'd know damn well where everything is
Actually none of them do. The truth is devs can't be bothered to do anything properly because compromise on system, especially for large projects like KDE, is inevitable. That's why an enforced file-hierarchy policy similar to (but still eons better than) nix is the only way (even though the fact that nix's & gobolinux's file hierarchy were designed to appeal to a certain niche of file management, specifically the reduction of program breakage, not an overall reshapening for organized and neat filing for all kinds of system)
Andrew Myers
Wow nice sperging faggot.
Thomas Gonzalez
>>/Resources >>/Packages >>/System >>/Users >like windows does? You ever looked at C:\ showing hidden and system files? From the top /boot/ For bootloader files /dev/ Full of mount points for device files /proc/ Process information (You need to understand that, unlike windows, executables don't just pass info between themselves, EVERYTHING is a file) /mnt/ mounted disks /media/ removable disks /bin/, /sbin/ binaries. Essentially "Program files" and "Windows" (the windows folder/system32) /etc/ configurations /home/ your home folder /lib/ libraries /tmp/ temp files
But nah, it's be soo much better if half of them where all just stored in C:\Windows, all thrown in together without anything to seperate them, or in %appdata%
Lincoln Morgan
>>Why can't it just have in the root fs >>/Resources >>/Packages >>/System >>/Users Because I guess Linux decided to mostly flatten the directories right under those into /
It would be /System/Root/Binaries, but it's /sbin It would be /System/Users/Binaries, but it's /bin
Thing is, this is easier to work with regardless of it not being absolutely perfect.
But if it triggers your autism, there are Linux distributions that have a different structure.
That said, Windows' approach is a dumb mess because it doesn't even have folders collecting binaries and libraries, and no it also doesn't really do Resources folders. You never ever want that.
Bentley Rivera
so you want another layer of magic that is non-intuitive and strange to new users
anyway, here's a better unix than unix
/amd64 amd64 root bin amd64 binaries boot amd64 boot files include amd64 headers lib amd64 libraries misc misc installed program files /arm64 arm64 root bin arm64 binaries boot arm64 boot files include arm64 headers lib arm64 libraries misc misc installed program files ... /dev "device" file handles /proc process file handles /n network mounts & local mounts /sys config system-wide config directory include portable headers log system log files man manual pages src operating system source code /tmp temporary files /usr user directories someone user directory config user config directory someoneelse as above config
Owen Garcia
That's fucking garbage.
Luke Smith
Because people still think /usr/ means "User"
Jordan Johnson
>/usr/dmr >/usr/ken
that's the fault of morons like freedesktop who don't follow the conventions
It doesn't matter at all what you use to remember the path as long as you know what it's function is. "user", "loser", "ur mom'. It's all fine.
Joseph Harris
t. >retards who think I like or am defending windows at all by just pointing out a user-friendly something >NEETS who get so easily tr0ggered when someone points out a flaw in a os that happens to be the center of their cringeworthy fanboism >filthy sodomite propoganda
Really no point discussing legit anything with morons.
Or better yet subdirectories under common objects?
It's now time for you to shut up and build a distro with your proposed directory layout. If it's indeed superior it'll be adopted everywhere and your problem is solved. No need to shit on Sup Forums.
Chase Gomez
Way too many subdirectories IMHO, it looks like a retarded OOP inheritance hierarchy.
Caleb Ward
Threads like this make me sad that brainlet scum like op actually exist
Angel Martin
So much under /System/ you might as well, ya know, just make it root? Because, in linux, root is your system? >Great. Let it stay that way without installed packages and the system itself UNLOADING JUNK ALL OVER THE HOME FOLDER. This isn't a problem with the structure, they have /bin/ for user system binaries, /urs/ for userland binaries, docs, libraries, all that shit, but they still choose to puke all over /home/. This isn't linux's fault, this is devs never deciding which paradigm to use, getting confused, and ending up fucking their sisters instead.
Adrian Murphy
maybe you should THINK before posting suggestions
anyway, you're just mainly renaming unix paths. you were moaning about the hierarchy, but now supposedly it's just that you're bothered seeing "sys" rather than "System" because you're a lennartcunt and need to die
Lucas Johnson
>build a distro
Great. How? LFS?
How do I ensure compatibility between packages and my changes to the file-hierarchy & filesystem
Anthony Foster
what, do you think you'll be installing deb packages or something
Honestly I don't see anything brainlet about this. It's kind of shitty that any package can shit all over every directory it feels like including the user folder. I thought my user folder is mine? Since when was it a garbage dump for bad coders who couldn't into basic protocol?
Carter Reyes
p.s. this fucking shit where you have /bin, /usr/bin, /usr/local/bin has to end. all it is is a crusty stinky relic from when some third-party company started making ill-considered changes to unix.
David King
where would you prefer programs put your configuration data? what if there's something sensitive in the configurations that you don't want another user to see?
Alexander Myers
Wouldn't an ownership local chmod into some user specific config file in the package directory be enough?
What about a user specific config directory where they can at least tell where they want to shit all over instead of dumping dot.asdf and other shit into my home and music folders?
Noah Brown
>like windows does
>32bit libs are in C:\Windows\SysWOW64 >64bit libs are in C:\Windows\system32
>two separate user folders because legacy >C:\Users >C:\Documents and Settings
Nolan King
Why? /usr/local/bin is a good idea, it's the place where you can put manually compiled stuff.
/usr/bin is managed by the package manager, and can contain the bulk of binaries.
/bin needs to be there at boot time or in rescue mode, unlike /usr/bin. I guess you could do away with it, but it's not completely meaningless either. Can make things easier if you boot a cloud machine off a microSD or such. /bin can be on the microSD that is per host, /usr/bin can be on the data cloud.
John Morgan
simply relying on permissions to keep something sensitive safe won't work. an encrypted user directory would work. so that is one advantage of having programs write their user-specific configuration to your user directory.
i do wish they'd stick it in one subdirectory like "config" though
Brody Bailey
There's a longer version of that gif
Logan Collins
you only need /bin. with namespaces, if you want something you've compiled to appear to be in /bin but don't want to copy it there (maybe you're testing a drop-in replacement for a system command or something), then you can set up a union mount between ~/bin and /bin. clean and nondestructive.
/usr (as currently used) and /usr/local are really useless
Caleb Rivera
Since you decided to install their shitty software
Fixes 90% of your problems and doesn't change all the well known paths to your retarded naming schema.
Christopher Davis
The tools to do the cloud server networking and set up the union mount would be in /bin in the first place, so no, unless you actually have /bin already you can't do your union mount.
And it doesn't belong into ~/bin at all.
> /usr (as currently used) and /usr/local are really useless Maybe. There could be another place for generally (except to the package manager and sysadmin) read-only userspace non-boot / non-rescue critical programs.
Brody Young
well you can do a filesystem hierarchy in 100 million ways. we all have opinions about how it should be done but most of them aren't worth a damn.
Adam Russell
>The tools to do the cloud server networking and set up the union mount would be in /bin in the first place, so no, unless you actually have /bin already you can't do your union mount. what? i don't think you understand namespaces.
>And it doesn't belong into ~/bin at all. what doesn't? a binary?
Jose Turner
No. There is (ultimately) one perfect way for every kind of use. We just haven't discovered it yet.
UNIX has take a step towards the one perfect way in their lowest common denominator of everything being a file. But one step is not enough.
Hunter Watson
> what? i don't think you understand namespaces File systems are namespaces that assign names to files and folders.
Either way, even if you do namespace unions inside a filesystem that's irrelevant to the need for /bin to be there when you need the tools to actually you mount /usr from the cloud storage of which you maybe then later COULD union namespace into /usr/bin or whatever.
> what doesn't? a binary? Anything systemwide. ~/bin is for the binaries the user compiles himself.
Grayson Long
>messy It's literally the most organized file hierarchy
Parker Clark
no
Jayden Powell
why are you talking about "cloud storage"?
>~/bin is for the binaries the user compiles himself. yes it is. and a way of making it appear as if your binaries are installed on the system is to bind ~/bin into the namespace as a union with /bin.
>There is (ultimately) one perfect way for every kind of use. We just haven't discovered it yet. what a fucking brainlet
Lincoln Gomez
>hidden files You're not supposed to interact with them unless you're a poweruser, and if you are then you have nothing to complain about.
Josiah Perez
that's the fault of third-party software
Carter Cook
Arch for instance cleaned this up somewhat by having all binaries in /usr/bin. The other locations need to exist as symlinks for compatibility though.
>32bit libs are in C:\Windows\SysWOW64 >64bit libs are in C:\Windows\system32
Literally who's braindead idea was this? What's worse is it has some magic going on so if you ask for system32 (same for Program Files) it could be either directory depending on what bitness the calling program is. This caused major headaches for universal installers and is why everything has two releases causing regular users to just keep using 32bit everything.
Why the fuck did they just not make system64 and call it a day?
Jonathan Allen
Can anyone tell me the difference between User Binaries and User Programs?
Also, why the fuck is the Configuration Files folder called etc?
Jace Rogers
Just use Godo.
Liam Wright
>I'll just hide them and pretend they don't exist, that w-won't cause problems and provable system productivity incorrectness in the future I h-hope
Mind of the subhuman ROTlet
Brandon Turner
There is already a solution for this
Owen Sanders
>why are you talking about "cloud storage"? Because that's one use case.
You want just /boot /bin /sbin /dev and some other things to then mount /usr/ or /home from a cloud storage. It's not local. Ever.
If it disconnects, /bin & friends need to be able to reconnect, too.
> and a way of making it appear as if your binaries are installed on the system is to bind ~/bin into the namespace as a union with /bin. Possible, but not acceptable. User accounts will NOT put anything into the shared system unless they've got root.
They can have their own priority list in the PATH "run executables without full path from ~/bin, then from /bin and then from ~/usr/bin, as I have permissions to". Simple.
Connor Thomas
>why the fuck is the Configuration Files folder called etc >can't get the clue in "etc...L Because the original UNIXtards (pbuh said the normies) said "let's dump all our garbage that we may/maynot need in here and pretend its where we store our config files"
Austin Anderson
>User accounts will NOT put anything into the shared system unless they've got root. every user shell has its own namespace
if the administrator wants to put something in the base namespace for all users he puts it in the profile to be run by all shells on startup
if a user wants something added to the namespace for all his invocations of a shell he puts it in his profile
bind [a] [b] is basically a clean analogue of PATH
Cameron Powell
Bless my nigga ROTEelle
Jayden Barnes
> if the administrator wants to put something in the base namespace for all users he puts it in the profile to be run by all shells on startup No. He changes the system binaries if necessary.
Users may maybe decide if and with what priority they want to use these in their PATH, but it's what the system runs on.
> if a user wants something added to the namespace for all his invocations of a shell he puts it in his profile Yep, they can manage their own PATHs if this is allowed on the shells they work on. Simple.
> bind [a] [b] is basically a clean analogue of PATH It's a messy mixture, nobody wants it.
This might start to work if everyone becomes a skilled Haskell programmer and they can easily define their bind as lens over a monoid over an union between these configuration objects to deal each of their user account's needs... not before.
Asher Peterson
it's been working fucking great in plan 9 and inferno for decades, and linux has union mounts too
it's a great way to solve the portability problem too, since you can just bind /$ARCH/bin as /bin (which doesn't actually physically exist on the system) on boot, very elegant
Evan Nguyen
>Yep, they can manage their own PATHs if this is allowed on the shells they work on. Simple. so in other words /usr/local/bin is useless, glad you agree
Brayden Gutierrez
Why not? This sounds perfect to me. Might install it on one of my systems to try it out.
Asher Wright
And lenses over monoids and so on have worked fucking great in haskell. Time to change Plan9, Inferno and Linux's configuration?
Linux's way is a better way to solve the actual portability problem too, you generally just don't even put files onto machines where they don't belong, by means of a package / container manager. Keeps things slim.
Levi Garcia
No, that is just where the sysadmin puts not package managered binaries (hand compiled and installed) that nevertheless are meant to be available to all users.
Justin Roberts
I move all the xonfigs of everything i install to $HOME/.config/programname/config. Its a bit of a pain, but it makes troubleshooting and ricing much easier.
Jaxson Cox
Don’t forget that wangblows has a 32 bit and 64 bit registry, as well as file systems, the entire os is basically vomit in th form of software
Blake Ramirez
>dump shit all over the place and let the server accrue storage rot ah, so you just wanted to confirm for us that you really don't know the first thing about the linux kernel or the posix root file system then. cool.
Hunter Wilson
They're hidden by default you fucking nigger, and windows does the same.
Christian Diaz
> >/Resources > >/Packages > >/System > >/Users Apple did just that. The answer is because it was developed in times when HDDs wasn't a commodity, so every HDD served as a mount point to one of those places.
Elijah Morales
>bringing your archetectuer into the filesystem
lmao this is just as bad as windows
SysWoW64 Program Files (x86)
lmao, what a cucked decision
Elijah Long
your idea is stupid. read some books about linux so that you have knowledge before speaking. please stop promoting your stupid idea. it's starting to get cringy.
Grayson Ward
just tell thunar to hide dotfiles
Jackson Howard
>Also, why the fuck is the Configuration Files folder called etc? like the other user said, it's actually the trash directory. you can just delete everything there
Ian Price
don't be so sad OP, at least your thread has something of value to discuss, most threads on this board are fanboy wars, which programming language i should learn, x language is better than y language, x os is better than y os, basically some babby-tier shit you'd learn on your first day of learning anything tech related, either those examples, or generals.
great work!
as for the thread, although your idea makes some sense, i'd avoid capital letters, I mean when you're calling cd all the time and you have to type a capital letter, it's pretty annoying, even with tabbing.
Cameron Wilson
Linux is a kernel. Unix was a system back in the 70s. Linux is neither Posix nor UNIX certified.
Liam Mitchell
Pretty much this.
BTW it's because you don't need to install the same library over and over again. Also because you can leverage a universal hierarchy taking advantage of the ecosystem while making a new software. Finally because it's a well documented "standard" and makes it really scalable and future proof.
Source: muh dick
Jonathan Reyes
>install the same library over and over again
Retard >what is legacy dependancies
Jaxson Allen
Many Linux distros symlink the /bin and /sbin directories to /usr/bin and /usr/sbin now because the root level directories are actually mostly useless on Linux where everything is a user package anyway. Those root level directories are provided for compatibility with other *nix systems.
/home was added because /usr directory was re-purposed for use as a place to store user binaries and packages.
/boot was added because storing those things in the root directory cluttered it up.
Jaxon Gomez
5 years with windows 7 and never needed it.
Matthew King
It's because if you have trouble understanding things like the file hierarchy, then you should avoid editing anything outside of /home. Seriously people have limitations and they have to learn to accept them.
Austin Wood
Several developers have proposed a Registry for Linux as well
Ethan Phillips
>Can anyone tell me the difference between User Binaries and User Programs?
Back in the olden days of UNIX /bin and /sbin were mostly used for the operating system's binaries because space was scarce on the main disk. When the UNIX devs wanted to store more of their own programs they added more disks to their system and mounted them under the /usr directory instead, which became the standard.
Jeremiah Mitchell
>being a conceited in all likelihood unix newfag Sometimes its time consuming and hard to edit files strew around the system like a plate full of cookies, shredded and tossed all over the house
