It was less than a year ago that KB5026372 was breaking VPN connections; and now they've broken them again?

We're taking pious lectures about excessive attack surface and too many features from the systemd guy?

I'm a little confused by who is supposed to be caving to the threat here. It's a paid database, so I assume that Thompson-Reuters/Refinitiv aren't thrilled; but it was apparently stolen from one of their customers, not directly from them, so their reputation for security competence isn't really affected; and I suspect that most of the people paying for access to this sort of database need something authoritative that ticks the "I'm really trying to know my customer, really" box when feds or auditors come around; so even a reasonably fresh and reasonably large leak is still of limited value("So, you decided to reduce costs by basing your compliance efforts on data of unknown completeness, potentially subject to unknown modifications, sourced from unknown criminals? Very interesting...") as an alternative to continuing to subscribe.

If anything, it seems like its release would be largely positive: probably lots of interesting leads to be followed up, both with regard to what the creepy data broker types know and the things they know about the people they consider relevant, by people who are in no position to afford access normally(if it's even something you can just purchase if your money is green enough; rather than being offered specifically to potential customers known to be in financial services; not just anyone with a checkbook).

Heâ(TM)s arguably not wrong that VMwareâ(TM)s offerings outside of their core product are kind of inchoate(though, in fairness, itâ(TM)s not like the âhyperscale cloudâ(TM) guys donâ(TM)t all have a stable of shit thrown at the wall to see what sticks that surrounds the core of services that people actually care about or trust); but that seems like a pretty shabby excuse in this context; where it would have been trivial to just not fuck with what people were using and liked while making the alleged investments in glorious future VMware; then letting the value proposition of that help sell it.

As it is, itâ(TM)s hard to read this as anything other than an awkward(and almost certainly temporary, nobody ever genuinely stops trying to boil the frog once they start); climbdown after recklessly spooking more customers, harder, than intended.

If you are trying to explain why we haven't detected any aliens, how is "they were massacred by even more advanced aliens" a remotely adequate answer? That just leaves you with "why haven't we detected the even more advanced aliens?". The question was never "why do we detect so many deathbots and so few little green men?"

If anything, superintelligences are presumably more capable of doing high-visibility things(if they want to) by virtue of being more advanced; and, while they could all be carefully hiding because they're paranoid that same explanation would hold for standard aliens as well.

Seems like an awful lot of hypothesis to explain nothing.

They also aren't cheap even if the knowledge problem is solved. Something like a roomba lives in a special case where being more or less a toy RC car is enough robotics to actually attack a real-world cleaning problem(on reasonably uncluttered flat floors).

If you want "look for missing items, get things out of the refrigerator, scrub the kitchen floor, clean the toilets, and vacuum" you are suddenly talking about a *lot* more robot. Not necessarily 'call Boston Dynamics for their most humanoid biped', you might be able to get away with some sort of wheeled platform with robot arms since the arms count for more than the legs(as long as you can reach things that are a meter plus away from the floor); but you are definitely talking a much more involved piece of hardware with considerably more fiddly moving parts; especially if you don't want to overhaul your entire house.

âoeDonâ(TM)t just read the slide deckâ is more or less rule #1 of not completely ruining a presentation. Is there any room for optimism about the results of a tool that generates video of you reading the slide deck? Even if itâ(TM)s a goddamn miracle on a technical level it seems like a fundamentally mal-suited tool for the job. If anything, the better it works the worse it will likely be, since it will just be doing the wrong thing more attractively and easily.

I'd agree that a production system that actually relies on actual floppies would be rolling the dice in a deeply uncomfortable way at this point; but I'm a little puzzled by the extent of the fuss given that(admittedly, more for hobbyist and niche stuff, retrocomputers and synths from the floppy era, that sort of thing) the practice of emulating floppy drives is quite well established and, thanks to the age and (low) speed of the busses in question, pretty technically undemanding.

If I had a floppy-dependent system I'd have wanted people evaluating commercially available floppy emulators starting 10 years ago; potentially trying to push specific developments if my system requires things that the retrocomputing guys don't(whether in terms of features or in terms of not being hand-built in small runs by hobbyists); but, barring some especially esoteric complication I'm not thinking of, slapping floppy emulators into a floppy-based system and bringing it right up to the present day in terms of media seems like it would be both a relatively simple project and much, much cheaper, lower risk, and more predictable than a full 'upgrade' that promises to rip out the old system and replace it with a full new glorious IoT something something.

Even before Rust, the kernel wasn't written to ISO C, but to GNU C (there's plenty of quotes from Linus to that effect).

