You can never really go home.

Fuck.

$0.02: Whenever it’s an immediate gut reaction with a disproportionate response like that, it’s un-diagnosed trauma; the stimulus is a trigger. Sad part is, “fixing” that involves access to really good healthcare, and a strong will to change one’s self in order to not feel like that anymore. What’s worse is that, statistically speaking, the abuse is usually perpetrated by someone they know (e.g. family member), which makes it extra hard to accept and overcome.

Meanwhile, we have free support systems (e.g. “religion”, TV, Social Media) that encourage and directly exploit mal-adaptive behavior and triggers.

I agree. Rather each one of those is rather substantial on its own. Plus the churn of going from framework to framework makes it less useful to compress and bundle all this stuff into fixed versions on a slower schedule (e.g. like Ubuntu packages do). I think that all contributes to bloat.

Kind of. They do center on code generation, at the end of the day. That’s where the similarities end. You can’t insert macros into your code arbitrarily, nor can you generate arbitrary text as an output. Rust macros take parsed tokens as input, and generated (valid) code as output. They must also be used as annotations or similar to function calls, depending on how they’re written. The limitations can be frustrating at times, but you also never have to deal with brain-breaking #define shenanigans either.

That said, I’ve seen some brilliant stuff. A useful pattern is to have a macro span a swath of code, where the macro adds new/additional capabilities to vanilla Rust code. For example, here’s a parser expression grammar (PEG) implemented that way: https://github.com/kevinmehall/rust-peg

Just the fact that we can have a whole contest around the idea, and that there’s still room for words contestants haven’t seen before, illustrates just how insane English is.

You say that, but I’ve watched the JS community move from one framework and tool suite to the next quite rapidly. By my recollection, I’ve seen a wholesale change in popular tooling at least four times in the last decade. Granted, that’s not every developer’s trajectory through all this, but (IMO) that’s still a lot.

I used to struggle with this, until I realized what’s really going on. To do conventional web development, you have to download a zillion node modules so you can:

• Build one or more “transpilers” (e.g. Typescript, Sass support, JSX)
• Build linters and other SAST/DAST tooling
• Build packaging tools, to bundle, tree-shake, and minify your code
• Use shims/glue to hold all that together
• Use libraries that support the end product (e.g. React)
• Furnish multiple versions of dependencies in order for each tool to have its own (stable) graph

All this dwarfs any code you’re going to write by multiple orders of magnitude. I once had a node_modules tree that clocked in at over 1.5GB of sourcecode. What I was writing would have fit on a floppy-disk.

That said, it’s kind of insane. The problem is that there’s no binary releases, nor fully-vendored/bundled packages. The entire toolchain source, except nodejs and npm, is downloaded in its entirety, on every such project you run.

In contrast, if you made C++ or Rust developers rebuild their entire toolchain from source on every project, they’d riot. Or, they would re-invent binary releases that weekend.

My reaction as well. I was just fine living out the rest of my life, not having to see that smugshot again. But here we are.

What can’t they do?

Stay intact after exposure to UV radiation. It’s good plastic, but it’s not that good. Stay safe out there.

Yes. It really sells the whole “latch-key-kid” experience for improvised nachos. We don’t have proper ingredients on hand, and are also inexplicably out of clean plates and paper towels, so here’s Tostito’s cups and pre-shredded cheddar microwaved on yesterday’s homework. Tastes like loneliness, neglect, and “I wonder when dad’s getting home?”

It never even occurred to me that people might have an advanced mnemonic toolbox for things like this. I know the basics, but this is just a new level.

The only oddball thing I’ve used, involuntarily and entirely by accident, is “the method of loci”. It’s fantastic… when it works.

Rust […] could use a higher level scripting language, or integrate an existing one, I guess.

One approach is to use more macros. These are still rooted in the core Rust language, so they give up none of the compile-time checks required for stability. The tradeoff is more complex debugging, as it’s tough to implement a macro without side effects and enough compile-time feedback that you’d expect from a DSL.

Another is to, as you suggest, embed something. For example, Rust has Lua bindings. One could also turn things inside out and refactor the rust program (or large portions of it) as a Python module.

My plan is to quickly go limp.

Solid strategy. It’s your only defense.

Thank you.

I once showed that trick feature - opening the terminal - to an Apple Genius Bar employee once. His brains almost fell out of his ear he was so surprised.

I was convinced of this years ago. This was as true now as ever, with the rate of compromised, a-moral behavior being well above chance, it defies any consideration of mere coincidence. The idea of a political party not conducting background checks on candidates it endorses would be lunacy, so we’re left to conclude that they’re either a very forgiving bunch, or prefer dirtbags they can control.

Where things get interesting is that it may not work forever. Epstein thought that manufacturing dirt on the rich and powerful was enough to keep his operation going, and save his neck, all at the same time. That didn’t exactly pan out for him. This makes me wonder if such a scheme really is tenable when playing at that power level.

It’s been a hot minute, but here’s what I recall.

Take a look under /etc/systemd/system/ This is a good place to put custom system files.

You’ll want to add your new foobar.service file here, then run systemctl daemon-reload or systemctl reload foobar to make systemd load the new config file. Then you can run systemctl start foobar and so on.

The rest is up to you and the published docs for the system file itself. My recommendation is to also try to understand daemons you may already use like nginx, apache, postgresql, etc. Their configs can be found by first running systemctl status <servicename> and to look at the Loaded: line. Most of the packaged stuff is hanging out under /lib/systemd/system.

It’s important to have a backbone; put faith in the core of your being. Especially for inter-species negotiations and the occasional order to transport unruly cargo.

Personally, I prefer to have faith of the spine(r).

I appreciate that. And don’t count yourself as less advanced - a lot of folks would consider using a CM tool like Ansible to be pretty wizardly stuff.

You’re not alone. For most of my career, I’ve only used Linux to develop software and deploy that software to production. That usually means webservers, databases, iptables/netfilter, and all the other backend processes that glue that together.

Before systemd, I was using sysVInit. Let me say that systemd has been head-and-shoulders above the previous experience in a variety of ways, with a host of built-in features:

• Predictable start-up order of processes
• Configurable inter-process dependencies (for the above)
• Restart on fail
• PID management
• Socket management
• Standard config format (no more copy-pasta init scripts)
• Clearly defined filesystem areas for package managed and user-managed services
• Clearly defined layering of config areas (e.g. systemctl status <service> shows you exactly what files are loaded)
• Solid CLI experience that provides detailed information about every managed service

Bottom line: it’s dead simple to add your own stuff, and just as simple to read what packaged software is doing. I also think that using a CLI (instead of poking around /var/run and ps output) is a step up in terms of system administration, given how complex all this can get.

My only contention is the forced use of journald, where my preference would be to use the standard /var/log paradigm for all this, rather than have a doorman to a binary logging database. You can configure it to emit text logs, but that’s not the system of record for logging - just a feed.

All that said, container-based solutions have rendered both init systems irrelevant a lot of the time, with tools like Kubernetes providing just about all of the same features. Moreover, cloud solutions tend to lean into cloud-init for host startup configuration and management anyway.