I think more likely got something wrong with the units; System.Net.Networkinformation.ping reports in whole seconds (so this is ~400ms) for example. Maybe it is some weird tool or typo.

There once was a program called https://en.wikipedia.org/wiki/ManaGeR which appears at first blush to be some kind of X11-competitor, except it was using the VT330's regular terminal capabilities to do those fancy pixel-patterns and fonts, and so there's just some weird VT escape sequences you've never heard of in there.

You can also use SIXELs if you want even more control, and you can readily see such things in action because qemu can (in 2026) send its graphical VGA display into a sixel terminal, but in the 1980s such a thing would not have been performant (probably something like 3 frames per minute) because the VT330 was slow, and such a thing would not be popular you would "lose the text" at some layer which would be as inconvenient as using any other graphical application.

I do this all the time.

One of my favourite applications is a tool called "autoexpect" and I use it every time I try a new program.

What it does is this: I run a program in it's virtual terminal, and it writes a TCL script that does what I did, and puts little regex tests in for the output of that program for me. I can then edit that program (or not: sometimes the first output is fine).

Once upon a time I used to use a program called DESQview: It had a "learn" feature that allowed you to record and playback even DOS programs, so it was very easy to pick up autoexpect.

DESQview/X was their X11 server, and it also had the "learn" feature, but unless the application could be driven entirely by the keyboard, it didn't work; most similar applications I've seen over the decades since need such care for reliable "scripts".

Yes sometimes you also have the possibility of using the GUI accessibility framework to "script" the app. This is barely ok if it works, but most GUIs that I want to script were designed so that would not work at all, and it is coding that requires me work with the app instead of asking a domain expert for a recording.

autoexpect on the other hand is just text, easy to read and modify, and easy to send by email. It is hard to make a terminal application hostile to autoexpect without a great deal of work that (in the text based environment) can usually be undone just by using tmux and mosh on loopback.

> What I don't understand is why that must happen inside a terminal window where (for instance) all text must have the same font and size.

Modern (as in, since the 1980s) terminals are very capable of multiple fonts and font-sizes. I usually use a non-proportional font for coding myself.

For example, go to https://lg.he.net choose BGP Summary IPv4 and plug in a well-known anycast address like 8.8.8.8 (operated by Google) or 1.1.1.1 (operated by cloudflare) and try a few different routers in different parts of the world, and you will see lots of different neighbors claim to be directly connected to these addresses -- something that should be very strange if you thought (for example) that an IP address had a geographic location at a particular point-in-time.

You can also try this for some of the addresses in this range and see that some of the addresses are like this.

The same IP block is announced from multiple geographic locations, and so IP traffic will be routed to the nearest.

It's an old trick that everyone designing protocols should know, since there are lots of applications beyond AI companies.

[1]: As in, pg's lisp: https://arclanguage.github.io/ref/srv.html#:~:text=The%20pre...

False. Advertisers have budgets and ROI targets. If Google cannot compete people will get their clicks elsewhere.

> A jump in traffic to DuckDuckGo does not mean Google is experiencing a decline in search volume. Number of queries per session has increased since launching AI Overviews.

But it does produce lower ROI for advertisers (in this case: CTR goes down because my ad is being shown to more people). Once user is on my landing page, my conversion rate is fine month on month (±1%), but my CTR on google got sharply worse by 5% since, and if it goes much further I'll stop completely on Google.

I doubt I am alone: Maybe others will jump ship sooner and the price will recover (demand goes down) but in either event Google is less net revenue, and given how aggressive their sales pushes have been I think it could be that big

If you buy a €100k rolex, you probably can't be sure you can sell it for more than €100k anywhere at anytime in the future.

You probably can't even find a bank that would take that €100k rolex you just bought as collateral for €500k on a 30y mortgage.

That's why a €1m watch collection is never going to be worth €1m unless we're talking raw materials.

How do you know we are "before-the fact"? Because these numbers are bananas?

Somebody just tanked their job, their life, for a million bucks.

Anybody who took that bet, might've individually spent only a few bucks to see that.

Everyone else (the people watching) learned the price of entertainment is a few bucks, and ruining someone's life is a million bucks.

