wowczarek

> You can just look at the airflow charts and buy accordingly?

Not with Noctua and the likes, not always at least. These fans are quiet, but they are not made of magic fairy dust. They simply max out at lower flow rates than some of the the noisy, high-RPM fans people replace with them. Those 40 mm Noctuas, apart from voltage options, don't really come in many varieties.

It's a trade-off - you definitely lose the upper end of the device's original temperature range, but if it's stable under your conditions - great. How do you find out? Well, you replace the fans and check if it sizzles or not.

And funnily enough, a LOT of equipment these days isn't made with formal thermal design, they simply throw in high-cfm fans and... check if it sizzles. It usually doesn't because there's plenty of headroom. It's loud, but who cares since it's not meant to sit on your bench.

Source: replaced PSU and chassis fans in countless pieces of network and test & measurement equipment.

20+-year long user here, not an issue once. Josh replied to emails then and replies today still. Let's just hope there's someone to continue should something happen to him (chosen diety forbid).

Good job the Earth doesn't have an air shield protected by this byte or we'd be Skroob'd.

"Edit": ...89.999999999 -> ...91.000000000.

I also see this as a defeat. BIPM's Bulletin C announcing the leap second or lack thereof, is almost always very close to full six months before the event. Even this is almost enough time to both develop and test an implementation, not just test it, plus there are usually years of no action between the events.

> Instead of changing the time definition it would make much more sense to switch to TAI for me.

Should UTC permanently stop diverging from TAI, it is more likely that the opposite would happen - TAI would be subsumed by UTC, because there would be no need to maintain two timescales.

Systems which prefer not to deal with discontinuities already use TAI. Many packet capture / timestamping systems natively operate in TAI, and UTC conversion is/can be done in "post-processing". Many / most time servers also do internally, and for example the native time scale for IEEE 1588 / Precision Time Protocol is TAI, and UTC->TAI offset and leap events are announced separately. NTP though, while using its own epoch, is still UTC aligned and while it indicates the LS events, it operates on discontinuous timestamps.

TL;DR: Time sync hard; must make easy.

> almost no software has tested this case.

This part I simply fail to understand. In the age of CI and formalised approach to testing? What about, simply, "good engineering practices"? What, we look at a (defined, described, standardised) corner case and go "naaah, how likely is that...", and just let it slide? What, if we have a 64-bit counter somewhere, do we go "how likely is that to roll over..."? I f# hope we don't.

In any case, I don't accept the "hasn't been tested" argument. Those mechanisms have been in place for decades now, so what if we had no occurrence. I think this is helpful FUD and buzz generated to accelerate moving away from a slightly cumbersome maintenance event, and I get it, but the "not tested" to me, is (or should be!) an insult to software and hardware engineers out there.

As someone involved in time sync and always on alert during leap seconds (leap second party anyone?), I have mixed feelings here. On the one hand this is less work, but on the other, it is a triumph of reducing complexity - or laziness, dare I say - over "correctness".

This, I think.

Coming from someone whose daily work has been time sync for years (me):

If you look at Linux and many other Unix and Unix-like systems, to me it's the insertion of a leap second that has more potential for a failure than a removal.

Insertion ("positive leap seconds"): Time formatting functions will output "hh:mm:60" - this in itself is bound to catch some sofware off-guard - but internally during an insertion the same epoch value runs twice: 123456789.999999999 -> 123456789.000000000, which again is bound to cause some amount of confusion to assorted systems, and clearly the smear was implemented to combat this.

Surely this must be worse than the removal ("negative leap seconds"): 123456789.999999999 -> 123456790.000000000 - yes, still a discontinuity, but we have continuous increase and no ":60".

During my time spent developing time sync architectures and software, I tested both, ad nauseam, and tested it for others, a lot, GNSS simulators and all. Clearly precision time sync remains a specialised discipline, and pays my bills, so I don't mind, but I think this is a case of FUD combined with poor engineering practice and inadequate software testing eventually defeating a well-established timekeeping practice that (now this is more poetical than factual) allowed us to keep our timekeeping aligned with "nature".

I actually think we're in for a bigger mess when after this resolution we attempt to big-bang a batch update, but I will be retired and actually more likely dead and gone by the time this happens, so...

"Please identify a [PELICAN/PUFFIN/toucan] crossing."

I'd love that. Good luck.

I can relate - and at the same time I can't remember if and what I ate today.

That era was great - think PC Engines, Soekris, early Mikrotik RouterBoard, etc. Felt proper elite at the time.

I still have one of those C3 embedded aluminium boxes with a pass-through Ethernet bypass port pair. I ran it as a transparent bridging FW, when power went, it turned into a coupler. This is what got me using pfSense.

Another thing VIA C3 had was the integrated Padlock crypto engine, and this was way before AES-NI, supported on both Linux and BSDs. I remember benchmarking SSL against contemporary Xeons at the time and it wasn't even apples and oranges, it was more like tar and fibre optics. Cisco's AIM module throughput at the time felt laughable in comparison.

Atom was OK, but today Intel's N-series are proving great and we are completely spoilt for choice in terms of good, cheap platforms available.

'tis not. More of a RuneScape man myself.

I'm sure Czarek (a diminutive form of Cezary = Cesar) is flaunting his victory until this day. Now sit, nooblet.

Random member of the public: THEY HACKED THE FBI111!11!!

Anyone with minimal understanding of technology: Oh, PeopleSoft.

...sorry, not HP/Tek/R&S/Lecroy ;)

There are exceptions to the "Winscopes" from the same era in the 1 GHz+ space (RTOS like VxWorks but with Ethernet and modern goodies) that are not HP/Tek/R&S, but I'm not listing them because I'm out on an active hunt for one ;-)