I feel like almost everyone using AI for support systems is utterly failing at the same incredibly obvious place.
The first job of any support system—both in terms of importance and chronologically—is triage. This is not a research issue and it's not an interaction issue. It's at root a classification problem and should be trained and implemented as such.
There are three broad categories of interaction: cranks, grandmas, and wtfs.
Cranks are the people opening a support chat to tell you they have vital missing information about the Kennedy Assassintion or they want your help suing the government for their exposure to Agent Orange when they were stationed at Minot. "Unfortunately I can't help with that. We are a website that sells wholesale frozen lemonade. Good luck!"
Grandma questions are the people who can't navigate your website. (This isn't meant to be derogatory, just vivid; I have grandma questions often enough myself.) They need to be pointed toward some resource: a help page, a kb article, a settings page, whatever. These are good tasks for a human or LLM agent with a script or guideline and excellent knowledge/training on the support knowledge base.
WTFs are everything else. Every weird undocumented behavior, every emergent circumstance, every invalid state, etc. These are your best customers and they should be escalated to a real human, preferably a smart one, as soon as realistically possible. They're your best customers because (a) they are investing time into fixing something that actually went wrong; (b) they will walk you through it in greater detail than a bug report, live, and help you figure it out; and (c) they are invested, which means you have an opportunity for real loyalty and word-of-mouth gains.
What most AI systems (whether LLMs or scripts) do wrong is that they treat WTFs like they're grandmas. They're spending significant money on building these systems just to destroy the value they get from the most intelligent and passionate people in their customer base doing in-depth production QC/QA.
This rings true. However I have used one AI automated support chat that didn't behave that way. I wish I could remember the vendor but I do remember being blown away when it said something like "that sounds like a real problem would you like me to open a support ticket for this?". Which it then did and subsequently a human addressed my issue.
The word "interstate" does not exist in the text of the Constitution.
There's arguably some merit to your position, but the argument that some case law is invalid because it doesn't meet the definition of a term defined in other case law is circular and incoherent.
Completely agree. This is really unique. Can you imagine if it were standard practice to be open to supply chain attacks like that, by blindly relying on hotlinked or unpinned dependencies?
Why imagine? Let's take a quick look at what's actually happening right now. We can check some widely used libraries and see what their instructions are teaching new developers.
Pay close attention, they are inviting the new developer to link not just to Bootstrap, but to Popper!
HTMX (code snippet from their quick start guide):
```
<script src="https://cdn.jsdelivr.net/npm/htmx.org@2.0.8/dist/htmx.min.js"></script>
<!-- have a button POST a click via AJAX -->
<button hx-post="/clicked" hx-swap="outerHTML">
Click Me
</button>
```
Fontawesome: A video quick start guide and instructions that recommends using the direct link to the kits via CDN for performance!
Look, I certainly don't think they should be used this way. But, to say that it's unique to the White House app? I definitely wouldn't say that. In fact, I think you've dangerously overestimated the status quo.
I was being sarcastic. Although hot linking is not particularly common, it's common enough; and unpinned dependencies are just as much if not more of a supply chain attack risk.
I'd bet something like 70+% of all JS apps are inadequately protected against the risk of a malicious actor gaining access to a dependency's repo.
Pearlclutching over this while ignoring the lessons of `left-pad` and `colors` is biased motivated reasoning at best.
I'm not sure I follow. How does an integrity check help when the source is compromised? The developer doesn't know that their repo is compromised. They continue posting legitimate hashes because the repo is legitimately compromised.
> This is particularly problematic given the ways that it could be abused by some of the more authoritarian governments in the EU.
> Yes, I'm thinking of Viktor Orbán of Hungary.
Lol what?
The UK leads [edit: in Europe overall, obviously not the EU] with approximately 18 per 100k prosecuted for online speech. Germany is at about 4 per 100k. Poland at about 0.8 per 100k. Hungary about 0.1 per 100K.
For any definition of authoritarian that relates to chat control, the UK is two base-10 orders of magnitude more authoritarian than Hungary (7 base-2 orders of magnitude).
This figure in the UK is unsourced and I'm fairly sure is not true (or at least not what you've labelled it), and has been quoted out of context by people trying to stir trouble not reasoned debate. I'll assume good faith here and say the start of the video lays out why the figure is not what you've labelled it to be
The issue isn't how much free speech online is being punished. It is how surveillance could be used to reinforce authoritarianism.
The UK does a lot of prosecuting people for having said nasty things online that someone else didn't like.
Hungary is far more inclined to surveil political opponents, put people in their network in jail without fair trial, surveil successful businesses whose bribes were insufficient, find excuses to punish those businesses.
Not only are there not similar reports about the UK, but its better position in international corruption rankings points to a culture that would be less likely to tolerate this.
Any further questions about why there should be concerns about how Hungary would be likely to abuse a law like this?
Germany and Poland are. Does the existence of a non-EU country in a data set about European countries detract from the fact that Hungary doesn't prosecute people for online speech to the same extent as other European (incl. EU) countries?
I'm quite sure they thought about the UK as well, given the practice of prosecuting for lawful speech, jailing or arresting for planning peaceful protests (or threatening to arrest a man with an EMPTY placard), jailing for opposing the genocide or voicing support for the unlawfully proscribed organisation.
> any high end Ryzen will blow an ARM64 chip out of the water
I'm very skeptical about this. I've read that many benchmarks show ~40% better performance per watt on ARM than the best x64 machines. Do you have any sources that say differently?
Performance per watt isn't the same as performance. On the high end (think Threadripper), amd64 still wins most performance tests by having many high-performance cores working all at once (at the cost of single-core performance).
I disagree with "any high-end Ryzen" blowing an ARM64 chip out of the water, though, it takes quite a beefy CPU to beat an M4 Max.
No. This is a common contrarian take, but it's nonsense. macOS is built on Darwin which, along with XNU, traces its lineage through NeXTSTEP to 4.3BSD.
macOS is every bit as much of a BSD derivative as FreeBSD is.
Here's a contrarian-squared take: in reality, the question "Is macOS a BSD" is malformed. It makes some sens, but is more confusing than it's worth.
Yes, NeXT was built on Mach, which was itself basically an evolution of the Accent microkernel married with BSD, when BSD was a proper noun.
In fact, NextStep 0.8, the first public "pre-release", has left support in for A.OUT executables. The included ex and vi binaries are indeed A.OUT executables taken straight from BSD! In the very next release, support for A.OUT was removed, leaving only the Mach-O loader.
XNU is not derived from the Mach that NeXT was, though, but from the OSF Mach kernel, which was continued at the University of Utah. The BSD "bits" were selectively copied from the extent continuations of BSD, or rewritten from scratch. The XNU kernel doesn't strongly resemble any particular *BSD tree, to my knowledge.
Darwin's origins are messier, since it looks like it was a direct continuation of the existing NeXT packaging (but only Apple would know for sure). NeXT, very much unlike BSD, split its userland into distinct packages, which were versioned independently. This practice has carried on to this day, where e.g. Darwin's libc is packaged and versioned separately from the kernel and other utilities.
For that matter, for a very brief period of history, Darwin used Debian's dpkg for building and installing packages. Evidence of this stayed until OS X 10.4-ish, in the Darwin releases, but they returned to NeXT style BOM files for package management.
All that to say, does NeXT/macOS have a BSD-like userland? Yes, but so does Chimera Linux. Does the kernel resemble BSD? In some ways yes, but in many ways no, it's very semantically different.
And is it descendant from BSD? Again, "yes", but it also doesn't really "come" directly from BSD anymore than, say, OSF/1 did. There's no specific BSD it forked from, and no specific point at which it ever really looked like BSD, in terms of userland, packaging, or kernel semantics.
So I think the question just doesn't make much sense to ask.
- Darwin has no direct BSD ancestor. Unlike {Net,Free,Open}BSD and the more obscure ones (Bitrig, anyone?) there was never a point in time where it directly "connects" to the BSD lineage. The other BSDs all can trace their repositories back to CSRG's BSD.
- Darwin isn't stored or built like a BSD. The BSDs have massive monorepos containing all of the source, traditionally checked out to /usr/src, while Darwin is split into many independently versioned packages, (usually) compiled with Project Builder/Xcode.
Yes, the C API is derived from and supposed to resemble BSD, and much of the userspace was copied from a BSD-derivative (this has grown over time, as Apple (and the BSDs) replaced GNU utilities).
But that's why I would call macOS/Darwin "BSD-like" or "BSD-derived" rather than "a BSD".
Also, this isn't meant to be taken too seriously. I just like "OS taxonomy", and I think macOS/Darwin is distinct enough to qualify as a separate species ;-)
Yeah, I probably went too far in saying it's just the userland, but I'll insist it's more complicated than saying it was based on 4.4BSD-Lite2. I haven't done a proper deep dive yet, but I can tell that it wasn't strictly based on the Lite2 release. Take a look at XNU 123.5's (OS X 10.0) kern/tty.c:
You'll also see the source has been reorganized, with e.g. the VFS source being regrouped into bsd/vfs, instead of being left in bsd/kern. This coincidentally mirrors how OSF/1 was organized (no other source relation though, just an interesting observation):
This file had to be reimplemented by all of the BSDs. In this case, this version appears distinct from the FreeBSD and NetBSD versions I can find.
If you grep around for the `NeXT` ifndef/ifdefs in XNU, too, you'll see some code of which some appears to have been copied/adapted from the NeXT source tree, itself derived from Mach/CMU sources. (and 4.3BSD ;-)
I say all this to draw attention to the ways XNU differs from BSD, which is pretty interesting, at least to me.
> Jails solve the isolation problem beautifully, but they don't have a native answer to shipping. That gap is real, and it's one of the main reasons the ecosystem around jails feels underdeveloped compared to Docker's world.
The link literally uses the term ecosystem. Several times actually.
The lunatic obsession with making scroll bars invisible is not just an aesthetic choice, it's a moral one; and as a moral choice it is emphatically condemnable.
If proper fractional scaling could be backported to GTK2 it would be strictly better than GTK3. Having GTKRC theming again would be amazing.
reply