thomashabets2

In a "realtime system", sure. But for almost all workloads programs have to deal with overshooting. Like, maybe CPU overloaded or swap intensity caused that second to "disappear". On almost all workloads you can't just assume that you'll execute on every single second.

And if you do need to be scheduled on every second, well you always needed to use a monotonic time.

Negative leap second should only cause measurements to be off by a second, at worst. Added leap seconds means time goes backwards, which is worse.

Of course NTP can cause either.

That's exactly what I see happening when a leap second is ADDED.

A leap second is added. The system goes "oh shit, I'm a second ahead", and subtracts a second. And that's how you get a negative duration and exactly this problem.

Whereas if a leap second is subtracted, you get charged for an extra second.

While it doesn't produce an image, not having 2D data, KrakenSDR has some cool direction finding too.

The topic was energy expense of wideband vs narrowband jamming.

Both can be used for targeting.

As per my linked blog post…

Which is a completely unrelated to what we were talking about.

Which is a completely unrelated to what we were talking about.

It can still be in scope:

Direction finding equipment for determining bearings to specific electromagnetic sources or terrain characteristics specially designed for defense articles in paragraph (a)(1) of USML Category IV or paragraphs (a)(5), (a)(6), or (a)

ITAR part 121.

The "specifically designed for defense" probably makes this OK, but IANAL.

huge incentive to resell the free service

Not all mobile data APNs go to the Internet. You can't resell an IP service that lands on an RFC1918 network with exactly one IP:port available; the API endpoint.

Not saying I've seen this in devices, but I have built and run mobile data networks with private APNs.

Homing in on sources of electromagnetic transmissions has been a thing since at least the BV246 in 1943.

The first phased array systems date back to 1905.

We have had some time to productionize this.

Hell, the "PA" in "PATRIOT missile" stands for "Phased Array".

But the jammer can be plugged in to the grid or a diesel generator. Being on the ground without flight requirements grants access to such resources.

If you own your home I'd say you need a thermal imager. Just the ability to diagnose clogged pipes is priceless.

https://x.com/ThermoInstagram/status/909356506059026432

Also for checking if microwaved food is ready.

I'd say yes we are ready. gettimeofday() should never be used to measure time[1], but at least with a negative leap second it's monotonic.

We'll just get some poorly coded stuff claim that an operation took 1100ms instead of 100ms. Not great, but not -900ms.

Well, I say that, but per my link here F5 load balancers at least used to keep track of TCP connections using gettimeofday. And it's annoying that libpcap delivers metadata in wallclock time.

[1] https://blog.habets.se/2010/09/gettimeofday-should-never-be-...

Personally, I hate split horizon DNS. I prefer the "BeyondCorp" model. I MUCH prefer putting an mTLS cert in my trusted devices over relying on VPNs in same devices. I've yet to see a "clever" DNS setup not cause annoyances.

Specifically grafana is nice to be able to see on the phone, and split horizon DNS and corp VPN is a hassle, to say the least, on phones.

I bet you can do it with HA-Proxy, but I use https://github.com/ThomasHabets/sni-router

I got reminded every week that my static site generator "Jekyll" is insecure.

Ok. Hacking me by changing the input to my Jekyll rather involves being on the other side of the airtight hatch.

Hate to break it to you, but anything can legally be taken away from you by the justice system. And fighting the government can put you in prison, too.

It's just LARPing.

1. A looong skim before it's revealed which type of "crypto" this is about. Because quantum computers, real crypto is also having a challenging year.

2. 2026? Cryptocurrency was always just hell. Well, before it was hell it was LARP.

One pattern I saw repeatedly was a contractor being let go, only to return via a large outsourcing provider. The provider must have added a substantial markup despite supplying the same engineer back to the same team, without having incurred any procurement costs.

When I worked (well, was a contractor at) a very large company, they'd kicked out all their small contracting providers only to get the same people back via a single big one. I was told this was part of a vendor consolidation move, because maintaining their existing direct relationship with literally hundreds of thousands of vendors had a huge cost in itself.

I doubt they were dumb enough to think there was no markup, but going direct isn't free either. There ain't no such thing as a free lunch.

Now, was it a net good move? That's both above my pay grade and not my expertise. But from the fact it took me a month of billed time to buy a license of that same company's own product[1], I wouldn't have called it an efficient bureaucracy.

[1] all purchases of own-company product had to be done through the 99% internal billing discount program.

Oops, I actually replied to the wrong comment. I replied here: https://news.ycombinator.com/item?id=48617774

But it's a relevant reply to both comments, so copied here:

Yes, my understanding is that I should be able to emulate sendfile via splice. The problem with that is that splice requires one end to be a pipe. So I think this means two extra file descriptors per connection (one per side of the pipe). And per connection this adds 5 slots in the submit/completion queue, with a LINK dependency. Maybe the trade off is worth it. I've not done concrete experiments with it, but I'm guessing it would be if the saved copy_from_user is large enough.