There is only one reaction: All future submissions should use a Headshot Square from Bert Reynolds infamous certerfold shot.

Even if the history of Russian 'import substitution' weren't littered with farces where someone gets a gold star for domestically producing tractors...from imported Polish kits with the serial numbers filed off...or the like; "game console" seems like a strikingly hard target, especially relative to its value.

It's a consumer product, rather than the state or state owned or heavily influenced companies being the customer, so there's a lot less leverage in terms of just making 'domestically produced' patriotic and mandatory; and it's a toy that only some people are even interested in, so it's even more difficult to distinguish between people who don't buy Super Motherland 3 because they just don't play video games and ones who don't buy it because they are playing Genshin Impact on something imported from China or a cracked copy of CoD on the wintel they say they use for work. Obviously possible, if you wanted to divert even more statesec guys from keeping an eye on planned terrorist attacks in order to do traffic analysis to look for game pirates; but not obviously worth the trouble.

It's also a pretty demanding category: customers tend to be pretty cost-sensitive and tend to expect frankly remarkable levels of hardware and software punch that are deliverable only thanks to mass production at all levels(whether you are talking ICs, game engines, asset packs, or very large numbers of sales of the final product). This isn't some military thing where you'd like more; but it's workable, and arguably worth it, to be able to reliably deliver domestic clones of some 20-year-old TI DSP even at twice the market price. Unless you are running a crackdown on the alternatives that would make North Korea blink that's not going to work on the gaming side: expectations are high and prices are low; and 'good enough' is defined in large part relative to what other people have, rather than to specific requirements.

Please re-read what I wrote: Smearing works perfectly well in an environment where you control both the (smearing) server(s) _and_ the clients!

If you can make sure that all your clients reduce their poll interval before the smearing starts, then you can track any reasonable smearing trajectory, without ever getting more than a ms or so away from your reference, and consequently, all your peers in the same environment.

For a global/pool server, the NTP Hackers would prefer all this to just work, with all clocks agreeing what the time is, without any single client dropping out of sync because it suddenly realizes that its local clock is more than 128 ms away from the reference(s).

As soon as you need this to also work in a real-time process control environment it becomes a lot harder: Are you sure that all your processes can handle a temporarily non-stable time reference? Can you even apply smearing to some of those process-internal clocks/frequency references?

Terje

NTP has absolutely nothing to do with local time and/or daylight savings: It works only in UTC, but with corrections to handle and propagate leap second events.

Terje

Smearing the leap second is a solution Google came up with for their own data centers when they realized that they had too many protocols that didn't know how to handle UTC leaps properly, it really cannot be applied generally unless everyone can agree on exactly how to do it.

In my own test code, I did the smearing over a 24 hour period, centered around the leap event. The main arguments here are on how to determine an optimal smearing function: You want a gradual increase, then a mostly constant slope period, before a gradual decrease near the end.

There are however several potential problem areas with smearing:

a) ntpd works within a maximum of 500 ppm adjustment rate, of which the majority must be reserved for correcting the local clock, leaving maybe 100 ppm as the maximum smearing, so at that point it will take about 10000 seconds (or ~3 hours) to smear a second. Reducing the max smear rate to around 20 ppm is compatible with a 24-hour adjustment.

b) Very stable clients will only poll the server(s) every 1024 seconds, or even less (every 2K/4K/8K seconds), and to detect a change in the reference clock, a client needs 4 consecutive polls showing a drift from the previous stable value.

c) ntpd considers an offset of 128 ms to be infinity, at that point it will restart the protocol engine and losing sync until everything has been stabilized against the current smearing rate. It should be obvious that a smearing setup which drops sync at both ends of the process would be really bad.

d) If you can force the protocol to drop the sync interval, from 1024 s down to the standard minimum of 64 sec, then it becomes much easier to track/follow a smearing server.

Terje

No. You are thinking of Harlan Stenn who took over the lead role more than 15 years ago. He does not live in Nebraska though, instead he migrates a bit between Oregon and California (Silicon Valley). Otherwise that comic is _exactly_ right!

Terje