What's the frickin point?

That is what happens when you don't have a naming convention for things.

based

there is no point just one more terrible design decision they made which has rippled through many generations of windows

seamless compatibility
contrary to linux, windows (at least up to the 8th version, windows 10 is a fucking mess) actually cares about userland and old shit _must_ work

Not OP, but why couldn't they just fucking kept them in 1 dir?

why is one x86 when the other directory is also for x86 (just the amd64 subset)?

You should ask the same thing about linux

>want to change hosts file on linux
>nano /etc/hosts
>want to change hosts file in windows
>notepad C:\users\\windows\system32\drivers\etc\hosts

they're both easy as all fuck. Don't make it out to be some kind of huge annoyance

Nano sucks
It does its job, but it's a shit text editor

You don't need to learn absolutely nothing to use nano.

The absolute state of fucking Jow Forums

Oh yeah? Why is /lib called /lib if it houses 64 bit libraries when /lib64 has 32 bit libraries?

Because x86 is the exception here. The folder for native x64 does not need to be specifically named, since it's the native and expected.

>wjat are symlinks

We don't generally use x86 anymore, we use AMD64.
Windows does name it AMD64 too.

Considered harmful
harmful.cat-v.org/software/symlinks
doc.cat-v.org/plan_9/4th_edition/papers/lexnames

>/bin/
>/sbin/
>/usr/bin/
>/usr/sbin/
>/usr/local/bin/
>/usr/local/sbin/
>/opt/
m8...

Attached: 1 (You).jpg (3840x2160, 1.46M)

It's just one of those naming conventions that's somewhat inconsistent. x86 of course comes from Intel 386 type processors (exactly where it originates idk). The original IBM and Intel 64bit instruction sets didn't really take off. Amd 64 is what we generally work with, and yeah it's based on the x86 set but it's not the same (although it's closer than the old Intel set was). Originally people were calling it something like amd64 but then that gets awkward because everyone uses it now. At some point it became x64, which looks like x86 but has a pretty different meaning. So anyway... This is how a lot of shit ends up getting named. The name isnt totally logicall but comes from history.

Btw, most Linux distros that are multiarch just have lib32 and lib64 directories then symlink lib to the default arch. Makes more sense to me. Linux has other stuff that's retarded though like splitting up binaries over /bin, /usr/bin, /opt/bin, among others, which only served a primary purpose historically. Some have pulled their heads out of their ass and consolidated directories like this though. Fun fact: /usr was originally what /home is now. It became a system directory when a disk ran out of space and the developers decided to move the user files and use the old user disk for system files. /usr was short for user and was the mountpoint for that disk, it wasn't until years later that "Unix system resources" was invented as the backronym

>what's the frickin point?
It gets better. Say you want to install both 64bit and 32bit TWAIN drivers. The 64bit DLL goes in System32\ and the 32bit DLL goes in SYSWoW64\.

So the short answer is Microsoft sucks really badly and that Windows programmers are even worse.

/bin/ and /sbin/ are where you put the minimum programs so that you can boot the computer and mount /usr.

/usr/bin and /usr/sbin is where all the programs installed with the OS go.

/usr/local/bin and /usr/local/sbin is the old place you'd put programs that were installed from other sources.

/opt is the new place to install programs from other sources.

sbin is for programs only the admin will run, bin is for everyone.

All the above was important back in the day when hard drives where small and package management was flaky.

also
>/lib/
>/lib/x86_64-linux-gnu/
>/lib64/
>/usr/lib/
>/usr/lib/x86_64-linux-gnu/
...

> /bin/ and /sbin/ are where you put the minimum programs so that you can boot the computer and mount /usr.
Depends on distro

>/usr/bin and /usr/sbin is where all the programs installed with the OS go.
These days, usr/[s]bin is getting consolidated into the root bin dirs. In the past there have been different philosophies. One approach is to keep only the minimum software for a system boot in the root /bin and /sbin because it makes it simpler to build initrd, and if you pull in those entire dirs, the initrd will be smaller. Another philosophy has been that /bin and /sbin are upstream programs whereas /usr/[s]bin would be for programs included with the particular distro. Things have also changed as "libexec" has become popular, many programs that would have been in bin or sbin are now hidden away since they aren't meant for direct her invocation
> /usr/local/bin and /usr/local/sbin is the old place you'd put programs that were installed from other sources.
Not exactly, it is/was a place for users to install system packages that aren't maintained by the distro or any package streams. For example, on Ubuntu, if I compiled st and dwm I might put them in /use/local (if I wanted to install system-wide, otherwise I'd just put them in my home dir somewhere). It's not consistent whether or not usr/local is controlled by a package manager. Some people package stuff that goes into /usr/local, some people just install it there and manage it manually. Most software that compiles with ./configure;make;make install; defaults to /usr/local.