Was that a surprise to you? If not, then the (market) prices may be said to have converged (close to) reality.

But maybe it is, and you think people would ruin their lives for less, or would pay more for human misery. In any event, the distance between whatever you think that probability is, and the return earned on these odds is information, that we all can enjoy (as benefit) before-the-fact.

You can carry them on your person through airports and other places reasonably unmolested in a way carrying a bunch of cash isn't so easy.

> Is it kind of like art collections, where its a decent store of value

Art doesn't store value: It trades whatever number the parties exchanging it want it to have, so those parties can manipulate their total annual revenues, which might be confused with value if you cannot think of why else someone would want to tell other people they made more or less money in a year, but is not valuable to anyone else.

    #define $ [0]

qmail was at one point the second most widely deployed email server, handling the majority of online mail. It wasn't a research project; it's not obscure. Yahoo used to use it.

And what I mean by track record: After more than a decade after the last published version, a theoretical attack was found requiring special setup uncommon for a sysadmin, and impossible ten years prior.

When anyone thinks about how to build reliable secure software, I think they should be thinking of qmail because it really has no public source-available equal, except maybe djbdns.

seL4 on the other hand makes some specious claims about some ten year old version of itself, and so few people have even heard about it you thought it important to remind it is "technically" C -- qmail isn't like that at all: There is no prover, no test suite, and almost no metaprogramming of any kind. It's just C.

you able to find a reason to come visit? or am i going to have to come to blighty so we can hang out?

The software with the best security track record of all time is written in C.

Yes.

> Sure there are many edge cases, but surely the OS and FS can just be abstracted away and you can verify that "rm .//" actually ends up doing what is expected (Such as not deleting the current directory)?

I think people have been trying that since before I was born and haven't yet been successful, so I am much less sure than you are.

For example: How do you decide how many `/` characters to try?

For a better one: Can you imagine if "rm" could simply decide to refuse to delete files containing "important" as first 9 bytes? How would you think of a test for something like that without knowing the letters in that order? What if the magic word wasn't in a dictionary?

> This doesn't seem like sloppy coding, nor a critique of the language, it's just the same old "Oh, this is systems programming, we don't do tests"?

I've never heard anyone say that except as a straw man.

I've heard people say tests don't do what people think they do.

Also, hi how's things? :)

Yes. And I agree, but it also enables chroot(2) to work without being root, which was the syscall we are talking about, and which I still maintain is not as important as reading.

> arguably, it's the root that should be prohibited from calling chroot(2).

> IMHO there are a bit too many root-restricted operations that should not have been

It's a popular opinion. It's also cheap. So what?

> so we're stuck with setuid-enabled "confused deputies"

chroot(8) is not setuid-enabled. This has nothing to do with anything.

> That's the problem: the choice is implicit. If the author moved setuid/setgid calls way up in the call order, the implicit choice would've also been the safe one but it was literally impossible.

False. The setuid/setgid calls are in the right place. The lookup of the database mapping usernames to userids is in the wrong place.

If the rust programmer just read what they wrote they would see this.

If you just read what they wrote you would see this.

I did not choose the term to confuse you, that's from the definition document linked to the CVE:

https://cwe.mitre.org/data/definitions/426.html

The CVE itself uses the language "If the NEWROOT is writable by an attacker" which could refer to a shared library (as indicated in the report), or even a passwd file as would have been true since the origin of chroot()

> root technically controls everything in one sense of the word.

But not the sense we're talking about.

> Because you can't call chroot(2) unless you're root

Well you can[1], but this is /usr/sbin/chroot aka chroot(8) when used with a non-numeric --userspec, and the point is to drop root to a user that root controls with setuid(2). Something needs to map user names to the numeric userids that setuid(2) uses, and that something is typically the NSS database.

Now: Which database should be used to map a username to a userid?

- The one from before the chroot(2)?

- Or the one that you're chroot(2)ing into

If you're the author of the code in-question, you chose the latter, and that is totally obvious to anyone who can read because that's the order the code appears in, but it's also obvious that only the first one* is under control of root, and so only the first one could be correct.

[1]: if you're curious: unshare(CLONE_USERNS|CLONE_FS) can be used. this is part of how rootless containers work.