"No bastard ever won a war by dying for his country. He won it by making the other poor dumb bastard die for his country." -- attributed to George S. Patton

No, Texas can (maybe) legally split into up to five new states as long as one is still named Texas (assuming its original admission terms from 1845 still apply and weren't superseded by the terms of its readmission in 1870). Neither it nor its hypothetical child states can legally secede. https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.smithsonianmag.com...

"Publishers have always controlled how their content is made available to Google as AI models have been built into Search for many years, helping surface relevant sites and driving traffic to them. This document is an early-stage list of options in an evolving space and doesn't reflect feasibility or actual decisions." Right, except that that "choice" is "feed the AI Overview, or don't get indexed": https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.bnnbloomberg.ca%2Fbu... Now, it's Google's service and within the law, they can run it however they want. But don't tell me about how much choice publishers have when the choice is as stark as that.

The reason for those originally was it was how you made a box with old typewriters. The reason you still see it is that law firms and the legal profession generally are still one of the most hidebound, "we've always done it that way so we always *will* do it that way" types of employers on the planet. I used to work at a Kinko's (2002-2004) and law firms were the only ones we regularly got WordPerfect documents from. Why? Because the templates they used for filings were all created in WordPerfect 20 years ago and they were still using them and had no plans to change because no lawyer wanted to get yelled at in open court by a judge for filing a brief with the wrong margins or something. It was honestly a miracle most of them were bringing us WordPerfect and not a pile of typewritten originals. They all had very specific binding and covering instructions too, because the court mandated every detail from font size and margins to the paper type and color of the cover on each copy.

Wouldn't work. LLMs have no true concept of meaning -- they don't know what the text of regulation Foo *intends*, or how to express a given intent as a block of code. At best they can extrapolate from, say, having seen training data where similar blocks of text were associated with blocks of code that have some patterns in common, and regurgitate based on that -- but that training data might well have been an example of why the given block of code *doesn't* properly implement the regulatory language, or it might have just been incorrectly asserted to do so, or a hundred other things that mean what the LLM spits out may compile, but still won't be correct. (And it may not compile in the first place, because again, LLMs have no actual concept of meaning or syntax, just patterns they see in their training data.)

It doesn't have to be perfect, just better than what this is, and it is. I put my TLS certificate in my DNS zone with a TLSA record, then sign my zone with my known, published DNSSEC key. Only I can sign my zone with that key and the chain of trust extends from the root of the DNS down to my signed records -- just like the current highly-centralized CA system, except history suggests publishing a malicious DNSSEC key for my domain is a lot harder than getting one of a couple of hundred CAs of varying trustworthiness to issue a certificate for my domain. DANE is a technical measure against malicious activity, where things like this and CAA records are mere administrative advice to authorities -- if you are a CA abiding by CA/B Forum rules, you must not issue a certificate if things don't match up, but nothing actually *stops* you from doing so. DANE is vulnerable to key compromise, but so are DNSSEC and the CA system (in both cases, if I get your private key associated with an issued cert or published public key, I then have everything I need to impersonate you). Another way to look at it is that to guard against the most common subversions of the CA system, you need DNSSEC anyway (to prevent cache poisoning attacks that redirect requests to a malicious site with a compromised or stolen cert). But if you *have* DNSSEC, you can just directly publish your TLS key and take advantage of the already-established chain of trust instead of needing to involve a rent-seeking third party.* * Except that browsers don't support it even though both OpenSSL and GnuTLS do, so just using DANE doesn't provide any security or authentication of your identity for the vast majority of web users today.

The problem is that we all just go along with the idea that a couple of hundred "authorities" chosen by a small cadre of mostly profit-seeking entities are ultimately-trusted by default to issue any certificate for any domain. There are already methods like DANE for authenticating a cryptographic key as belonging to an identified domain registrant that make CAs basically unnecessary in the vast majority of cases -- but your browser doesn't support them because it's overwhelmingly likely that your browser is Chrome, and Chrome doesn't (and won't, judging by history) support anything but the status quo on this, so there's little incentive for other browser makers to do so either.