>/opt is the new place to install programs from other sources.
Not exactly. There isn't a standard for opt. Some systems use opt for external or binary packages. It's common for software that is self packaged to install to opt to avoid collisions with software the system package manager installed. /usr/local is more for user compiled/installed applications

>sbin is for programs only the admin will run, bin is for everyone.
correct

wouldn't hurt to learn a little english

Just to really make a point that this is all pretty arbitrary, heres a screenshot of these directories on NixOS

but then I have /run/current-system/sw/{bin,sbin,lib,etc,share} which holds everything, and it's managed by the OS to deal with issues like file conflicts

Attached: nix_bins.png (1838x518, 93K)

>Plan 9 has no symbolic links but it does have other mechanisms that produce the same difficulty.
In other words they are a solution to an actual problem, which makes complaints pretentious.
Any modern terminal emulator can display symlinks as a different color.

the same reason windows does that

What is even the point of different directories for different architecture binaries? They are functionally the same for the end user and are invoked the same way. The os already knows what size they are from the elf meta data anyways.
And libraries already have a bunch of horseshit versions in their name anyways and are never invoked by the user.

>notepad C:\users\\windows\system32\drivers\etc\hosts
The current state of linjeets.

What's wrong with my sentence? The use of "absolutely nothing" instead of "anything at all'?

because the files have the same name but different contents

Because folder and file permissions. Mainly limiting naming conventions for the 32bit folder. Everyone else in this thread is wrong.

>windows folder inside user folder
what?
also
>modifying hosts file 100 times a day
if you are not doing this than your complain is retarded
if you are doing this then you are retarded

>32bit
>x86
why

On gentoo at least, I don't know about other distros, lib is a soft link to lib64.

you can google this

(OP)
>/bin/
>/bin86/
>/sbin/
>/sbin86/
>/usr/bin/
>/usr/bin86/
>/usr/sbin/
>/usr/sbin86/
>/usr/local/bin/
>/usr/local/bin86/
>/usr/local/sbin/
>/usr/local/sbin86/
>/opt/
>/opt86/

Of all the things you can complain about windows. You find this? Fuck you op

Union mounts are objectively superior to symlinks
Deal with it brainlet

Well, that's retarded. Just make a sub-directory inside your program's main one, don't shit up my directory structure, goddamn

(you)
cant believe people still for this bait

Attached: 1323947674652.jpg (550x550, 127K)

>want to print something on Linux
>several commands, drivers, and programs required and can take up to an hour to figure out
>want to print something on windows
>automatically find it in devices & printers and install drivers in 30sec

I wonder who is behind that post...

Nice

Attached: 1548961394121.png (486x415, 420K)

>mfw pajeet-tier Canon printer driver makes a fucking folder called "program files (x86) (x86)" for itself

Attached: 1537505979257.jpg (475x500, 45K)

It refers to legacy instruction sets from older CPUs like 8086, 80386, 80486, etc. It's literally named after the first CPU using that instruction set.

Most of then are filled with links in case a legacy program is looking for them on an older directory.

This thread is still going after the answer was posted with other stupid bullshit?

It's a shitty naming convention.

if_only_you_knew.jpg

Fuckin nice

Attached: B1ECEE9CD0174D679AFF13FC84909F28.jpg (540x523, 99K)

posting this here because this thread is pointless anyway.

why does windows 10 just occasionally 'forget' file associations? it'll happen when i know i haven't used a program that might have reset the file association. it's just a tad bit frustrating that i have to tell windows, for the dozenth time, that i still, indeed, open all of my video files in MPC.

it's just %windir%\system32\drivers\etc\hosts, retard

Your PC has Alzheimer's. I'm sorry fren.

Add /etc/ to your environment paths and now you can just %etc%/hosts

>We don't generally use x86 anymore
In case you're not pretending to be retarded:
They're both x86. x86-64 is an extension of x86 that supports 64 bits. "x64" is an abbreviation of x86-64. If you're not using x86, you're using something totally different like powerpc, ARM, MIPS, etc

AMD64 is the proper name for what you refer to as "x86-64".

I'm sorry, but that's incorrect. Do you need a Kleenex to wipe your eyes? How about some Q-tips?

No, it's correct. It was named AMD64 by its creator, AMD. x86-64 is an informal vendor-neutral term used to avoid hurting Intel's feelings, but not the true name.

>Re-enforcing a flimsy AMD marketing tactic that was basically dropped years ago.
What time is it in India Rajesh?

Nice

kek

So will Fuchsia finally create a dir tree and whatnot that was created in the 2010s rather than the 1970s?

Arch has it all in /usr/bin