Hacker News new | comments | show | ask | jobs | submit login

> 1. Unnecessary and confusing directory structure.

"Unnecessary" for you maybe, but have you considered the possibility that there is a reason why the directory structure is the way it is - and that the problems originally addressed may still be relevant? Here is a hint: partitions. Partitioning the files roughly by usage pattern allows you to tune performance, safety and security in a way that you would have a very hard time doing otherwise. Your suggested names make me think that you aren't very clear on the directory's actual purpose [0]. While longer names may have helped you out in understanding their purpose, once you actually learn it you're stuck with an unnecessarily long PWD that wraps each prompt.

> 2. Programs are mushed together and scattered...

Again, consider why it is the way it is. Do you really want to have a PATH that includes every directory for every binary on the system, or manage individual file permissions within all those directories? You want to do that with libraries as well? Just consider the complexity of what you're proposing and how you'd address: system defaults, setuid, per user preferences, dependencies, build environments... Years ago I basically did what you're suggesting, when Redhat was my daily driver. I'd build from source and install into ~/bin. Try it out for a while, you'll hate it.

> 4. Emphasis on text-based configuration files... hard to integrate with GUI tools...

What are you suggesting, a windows like registry? The text-based configs are no more difficult to use through a GUI than a binary representation, they're both a library function call away. Unless you are suggesting a windows like registry... but you've already pointed out how developers don't want to spend time on portability - so that can't be it.

> 7. General bugginess... Windows is a lot more reliable than Linux...

Ah, well try out an OS that is closer to Unix than Linux - maybe one of the BSDs. I'd put my Freebsd workstation against any flavor of Windows in a contest of uptime and performance, that is a bet I'd be happy to take. As far as Windows just working, that is true for the majority of tasks for the majority of users. But if you fall outside of that happy band of the target market, you are SOL. Consider the whole Windows telemetry issue. Also, I just noticed in my network logs that Windows update is sending out IPv6 dns requests despite the fact that I've disabled it on the network interface and tweaked several registry variables... there is nothing I can do about it. It would be a pretty simple fix for any opensource OS though.

[0] https://www.freebsd.org/doc/handbook/dirstructure.html

> Do you really want to have a PATH that includes every directory for every binary on the system, or manage individual file permissions within all those directories?

No way. But I'd love to gt ride of the plain PATH, replacing it with a hierarchical PATH with a convention. Maybe with every 'bin' directory inside that path getting in the search path, or maybe something that let me nest things deeper.

One can not do this in Unix, and that's the point.

> One can not do this in Unix, and that's the point.

One certainly can, very easily actually: edit you shell rc file in /etc to modify your PATH based on PWD, boom - hierarchical PATH the Unix way. Don't want it system wide? Edit your shell rc in the user home directory. Want something more complex? The posix shell source code is a lot simpler than you'd think. I wanted the same fancy git repo status PS1 stuff found in bash rc scripts, but without the performance impact - and in tcsh. It only took an hour of work to integrate libgit2. I don't think it would have been as easy with cmd.exe.

In fact, you are right.

And I'm hierarchising my ~/bin :)

I personally implemented my PROMPT generation's git commit and branch checks using zsh (just shell scripting) because compiling and dealing with a divergent version of my shell is just too much of a pain given how many machines I have to deal with.

That would have been the easy way to do it, if tcsh allowed dynamically generated prompts (outside of a few stock flags). On Freebsd it makes sense to run your own packaging build server once you start running custom compiles on more than a few machines, so it is no big deal to compile once and `pkg install` everywhere you want it. I guess the downside of that is that it makes it easy to be lazy and not push upstream, which I'm pretty sure is the primary motivation for a lot of code contributions :)

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact