ls65536

It depends on the type of sailing and where the race will be taking you. The participants in a race such as the Vendée Globe [0] are almost certainly using the likes of synoptic scale models like the GFS and ECMWF to plan their routes.

[0] https://en.wikipedia.org/wiki/Vend%C3%A9e_Globe

The GFS is a coarser model which covers the entire globe, so while the overall situation at the synoptic scale will tend be modeled quite well (at least inside of a few days into the future), the resolution of smaller-scale weather phenomena taking into account local factors just isn't going to be there.

For something maybe more useful on the local scale, you can also look at a model like the HRRR (which I believe does take into account the terrain and other local effects from things like larger bodies of water). While this model only really covers the conterminous United States and southern Canada, I've generally found it good for showing the shorter-term, local weather details, including forecasting convective storms and winds on and around the Great Lakes.

Since light travels at 100% the speed of light in a vacuum (by definition), I have wondered if latency over far distances could be improved by sending the data through a constellation of satellites in low earth orbit instead. Though I suspect the set of tradeoffs here (much lower throughput, much higher cost, more jitter in the latency due to satellites constantly moving around relative to the terrestrial surface) probably wouldn't make this worth it for a slight decrease in latency for any use case.

Obviously, nobody is going to outright admit they put profits above security; indeed, they will often state the opposite. But their closely-held beliefs will shine through when it comes time to make decisions and the outcomes of those decisions are exposed to their customers and to the public.

I'm sure there are some companies that realise security (or rather the critical lack of some important aspect of it) can impact profits, but that depends a lot on who their customers are too. Ultimately, if the customers who pay for a vendor's products and services don't value it, then the vendors won't value it either, short of any regulatory or legal requirements that might compel them otherwise. However, given that many large organizations (including governments) are Microsoft customers, it's strange to see in this case. Maybe there's a kind of "it can't happen to us" or "nobody will find out about it" arrogance going on, but they must now be seeing that the reputational damage is likely to have negative impacts, including hurting future profits, down the road.

