Wasn't that abbreviation from "pipe"? As in - this is a pipe that you can use to connect terminal to a file, file to a printer... and yes, file to a file (that's cp/copy).
1,024 karma · joined July 3, 2016
Couple of misidentified IPs:
141.98.83.0/26 - shows as "Panama", echoing bogus whois record. Real location is probably Romania, at least that's where origin AS209588 has peers. RTT triangulation is also consistent with the latter location.
93.123.109.0/24 - shows as "Bulgaria". Going by RTT, very likely it's in the Netherlands.
With mmap()-ed file, for each pagefault, kernel will conservatively estimate block size to page in, so you'll have a ton of relatively small requests going to SSD. This would be IOPS-bound, and likely under-perform relative to maximum possible bytes/second throughput.
With explicit read()/pread(), kernel & SSD can work with much larger chunks, so it's easier to hit maximum bytes/second throughput.
Plus, with modern CPUs, IO-wait could be efficiently combined with number-crunching. So, if software knows in advance which data chunk (expert) it'll need for the next token, it can load that in parallel with computing current token.
I'm getting ~0.5 tps from [qwen], and ~10 tps from [gemma] - roughly the same size, same quant, same hardware (8-core CPU) same software (llama.cpp).
[qwen] Qwen3.6-27B-Q4_K_M.gguf
[gemma] gemma-4-26B-A4B-it-qat-UD-Q4_K_XL.gguf
static inline long read(int fd, void *buf, long count) {
register long rax asm("rax") = __NR_read;
register long rdi asm("rdi") = (long)fd;
register long rsi asm("rsi") = (long)buf;
register long rdx asm("rdx") = count;
asm volatile(
"syscall"
: "+r"(rax)
: "r"(rdi), "r"(rsi), "r"(rdx)
: "rcx", "r11", "memory"
);
return rax;
}The other day, colleague showed me a (pretty basic) terminal emulator written in one-shot by Opus. Kicker is - that was compiled to a 30 KB static binary. That's right. No libX11, no libXfont, not even libc.
LM Arena permanently flagged / sent to the captcha hell my account after trying the same prompt twice. So, YMMV.
This addresses one of two main failure modes of solar roadways (grippy coating disintegrating from being driven over), but keeps another one (contamination).
Note that this particular trail was right next to a terminus of very lightly used branch, served by well-maintained rolling stock.
Should one install this anywhere with large traffic of older locomotives, panels will quickly get covered in dark goo from oil drip+dust, reducing output dramatically.
Receiving a message in a timely manner, is far more energy-intensive, for two reasons:
- modern Internet, with nearly universal deployment of NAT, is such that any app (or phone OS, for that matter) can only make outbound connections. That is, to receive, it must keep making outbound requests to the server, constantly asking "is there a message for me?";
- modern android (and iOS too) has some pretty aggressive algorithms/rules to identify apps that can be safely suspended (i.e. denied the right to run in background). One such rule is "no activity within X amount of time". So, ironically, app has to waste CPU cycles to convince OS to keep it running.
There is an OS-level mechanism in both Android and iOS to avoid the second problem above, by the way of OS doing the polling (so-called "push notifications"), but there are their own dragons there, so many apps out out.
GCC says there are a bunch of undefined symbols, first one being "R" right in the beginning:
typedef unsigned char u;
u w,X,T,D[1<<16],t[]=R,U=255;Same with "TWI" (Two-Wire Interface) , a name that Atmel (now Microchip) uses for I2C bus. There are 3 wires there (SDA, SCL, ground). Or 4, if you count power.
Maybe I shouldn't. But then I have to deep-dive into yet another flagrant cheap hallucination. You see, when a molecule oxidize, it becomes a different molecule.
It is impossible for a benzoquinone to oxidize, yet remain a benzoquinone. There are just two of them [1], and the two are isomers [2]. Transforming one into another would be isomerisation, not oxidation.
Not to mention — "oxidize on contact with air" is such a pile of nonsense. Just look at those things: benzene ring with a couple of oxygens sticking from it. [1] That stuff is pretty darn stable in presence of atmospheric oxygen.
...and then dozen of words further on:
"blue benzoquinone has the capacity to act against the bacteria that cause tuberculosis, while the red one is effective against Staphylococcus aureus."
How quaint! Blue colorless molecule is different from the red colorless molecule!
I don't think this is a valid argument. Free-tier VPS do exist also.
On the other hand, if you don't trust unattended-upgrades [0], and prefer to spend time poking package manager manually (while at the same time considering that time an expense) - sure, that's a strong argument in favour of using lambda.
[0] https://ubuntu.com/server/docs/how-to/software/automatic-upd...
That story is mentioned in the TFA.
Fish lack urea cycle, so they produce and excrete significant amounts of ammonia as part of normal metabolism.
https://www.kernel.org/doc/html/latest/admin-guide/sysrq.htm...
It's technically not an unmount, but still a pretty strong guarantee OS will not corrupt the image being written.
When done, reboot has to be done from the same sysrq handler, of course.
They are plenty reactive in a sense of interacting with enzymes and other cellular machinery.
But not that much, unfortunately. Those same "cYbeRseCUrITy" orgs also ingest SSL transparency logs, resolve A and AAAA for all the names in the cert, then turn around and start scanning those addresses.
In my experience, it only takes a few hours from getting an SSL certificate to junk traffic to start rolling in, even for IPv6-only servers.
Small percentage of that could be attributed directly, based on "BitSightBot", "CMS-Checker", "Netcraft Web Server Survey", "Cortex-Xpans" and similar keywords in user-agent and referer headers. And purely based on timing, there's a lot more of that stuff where scanners try and blend in.
Nowadays, wireguard would probably be a better choice.
(both of above of course assume one is to do a sensible thing and add "perma-bans" a bit lower in firewall rules, below "established" and "port-knock")
Yep, #1 source of junk traffic, in my experience. I set those prefixes go right into nullroute on every server I set up:
https://raw.githubusercontent.com/UninvitedActivity/Uninvite...
#2 are IP ranges of Azure, DO, OVH, vultr, etc... A bit harder to block those outright.
Built-in approval thing sounds like a good idea, but in practice it's unusable. Typical session for me was like:
About to run "sed -n '1,100p' example.cpp", approve?
About to run "sed -n '100,200p' example.cpp", approve?
About to run "sed -n '200,300p' example.cpp", approve?
Nearly every shell script starts with "#!/bin/sh", so you can't drop /bin. Similarly, nearly every python script starts with "#!/usr/bin/env python", so you can't drop /usr/bin.
Hence symlink.
Eh, kinda. That's where "essential" .ko modules are packed into - those that system would fail to boot without.
Alternative is to compile them into kernel as built-ins, but from distro maintainers' perspective, that means including way too many modules, most of which will remain unused.
If you're compiling your own kernel, that's a different story, often you can do without initrd just fine.
Claude spits that very regularly at the end of the answer, when it's clearly out of it's depth, and wants to steer discussion away from that blind-spot.
When deployed on a popular server, one bit of "IP intelligence" this detector itself can gather is keep database of lowest-seen RTT per given source IP, maybe with some filtering - to cut out "faster-than-light" datapoints, gracefully update when actual network topology changes, etc.
That would establish a baseline, and from there, additional end-to-end RTT should become much more visible.