They’re not awesome when your workflow revolves around the command line and you’re stuck choosing between wasting days trying to layer your configuration on top of the project devcontainer or giving up and using the unconfigured bash shell included.

The Darwin kernel is based on BSD… sort of. It’s a monstrosity hybridization of an ancient version of BSD and the Mach kernel.

You should do dev work in devcontainers anyway.

Devcontainers work for Visual Studio Code when developers are more than happy to click their way through running builds and debugging problems. But, as someone whose workflow is optimized for the command-line, they can fuck off.

If people don’t push back on this, you might not even be able to do it the way you choose even with a laptop. Unless you choose Windows… or Ubuntu maybe.

I disagree. This is a first step towards something far worse.

It sets up the infrastructure for getting user ages and allowing services and websites to get an attestation from the operating system. Once that system is widely used and becomes ingrained, they can create a follow-up bill that demands the attestation be cryptographically verifiable by a trusted party.

In that scenario, the only way the operating system’s promise that you’re not a minor would be trusted is if it was signed by whoever holds the private keys—and that’s definitely not going to be you, the device owner.

It would either be the government, or more likely, the operating system vendor. In the former case, now services can cryptographically prove that you’re a resident of $state in $country, which is amazing for fingerprinting and terrible for anonymity. In the latter case, you can guarantee that only the corporations will be holding the key (like with Microsoft and secure boot), and you can kiss goodbye to your ability to access services on FOSS operating systems like Linux or custom Android ROMs.

This proposal is just a way to get their foot in the door with something palatable. If you’ve ever come across banking apps on Android using Google Play Services’ SafetyNet feature to restrict access to only “secure” devices, you’ll know exactly how this turns out: either you use the phone you own the “approved” way with a stock ROM where Google has more permissions than you do, or you’re not doing your banking on your phone.

It’s like Secure Boot but actually, 100% useless.

Well, that explains a lot about the product quality. Their entire development workflow is a complete fucking mess.

• Long-lived feature branches.
• Creating merge commits to main just for the sole purpose of tagging them as releases while also maintaining separate release branches.
• Force-pushing tags to incorporate post-release hotfixes instead of releasing minor patch updates.
• Taking bugfixes from releases and merging them back into the development branch (have they not heard of cherry-pick?)
• Always using merges even when a rebase would be easier to follow and keep the history more straightforward.

Yoshi’s Wooly World Cook’s Fuzzy Fone

A hash is at least consistent when given identical inputs. What they created is more like a digital incinerator.

Historical context, delivery, and handling.

HUP—hang up—is sent to indicate the TTY is closed.
TERM—terminate— is sent by request.

What happens when received is usually up to the process. Most of them just leave the defaults, which is to exit.

There’s a whole lot of entitlement going on in that thread.

If the maintainers didn’t want to merge it because they had bigger issues to worry about, that’s that. Whining about it and trying to pressure them with prospects of “becoming obsolete [if you don’t merge this]” isn’t going to make a convincing argument.

They should either shut the fuck up and learn to RTFM, or maybe consider putting their money where their mouths are by actually paying to support the projects they seem to so desperately think they have a right to influence the direction of.

I didn’t want to make it sound too scary 😉

Seriously, though, git really needs an option to treat --force as --force-with-lease. In the exceedingly rare occasion where I might want to completely overwrite a branch, it should be extra explicit by having to type something like --force-and-overwrite.

Solution:

git commit --amend
git push --force

Problem:

The process of discovering best practices on how to keep a clean git history is a goddamned challenge.

I’d be surprised if it’s not easy to transpile a Markdown document into the format

By hand—if you have experience writing roff typesetting—it is.

Having a program do it for you… you’re going to get something, but it won’t be correct and you will need to fix most of it.

A few problems come to mind:

1. It’s a macro-based typesetting language. As a consequence, there’s a one-to-many association between representations in Markdown with some equivalent in roff. A Markdown paragraph is just a paragraph, but in roff it could be an un-indented paragraph, a paragraph with first-line indentation, a paragraph with line-wrap indentation, or a paragraph with a left margin.

2. Rendering a man page, you have multiple different implementations of man and multiple different implementations of *roff (roff, troff, groff, nroff). The set of macros and features that are available differ depending on which implementation, resulting in one-size-fits-all solutions targeting the lowest common denominator.

3. Ironically, the one-to-many association goes both ways. With Markdown, you have code fences, quotes, italic text, bold text, and tables. With lowest-common-denominator manpage roff, you have paragraphs and emphasis that will either be shown as bold or inverted. If you’re lucky, you might also be able to use underlines. If Markdown tables are no wider than 80 characters, you could preprocess those into plain characters, at least.

4. Despite being more structured with its typesetting, the contents of a manpage are mostly still unstructured. The individual sections within the page and its use of indentation and emphasis are entirely convention, and not represented in the source code by anything more than just typesetting macro primitives.

It could work out if you generate both the Markdown and man page from something with more explicit structure. If the plan is to go from a loose Markdown document into a manpage, you’re going to end up having to write your Markdown document almost exactly like a manpage.

Don’t forget to add incompetent leadership to that list. If feature needs to be shipped by some arbitrary deadline and the engineers are forced to rush through the design process, you end up with a patchwork hack of tech debt that leads to more tech debt.

How’s the weather up there, on your high horse?

Rust wasn’t meant to be the be-all, end-all solution to safety and soundness; it’s meant to be better than the alternatives, confining potential memory safety issues to explicitly-annotated unsafe blocks.

But, hey. That’s okay. With that kind of gloating attitude, I’m sure your code is 100% safe and vulnerability free, too. Just remind me to never step foot anywhere near an industrial system or operating system using it.

Well, now that’s just inaccurate. The hundredth-time programmer isn’t going to use a rake; the hundredth-time programmer is going to use a tool::basic_tool<tool::manual_operator<species::human_t>,tool::handle_type::wood,tool::pronged<5>>.

It doesn’t work like that. They use the self-reported user agent from the web browser that is requesting the page.

Many Mods are high on “authority” and ban for incredibly asinine reasons

The recent drama around r/art exemplifies this.

The attack was coming from ::1

Or if that’s too unbelievable, fe80:: has some scary implications while also not likely to ever be a real device.