So for optimal performance this may mean using write() for short files, and a pipe(), a pair of splice() calls, and a pair of close() calls, for larger files.

Yes, my understanding is that I should be able to emulate sendfile via splice. The problem with that is that splice requires one end to be a pipe.

So I think this means two extra file descriptors per connection (one per side of the pipe). And per connection this adds 5 slots in the submit/completion queue, with a LINK dependency. Maybe the trade off is worth it. I've not done concrete experiments with it, but I'm guessing it would be if the saved copy_from_user is large enough.

So for optimal performance this may mean using write() for short files, and a pipe(), a pair of splice() calls, and a pair of close() calls, for larger files.

Edit: I guess I could save some ops by reusing pipes, but then I'd have to make sure to flush them. Would add some complexity.

I've not yet tested the shared buffers for my io uring based web server, but that's because instead of reading from a file and writing, i send directly from a mmaped region.

But really, I want to sendfile with io_uring, but that's not supported yet.

My writeup, with extra buzzwords like Rust and kTLS: https://blog.habets.se/2025/04/io-uring-ktls-and-rust-for-ze...

It was on HN too: https://news.ycombinator.com/item?id=44980865

That's neither examples nor a clarification if you're talking about JS or WASM.

I'm not a frontend developer, but seems fast to me. I'm surprised that the UI portion of this example takes so little CPU: https://youtu.be/7k0JNT6itaI

Now, the rest of the DSP code sure is faster in native.

What are examples where web UI is too slow for you?

Or do you mean large apps written in JS, which is a different topic?

It's great!

But even though the title of this HN post is wrong, everything else is titled/domained to say that it's about GUIs.

TUIs are great! You can run them on a server, inside a tmux/screen, they don't require a browser or a virtual desktop.

Some things are obviously better as a graphical web app. With WASM I'm less sure that a GUI that is not just a browser app is worth it.

But I'm not a frontend developer, really.

I have a project that requires a GUI. I made it in WASM to run in the browser, and it can decode data packets over radio in real time, while showing fancy visualizations: https://youtu.be/7k0JNT6itaI. 99% of that runs in the browser. Only the RTL-SDR streaming is native.

For my purposes it seems WASM is not performant enough, though, and I'll have to shift more DSP to the server side of the streaming, leaving the UI with just the UI parts.

But I also have some TUI UI code. So much simpler to run remotely, then. No TLS certificates, webserver, etc. Just SSH in and attach to the tmux and see spectrums and graphs with "good enough" dot resolution.

2-3 years ago they changed something and I know tens of people (and I don't know that many people) say that now filling in bank details in the SA itself has become a no-op, and that they (and I) now had to explicitly request a withdrawal of the balance. Often 2-3 times.

And it's not been a matter of waiting. The money just sits there for the better part of a year before people have noticed.

So maybe it'll stop taking three requests, 1-2 months, and a certified letter every year to receive your tax refund?

HMRCs digital services in general are pretty good, but refunds not so much.

It's a workaround for a design flaw.

That's what I'm saying though; how is it a design flaw? It's arguably a flaw in the default configuration. That's certainly fixable without changing the design at all.

Trigger on demand would of course solve that.

Is it a design flaw that you can't trigger the job as a test? No, that's just a missing feature.

Ok, now that you're just commenting cope and ad hominem I think we're done here.

I mean it should include things that are usually on the path, like /usr/local/bin. And for the root user it should include sbin.

So changing the default PATH for cron requires a green field rewrite? You would expect /usr/local/bin. cron doesn't include it. It seems like a disagreement on default settings. I would agree with you about what the default should be, but I don't understand how this has anything to do with cron either as code or architecture.

This seems a bit like /sbin being missing in the default PATH for the root user's regular shell being a reason to rewrite bash to systemd shell.

Because you can test if systemctl start foo.service works and if it does, you know it'll work when foo.timer triggers it.

It's a better workflow than the one I mentioned for cron, yes, but it's nothing inherent. I would not call the difference one of being "predictable", though.

The article and thread is full of complaints about cron that are either just missing features that could be added (like this one, trigger on demand), exactly the same ("the time spec is too complex"), or just plain "no you can already do that with cron".

It wasn't until this comment (https://news.ycombinator.com/item?id=48385824) that I saw viable reasons why one would need to start from scratch.

Except, of course, that "green field is more fun than improving things".

I don't want to hardcode $PATH in the crontab just so I can test the cronjob

How is this different? Any way you slice it, you have to configure it somewhere if you're not lucky enough for the default to be acceptable.

[Lennartware] doesn't stack up that poorly against other projects but it's unacceptably low for a core system component.

Well put.