Why is the linux file structure so retarded?

Why is the linux file structure so retarded?
On windows you have "user" for , well, user-specific shit, "programs" for installed applications, and then system folders like "driver" and "windows". That's it. Makes perfect sense.
On linux it is retarded clusterfuck.

Attached: loonix.jpg (474x237, 16K)

Other urls found in this thread:

en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
sta.li/
twitter.com/SFWRedditVideos

Linux is a kernel.

Your mother is a whore.

I don’t get it either. It’s not logical or intuitive, it’s just crap and yet people defend it. It’s generally much easier to find things in windows with the fewer and more logically named folders

en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

You are a snf

If you build programs from the source code then all the files will be in the build folder.

Attached: silence.png (735x544, 474K)

When you install something in windows, it asks where you want it installed. Why the fuck doesn’t Linux do this?

Yes and on Linux you have the 'bin' folder for software executables, 'lib' and 'lib64' for the libraries, 'etc' for random files like icons, the rest are for the system or mounted devices and the 'home' folder for users files. That's the overall basics, in others words you are a brainlet that should stay in windows

Y-yeah.
>/bin
>/sbin
>/usr/bin
>/usr/sbin
>/usr/local/bin
>/usr/local/sbin
>/lib
>/lib64
>/usr/lib
>/usr/lib64

Even my mentor calls the operating system Linux, stop being a massive fag.

I find it really confusing how Linux splits /usr and non /usr stuff. It seems kind of random whether something ends up in /bin or /usr/bin.

>C:\
>C:\Program Files\
>C:\Program Files (x86)\
>C:\SYSTEM
>C:\Windows
>C:\Windows\Sys32
>C:\User

The 'usr' is when a program installs per user instead of system wide just like windows %appdata% folder, and 'sbin' is for system executables

>>/bin
vital programs
>>/sbin
vital sysadmin programs
>>/usr/bin
nonvital programs
>>/usr/sbin
nonvital sysadmin programs
>>/usr/local/bin
systemwide user-created scripts
>>/usr/local/sbin
systemwide user-created sysadmin scripts
>>/lib
vital libraries
>>/lib64
vital 64-bit libraries
>>/usr/lib
nonvital libraries
>>/usr/lib64
nonvital 64-bit libraries

I don't see what's confusing about this

Pretty much all your programs will be right under C or whatever you install them to. Maybe sometimes you have to edit a config in program files. That’s really all there is. You are really stretching by including the system or windows folders that hold hardly anything of relevance you would need to access on a regular basis

>The 'usr' is when a program installs per user instead of system wide
That's not it at all, programs that install per-user install to ~/.local. Files that can be safely stored on another partition without compromising the system's ability to run when that partition is unmounted belong on /usr. In other words, it's for installed programs and files that the system uses, but "doesn't need." /usr/local is for programs and files the system doesn't even use, that users use instead, and /opt is the same thing, but with the implication that the programs and files in question specifically were not written or built on the system in question. Or, more intuitively, /usr/local is for user scripts and utilities, and /opt is for shit like vidya.

You say “programs” as if a the files of a program will be stored there, but really it’s just usually one one TYPE of file for the program. On Linux the files for a program will be spread out all over the system in a really confusing way. It just feels like in windows you can easily find pretty much all the relevant files of the program in one folder.

>You say “programs” as if a the files of a program will be stored there,
I don't see how what I said implies that in any way.
The programs are stored where I said they're stored. The files for the programs are stored in the other places.
I guess I just don't consider the files that a program uses to be files "of" those programs the way you do. To me, the only file "of" a program is the executable. If it:s not the executable, it's not "the program"; it's either a library, a config file, a logfile, etc.

>pretty much all of your programs will be under '/'
ok retard

Have of these just simlink to others in most distros though.

It *is* kinda hard to defend

Thanks for the tip

I like modding games a lot and changing settings for programs I use, which requires a lot of switching and editing files, so to me it’s really annoying that Linux has a hard time putting all the stuff in basically one folder. To me the executable is hardly even relevant to find because you could just create a shortcut or search it. IMO Linux makes it a lot more annoying to find relevant configuration files and to make them point to the right place. Often on windows you can even just drag mods onto the exe, not really a big thing in linux

Different philosophies.

Windows keeps software packages isolated. All the files for a program are in one place because the program is considered a disjoint and self-contained item Windows is being used to run, not an integrated part of Windows.

