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.
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.
> 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.
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.
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.
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.
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.
> 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.
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.