drysart

WSL Containers and Hyperlight are two of the available backends for MXC. MXC is not a replacement for them -- it is not an isolation technology itself, it's a unified management API for leveraging other isolation technologies.

You can use the same API to configure and run code in a WSL Container as you would to run them in an LXC container on Linux, or Seatbelt sandbox on MacOS; or in a MicroVM or a Hyperlight VM.

> Those who understand technology to verify arguments already exists can only come to the conclusion we'd be better of with formal verifiers in legal systems.

Those who understand law know that formal verifiers cannot replace a judge, because every facet of law (the writing of it, the interpretation of it, the application of it, and the enforcement of it) has to account for all the vagueries of human existence.

No formal verifier can account for definitions that need to expand as the scope of human endeavor expands. No formal verifier can determine mens rea. No formal verifier can determine if something is obscene. No formal verifier can determine someone's mental competence. No formal verifier can cover all mitigating factors. No formal verifier can apply mercy where mercy is needed.

You can kinda get close in pure CSS with CSS media queries using the resolution query on dppx measurements; but that only allows you to be as granular as however many distinct "dots per CSS pixel" values you want to add media queries for. Something like this would let you scale by device resolution for both traditional 96dpi screens, higher DPI 192dpi screens, and super high resolution 288dpi screens:

    body { --resolution-scale: 1; }
    @media (min-resolution: 2dppx) { body { --resolution-scale: 2; } }
    @media (min-resolution: 3dppx) { body { --resolution-scale: 3; } }
    .myPixelSizedElement { width: calc(96px * var(--resolution-scale)); }

But unfortunately there's no way to directly use the devicePixelRatio value you can read from Javascript directly in a CSS calculation to be able to get a precise scaling on any arbitrary pixel density.

It's tempting to look at it that way; but that's being over-reductive. UIs of today are not the UIs of 20 years ago. Users expect much more from today's UIs, and UI toolkits necessarily get more complex as a result in order to deliver on those increased expectations.

And if you don't agree, this is Windows we're talking about. Nothing's stopping you from creating your application with Win32 except for the fact that it's going to look and feel like an application from 20+ years ago.

Not as much of a lack of seriousness as excusing away hallucinations as not that big of a deal in what's supposed to be a researched, scholarly body of work written by humans.

Not the author, but:

> how do you exactly know how javascript works inside out?

Javascript has pretty detailed specifications. They're not exhaustive, but the article here does mention that in some of the dark corner cases they compared behavior against other existing Javascript engines.

There's also a very comprehensive test suite (Test262) that comprises almost 40,000 unit tests that exercise various aspects of the language that a new implementation can use to get a pretty good view of how much their new engine conforms to the specification.

> I sat through a conference session in the late nineties trying to understand the difference between an OLE document, a COM object, and an ActiveX control.

To be brutally honest, if you were a serious Windows developer in those days (and you were even the sort who'd have sat through a conference session on the topic); there is absolutely no way in hell you'd not understand the difference between OLE, COM, and ActiveX. Conflating these things as some sort of confusing mess either shows a lack of actual experience, a lack of competency, or a desire to falsely make things seem more confusing than they were to add some meat to an article.

This article dances with some good points, but opening up with this sort of hyperbole (and then ending it with an unabashed AI slop image filled with brand new hallucinated characters of the alphabet) just totally tanks the author's reputation.

This particular vehicle was sold at an impound auction under a court order. Any existing legal ownership of the vehicle prior to the auction was extinguished.

There was a software package a couple decades ago, I want to say it was Lotus Notes but I'm pretty sure it wasn't actually Lotus Notes but something of that ilk, that would show a small, random number of asterisks corresponding to each character entered. So you'd hit one key and maybe two asterisks would show up on screen. And kept track of them so if you deleted a character, it'd remove two.

I thought that was kinda clever; it gives you feedback when your keystrokes are recognized, but it's just enough confusion to keep a shoulder surfer from easily being able to tell the length of your password unless you're hunt-and-pecking every single letter.

It's not React. It's React Native. React Native and React are about as similar as JavaScript and Java.

React Native is a way of orchestrating a UI comprised of native controls.

Hopping in here to suggest that instead of running a persistent whole-ass daemon, you could just configure a systemd service, set it up to trigger off a write to a fifo, and then use filesystem permissions to restrict access to who can write to the fifo to whatever user/group should be allowed to perform the operation. (You can also do it by giving those users sudo access specifically to be able to trigger the service via systemctl; but if our goal here is to eliminate the use of setuid then any solution that uses sudo fails the assignment).

The systemd service executable is just your simple C program as-is.

Persistent whole-ass daemons aren't really the way it should be done even over in Windows, because in Windows you can attach ACLs to give permissions to start a Windows service to any arbitrary users that should be able to do so; which is spiritually equivalent to the Linuxy systemd solution.

I mean it's a dog so you can't exactly ask them; but this was a dog that would bark at every other dog. If he wasn't barking at Hooch because Hooch was only showing up at 24 FPS, then I'm inclined to think he didn't recognize Hooch as another dog.

It's about being able to perceive it as a "living" moving creature and not something different.

You can understand something below the perception threshold is supposed to be a creature because you both have a far more advanced brain and you've been exposed to such things your entire life so there's a learned component; but your dog may simply not be capable of making the leap in comprehending that something it doesn't see as living/moving is supposed to be representative of a creature at all.

I've personally seen something adjacent to this in action, as I had a dog over the period of time where I transitioned from lower framerate displays to higher framerate displays. The dog was never all that interested in the lower framerate displays, but the higher framerate displays would clearly capture his attention to the point he'd start barking at it when there were dogs on screen.

This is also pretty evident in simple popular culture. The myth that "dogs can't see 2D" where 2D was a standin for movies and often television was pervasive decades ago. So much so that (as an example) in the movie Turner and Hooch from 1989, Tom Hanks offhandedly makes a remark about how the dog isn't enjoying a movie because "dogs can't see 2D" and no further elaboration on it is needed or given; whereas today it's far more common to see content where dogs react to something being shown on a screen, and if you're under, say, 30 or so, you may not have ever even heard of "dogs can't see 2D".

The use cases for YAML that don't involve any sort of scripting vastly outnumber the use cases for YAML that involve embedding scripts into a document; so it's a little unfair and inaccurate to say that "in YAML it's kind of expected".

It is more fair to say that if your document needs to contain scripting, YAML is a better choice than JSON; for the singular reason that YAML allows for unquoted multiline strings, which means you can easily copy/paste scripts in and out of a YAML document without needing to worry about escaping and unescaping quotes and newline characters when editing the document.

The more SKUs you have, the more digital shelf space you get on a shopping website. When your sole differentiating factor from your competitors is that your laptop has an "HP" logo on it and theirs has a "Dell" logo on it, your only effective strategy is to try to make sure fewer laptops with "Dell" logos on them show up above the fold in Amazon search results by creating lots of distinct SKUs to try to eat up as many of the slots on that first page of search results as possible.

Apple doesn't have to exist in that type of competitive environment. If you want a Mac, you're either getting it right from store.apple.com; or you're searching for Macs specifically -- in both cases, Apple owns all of the shopping screen real estate.