pkkm

lsblk accepts a --json flag and can give you a lot of information (try lsblk --json --output-all). Very useful if your script needs to check what disks and partitions there are in the system.

CBOR? It's based on JSON, so it should be pretty easy to add to a tool that already has JSON serialization.

Cryptography yes, but are you sure about parsers? As far as I can tell, there's some kind of U-curve there. Beginners code them by hand, intermediate-level programmers and intermediate-scope projects use parser generators, and people maintaining the most sophisticated parsers prefer to code them by hand too. For example, GCC used to have a bison parser, but they switched to a hand-coded recursive descent one because that let them produce more helpful error messages. Clang uses recursive descent too.

Any advice on how to find these quality shops and this quality knowledge? Any particular things to look for, or particular books/courses you recommend?

> companies engineer food to exploit our senses

This is just a maximally edgy way to phrase "companies are making tasty food". Which I don't disagree with - like Stephan Guyenet and (apparently) you, I blame the fatness problem on the fact that we've evolved to eat a bit extra because food wasn't always available, and now we're surrounded by an extreme variety of tasty food 24/7. I don't believe any of these food ideologues (keto, anti-grain, carnivore) who try to vilify a single ingredient or food group. But then, how could you possibly regulate that? If it was some bad ingredient then it could be limited or banned, but how would you regulate tastiness itself? To me, this seems hopeless, and I'm expecting the obesity problem to get addressed by a combination of making cities more walkable and normalizing semaglutide-like drugs to the point their use is as ordinary as popping a vitamin pill with breakfast. I'm curious to hear if you have different ideas.

If the code is fairly short, there is https://codereview.stackexchange.com/

> Perhaps the 'evil motives' might be more subconscious or even class conscious than overtly articulated in the minds of the actors, but the goal is the same.

So you're going to claim that you know people's true motives better than they themselves do, like you're some kind of political Freud? This is really stupid. I don't know why we should pretend that it's impossible for two people to reach two different sets of conclusions in good faith.

This is the kind of "political mind reading", where you confidently attribute hidden evil motives to anyone who disagrees with you about what is a good policy, that has made Reddit unbearable to read and, I suspect, increased political polarization in general. And your entire comment history is just you doing this over and over again. Please don't ruin another website with this.

Make sure to also watch this guy's Rust "interview". It's really good.

The Arcan display server is a really cool idea. Even if it doesn't manage to get popular, I think there are ideas here that we could mine to use them in popular programs.

- https://arcan-fe.com/2022/10/15/whipping-up-a-new-shell-lash...

- https://arcan-fe.com/2021/04/12/introducing-pipeworld/

- https://arcan-fe.com/2020/12/03/arcan-versus-xorg-feature-pa...

- https://arcan-fe.com/2021/09/20/arcan-as-operating-system-de...

Well, the money is theirs to spend, plus it's exactly on-brand for a religious organization to put traditional aesthetics over economic efficiency. I doubt that their donors are dissatisfied. If it was a government doing this with taxpayer money, then it would be different.

In other words... you made it up to confirm your bias?

What is your evidence for this grand conspiracy theory?

This is just the Clean Code style. If you read the book (or an article with examples [0]), you'll see that it advocates exactly this kind of thing: refactoring functions that are "long" and "unreadable" because they have a dozen or two dozen lines into a "clean" and "maintainable" web of tiny functions calling one another. Personally, I find this style very mentally straining because I have to constantly jump around and keep track of a huge function call graph in my head; it's almost as bad as beginner code with a thousand lines per function. The popularity of fads like this in the Ruby community is one of the reasons I'm glad I switched to Python.

[0] https://qntm.org/clean

This title is pure clickbait. The article says that out of the last 9 years, the statement has been true for 1 and false for 8. Flagged.

You're right that disabling strict aliasing removes some optimization opportunities for the compiler, but you can always get them back by adding restrict here and there. So it's really about what the default behavior should be. I'm thinking that it probably would've been better for the safe and intuitive behavior to be the default and for the extra optimization opportunities to be opt-in. A set of rules that usually does the right thing, but not always, can lull programmers into a false sense of security.

Also, I'm not sure how true your argument is in practice. Modern compilers have other, more sophisticated ways to prove that things don't alias. A number of projects compile with -fno-strict-aliasing without using restrict very often, for example the Linux kernel, and they don't seem to suffer much from it. Linus has this to say about aliasing in kernel code:

> In x86, I doubt _any_ amount of alias analysis makes a huge difference (as long as the compiler at least doesn't think that local variable spills can alias with anything else). Not enough registers, and generally pretty aggressively OoO (with alias analysis in hardware) makes for a much less sensitive platform.

Unless you think that the abbreviation const stands for some other word than constant, I'm not sure how that's relevant here?

> This is a woeful state of affairs propagated by an ill founded and widespread confidence that the C and C++ standards probably aren't as hostile to type aliasing as they actually are.

Yep. Honestly, while I get the historical reasons for strict aliasing, I wish it hadn't been created. Just make -fno-strict-aliasing the default and normalize the abundant use of restrict, maybe shorten it to res or rest just like we use const instead of typing out constant. These implicit rules that usually, but not always, do what you want can be a bigger footgun than having to do things explicitly.

See also the GoboLinux filesystem hierarchy [0], which may be what would happen if we redesigned the traditional Unix hierarchy.

[0] https://wiki.gobolinux.org/Overview/GoboLinux-Filesystem-Hie...

Everyone already knows what the words "bombing" and "shooting" mean, and it would be hard to find someone who considers war to be a good thing. The entire question is which dead children and whose misery we pay attention to.

This article doesn't help answer it. It's just a journalist trying to justify a more emotionally powerful and eye-catching form of journalism in a world where a huge number of people are already addicted to doomscrolling. If anything, we need mutual disarmament in the area of giving people an endless stream of depressing and enraging news in ever more optimized ways. I would treat this piece similarly to an oil industry worker explaining the benefits of using more fossil fuels, or an alcohol industry executive expounding on the positives of drinking.

> Sysvinit did so little that it's almost trivial to understand.

This is only an advantage if you take an extremely short-sighted view of complexity. Yes, sysvinit itself is very simple, but by that metric you may just as well replace the init with a single exec to a user or distro-provided program. That would be even simpler, right?

Well, not if you think about systemic complexity rather than just the complexity of that one program. A modern Linux system will include the monitoring of daemons, auto-restart, parallelized dependency-based boot, and so on. A lot of people also want features such as starting a daemon only when a connection arrives or a device is plugged in, or automatically redirecting a program's output to the system log. This stuff is inherently complex, and that complexity has to go somewhere. sysvinit just says "not my problem", so every distro needed to ship lots of scripts to do these things. Every program that wanted to act as a daemon had to do a whole dance of double fork, setsid, environment variable sanitization, umask, managing a pidfile, etc. You'd have this error-prone logic repeated dozens of times in your system, in different programs, often written by people who aren't Linux experts. That's not systemic simplicity. systemd takes all of this complexity onto itself, and centralizes it into one place that is written by Linux experts. This lets many other programs be simpler.

> Makes other use cases more difficult. It makes the system quite opaque to the user, a bit like Windows or MacOS that become almost impossible to fix when they break.

What use cases does it make difficult? How does it make things impossible to fix? Please give specifics, because my experience has been the opposite. When something breaks in a systemd system, I usually find good clues in the system journal and the fix can be a simple configuration change after googling the problem. It's a breath of fresh air compared to having to trace the workings of a hairball of distro-specific shell scripts.

This is just motte-and-bailey. You're shifting the definition of the "unix philosophy" between the general idea of interoperability, and the UNIX design of small programs that communicate via text and are glued together with the shell and pipes. The argument doesn't work if you actually use a consistent definition: the former is an obviously good thing but also an area where systemd scores well, and the latter isn't necessarily a good idea when you're doing something other than ad-hoc text manipulation.

I honestly don't understand why people want to do all these rhetorical backflips in order to maintain some kind of bizarre religious reverence for the "unix philosophy". UNIX's design was quite mediocre, it only looks brilliant when compared to the DOS lineage.

How about you make an actual technical criticism of systemd instead of hiding behind vague generalities? In particular, why is it bad that all the functionality needed to manage and monitor daemons is in one program? How would you split it into several programs in a way that maintains systemd's robustness for administrators and convenience for developers? What would be the practical benefits of this split to the users and developers (no "philosophies" please)? Can you justify that this proposed split would reduce systemic complexity (the complexity of the whole system) instead of actually increasing it by just shifting responsibilities onto daemon developers?

> The core idea is "do one thing and do it well".

The historical "unix philosophy" was specifically about small programs communicating over pipes via plain text. If you retroactively change it to "do one thing and do it well", then it becomes a meaningless truism. "One thing" is so vague that you could argue Photoshop does one thing too; every large piece of software uses some kind of modularity; and who would deliberately write a program to do its job badly? The devil is always in the details that such cliches don't help us decide: how broad should our definition of "one thing" be, what should be the unit of modularity (processes, classes, Python modules?), what is the communication interface between the modules.

In the case of systemd, it's an umbrella project maintaining a bunch of medium-size C programs that communicate mostly over D-Bus, in ways that are extensively documented on systemd's website. I find it to be a big improvement in interoperability. Before systemd, most distros used the "simple" sysvinit in theory, but in practice sysvinit was so lacking in features and such a pain in the ass to program for that each distro usually shipped a bunch of helpers glued together with shell and Perl. So you would have to write distro-specific stuff, based on documentation that was less abundant than systemd's. That wasn't very good for interoperability.

Can you elaborate on how systemd doesn't let you use your system as a general purpose computer? Because that sounds ridiculous on the surface. There are several ways in which systemd is more general and hackable than sysvinit, for example having targets instead of runlevels. And in practice, after the introduction of systemd I've only found it easier to look into things on my system and tinker with it. journalctl's log formatting and filtering is a very useful addition to grepping when you need to investigate a problem quickly, and systemd user services have made it trivial for me to run my short Python scripts as full-featured daemons that write to my system's log and can be monitored.

> Systemd OTOH makes almost all possible sins against the unix philosophy

Is this supposed to be a bad thing? Because I don't find it obvious. In fact, I don't get why many people have this mystical reverence for the "unix philosophy", as if having a large number of small processes that communicate via plain text was some kind of divine commandment rather than just one of many ways to design software (and not necessarily that good for tasks other than slicing and dicing text). I'm guessing that you do your image editing in a program like GIMP or Photoshop rather than with a bash shell, pipes, and a hundred tiny programs that input and output text. The "unix philosophy" simply isn't a good fit there. Having used both sysvinit and systemd when doing server administration, I find systemd so much better that to me, it's evidence that maybe the "unix philosophy" isn't the best choice here either.

Try setting showdead in your user profile.

For people who can't afford custom earplugs, you can find a lot of earplugs with good sound clarity if you google "musician earplugs" or "concert earplugs". You may have to try more than one brand before you find something that fits well, but it will still be cheaper than the custom option. I like the EarPeace plugs, though it's not because of sound quality but because they're discreet and I find them comfortable.

Oh, that's just one of many such cases. There's also the history of how it took years of requests, and pressure from Valve, for Wayland devs to consider letting the user disable VSync. Or the disaster around the UI scale, which until recently would be rounded up to the nearest integer, passed to the client, and the client's rendered bitmap would then be downscaled by the compositor to match the actual scale set by the user. Because who needs performance, accurate display of images, or subpixel antialiasing of fonts? Fortunately, they have relented on this too and a fractional scaling protocol got merged. Unfortunately, it basically obsoletes a core protocol field.

It's a whole repeating pattern: Wayland starts out with a weird and inflexible design -> Wayland devs try to make the whole Linux ecosystem conform -> they start backtracking after years of pressure, but now they have to add cruft/workarounds to the protocol. Happened to forced VSync, integer-only UI scaling, the compositor-driven render loop with no visibility hints, client-side decorations only... At this rate, Wayland will be full of obsolete cruft before it even overtakes X11 in popularity.

Wayland and systemd are two topics that I credit with showing me that I shouldn't give too much weight to the consensus on Hacker News and Reddit. Things turned out opposite to the prevailing sentiment at the time.

systemd faced an enormous torrent of criticism for replacing the simple sysvinit with something more complex. Yet, sysvinit was only simple if you focus on the init program only instead of taking a systemic view. Under sysvinit, if you wanted to turn a regular command-line program into a daemon, you had to code a whole dance of closing file descriptors, sanitizing environment variables, forking, calling setsid, forking again, resetting the umask, and so on [0]. You had to make sure that all code writing to the standard output and error streams was changed to use the syslog. You also had to manage a pidfile in a way that was free of race conditions. People would write the same logic over, and over, and over again in different projects and programming languages.

On the admin side, a server system with a sophisticated configuration that involved starting daemons when a connection arrives, automatic restarting, e-mailing on error, and so on, could easily turn into a complicated maze of interacting programs and shell scripts. To get the full picture of how a daemon is actually managed, you would need to check many config files with completely different syntaxes.

systemd has greatly reduced this pointless duplication of effort by centralizing the complexity into a single, well reviewed set of implementations. Now, you can take a small program that runs in the terminal and prints log messages to stdout and, with a single INI-like file of a dozen lines, turn it into a daemon whose process supervision is better than anything you could implement yourself. The ease of configuration encourages you to add features such as automatic restarts, resource limits, or dynamic users, which you probably wouldn't have done on sysvinit because it was a pain in the ass.

Wayland, until recently, almost universally praised, but it does the opposite. In order to keep the protocol pristine, it just pushes complexity onto everyone else and ends up making the situation terrible from a systemic perspective. Wayland can push video from a regular program (client) to a privileged one (compositor), but when asked about pushing video the other way to record the screen, they went "not my problem" so pipewire has to handle it. There is no longer even a set of standard command-line utilities you can expect everywhere. On X11, you can type a setxkbmap command to tweak your keyboard layout at runtime regardless of the desktop environment. You can get information about the connected monitors with an xrandr command. In Wayland, every compositor has its own way of handling these, and sometimes you can't even change a keyboard setting without restarting the compositor. What a regression and a blow to the community of tinkerers who like to share small utility scripts with one another.

These are just two examples, but I don't think that Wayland's approach of targeting specific use cases, instead of providing a set of general tools, can ever work well when combined with its bureaucratic approval process. It took years of asking before Wayland devs decided that maybe the user should be able to disable VSync after all. It also took years to backtrack from the bizarre choice of making the UI scale integer only instead of just exposing the real fraction set by the user.

[0] For details, see https://www.freedesktop.org/software/systemd/man/latest/daem...

I'm guessing that your intention was to show us https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 ? It would be better to submit the direct link to the post than to make people scroll through the whole page in order to guess which post you meant.

> During these frenzied moments we almost need a forked HN homepage where the trend of the month is cordoned off to prevent contagion.

I wish dang would just disable registration for a week or two when this kind of thing is happening. It attracts low-value commenters who only want to talk about drama, pick fights in the comments, and ban evade. We even have one such commenter in this thread. I'm sure people who actually want to discuss technology would wait until registration is reopened.