Hacker News Reader

Comment by malux85 | Hacker News Reader

If the author has “been playing with the web and code for years” and is still “wtf” on /usr/local/bin in $PATH it shows a lack of discipline and structure in their learning.

I see this in many in many of my apprentices - the desire for instant gratification and the lack of experience means they refuse to do anything that doesn’t immediately proceed them closer to their goal.

Here’s the thing with programming - you can’t run before you can walk.

Go read “Learn python the hard way”, do 1 lesson a day

Go do Linuxjourney - do 1 lesson a day

By lesson 8 you’ll know about /usr/local/bin and path, and packages, that’ll fix all of your gripes about not being able to install ruby, pip and node too.

And all of that is solved only after 8 days of disciplined learning. Sure it’s not immediately towards your goal but you need the lower level skills and knowledge first. And it’s only 8 days!

Stop trying to assemble a fully functional car with no understanding of the fundamentals and then getting frustrated that car assembly is difficult. Go and learn some electrical engineering, go and learn some metalworking, go and learn some mechanical engineering, then you may come back and attempt to assemble a car. You might fail the second time too, but each time you’ll get further.

Stop seeking that immediate gratification, the path to success is NEVER a straight line

View on HN

> Stop trying to assemble a fully functional car with no understanding of the fundamentals and then getting frustrated that car assembly is difficult.

Most of these people find driving hard. You have to put the liquid in the hole and turn the key and keep pressing the floor-thing and hold the circle thing all while looking out the window to make sure no one gets in your way and the car stays on the hard paths.

What they really want is to just be able to jump in the back seat and state their destination then go back to chuckling at tik-toks and messaging friends until they're there. That's the kind of car assembly they want, complete with the commensurate salary and benefits. Is it really so much to ask to have that delivered to them?

Thank you for mentioning Linux Journey[1]! I never heard about it before - it looks like a great resource.

Another thing I want to add on - it looks like the author is lacking curiosity. I didn't have much discipline and structure in the beginning of my programming journey. In fact, I've been trying to add more discipline and structure to my learning now.

When I started though, I had a TON of curiosity. I fiddled all the time with everything. I fiddled with settings in Windows XP to make my family's computer faster, I fiddled with my own laptop by installing Linux and trying out tons of programs, I fiddled with the code on my computer to make it do cool things on the command line, etc.

I didn't have an end goal in mind - it was just something fun to do and I just wanted to answer all the questions in my head. Being curious drove me to learn, adding discipline and structure helps to fill in some gaps in my learning that my curiosity may have missed.

[1]: https://linuxjourney.com/

If you're looking for resources currently, Humble's got a Linux book bundle for the next 2-3 days that looks pretty good.

Immediate gratification does have its purposes.

It helped me a lot as a teenager in the late nineties that I could install borland delphi and very easily have a self contained windows app running without understanding too much, it gave me the confidence to go on and learn the lower level stuff.

/usr/local/bin has absolutely nothing whatsoever to do with programming. Nothing. Zero. Zilch. It is completely superfluous knowledge.

It is only required because, as the author correctly points out, the tools we use are BAD. They are absolutely fucking AWFUL.

/usr/local/bin is an implementation detail from an OS nobody has used for decades. It's still here because we refuse to fix these ridiculous things. Nobody should need to know this.

I've been programming for 25 years now, about 20 of which as a developer at billion dollar companies, google, facebook and various high scale hedge funds, including systems that serve billions of users a day. I have had a hobby in embedded programming and FPGA programming, compiler design and distributed deep learning.

All of which used /usr/local/bin and $PATH. Every system, regardless of programming language across python, C, C++, java, go, erlang.

Saying /usr/local/bin and/or $PATH "has absolutely nothing whatsoever to do with programming" is total rubbish. Programming as a field doesn't just include domain and syntax knowledge of a programming language, it includes ALL of the system implementation details below it, and YOU ARE EXPECTED TO KNOW THEM.

Saying something so basic and fundamental "has absolutely nothing to do with programming" only shows a terrible lack of systems knowledge, this is used in unix, linux, bsd, embedded and massive server scale deployments.

