zanecodes

We were making great progress under the previous administration until six months ago, yes.

Nothing was compromised. A bunch of Windows systems were unable to boot. https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_ou...

Well, I hate Microsoft as much as the next person, but I'm not sure "writing a buggy kernel module can crash the kernel" is much of an indictment of Windows in particular...

CrowdStrike is not made or owned by Microsoft.

The first sentence of that paywalled article links to TFA.

The Dell Streak (shoutout to the other 3 people who bought one) had a 5 inch screen in 2010, a notable jump from contemporary phones like the iPhone 4 which was still 3.5", and other Android devices like the HTC Droid series which were around 3.7" and slowly starting to creep upwards to differentiate themselves from the iPhone. I think the largest Android devices you could get at the time were still smaller than 4".

I thought all the cool kids were on Pijul, or was it Darcs? Maybe it was Fossil? No wait, it was definitely Jujutsu.

I agree, Hyper-V is a pretty cool technology! I wasn't aware WSL1 was still supported at all, let alone receiving pull requests. Windows Subsystem for Android was a neat feature, but not something I used regularly, especially since it lacked Google Play Services which made many popular apps fail to function on it.

I understand that, but I think for an operating system it's more valuable to provide stability for applications than to be able to move fast.

Secondarily, do the same issues not apply to the Linux API as to a hypothetical ABI? If the API changes, don't userspace applications still need to be updated and/or recompiled accordingly, or suffer breakage? At some level, whether it's an ABI, a statically linked API, or a dynamically linked API, there always has to be some interface between applications and the operating system, and breaking changes to that interface must be managed with care.

It comes down to where you decide to draw that interface, and I think the ABI is just a better place to draw it from a user's perspective. This way, applications don't need to be recompiled to work on newer operating system versions, and given how challenging and painful it can be to compile applications reproducibly, and how many applications are only provided in binary form to begin with, this seems like a worthy goal.

I'm convinced that the lack of a stable ABI and the lack of a hardware abstraction layer (requiring drivers to be in the kernel source tree) is what's preventing The Year of the Linux Desktop from ever arriving. I understand the principles behind both decisions, but at some point I think pragmatism should win out. I guess I'm just a bit surprised that no distro has taken up the mantle of providing these things; it seems to me it should be possible to build a stable ABI and HAL on top of the existing Linux kernel.

Docker on macOS also runs a Linux VM under the hood, just like WSL2 does, they're no different in that respect. WSL1 used the more exotic approach of translating Linux system calls to and from NT kernel system calls, but for various reasons (compatibility, performance, complexity) Microsoft abandoned that technique and adopted a Linux VM running under the Hyper-V hypervisor for WSL2.

Maybe companies should provide some sort of incentive for the juniors they trained to stay with them. As it is, the obvious and rational choice is always to leave for another company that will pay you 25% more whenever you feel undervalued.

It has not been cancelled as of now, the cancellation has only been proposed, not passed.

We have one in Baltimore which also offers classes and workspaces: https://toollibrary.org/

The non-standard library, if you will.

"The major problem—one of the major problems, for there are several—one of the many major problems with governing people is that of whom you get to do it; or rather of who manages to get people to let them do it to them.

To summarize: it is a well-known fact that those people who must want to rule people are, ipso facto, those least suited to do it.

To summarize the summary: anyone who is capable of getting themselves made President should on no account be allowed to do the job."

- Douglas Adams

For the curious, the graphs in question: https://daughternumberthree.blogspot.com/2020/01/graphing-re...

Good find, I currently have an aging Pixel 6a (with, regrettably, no headphone jack) but I like Motorola's hardware and their fairly vanilla Android. I may consider a Motorola device, if they provide updates for at least 5 years.

Thank you! I'm not a huge Samsung fan, their Android flavor doesn't appeal to me much, but I'm glad that someone is still making phones with headphone jacks. USB-C adapters are mostly fine, but I like being able to charge and listen to music at the same time without a clunky adapter, it's yet another thing I'll lose.

What phone still has a 3.5mm headphone jack? Sincere question, I'd like to buy one.

Closing your eyes is always an option, if you're trying to think deeply and without distraction. It helps a lot to explain your stream of consciousness as you think, even if it's disorganized, and you're definitely not cheating if your eyes are closed!

I would love a feature like retention policies at the filesystem level. If it could somehow take data provenance into account, that would be even better, i.e. data that I've created directly is irreplaceable and should never be deleted unless I say so and should always be backed up (photographs, writing, project source code, art, game save files, my list of installed applications, etc.); data that I've created indirectly is high priority but may be deleted under certain circumstances or may be omitted from backups (browsing history, shell history, recently opened file lists, frequently used app lists); data that can be easily replaced is low priority and may be cleaned up at any time and need not be backed up at all, contingent on how replaceable it is (application files, cached data).