Linux doesn't maintain the same kinds of firm boundaries between the operating system and its programs. On Linux, the program's files are spread across the system because the program isn't a self-contained item, it's an integrated layer grafted onto the system to extend its functionality at a fundamental level.

This is also why on Linux it's more common to pipe stdio between utilities. They're not self-contained programs, they're tools, meant to be used together and expand upon each other.

Some programs are still self-contained where appropriate. Mostly you'll find them in /opt, and, to a lesser extent, /usr/local.

I don't see why it would be an issue for modding things, since everything *is* in one place prior to building from source

because the kernel, which is Linux, doesn't care where programs are installed

Finally someone rational here.

>Have of these just simlink to others in most distros though.
Yeah, the *64 ones, I know. That's appropriate for multilib support.
I can also see how /usr/sbin might be linked to /sbin, if a distro happens to have the philosophy that all sysadmin utilities should be considered vital.

>installing a program on windows
>it asks you the location where you want to install. By default it’s probably in program files but you can put it wherever the fuck you want for easy organization
>installs pretty much all the files with the program in the location you choose
>occasionally other files get created in places like appdata but they aren’t that hard to find

There’s no way you can say it’s as messy as Linux. On windows you can choose the location and it just dumps it all there for you in one convenient package.

only nonretarded

Windows is for retarded people that can't use a computer properly.
If you can fucking read, just go into the goddam wiki and install the program where you want, you can do whatever you want on Linux.

Reminder that unix is a a failed multics
This is why every copy of it including loonex will be an even more washed-out failure
72768925
holy cringe that seethe

If you are talking about games then their files are usually in your home folder, not in the root.

So I can install everything on Desktop and it'll be fine?

If you want.

Whose way is better, though?

This is also why Windows programs mostly only ever depend on Windows core libraries, and the only dependencies you ever have to install are older or newer versions of those libraries, while in Linux, anything can reasonably depend on anything else. Which is in turn why Linux needs a package manager and Windows doesn't. Or rather, Windows does have a package manager built-in, but, as you might expect from this explanation, the only packages offered are different versions of Windows core libraries.

Yeah, and the installer never checks if a needed library is already in the windows folder, so it just puts them in the program folder and you end up with hundreds of repeated libraries that bloat the os

The one you want, depends if you are retarded or not.

Your mentor is clearly used to talking at a lower level the retards they mentor are capable of understanding.

Attached: codebarian.jpg (724x805, 136K)

Appropriate for different purposes. Linux way is more convenient for developers and allows more sophisticated software to be developed easily by building off each other's backs. Windows way is more convenient for users, and appropriate for proprietary software, whereby developers are only allowed to piggyback off the efforts of businesses they have special agreements with anyway, and have to do everything else from scratch every time, but it's okay because they have more than enough manpower and funding to do just that.

Windows isn’t for retards, the file system is generally a more intuitive way of organizing data. If you want to edit a program it makes sense you would open a folder for that program, as opposed to a configurations folder that contains editing files for all your programs. Windows folders are generally organized by top down importance from hardware -> software -> software data.

GoboLinux doesn't have this problem.

To download the latest version of a program for windows all you have to do is download a zip file. On Linux you probably will need a lot of other shit too because they have dependencies on a bunch of other folders.

Oh, yeah thats true, windows programms doesnt need fucking 300 different versions of the .net framework or some shitty directX nigger program.

Distros with package managers don't have this problem.

Anyway, to write a new feature into your program on Windows you have to manually download FOSS DLLs and/or make business deals. On Linux you can just require that the necessary libraries are installed, expect to find them at their proper paths in the system, and, like magic, so it shall be.

Problem for me is, it never seems immediately obvious where everything is. After immediately installing a program, could you instantly say where the executable, configs, saves, scripts, models are all located? You are probably going to end up having to search to find their exact locations because it never seems totally consistent per program.

And which Linux programs are stored in /lib?

>could you instantly say where the executable
use the where command
>configs, saves, scripts, models
read the man page

>could you instantly say where the executable,
use which
>configs,
if the output of which starts with /bin they'll be in /etc
if the output starts with /usr/bin they'll be in /usr/share
if the output starts with /usr/local/bin they'll be in /usr/local/share
if the output starts with ~/.local/bin they'll be in ~/.local/share
>saves,
hidden directory in your home
>scripts, models
usually same place as configs

