5 ms·

This is more of a linuxism no? I agree though, I have used Linux for decades but I never remember the usr, bin, local, etc permutations of magical paths, nor do

by klabb3 2y ago

This is more of a linuxism no? I agree though, I have used Linux for decades but I never remember the usr, bin, local, etc permutations of magical paths, nor do I think it makes any sense. It’s a mess honestly, and is almost never what I want. When I was younger I thought I was holding it wrong but these days I’m sure it will never, ever map well to my mental model. It feels like a lot of distro-specific trivia that’s leaking all over the floor. It seems like a lot of the hipster tooling dropped those things from the past and honestly it’s so much nicer to have things contained in a single file/dir or at most two. That may be a big reason why kids these days prefer them, honestly. As for nginx itself it’s actually much better suited for high performance proxies with many conns, imo. I ran some benchmarks and the Go variants (traefik, caddy) eat a lot of memory per conn. Some of that’s unavoidable because of minimum per-goroutine stacks. Now I’m sure they’re better in many ways but I was very impressed with nginxs footprint.

gjvc 2y ago
honestly
- klabb3 2y ago
  Making me self conscious, honestly. I’m not a patient and careful writer. That’s why I’m lurking in the comments.
nevermore24 2y ago
I don't know if not being able to remember filesystem conventions is Linux's fault. Computers have a lot of esoterica and random facts to recall. How is this one any different? See also: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
kbenson 2y ago
Windows has the same thing, it's just much less exposed, and none of the paths are magical, they're well defined and mostly adhered to for all major distros. The core of how it works in Linux is fairly straightforward. The main difference is in how additional software is handled. Windows, because of its history with mostly third party software being installed, generally installed applications into a folder and that folder contained the application... Mostly. Uninstalling was never as simple as that might imply. Linux distros had an existing filesystem layout (from Unix) to conform to, so when they started developing package managers, they had to support files all over the place, so they make sure packages include manifests. Want to know where use executable are? Check bin. Superuser.com executables? Check sbin (don't want those cluttering the available utils in the path of regular users). Libs for in libs. /bin and /usr/bin and the others are holdovers from the long past when disks were small, and recent distros often symlink usr to / so they're different in name only. /usr/local is for admin local modifications that are not handled through a package. /opt is for whatever, and often used for software installed into a contained folder, like in windows. Just know what bin, sbin, lib, opt and etc are for and most the rest is irrelevant as long as you know how to query the package manager for what files a package provides or as it what package a specific filer belongs to. If you looked I to windows and the various places it puts things I suspect you'd find it at least complicated, if not much more. Note: what I said may not match the LSB (which someone else usefully posted) perfectly, but for the most part it should work as a simple primer.
jeffreygoesto 2y ago
I think the reason is that you needed to save on places where to look for files and sort by function in LFS. The package manager converts a package view into a system view, it kind of "turns around file system layout by 90 degrees". Both views have their pros and cons. It is annoying however, that configuration is not standardized across distros.
antifa 2y ago
> I ran some benchmarks and the Go variants (traefik, caddy) eat a lot of memory per conn. I'm pretty annoyed with how many people on HN are shouting in every thread "caddy is soon much better!" and the only material benefit to caddy I can glean from these threads is that it's easier for noobs. Which, to be clear, as far as I can tell, it does a good job of that and will probably win the next decade over nginx for that reason alone, but nginx really isn't that hard to set up, and I'm surprised there isn't so much push back against the pro-caddy narrative. It's just an uphill battle for an application written in golang to be faster than a mature application written in C. Obviously I will continue to use nginx until hard evidence of on-par performance is published, but at the same time I'm more likely to hold out for a competitor written in rust.
- deleted 2y ago
  [deleted]
- klabb3 2y ago
  > It's just an uphill battle for an application written in golang to be faster than a mature application written in C. Yes but Golang can be fast on almost every aspect too with some simple tricks. The main thing is the goroutine overhead per socket, which impacts reverse proxies indeed. > but at the same time I'm more likely to hold out for a competitor written in rust. Rust with Tokio can keep very low overhead theoretically. But language is not everything. For instance Envoy is also quite high per-conn overhead when I checked despite C++. I assume it’s just too many knobs and features.

by klabb3 2y ago

gjvc 2y ago

honestly

klabb3 2y ago
Making me self conscious, honestly. I’m not a patient and careful writer. That’s why I’m lurking in the comments.

nevermore24 2y ago

I don't know if not being able to remember filesystem conventions is Linux's fault. Computers have a lot of esoterica and random facts to recall. How is this one any different? See also: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

kbenson 2y ago

Windows has the same thing, it's just much less exposed, and none of the paths are magical, they're well defined and mostly adhered to for all major distros. The core of how it works in Linux is fairly straightforward. The main difference is in how additional software is handled. Windows, because of its history with mostly third party software being installed, generally installed applications into a folder and that folder contained the application... Mostly. Uninstalling was never as simple as that might imply. Linux distros had an existing filesystem layout (from Unix) to conform to, so when they started developing package managers, they had to support files all over the place, so they make sure packages include manifests. Want to know where use executable are? Check bin. Superuser.com executables? Check sbin (don't want those cluttering the available utils in the path of regular users). Libs for in libs. /bin and /usr/bin and the others are holdovers from the long past when disks were small, and recent distros often symlink usr to / so they're different in name only. /usr/local is for admin local modifications that are not handled through a package. /opt is for whatever, and often used for software installed into a contained folder, like in windows. Just know what bin, sbin, lib, opt and etc are for and most the rest is irrelevant as long as you know how to query the package manager for what files a package provides or as it what package a specific filer belongs to. If you looked I to windows and the various places it puts things I suspect you'd find it at least complicated, if not much more. Note: what I said may not match the LSB (which someone else usefully posted) perfectly, but for the most part it should work as a simple primer.

jeffreygoesto 2y ago

I think the reason is that you needed to save on places where to look for files and sort by function in LFS. The package manager converts a package view into a system view, it kind of "turns around file system layout by 90 degrees". Both views have their pros and cons. It is annoying however, that configuration is not standardized across distros.

antifa 2y ago

> I ran some benchmarks and the Go variants (traefik, caddy) eat a lot of memory per conn. I'm pretty annoyed with how many people on HN are shouting in every thread "caddy is soon much better!" and the only material benefit to caddy I can glean from these threads is that it's easier for noobs. Which, to be clear, as far as I can tell, it does a good job of that and will probably win the next decade over nginx for that reason alone, but nginx really isn't that hard to set up, and I'm surprised there isn't so much push back against the pro-caddy narrative. It's just an uphill battle for an application written in golang to be faster than a mature application written in C. Obviously I will continue to use nginx until hard evidence of on-par performance is published, but at the same time I'm more likely to hold out for a competitor written in rust.

deleted 2y ago
[deleted]
klabb3 2y ago
> It's just an uphill battle for an application written in golang to be faster than a mature application written in C. Yes but Golang can be fast on almost every aspect too with some simple tricks. The main thing is the goroutine overhead per socket, which impacts reverse proxies indeed. > but at the same time I'm more likely to hold out for a competitor written in rust. Rust with Tokio can keep very low overhead theoretically. But language is not everything. For instance Envoy is also quite high per-conn overhead when I checked despite C++. I assume it’s just too many knobs and features.