The public statements are exactly the kind of thing some insecure executive who takes personal offense (for whatever reason, not necessarily because they're personally called out) demands be said - I've seen it from the inside of a few employers over the years. I guarantee you the people inside Facebook whose actual job is crisis communications in situations like this are pulling their hair out because they know this is the worst possible response (and are being overridden), unless they're just incompetent at their jobs.

I have a Fedora install on my main personal laptop and recently I ran into an issue where VS Code complained it couldn't run a Kubernetes plugin because `kubectl` was not in the user's PATH. But I knew it *was* in my path because I use `kubectl` in the shell myself, quite often. Turns out VS Code was installed from a Flatpak; removing the Flatpak install and switching over to installing from the "deprecated" RPMs (from RPMFusion, I think) resolved the issue completely. Quite likely I could have resolved it with some sort of configuration change to the Flatpak, but honestly, I just didn't find it worthwhile to spend the time, as experience tells me it would likely become a train of constantly tweaking the Flatpak config to make it work with one more thing it would just work with in the first place if installed the usual way. The isolation the Flatpak system imposes was the problem, not a solution.

...seven years ago. It seems things have not improved.

...or is DoNotPay just using an army of low-paid workers to provide the service? It's not as though they haven't been caught possibly doing that before.

There has been a belief for literally decades that something other than brute-force scaling will finally bring about a revolution in AI. Time and time again, AI research tries to use some form of applying human knowledge to constrain a problem space and make solutions more efficient, but ultimately statistical methods based on just throwing more compute at the problem win out. It's repeated so many times that one of the recognized leading figures in the field, Rich Sutton, wrote an article five years ago called "The Bitter Lesson of AI" where he lays out the history of the field failing to learn this pattern time and time again.

Have *you* read the manifesto lately? Because it literally says "Welcome changing requirements, even late in development." Your comment actually exemplifies the biggest problem Agile as a movement has: whenever something about it is pointed at as causing a problem, even core principles of what Agile is supposed to be, the response from Agile partisans is always "if that's causing you problems, you're not doing Agile right". There is never any circumstance in which they will admit that Agile isn't the very best development method because their answer to any demonstrated problem with using Agile development (where their first go-to answer of "then do Agile harder" didn't work), is "well then you should stop doing that, doing things that don't work isn't Agile". In other words "Agile means committing to doing things a certain way, except when that turns out not to work - then it means committing to not doing them that way." That's not methodology - of course Agile claims not to *be* a methodology, but a mindset! It's not even a mindset though, it's just constantly moving the goalposts so you never have to admit that sometimes what you advocate doesn't work all that well. Look, I actually like the general ideas of what the manifesto is driving at - but at some point the movement has to realize that you have to *actually advocate something actionable*. If your answer to "but what you told us to do didn't work" is trite inanities like "Agile is a framework, not a methodology" and you can't say "not doing this is not Agile" about anything, then you're just saying "Agile is any time anything a team does works", and that's not an actionable mindset, framework or whatever you want to call it. Commit! Put a stake in the ground, say "these practices are the Agile development methodology, *and if Agile doesn't work for you, that's OK*, don't do Agile then, it's not the only way to get things done".

Right now warehouses have large chunks of structure and infrastructure built for bipedal workers - but donâ(TM)t worry, long-term I would bet Amazon is already looking at warehouses designed solely around tracked/cabled/wheeled robots, that would be difficult or downright unsafe for humans.

There is such a thing as taking the "Unix philosophy" to a non-functional extreme. If you took the Wayland approach to shipping a Linux distro, you would ship only a kernel and a libc and maybe Bourne shell and a few GNU utilities and it would be up to the user to decide which other libraries and utilities they want to compile to actually get the system booted and get work done. And if you really want to, you as a user can do that and it's a very educational adventure. But most people expect a system they can actually use after installation, and most distros understand that giving them that is a good thing. If Wayland shipped as a full replacement stack for X11, with a fully-featured desktop-oriented reference compositor and basic utilities that could be swapped out for distro or user choices of different components and configurations, then the Wayland folks would be entirely correct to say "we shipped a fully-capable replacement for the old system, any choices users or distros make that replace the default components with less-functional or incompatible ones are not our problem". But that's not what they did; they did create Weston, "a minimal and fast compositor", but it's described as "suitable for many *embedded and mobile* use cases" (my emphasis but their words). And it ships with "a few demo clients". Wayland + Weston + that handful of clients is not an X11 replacement. We saw this play out also with GNOME 3 and extensions. Iâ(TM)ve been actually using GNOME Shell as my default desktop for the last almost-decade and with *every release* some extension I installed and built my workflow around has stopped working. (And in some cases those extensions were installed to undo unwanted changes in GNOME Shell's own behavior, like showing the overview by default on startup.) The change didnâ(TM)t *reduce* the amount of work involved in maintaining a functional desktop â" it just *shifted* it out of the GNOME dev team to all GNOME users (and an ecosystem of extension developers that became necessary to give those users back a semblance of what they had before).