Actually on Windows you have everything, everywhere, usually split in a million places that the user isn't supposed to be looking at and most software is going where the fuck it pleases. My disgust with the windows file system and the fact that most programs have more rights and information about the system than the user was the first that made me consider Linux. There is no actual hierarchy for software in Windows.

whereis shows where the configs are and where the binary is

There is hierarchy but it’s all in the software folder. Like you go into the folder for “Skyrim” and within that folder are other folders for stuff like “mods”, “data”, “sound files”, etc. I think it’s a more logical hierarchy.

Not mother, but GNU/Mother

/bin for binaries, /lib for libraries, /usr for user-specific files, /mnt for mounted storage, /man for manpages etc etc

And then what about /opt, for “optional software packages?” Why are those not in the same place as “nonvital programs?”. That is confusing.

Because /usr is for nonvital programs the system is configured to use. /opt is for nonvital programs for the user to use, that the system doesn't care about. Additionally, programs in /opt should be self-contained, per the Windows philosophy, as opposed to /usr/local, which serves the same purpose but for programs which may be interdependent.

Nice thing buddy, and how's your 8 bit OS going? Are you able to create folders that are not DOS compliant yet?

>Windows isn’t for retards
No, it's by retards. Quite a difference.

>"programs" for installed applications
there exist linux distributions which do this, consider gabolinux for example
either way programs/ is bad
gets it, windows programs tend to be more "one program" than a lot of linux ones, which are meant to work with others.

add ~/Desktop/ to your $PATH
add it to ld directories for libraries too
thats it you sperg

>C:\Games is very important
>C:\Users\Name\AppData\Local\Company is unimportant

>executable
~/local/share/steam/steamapps/common/game/bin/
>configs
~/local/share/steam/steamapps/common/game/bin/
>scripts
~/local/share/steam/steamapps/common/game/bin/
>models
~/local/share/steam/steamapps/common/game/bin/

the kernel defines what OP said retard

you are fucking retarded

Civilized men are more discourteous than savages because they know they can be impolite without having their skulls split, as a general thing.

Attached: 1568646605186.jpg (724x805, 301K)

Let's all pretend this isn't an issue for both Windows and Linux and that shit doesn't end up all over the place based on arbitrary reasons.

based but linux is still an operative system and the kernel itself define how programs are written and how the file system works

The Unix File System standard is archaic. It's based on technological limitations in the 90s, but pretty much all of the justifications for the various folders have been eliminated by updated software.

Distributions such as Nixos and Gobolinux prove that the file system standard is an archaic bloated mess.

