Which then, inexplicably, pulls left-justify as a recursive dependency.

The dependency cycle is actually the functional mechanism of the code, because they subvert the dedup mechanism in the package manager using a random generation trick. Each recursive copy of the dependencies takes up a little bit more space, which ultimately gets converted to the spaces inserted into the original datum; the caller is expected to adjust the cache settings to signal the desired amount. That's also why if you're using left-justify to process strings, Yarn is recommended for best compatibility. /joke

So you're saying dependency resolution is Turing complete?

The lessons in that book have broadly held true for nearly every single one of my employers throughout the entirety of my career.

A single datacenter having the requisite power to travel back to 1955 many times over seems pretty meaningful to me.

When I was a kid my stepdad was big into amateur rocketry, so we'd go to a lot of launches, including at Black Rock. One of them (could've swore it was LDRS, but given the timeline it would've had to have been XPRS or maybe BALLS) was at the same time that Burning Man's MOOP crew was doing their thing, and that was my exposure to how much work goes into preserving the playa for future users/visitors (including us). It's impressive to watch, even from long distance via binoculars. Of course the rocket launches have similar requirements, but they involve a lot fewer than 70,000 people (but on the other hand, a much larger area of potential litter, given that rockets fly far and sometimes don't come down in one piece).

I live in Reno nowadays, and the locals either love or absolutely despise Burning Man, in the latter case for good reason: while Burning Man as an organization clearly cares a lot about “leave no trace” (as I've gotten to see firsthand), the Burners themselves have a tendency to leave pretty giant traces throughout Reno. A big one is bikes getting left behind (by people who don't want to deal with a bike caked in excruciating-to-fully-clean playa dust), and there's a whole supply chain of companies here that'll find those dumped bikes (or encourage Burners to bring them directly), clean 'em up, fix 'em up, and resell them (often back to Burners the following year; rinse and repeat). A lot of other, less-lucrative-to-refurbish-and-resell stuff unfortunately ends up clogging up every dumpster in town.

Since when are SOC audits not a meaningful thing?

If soc audits are driving your development process you are doing it backwards. And _certainly_ a time is coming when just using the llm will be soc compliant.

SOC2 is generally regarded as a joke and has in fact almost nothing to do with software resilience even on its own terms.

A joke or not, a lot of organizations take SOC compliance and auditing seriously. Responding to someone requiring it with “who cares, the accountants doing the audits don't know anything anyway” is unlikely to go well.

I'm intimately familiar with SOC2 and I'm telling you it has practically nothing to do with software security and to the extent it does, the story is improved starkly and mechanically by agents. That's an outcome of how superficial SOC2 is, not a statement about how good agent code is.

Of course, the reality is that competent orgs generally exclude virtually all their software from their audit scope, and it would be a mark of incompetence to loop tooling-grade or line-of-business backoffice code into it. But even if you were crazy enough to do that, agents would improve your outcome.

Anybody claiming that SOC2 is a reason agent-based code will falter is talking about the world as they want it to be, not as it is.

Your word for “competent” seems to be my word for “irresponsible”. A failure in that “line-of-business backoffice code” is exactly the sort of thing that'd cause irreparable damage in terms of regulatory compliance (and, you know, the tangible harms those regulations are meant to prevent). An LLM hallucination introducing bugs that make ERP transactions spontaneously disappear or allow users to bypass permissions checks on sensitive documents is the sort of thing that's catastrophic for any business that's not actually just a money laundering front (and hell, even then). Maybe you trust agentic AI to make fewer mistakes than humans, but I sure don't.

Like, I'm trying to avoid hyperbole here, but you're advocating for a wild-west sort of attitude that can, will, and has gotten people severely defrauded or outright injured/killed. And I know you know better than this because you've written at length about what it took to achieve SOC compliance at your current employer.

I believe that if you read what I wrote about that you'll see it's consistent with what I'm saying here.

> I doubt this is an Edge-specific issue.

It absolutely ain't Edge-specific. Firefox (AFAICT) also keeps stored passwords in clear-text unless encrypted with a passphrase (which is not the default on desktop; on Android there's a fingerprint/PIN check to access them, but I don't know offhand if there's any encryption involved with that).

Really this is true of most credentials stored within applications; unless you're providing a decryption key on open (whether explicitly or on OS-level login using some keychain mechanism), the stored credentials are probably plaintext.

Or unless you need to reenter password/offer fingerprint after certain amount of time. Which, I think, should be the actual standard, and typically is with the apps like Bitwarden.

Probably based on insider info to some degree; if you already do any sort of work for the DoD, then that tends to help narrow the scope of the search for vulnerable things to exploit.

I feel like the better solution here (than trying to shoehorn a GUI into an interface meant for text) is to make terminal windows graphically-aware, like how things work in Plan 9.

I already do use tiling window managers and they don't really accomplish the “if you launch a graphical app in a terminal window it takes over that terminal window” flow. Closest I've found is Niri's support for tabbed windows, but even that's just sticking the graphical app window on top of the terminal window instead of the terminal window itself becoming the app window.

Depends, I'm building a markdown down editor that just previews in the web ui. However, I can use the web ui to do tasks like uploading files, view git commits etc. Different interfaces for different purposes. The CLI gives me focused mode, and then visual stuff that steal my time goes in the web

Any keyboard can type “→” if you set up a compose key :)

Perfect timing. I'm expecting to get my hands on a MOTU MIDI Express XT from my local Guitar Center within the next couple days (I paid for it when it arrived there a couple weeks ago, but they have a mandatory waiting period on used equipment to make sure it ain't stolen), which unfortunately uses some weird proprietary protocol instead of class-compliant MIDI-over-USB — so any use over USB from my PCs (nearly all of which are running Linux, OpenBSD, Haiku, or something other than Windows or macOS) is a no-go. This is okay for my immediate use cases (I just need it to route between some synth modules and controllers, without necessarily needing the PC to do any processing in-between), but it'd be cool to get the PC side of things working, too.

There's an existing out-of-tree Linux driver¹ that looks promising, but AFAICT it only does the bare minimum of exposing the MIDI ports for use with e.g. JACK, and it's also unclear how stable it is and whether it really does support the XT (the README says the kernel panic got fixed, but there are open issues about it; the README says the XT's supported, but there are open issues about that, too). I'd like to be able to create new routing presets and stuff like what the proprietary companion app can do, and I'd also like to be able to use the thing without needing to shove extra drivers into my kernel, and I'd also like to be able to use the thing on my OpenBSD and Haiku boxen, so I've been perusing LibUSB docs since a userspace USB driver that then presents the relevant MIDI ports and some tooling to reroute the MIDI ports as desired seems like something useful. This article happens to be exactly what I've been looking for w.r.t. a starting point for such a userspace driver.

----

¹: https://github.com/vampirefrog/motu

I packaged that driver on the AUR, since I’ve got the same device. I can’t get the binary blob to work (admittedly, I haven’t tried very hard) and it’s not high on my list of priorities so I’m okay using it as a dumb MIDI tool.

I could be misremembering but I believe the guitar center waiting period isn't _just_ to make sure it's not stolen (I kind of doubt they're actually doing anything like an investigation) but also because legally their used equipment side of business has to operate like a pawn shop, in that they aren't allowed to sell something they've "bought" until after the window for the pawner to buy it back expires.

I have had significant success using Claude to reverse engineer hardware

Yes Claude is impressive in HW-Development. It knows all those magic numbers and how chips work. i even use it to do development for Power delivery Systems.

hope nothing goes wrong with it