It has happened before with other kinds of large cargo (the type that you really wouldn't want to have undesired holes in): https://www.airliners.net/forum/viewtopic.php?t=276419

There's a great video with excellent visualizations by 3Blue1Brown that illustrates what's happening here: https://www.youtube.com/watch?v=851U557j6HE

Thanks for sharing those insights!

I found this in a RIPE document on IPv6 best practices [0], and it's indeed worded quite strongly (emphasis theirs):

"Assigning a /64 or longer prefix does not conform to IPv6 standards and will break functionality in customer LANs. With a single /64, the end customer CPE will have just one possible network on the LAN side and it will not be possible to subnet, assign VLANs, alternative SSIDs, or have several chained routers in the same customer network, etc."

[0] https://www.ripe.net/publications/docs/ripe-690/#4-2-3--pref...

I couldn't find any such recommendation published by ARIN (the RIR for the US, Canada, and a few other countries nearby), though maybe I haven't searched hard enough yet. I have no experience with ISPs in other places around the world, but perhaps the lack of such a recommendation from ARIN contributes to why I've mostly seen only /64's here.

It really would be nice for all ISPs to provide /56 (or shorter) prefixes by default instead of /64's so that we could properly subnet our internal LANs without having to resort to "solutions" like NAT (or just sticking with IPv4-only forever).

There are some interesting plots (including future predictions) from the IERS Bulletin A data here showing the insertion of leap seconds over time to balance against changes in the Earth's length of day: https://datacenter.iers.org/singlePlot.php?plotname=Bulletin...

It isn't obvious yet to me that there will certainly be a negative leap second (or even a positive one, for that matter) needed in the upcoming years, but predictions farther into the future here are difficult. However, the changes in the length of day that have kept UT1-UTC so close to zero the past several years are very interesting, and as a result we haven't needed a leap second since the end of 2016!

And since the BIPM decided a few years ago to abandon leap seconds by 2035, if this somehow manages to hold for several more years, it's possible that we may not even see a leap second insertion (or deletion) again.

I wonder how many people would continue to so casually use these services if they understood that, for the most part, there is rarely proper end-to-end encryption of their data with these services. It is awfully disingenuous when these companies' marketing materials describe their services as "encrypted" when it usually just means there are two independent TLS pipes, which both terminate in their "cloud"; this surely gives a false sense of security to end-users who may not understand the implications of such a setup.

Yeah, that's a good point. As a further experiment, I tried with various "hardware" combinations (from 486's to Pentium II's) in 86Box, which actually performs such emulation, but unfortunately I haven't been able to get it to boot properly (kernel panics during initialization, if it gets that far at all).

I got it running as a VM guest on QEMU+KVM, exposing only a 486 CPU profile with 256 MB RAM, and it was still usable (with terminal, file manager, and some light web browsing). Looking at the system's memory usage though, it appears that going much lower than about 200 MB RAM would probably make it quite difficult to use (at least without relying on swap, which could make it even more miserable depending on the device being used there).

This is a good point, and by your example it's obviously feasible to find enough of a "collision" on both ends of the digest to make it look like a match at a careless first glance.

In your particular example, I counted at least 96 bits that match on the ends (in total...from 48 bits on each end), and now I'm curious what kind of hardware you used and how long it took to find this match.

There's a good book, "The Right Stuff" [0] by Tom Wolfe, which goes into quite a bit of detail about the stories and some of the psychology around being a test pilot in those days, and in particular about the men chosen as the Mercury Seven astronauts, many of whom were also later involved in both the Gemini and Apollo programs.

[0] https://en.wikipedia.org/wiki/The_Right_Stuff_(book)

As it appears Intel Capital is one of their Series A investors, I wonder if this has some bearing on the chances that there could also be an Intel CPU-based Oxide rack (or maybe individual sleds?) in the future.

It seems that Oxide's product is rather tied to AMD's CPU offerings for the time being (which perhaps will serve them very well for now), and given what they've accomplished so far, I imagine it would take quite a bit of effort on the platform initialization side (and other lower level stuff) to get things working with Intel CPUs instead. Surely the ability to have vendor diversity for many of their components should be an advantage for Oxide (and their customers downstream as well), so maybe there's something to think about there. Of course, this is all interesting only once Intel actually gets competitive again on the datacenter CPU side of things, where they seem to have really dropped the ball in recent years.

On the other hand, their networking switch hardware uses Intel components (Tofino), so maybe that'll be the extent of Intel's integration in their rack for the foreseeable future?

It is certainly not to the same levels of accuracy as the capabilities provided by the setup presented here, but I recently put together a stratum 1 NTP server (there are lots of various instructions online for setting up something like this [0][1]) on my LAN using a Raspberry Pi 4 and a GPS module with PPS output [2]. The setup took a bit of fiddling and experimentation to get working reasonably well (and it still has some glitches when trying to initially sync the time after a reboot), but once it's synced it does track time from GPS very reliably.

For anyone who might be looking for a reliable, accurate NTP time server but isn't interested in the hassle of setting up and configuring the hardware/software themselves, there's also this little appliance [3] I am also using that does something very similar at a great price point (no affiliation here; just a very happy customer). I have both my RPi setup and the NTP200 appliance tracking each other on the same LAN, and they generally agree on the time to within single-digit microseconds, which I think is about as good as one can get with any NTP setup on an Ethernet LAN, at least without resorting to more exotic things like OCXOs, hardware timestamping, etc.

[0] https://austinsnerdythings.com/2021/04/19/microsecond-accura...

[1] https://www.jacobdeane.com/iot/2020/building-a-gps-based-tim...

[2] https://www.adafruit.com/product/746

[3] https://centerclick.com/ntp/

> With a promise that it will be given to them on request. Unless, of course, the manufacturer changes their mind.

Or if the manufacturer decides to simply shut down those servers after some time, at which point the effective default situation will almost certainly be a denied request. In this case, they may not necessarily even be actively changing their mind, but rather just trying to reduce some overhead for those devices they deem to be "no longer supported" but which are nevertheless still out there being used.

This is a valid forward-looking concern that I think needs to be much more clearly addressed. It's one thing to have default-enabled telemetry in the toolchain itself, but once that window is open it's going to be much more difficult to close it and stem the tide of telemetry features creeping in further elsewhere in the Golang ecosystem where they'd be much more of a privacy concern.

Without a strong commitment from the Golang maintainers that this is where it would stop (have they communicated anything to that effect?), we have no reason to believe it will stop here, and all the more reason to be concerned that this is just the beginning and it will be pushed much further in the future.

With that change, no meaningful difference in the results from what I can tell: the program still prints two large integers (around 420M) and two smaller ones (around 85M).

> On a system which has the bug, it should print two large numbers and two small numbers; on a system which does not have the bug, it should print one large number and three small numbers.

I built and ran the provided code on an AMD Zen 4 CPU, and it printed "two large numbers and two small numbers", so could this bug also be present in other microarchitectures implementing AVX-512 other than Skylake(-X)?

How about storing the data on a filesystem that performs data checksumming, also configured in a RAID-1-like mirroring profile to enable any corruption to also be corrected? Filesystems like ZFS or BTRFS could be a good choice here.

In case anyone else is wondering why the effects of being on the HN front page look small at first glance, notice the logarithmic scale being used for the y-axis.

At first I thought the increase in traffic, while noticeable, didn't look particularly impressive on those graphs, but then I noticed that those diurnal traffic patterns looked a bit strange, which is when I noticed the log scale!

I very recently upgraded and had considered both Raptor Lake and Zen 4 CPU options, ultimately going with the latter due to, among other considerations, the AVX-512 support.

Future proofing is no doubt a valid consideration, but some of these benefits are already here today. For example, in a recent Linux distro (using glibc?), attach a debugger to just about any process and break on something like memmove or memset in libc, and you can see some AVX-512 code paths will be taken if your CPU supports these instructions.

I made an online sailing navigation simulator (https://8bitbyte.ca/sailnavsim/). Originally it was just to "scratch a few itches" at the time, but I've found I keep coming back from time to time to make more changes and add little things here and there whenever I have some ideas: dealing with interesting data sets (geographical, meteorological), different programming languages (I've added some Go and Rust since originally starting), computer performance experiments, and so on. And being able to participate in virtual sailing races with others has also been a nice bonus that I never anticipated when first starting this project.

Some light technical details and links to much of the project's code can be found here: https://8bitbyte.ca/sailnavsim/code.html

Agreed. This is very fascinating stuff to help understand what's really happening at that low level in these new chips and how this can impact software performance, the intricate details of which are sometimes only sparsely available online and usually not as approachable.

They also had an excellent one posted just a few weeks ago on the Intel Skylake architecture in case you hadn't yet seen it: https://chipsandcheese.com/2022/10/14/skylake-intels-longest...

> The Boomer economists at the Fed have responded by raising interest rates so that Xers, Millennials, and Zoomers don't get uppity and ask for more money.

Maybe so, but you might want to also consider at the same time what's happening to all that Boomer wealth mostly tied up in retirement accounts (stocks and bonds) and in the real estate that they own while these interest rates rise. Sure, the effects here aren't equally distributed (neither generationally nor by asset class), but hardly anybody is getting away unscathed.

The KeePassXC team has also been trying to get their app into the store while this has happened. While this is nothing new in general, it's yet another "counterfeit" app proliferating in what's supposed to be considered a trusted source to be able to get your applications from.

This is a good example of how "app stores" tend to provide a false sense of security about what you're really downloading. There are clearly failures in terms of vetting what's there and towards ensuring that the user is actually getting what they think they're supposed to be getting.

Perhaps the "app store" model is still generally better than downloading executable code from completely random sources (nobody should be doing that), but I'm not sure there's anything more reliable (and also "secure") here than downloading a piece of software from its official source (such as from a server under the domain of the known publisher), verifying hashes/signatures, and leaving out as many intermediaries as possible who often have motives not fully aligned with the software user. Of course, this would require users to possess and be willing to use some knowledge of basic software and data hygiene, but it seems that along the way we have somewhat given up on that and so now we're stuck trusting these intermediaries usually much more than they ought to be trusted.

In general this makes sense, but I think you need to be careful in some cases where the lowest latency between two logical "cores" is likely to be between those which are SMT siblings on the same physical core (assuming you have an SMT-enabled system). These logical "cores" will be sharing much of the same physical core's resources (such as the low-latency L1/L2 and micro-op caches), so depending on the particular workload, pinning two threads to these two logical "cores" could very well result in worse performance overall.