HN user
Qwen is quite slow in general.
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
Yes, something like this:
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;
}Claude has surprisingly good knowledge of X11 protocol.
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.
same prompt 4 or 5 times
LM Arena permanently flagged / sent to the captcha hell my account after trying the same prompt twice. So, YMMV.
I agree.
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.
All it needs to do is be sent a new message.
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.
Uh... is this supposed to be valid standalone C?
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;Always annoyed me that it clearly has 2 wires (power/signal + ground).
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.
Nah, go straight for qmail. Give it your best try.
You are absolutely right.
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.
"colorless molecules called benzoquinones"
...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!
The cost to run these for me is less than the cost of the cheapest vps (my total requests per month stay under the free tier limit).
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...
Solvinity, and Kyndryl, respectively.
That story is mentioned in the TFA.
Agree with your point overall, but ammonia in particular is a poor example.
Fish lack urea cycle, so they produce and excrete significant amounts of ammonia as part of normal metabolism.
Keeping with the YOLO spirit of the article, one can be even lazier, and do emergency R/O remount using this little thing:
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.
Fluoroalkyl chemicals are only "inert and unreactive" in a relatively narrow sense of "wouldn't catch fire", "don't react with strong acids and bases", and similar.
They are plenty reactive in a sense of interacting with enzymes and other cellular machinery.
Agents excel at using CLI tools with well-written "--help". So maybe consider that instead of TUI.
That helps a bit, true.
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.
Back in the day - port knocking was a perfect fit for this eventuality.
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")
bunch of organisations that just probe the entire IPv4 range on a regular basis
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.
I my experience Claude gradually stops being opinionated as task at hand becomes more arcane. I frequently add "treat the above as a suggestion, and don't hesitate to push back" to change requests, and it seems to help quite a bit.
I ended up running codex with all the "danger" flags, but in a throw-away VM with copy-on-write access to code folders.
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?
Mount-points were key to early history of the split. Nowadays it's more about not breaking shebangs.
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.
initrd seems like an enormous kludge that was thrown together temporarily and became the permanent solution.
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.
Do you see "What's your use-case" too?
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.
Very clever, I like it.
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.
Exactly. It's not like backup certificate have validity starting at a future date.
heat pumps themselves are much more efficient.
For electricity-to-heat conversion, heap pumps are indeed much more efficient relative to resistive heating, yes. About 4 times more efficient.
In absolute terms, though - that is still only 50% of "Carnot cycle" efficiency.
https://en.wikipedia.org/wiki/Coefficient_of_performance
Similarly, heat-to-electricity conversion is about 50% efficient in best case:
https://en.wikipedia.org/wiki/Thermal_efficiency
So, in your scenario (heat->electricity conversion, then transmission, then electricity->heat conversion), overall efficiency is going to be 50% * 50% = 25%, assuming no transmission losses and state-of-art conversion on both ends.
25% efficiency (a.k.a. 75% losses) is pretty generous budget to work with. I guess one can cover a small town or a city's district with heat pipes and come on top in terms of efficiency.
Larger storage structures are easier to (thermally) insulate. Because geometry.
But going with larger structures probably means aggregation (fewer of them are built, and further apart). Assuming homes to be heated are staying where they are, that requires longer pipes. Which are harder to insulate. Because geometry.
bloated, buggy JavaScript framework
Isn't that the unfortunate status quo? At least hard requirement for JS, that is.
Google's homepage started requiring this recently. Linux kernel's git, openwrt, esp32.com, and many many others now require it too, via dreaded "Making sure you're not a bot" thing:
https://news.ycombinator.com/item?id=44962529
If anything, github is (thankfully) behind the curve here - at least some basics do work without JS.