However, the alternative is a massive effort to restandardize. Linux is much bigger than it was in the 90s, so getting authors to convert their programs to a more sane standard (such as all installed packages, including configuration files, being included in the same /programs directory, is a much more daunting task.

For now, you should use a distro such as Nixos, and compile software yourself if it isn't in the distro's repos, to maintain sane file system standards on your personal computers.

“There is a reason why things are the way they are”
This is something I hear constantly, often followed by an explanation about the difference between /, /usr and /usr/local, and/or /bin and /sbin. I do understand the difference1. If I did away with this three-level distinction, is because I believe there are other ways to approach the problems this distinction tries to solve. In a GoboLinux system, the argument for having separate /usr and /usr/local trees in order to separate programs shipped by the distribution and compiled by the user clearly does not hold. Each program is naturally separated, and this was the prime intention of creating GoboLinux in the first place.

The historical reason why Unix systems have some of its tree directly at the root partition (/bin, /lib, /sbin) as opposed to having it under /usr, is because this way you can boot in a bare-bones single-user rescue mode using those files only, in order to fix problems in the /usr tree. This is arcane. When I need to rescue my system, I can use a fully-featured live CD that runs a complete Linux distribution with a graphical desktop, that allows me to browse the web and search for the solution to my problem, and use all of the features of a regular system to fix it. I understand the rationale for having a bare-bones rescue mode decades ago, but we have a better solution in our hands now.

The distinction between bin and sbin makes no sense, in the present context. Historical evolution led to crazy arbitrary distinctions, like ping and traceroute lying in different directories (I fail to see how can they be of distinct “program classes”, by any measure). Unix systems have a permissions system. If one wants only the superuser to be able to run a command, then chmod 700 it. I suspect the separation could have been conceived to reduce the number of programs in the $PATH of regular users. In today's Linux systems, having 400 or 500 programs in your $PATH, does not make any difference.

There is one last argument, however, that is still valid for Linux systems to day: partitioning and remote mounting. Those two are really different shades of the same color, with remote mounting being, to my eyes, the most valid concern of those two. I've seen arguments about this among the lines of “hard drives today are cheap, and you'll most likely have all software installed locally anyway, for performance”. I agree with this, but I also understand the ones who'd like to maintain things centralized for administrative purposes. But imposing additional complexity on the overall system because of one particular scenario is usually not a good thing, and even then, the traditional Unix solution is not general enough: what if you have three or four application servers? You'll mount one at /usr, one at /opt, and then what? There goes the traditional Unix tree. In fact, in most of the larger Unix networks I had contact with, particular needs of the site configuration led to non-standard directories added to the Unix tree.

Fortunately, like with the live CD, we have nowadays a technological advancement that serves as a real solution to the problem: union mounts, also known as overlay filesystems. The idea is that you can mount several partitions in the same directory. This way, the semantics of /Programs as “the collection of all programs available in the system” is retained, independently of the physical location of the actual data. File systems are all about abstraction (we don't refer to files based on their track, sector and cylinder address), this progresses a step further. Overlay filesystems are very flexible: the sysadmin, for example, can overlay site-specific settings for an application on top of the defaults exported over NFS. Unfortunately, it is not in widespread use, for reasons beyond my understanding. The Plan 9 operating system has it as one of its basic filesystem operations: the bind command (in Plan 9, for example, you don't need a $PATH variable, because all directories containing executables are “bound” in a single directory). There is an implementation of an overlay filesystem for Linux: ovlfs.

Y'all fucks don't know about stalli or what? Just because Ubuntu does it wrong doesn't mean you're not free to do it better. All the binaries in a single folder. All the bloat in a separate folder. Like God intended.

sta.li/

Gatekeeping to keep fagcopters like you outside.

>using a two years out of date distro that isn't actively maintained anymore.

Try actually going in your windows folder and check the mess that the thing actually is.
Then as a bonus, open your regedit.

Oh yes OP, the linux users are retarded, they don't see how simple and well organized the windows fo...

Attached: windows folder.png (377x484, 30K)

this doesn't reflect on organization though.

>C:\
Nobody's installed programs there since 3.1, unless you're an idiot.
>C:\SYSTEM
Doesn't exist, idiot.
>C:\Windows
>C:\Windows\Sys32
People don't install programs in the former, and the latter doesn't exist, idiot.

I don't get it.
>download source code
>compile in the folder
>all the files stay in the folder
Honestly, its just like windows. the only way files go everywhere is if you download from the software manager

Attached: (You).png (256x307, 95K)

spbp

And the filesystem structure is apart of the kernel

based Rin

That would be so fucking retarded. Install on /tmp plz

Finally a good answer.

Which is why sane distros implement usrmerge and symlink /bin to /usr/bin

> C:\a\fucking\backlash
you think this is not retarded?

This, \ is fucking retarded

The most retarded thing about it is that it was a last minute change to DOS 2.0 for backwards compatibility with DOS 1.0, which uses forward slashes for command switches. Windows has been compromised for backwards compatibility since DOS 2.0.

>It’s not logical or intuitive, it’s just crap
It may not be intuitive, and it's largely redundant now, but it was perfectly logical for the purpose for which it was designed: separating files into categories that enable them to be stored on different filesystems.

People that complain about it as if it served no purpose just show their ignorance. The ability to have different filesystems mounted at /bin /var /home etc may not seem useful now in the average use case, but at the time it was pretty damn important, especially if you were network booting a lot of workstations.

Linux is a cluster fuck, we all know it.

classic windows users not understanding anything

>hurr durr its different so automaticly retarded
>im too fucking dumb to learn something new
and since you talk about serching for stuff find me all .jpg files in windows which are larger than "a" but smaller than "b" which names contain "c". no? thought so

then he's a retard

The point is that it no longer serves a purpose. It’s why stuff like windows came along in the first place to present a file structure that made sense for the average use case and not a business organization or server. As you say, how it is on Linux is largely redundant now, so why do we still have to use it?

Redpill me on nixos