Acting like this stuff is somehow below you, just shows intellectual laziness, this stuff both BASIC (easy to learn) and FUNDAMENTAL (applies almost universally in many systems), and if you acted like this during an interview or working at anywhere with non-trivial setups you'd be laughed out of the room.

So I think what's happening is that there are people here who have maybe been programming longer than you have. And we remember when professional programs might be written in BASIC and sold on 5.25 inch floppies. On machines with no /usr/local or PATH. And then we programmed PCs using Borland or Symantec or whatever IDE and there was no /usr/local or (usually) PATH to be concerned about. And we programmed MacOS before it was Unix based using Think C or CodeWarrior and there was no /usr/local or PATH or even a CLI.

And so when CLIs became popular with (broadly speaking) the early growth of the internet, we became more familiar with /usr/local and PATH (we probably had some exposure to these already). So while yes, these are found in most modern systems, we see these things as details. PATH simply doesn't feel "fundamental" to me because I've written exactly the same kind of code in environments where PATH is used and where it doesn't even exist as a concept.

Of course, what is "fundamental" is rather a judgment call, and your perspective makes it so that these are fundamental for you.

I won't defend the original post, particularly wrt nonsense like adding node to a browser. But I do think different perspectives are at play here, and disagreement on either side does not reflect intellectual laziness or people who should be laughed out of the room.

I started with BASIC on a second-hand VIC20, and then onto assembler on an 80286 running DOS. So I've been there.

I define "fundamental" as something thats in wide use and deployment in actively running systems. Like $PATH being in every operating system used today and /usr/local/bin on every linux distribution running on literally hundreds of millions of servers globally, right now.

And the requirement of understanding these are part of what's holding back the author of the article from not having a running ruby, pip and node.js

The reason I say it has nothing to do with programming is that none of all of these tools that make you rely on this stuff NEED to do so. They chose to. But they don't need to. This is an implementation detail that is entirely orthogonal to the rest of the task of programming.

Superfluous, and could be replaced at any time.

And I note you immediately jump to the conclusion that I am too stupid to know these things that you know because you are clever. And that is EXACTLY the problem.

No, I was just saying that in my vast experience the two things that you described as:

"absolutely nothing whatsoever to do with programming. Nothing. Zero. Zilch. It is completely superfluous knowledge"

Were indeed critical components to all of these systems, and organisations, and that it's not a big ask to require a programmer to know them.

Also, on what authority do you decide what is programming and what isn't?

The whole point is, there is no reason to require a programmer to know them. That is an arbitrary choice we have made.

We could make a different choice, and not require a programmer to know these things. They could do everything just as well without knowing this, if we let them.

When I was travelling through Italy, I learnt a phrase from programmers there, "If my mother had wheels, she would have been a bike" - and it's a criticism of hypothetical situations like your answer above.

Saying "This is arbitrary if we made a different choice things would be different" is a total meaningless statement because you just move the bar and then say if the bar is moved things are different.

My argument is that eventually all implementations are embedded in reality, if not /usr/local/bin and $PATH then some other abstraction that is equally arbitrary - but in the real world, the one we live in, we have /usr/local/bin, $PATH and a bunch of other "arbitrary" lines that have to be somewhere because without these lines (or some lines) there is nothing. And you have to know them, whatever they are.

Because you know what happens if you don't know them? You end up with people writing blog posts about how difficult programming is, ranting they cant install ruby or pip or node.js, like the article above. You have to learn the underlying system, whatever it is. In this case, it's /usr/local/bin and $PATH.