Only if you didn't run `uv lock --script` [0] and commit the lockfile. If you don't want that second file sitting next to the script, you could instead specify an `exclude-newer` timestamp, and uv won't resolve any dependency versions newer than that.

It might be cool if uv ignored dependency versions newer than the script's last modified timestamp, but this behavior would probably need to be very explicit to avoid the situation where a working script is mysteriously broken by making an innocuous change which updates its last modified timestamp, causing uv to resolve a newer, incompatible dependency version.

[0] https://docs.astral.sh/uv/guides/scripts/#locking-dependenci...

Presumably by configuring the system-level HTTP proxy settings to point to a tool like mitmproxy or similar running on a machine on their LAN, and then installing a locally signed root CA certificate generated by the proxy, to enable it to decrypt TLS connections. I'm not familiar with the process on iOS, but it's pretty straightforward on Android. Some apps bundle their own root CA certificate (see "certificate pinning") and ignore the system certificates, which defeats this method unless you can decompile the app package, replace the bundled certificate with your own, and recompile/sideload the modified package. It's also possible they statically analyzed the app package to discover URLs.

Similarly, older versions (<3.0) of the provider had a `build` attribute for the `docker_registry_image` resource, which made it possible to build and publish an image to a registry, without causing unnecessary rebuilds if there was no local version of the image on the build host.

Now you have to use the `docker_image` resource to build a local image on the build host, and then use the `docker_registry_image` resource to publish it to the registry. In a CI/CD scenario with ephemeral runners, there will never be a local version of the image on the build host, so the image will always be rebuilt on every Terraform run, even if there are no changes to it.

It's a tricky problem to solve from a provider design standpoint, since building a Docker image necessarily creates a local Docker image on the build host, which may not be a desirable side effect for the `docker_registry_image` resource to have and raises other design questions with no universal answers (Should it delete the local image after building? What if there's already a local image with the same name/tag, but it's not in the Terraform state; should it use the existing one or build a new one and overwrite the existing one? If the `docker_registry_image` resource is removed, should any corresponding local images also be delete? etc.)

What percentage of USD transaction volume is made up of scams, fraud, Ponzi schemes, and extortion rackets? What percentage of BTC?

I agree, I feel like Nix is kind of a hack to work around the fact that many build systems (especially for C and C++) aren't pure by default, so it tries to wrap them in a sandboxed environment that eliminates as many opportunities for impurity as it reasonably can.

It's not solving the underlying problem: that build systems are often impure and sometimes nondeterministic. It also tries to solve a bunch of adjacent problems, like providing a common interface for building many different types of package, providing a common configuration language for builds as well as system services and user applications in the case of NixOS and home-manager, and providing end-user CLI tools to manage the packages built with it. It's trying to be a build wrapper, a package manager, a package repository, a configuration language, and more.

I've always thought it would be nice to have a language whose spec describes a few different "power levels":

1. Literal values only (objects, arrays, strings, numerics, booleans, maybe datetimes), a la JSON, with standardized semantics

2. Literals, variable definitions and references, pure function definitions, and pure function calls, but prohibiting recursion, such that evaluation is not Turing-complete and any value is guaranteed to be able to be evaluated into its literal form in finite time

3. All of the above plus recursion and impure, side-effectful functions, custom type definitions, etc.

This way, implementing a literal parser in other languages would be comparatively straightforward (much like JSON), since it wouldn't have to support variables or functions, but it would also be possible to define values using variables and pure functions (much like HCL or Nix) and then use the language's own evaluator binary (or perhaps a wrapped FFI library) to safely convert these into literal values that another language can parse, while guaranteeing that evaluation will not have side-effects. It would also leave open the escape hatch of using a "full" Turing-complete language with side-effects and recursion, while ensuring that using that escape hatch is a deliberate choice and not the default.

I'm sure there are a few additional or hybrid levels that could be useful too (2 but with recursion? 1 but with variables?) but this seems like it would be a solid starting point.

A signed commit can only prove that the owner of a key did make a particular commit, it can't prove that they didn't make a commit, for instance by using some other undisclosed key.

One solution could be adding a `sort` argument (which takes a function that compares two `<T>` items and returns `true` or `false` depending on their order) to all functions on unordered collections of `<T>` items in which an order must be chosen, or requiring that the items in such collections implement a `TotalOrder` interface or something similar. This isn't very ergonomic in languages that don't have an equivalent of Traits or typeclasses though. In languages which permit side effects, this would include any functions that iterate over the items in an unordered collection.