Part of it is the community. I really like the OpenWRT community, but it’s harder to engage with them when you run a downstream distribution.
But also I’m a bit of a hacker (in the traditional sense). I like to experiment with custom builds of OpenWRT. (And FWIW, their build system uses the same menuconfig as Linux.)
I love my Turris Omnia!
I got the one with the WiFi 6 card. The cool thing is that you can easily open it up and replace parts.
I run the upstream OpenWRT rather than the customized version by Turris. They are good about submitting patches upstream.
+1
From an order of magnitude perspective, the max is terabytes. No “normal” users are dealing with petabytes. And if you are dealing with petabytes, you’re not using some random poster’s program from reddit.
For a concrete cap, I’d say 256 tebibytes…
Maybe.
Linux won because it worked. Hurd was stuck in research and development hell. They never were able to catch up.
However, Linus’s kernel was more elaborate than GNU Hurd, so it was incorporated.
Quite the opposite.
GNU Hurd was a microkernel, using lots of cutting edge research, and necessitating a lot of additional complexity in userspace. This complexity also made it very difficult to get good performance.
Linux, on the other hand, was just a bog standard Unix monolithic kernel. Once they got a libc working on it, most existing Unix userspace, including the GNU userspace, was easy to port.
Linux won because it was simple, not elaborate.
You talk about “non-absolutist,” but this thread got started because the parent comment said “literally never.”
I am literally making the point that the absolutist take is bad, and that there are good reasons to call unwrap in prod code.
smdh
Fair. But unwrap versus expect isn’t really the point. Sure one has a better error message printed to your backtrace. But IMO that’s not what I’m looking for when I’m looking at a backtrace. I don’t mind plain unwraps or assertions without messages.
From my experience, when people say “don’t unwrap in production code” they really mean “don’t call panic! in production code.” And that’s a bad take.
Annotating unreachable branches with a panic is the right thing to do; mucking up your interfaces to propagate errors that can’t actually happen is the wrong thing to do.
Unwrap should literally never appear in production code
Unwrap comes up all the time in the standard library.
For example, if you know you’re popping from a non-empty vector, unwrap is totally the right too for the job. There are tons of circumstances where you know at higher levels that edge cases defended against at lower levels with Option cannot occur.
orlp invented PDQSort and Glidesort. He collaborated with Voultapher on Driftsort.
Driftsort is like a successor to Glidesort.
Glidesort had some issues that prevented it from being merged into std, and which are addressed in Driftsort. IIRC it had something to do with codegen bloat.
Zsh
No plugin manager. Zsh has a builtin plugin system (autoload) and ships with most things you want (like Git integration).
My config: http://github.com/cbarrick/dotfiles
Unicode cat 😺
Exactly.
My take is that the issue isn’t with tmpfiles.d, but rather the decision to use it for creating home directories.
From an engineering perspective, I prefer Debian distros. Apt is the greatest package manager ever built. For a production server, I’d choose Debian or maybe Ubuntu if I needed to pay someone for support.
But for a desktop, Ubuntu kinda sucks. These days, I think I’d recommend Fedora to Linux noobs.
And for my toys at home, I run Arch btw.
Big +1 for Sync.
I was paying for Sync back when it was a Reddit client, and I moved to Lemmy mostly because that is where Sync moved.
It’s an awesome app. Best app purchase I’ve ever made. (There is a free version too.)