I think you're not arguing that you shouldn't know the underlying system (correct me if I'm wrong) but you're more saying that these particular abstractions are inconsistent or distasteful - if that's the case, let me assure you that no implementation is perfect, and programmers for nearly 100 years now have been trying to come up with the perfect abstraction that requires no knowledge below, but in reality, it never works, because theres always exceptions, or the abstraction is not flexible enough to apply generally enough to be useful, thats like the two forces that push and pull the argument both ways.

I've come to learn that you must just learn the underlying system, because you'll be able to diagnose better. To that end, you must learn sysadmin, you must know $PATH and you must know the underlying system. Go and have a look at the programmer competency matrix - this stuff is in there

What I am saying is, as soon as someone new to programming points out, entirely correctly, that the tools we use are weird, obscure and difficult to use for no apparent reason, programmers will scream in rage that no, they are not, and by the way, you are stupid for saying it, you clearly have no idea what you are doing and you will never be a programmer.

As is happening everywhere in this very thread.

I am saying that this is weird, toxic and must stop. We must be able to admit that yes, the tools we use are kind of bad. We must admit that we could do better. Otherwise nothing will ever change, and we will keep using stupidly broken tools until the end of days, while patting ourselves on the back for being clever enough to use them.

> programmers will scream in rage that no, they are not, and by the way, you are stupid for saying it, you clearly have no idea what you are doing and you will never be a programmer.

Nobody has said this to you in this thread, and the fact that you're acting like it is the only toxic thing here. This is called a straw-man logical fallacy, you misrepresent my argument so it makes it easier for you to attack. Nobody has said this to you, that part is all in your head.

I'm saying the tools are not weird if you understand them, and how they fit as a cohesive whole. I'm saying they just look weird to you, because you don't yet understand them. Can we do better? Absolutely, I'm all for better tools. But if the original poster wants to install pip and ruby and nodejs then knowledge of system paths is mandatory - because this is what they are trying to do.

In my answers above, I have named several programming languages, several operating systems, discussed my commercial experience and then talked about the rationale behind my logic.

You have done nothing but turn these into personal attacks against yourself, not discussing systems or operating systems, (not even naming one!) but always complaining about people calling you stupid or how you're the victim. The only person that has used the word stupid in this thread is you. You are a toxic narcissist, and I chose not to engage with you.

> I'm saying the tools are not weird if you understand them

No, they are still weird. They are only not weird if you've become accustomed to the weirdness.

I primarily develop on Windows, and when I come to Linux to work on things I am astonished to find that Linux developers think nothing of using upwards of half a dozen different languages to build one thing. CMake, autoconf, shell, and python all being used to build a single C++ program is weird and unnecessary. If you don't think so I submit you've merely become accustomed to doing things in this incredibly weird way!

PS: Windows has its own developer tendencies that are weird and unnecessary, but I will at least readily admit that about them.

I think a lot of this thread is people’s biases from what they are used to. I’m one of those guys who started on the command line and lived on the command line most of his life. I couldn’t imagine a more productive environment! I consider a bunch of xterms running vi to be the pinnacle of IDEs. But I did two brief stints at Windows shops and just couldn’t get really productive. The guy next to me who was scared of the command line and never went outside Visual Studio? He wasn’t stupid, he just had a different lineage and got accustomed to a different environment and workflow. One is not inherently better than the other.

That said, if you are a modern web developer, you just have to understand the command line. You have to know what /usr/local/bin is. You have to know how to install your toolchain. It’s inconvenient, but it’s table stakes. I don’t think it’s reasonable to say “Hey! I’m used to GUIs so people programming on the command line are wrong and I shouldn’t need to know about /usr/local/bin“

I think it is perfectly reasonable to question whether all of that is necessary just to program stuff for the web.

“Just” to program stuff for the web? Web development is a complicated and amazing feat of engineering! The fact that you can write some code on your machine to make any pretty graphic and maze of pages you want and it will run in this thing we call a browser that pretty much anyone in the world can also run even if they are on Linux, windows, android, iOS, or any other number operating systems not to mention hardware! Think of all the layers of abstraction and code that is necessary to have millions of combinations of hardware + software all show the same thing! It’s amazing how simple it is to do web development! The fact that it is doable to set up a website in an afternoon that is accessible all over the world is ASTONISHING.

This delusion that the web is an amazing feat of engineering is frankly astonishing to me. It is constantly broken and basically entirely relies on a single browser engine controlled entirely by one of the largest organizations on the planet. It has well known security footguns at every turn.

It isn't even unprecedented. Way back in the 90s Another World used a bytecode VM for portability between hardware platforms. It ran on a whole lot of them and had input, graphics, and sound. Before that Infocom used a VM for its text adventures that was ported to many platforms. P-Code existed before that. The modern web browser, and web code, is a jankier, significantly more complicated, design-by-intertia/committee/def-facto-monopoly hybrid monstrosity. It's a document viewer with incoherent bits glued on until it kinda almost works like an application platform.

> Think of all the layers of abstraction and code that is necessary to have millions of combinations of hardware + software all show the same thing!

Not that f'ing many if you didn't engineer your VM like a blind monkey! Cross platform VMs are not a new idea, at all, and that's essentially what the modern web is, only it's the most Frankenstein version of that idea ever conceived.

First you say nobody has called me stupid.

Then in the NEXT PARAGRAPH, you tell me that I don't understand command line tools.

I have been using them for decades. I know them very, VERY well. I am saying all of this from a position of long and deep familiarity with the tools.

Yet immediately you jump the conclusion that I just don't know what I am talking about.

> First you say nobody has called me stupid. > Then in the NEXT PARAGRAPH, you tell me that I don't understand command line tools.

Nothing I read by malux85 implied to me that not understanding command line tools makes someone stupid.

I think davorak is right, malux85 never says lack of understanding implies stupidity. I'd go even further. I don't read malux85's comment as an attack on your understanding personally. I read it as referring to people like the blog post author, who clearly don't understand the basics of the tools they're complaining about.

No one is screaming in rage about anything here. We do tend to get frustrated hearing complaints from people that are unwilling to take even the smallest amount of time to learn before complaining about the state of things.

I'd like to put one of your comments in a different but maybe enlightening context:

What I am saying is, as soon as someone new to gardening points out, entirely correctly, that the tools we use are weird, obscure and difficult to use for no apparent reason, gardeners will scream in rage that no, they are not, and by the way, you are stupid for saying it, you clearly have no idea what you are doing and you will never be a gardener.

Now imagine that gardeners all use chainsaws. They are very proud of how skilled they are at their chainsaw usage.

A new person comes in, and asks, why on earth do you all use chainsaws for this? Wouldn't it be easier to use more appropriate tools?

And the gardeners immediately call him clueless, make fun of him for not being able to handle a chainsaw, and tell him he will never be a gardener if he can't even figure out how to use a chainsaw.

A new person has no grasp on what constitutes a "more appropriate tool." People with zero experience don't get to dictate what tools people who know what they're doing should use.

Can you imagine if a layman walked into a mechanic's shop off the street and started trying to tell the workers there the same thing? Or a bakery?

I find this a highly amusing example, as gardeners do use chainsaws. Possibly not often, but it is a tool with a purpose that they do use.

And they'd be right to, because actually the situation is inverted. Saying a useful tool is unnecessary and a symptom of the fact that all tools are broken is the sort of thing the person holding the chainsaw would say, not the people who understand why a whole range of tools exist.

Except the person you're talking to is a gardener, who uses a chainsaw frequently, and is saying that indeed the beginner is right to point out that we should definitely be using a better tool than a chainsaw.

And then people shout them down because they've apparently become so accustomed to using a chainsaw that they honestly can't imagine a better way.

Except the Gardener is completely and totally wrong in this case. This assumes that no one else has tried something different. There have been an massive number of attempts at something better. The result? They have all failed and developers continue to use the command line. You can write a ton of type of apps with visual tools but almost universally it's sucked or only valuable for toy apps.

Examples that I have personal experience with:

  * VB6
  * Frontpage
  * Delphi
  * Access
  * Excel
  * Hell even storyboards in iOS based Dev
  * Blueprints in Unreal Engine
  * etc...

The same results, they work for non-programmers/non-professional programmers. Almost without question we have seen that text based programming on a more or less standard *nix based OS or text based programming on a Windows OS are the two ways that are the most effective for engineering of software. The programmers complaining about the tooling we use? Sure we should continue to improve that tooling but that doesn't mean scrapping the basic fundamentals. The installer should ask to modify the $PATH and then do that. There that solves that issue and doesn't throw out 50+ years of science and research and experience on the best way to engineer software.

> What I am saying is, as soon as someone new to programming points out, entirely correctly, that the tools we use are weird, obscure and difficult to use for no apparent reason, programmers will scream in rage that no, they are not, and by the way, you are stupid for saying it, you clearly have no idea what you are doing and you will never be a programmer.

If you are a beginner in some topic (any topic), and encounter a group of people who are proficient in that thing, and you disagree with them about some aspect of it, the options are broadly that 1. you've hit some great insight, or 2. you don't understand, but the odds favor option 2. If, however, you're confident that you've hit onto something better than everyone else, let me echo others and suggest that you should try to implement it; either you will succeed and show the industry the error of their ways, or you'll find out why things are the way they are, and both of those are good outcomes.

Except that many programmers, including parent, happen to agree that with what the beginner is saying. That it is so obviously true that even a beginner can see it is evidence that the people who can't see it have conflated the way things are with the way things need to be.

> The whole point is, there is no reason to require a programmer to know them.

There's no point to making sure a programmer knows how his environment is set up? Are you being serious right now?

> /usr/local/bin is an implementation detail from an OS nobody has used for decades.

Are you taking the piss? Should we also remove SOCKET's because they were introduced in that same OS?

It should be noted that _EVERY_ modern operating system implements a "path" system, even the ones that are very divergent.

Also, Namespacing and search paths are a concept in every environment where people name things. Be it the filesystem or a programming language itself.

Even in normal Life, when identifying people or things, we have concepts of this everywhere. How can people see that as pointless?

And environmental variables, too. You can see the same pattern:

  process :: function
  path ::  namespacing
  command line argument :: function argument
  environmental variable :: dynamically bound variable

(Ok, that last concept may be alien for non-Lisp people.)

Should we remove sockets? Possibly. We could most likely design a better API today.

Go ahead and do so, please.

You keep saying that things could be better but show no counterexample.

Lead the change or stop whining. Nobody is going to do the job for you if they're satisfied by their current tools, especially if they think you're wrong.

Do it and prove everyone else wrong. If everyone thinks the status quo can't be improved, but you're enlightened, it's your chance to turn your "likely can be improved" into reality.

The non-programmer user base is immense. You can get rich by selling your alternative.

> Lead the change or stop whining.

Ugh. Look, just because they themselves have not attempted to create something better doesn't mean that their criticisms are invalid.

They are if they are nonspecific. Saying "X is bad" requires a counterexample, at least.

They gave counter examples, specifically "we didn't need this in the past, therefore it is not actually necessary". Which is entirely correct. We do things the way we do things largely for historical reasons and beginner users are right to point that out.

I was there in the past and the tools are really not comparable. I just inserted a floppy disk and did A: then TP.EXE (which was just as arcane as knowing $PATH) but do I really want to work on Turbo Pascal in MS-DOS? Of course complexity skyrocketed!

That's not a counterexample because beginners have contemporary expectations. There are simpler alternatives that just work. Why do beginners want to use Node.js locally then?

> We do things the way we do things largely for historical reasons

Nobody challenged that. The question is: is the alternative better or just a different (but equally arcane) set of quirks?

If you're not using $PATH you'd be using an analogue system to solve the same problem, and you'd lose portability with current OSes.

Sounds like NIH to me.

> I was there in the past and the tools are really not comparable. I just inserted a floppy disk and did D: then TP.EXE but do I really want to work on Turbo Pascal in MS-DOS? Of course complexity skyrocketed!

Did it do so for reasons that are still relevant today, is the question.

> That's not a counterexample because beginners have contemporary expectations.

Alright I'll present a counterexample: Lazarus. You download it and install it [0], then you run it and make programs. It has a WYSIWYG GUI builder and produces stand-alone executables for multiple operating systems. There is no complicated build environment to set up.

> If you're not using $PATH you'd be using an analogue system to solve the same problem, and you'd lose portability with current OSes.

I contend that the problem $PATH solves has nothing to do with programming. $PATH is a solution for finding programs when you type their name on the commandline, nothing more. Windows and Mac programs don't really use or need it for the vast majority of tasks. Programming does not fundamentally require $PATH.

> Sounds like NIH to me.

And arguments that understanding $PATH is somehow a necessary pre-requisite to get into programming sound like needless complexity fetishism to me.

[0] I would argue that the installation step here is also unnecessary as there is no reason Lazarus cannot operate as a stand-alone self-contained portable folder other than the developers insistence on hardcoded paths.

> I contend that the problem $PATH solves has nothing to do with programming. $PATH is a solution for finding programs when you type their name on the commandline, nothing more. Windows and Mac programs don't really use or need it for the vast majority of tasks. Programming does not fundamentally require $PATH.

Do you write programs that don't load libraries? That don't interact with files? $PATH is required (or something to search along to find those libraries or files). I've been programming for 25+ years and I can't think of a serious actual application that I've written that doesn't need something like $PATH. Even simple data formatting console apps generally need to load a JSON library or something similar. It's impossible to bundle every library needed for an app in every app. People keep saying that $PATH isn't needed but location services of some kind is absolutely needed! I'd argue that $PATH is the result of 50+ years of engineering/science and research and is the best known way to address that issue as of now.

>And arguments that understanding $PATH is somehow a necessary pre-requisite to get into programming sound like needless complexity fetishism to me.

Understanding your programming environment is absolutely a prerequisite to getting into programming. If you don't want to deal with $PATH, you should know enough about your target OS to know how to run things without it (which is really, really not hard to do).

No program exists in a vacuum.

You seem to be advocating for an IDE-style environment, examples of which abound. Is that all this whole discussion is about?

I see what you mean. Lazarus look great, I might try teaching it to a friend!

EDIT: Any good small-ish project in GitHub to get a feel for the language?

"<CR><RET> is an implementation detail from an OS nobody has used for decades"

Yeah they're taking the piss. You can make the same argument about GUI tools too. We're gonna be dealing with "implementation details" for awhile lol. This thread is wild. Makes me understand why all the juniors I work with suck so much.

The server you submitted your comment to uses this 'OS nobody has used for decades'. The OS you wrote this from, also uses this implementation detail.

It most definitely does NOT use that OS. That is a ridiculous claim.

Every OS, Windows as well, uses the concept of search paths, namespaces, and environmental variables.

I think he's speaking about First Edition UNIX, and, yes, we don't use that operating system.

We just use operating systems which implement concepts derived from there.

So, technically correct, though the argument has little merit.

The point is, "/usr/local/bin" is an artifact that made sense on that system, and that system alone, but we started using it elsewhere, and not it is so firmly established we do not dare to change it, even though it is a completely arbitrary choice with no relevance to modern systems.

well, yeah. Every path and name ever in all of history is arbitrary. As is the seperator between the components.

All environments for computer development need to manage some amount of abstraction to bootstrap that environment and get programs to run. In nixes, it's the bootloader, the kernel, and shell (with its ENV). When you issue the command `node` to a computer, what does that actually mean? Your Delphi setup probably just hid most of that abstraction from you, the way most people need not worry about the bootloader. But env is kind of unavoidable. It's like the Construct from the Matrix. The staging area for all other programs.

I have struggled a lot with the nitty-gritty of ENV over the past few years and I agree with you that maybe there is a better way. /etc/, Conda, virtualenv, docker, ROS, Windows registry, they all deal heavily with managing the environment, and all have their own thorns. Then you have kube, consul, ansible, and all the fun of distributed environments.

The bottom line is, if you want multiple, orthogonal runtimes, you need an abstraction for managing namespaces. PATH is actually one of the simplest mechanisms to achieve this.

Yeah but they're bad cause they have to be.

I can't just wave my magic wand and eliminate Bash, and all $PATH nonsense.

It existed before.

So as a programmer, I expect you to know about it. There may be a day when the knowledge is obsolete. Where we can coordinate politically and socially enough to eliminate all usage of bash and $PATH. But those are social and political problems.

As a programmer, I expect you to have the technical knowledge necessary to do your job. Stop complaining about the social and political context that brought $PATH to existence and just know how to use it, and don't write something like it yourself.

Programming is not AWFUL. People and the social and political aspects of interacting with others is AWFUL and always will be. We work around it, we make it better, and we improve it. But no, our tools are not CRAP, they're not AWFUL. We build amazing, wonderful things with these tools.

What a short-sighted perspective. Just pass. Seriously.

I haven't seen anyone mention why $PATH is nonsense, and what a better system would be.

I'd say programming (at least modern programming) involves knowing one's environment and knowing how to get things done in relation to the actual code writing.

Also, using the search query "/usr/local/bin" in Google returns this[0] link first. This is my real issue. If a simple web search returns a good result first that gives you a good overview and gives you more background knowledge and more terms to search for and flesh out your knowledge, then there is little excuse to say learning is too hard. If you don't want to learn, that's fine, but complaining about learning being too hard here is unjust.

[0] https://unix.stackexchange.com/questions/4186/what-is-usr-lo...

> /usr/local/bin is an implementation detail from an OS nobody has used for decades

Linux, MacOS, the BSDs... They're very much used today, not just decades ago. the /bin, /usr/bin and /usr/local/bin are very simple to understand after around 10 minutes of looking at the contents of / (root).

*/bin/ has binaries,

*/lib/ has libraries,

*/include/ has headers.

Its as simple as it gets, I dont see a way you could make a "better" system, other than maybe renaming "bin" to "binaries" for the 5 people on the planet with an irrational fear of common abbreviations.

And what is /usr/lib and /usb/bin then? Sure, they had meaning historically but today they're often just symlinks because we don't really need the distinction.

> Its as simple as it gets, I dont see a way you could make a "better" system

I do, we could stop separating binaries from the associated other files they require in order to work. That is an artifact of how UNIX was originally implemented that is irrelevant today. Case in point: the existence of containers, flatpak, AppImage, and other such things that do exactly that! Not to mention all the operating systems, like Windows and Mac, that always worked that way.

And what does "usr" mean?

User System Resources

That is not what it meant when it was created. Apparently some people have retroactively tried to change it mean that, but, that is just a complete nonsense phrase.

Right, as far as I understand it originally was just short for "user". It's where home directories of users were placed. Now that it's been relegated to storing user-usable programs & data it makes sense to me that it's separate from say /Users, but I suppose it could be aliased to something like /UserProgramsAndData for verboseness and clarity to newer users. But regardless, "User System Resources" is a fairly useful phrase, it's there to separate their system resources (programs & data) from their personal resources (which should be in their user directory).

But, a system _does_ have users. Those users _do_ have programs. There's a hierarchical relationship. I've been following along with your comments in this thread and I just don't follow what you're getting at here.

If you designed this from scratch, is that the name you would naturally pick?

If the naming of the path is where you are hanging the crux of your argument about how "bad" things are, then you are not making a terribly convincing argument.

It is not. It is just one example out of a million of how things are weird and non-obvious for pointless reasons.

>/usr/local/bin is an implementation detail from an OS nobody has used for decades.

/usr/local/bin is where most Linux distros put binaries that were built locally, as opposed to those that came from the package manager...

Not to mention, if you don't understand how and where your binary is supposed to run, what on earth are you doing making it in the first place?

Every linux environment in the world is in disagreement with you.

While I'm not a low code fan, I would say please don't read Learn Python the Hard Way. https://sopython.com/wiki/LPTHW_Complaints

Rather than just criticise, can you please suggest a better alternative?

I am always looking for better tools and tutorials for the people I mentor, but LPTHW has been great, I have mentored 15 or so people so far from no coding to starting and running their own companies, and I have yet to find something better.

Reply on news.ycombinator.com