HN user
Looks like they're making progress toward getting things restarted: "Update #2: The GOES-19 Safehold has been resolved and engineers are working to prepare for restart of the onboard instruments. More information on the recovery timeline will be provided when known." [0]
[0] https://www.ospo.noaa.gov/data/messages/2026/07/MSG_20260716...
Very unfortunate timing given the ongoing wildfires and associated smoke spreading across eastern North America in recent days.
There's an agreement to do something about leap seconds before 2035, either by allowing DUT1 to exceed its currently specified bounds (this is most likely) or by agreeing to simply not insert/delete leap seconds going forward (this is less likely). For certain bounds on DUT1 and at some timescale, these would be practically the same in terms of their effects on civilization, computing, etc. In any case, a decision will almost certainly be made much sooner than 2035, perhaps even before the next leap second insertion/deletion would need to take place under the present rules.
Fortunately, in the past couple months, the likelihood of actually needing a negative leap second in the next few years has been trending down. This is based on measurements and predictions done by the IERS, the data for which they publish weekly in their Bulletin A [0]. I've been tracking this data for a while, and their DUT1 predictions have been trending more negative over the past few months, suggesting that the anticipated negative leap second is likely to be delayed, or it may very well not happen at all.
[0] https://datacenter.iers.org/data/latestVersion/bulletinA.txt
I have a machine that's on a Debian installation that I've been steadily upgrading, one Debian stable release at a time, since I originally installed it about a decade ago now. At one point I even copied the entire installation to another disk (just a "dd" from its original SATA SSD to a new NVMe one, plus some partition and filesystem resizing), and I've upgraded the CPU/motherboard/RAM at another time, and it just keeps going reliably. It's fun knowing that the origin of that Debian installation predates every hardware component it's presently running on (with the exception of only the case and power supply).
They bought P.A. Semi, but it was for their design capability; they never had fabs anyway, and Apple still depends on TSMC and others for manufacturing chips. Apple building fabs to ensure a guaranteed supply of memory (or logic) chips would be an unprecedented level of vertical integration, even for them.
I made something similar a long time ago partly as a challenge to see what could be done with just 2 KB RAM [0]. It was possible to implement some very basic context switching between two "processes", pipes (okay, I only had a single pipe, and it only worked between certain commands), and some other things like a few built-in games (pong, snake, and a breakout-style game, naturally). I didn't go as far as adding any filesystem functionality though, and ultimately yours does feel more Unix-like overall, but it was a fun little project where you learned to always consider every single byte as precious.
~450 square feet, with how many feet in the third dimension? You probably had an order of magnitude more volume than 330 cubic feet there.
This is really fun!
A possible bug though: I managed to finish Inverness to Gibraltar, and the top three spots on the leaderboard somehow had negative time durations!
My intuition would be that constant usage (not exceeding maximum rated capacity/thermals/etc.) should generally result in less wear compared to the more frequent thermal cycling that you might expect from intermittent use, but maybe there's something else going on here too. I suppose this would depend on what exactly the cause of the failure is.
Either way, these are obviously being intentionally sold to be used for non-gaming-type workloads, so it wouldn't be a good argument to state that they're just being (ab)used beyond what they were inteded for...unless somehow they really are being pushed beyond design limits, but given the cost of these things I can't imagine anyone doing this willingly with a whole fleet of them.
But if everyone follows this advice, then everything just gets overwhelmed by "hustlers" (and their "shameless spam"), and collectively we're now all worse off because of it. It just turns into yet another tragedy of the commons situation.
I say this as someone who received a lot of great feedback and had some interesting interactions after posting about a project of mine using "Show HN" a few years ago. I didn't need to spam anything to get the attention, but I admit maybe I just got very lucky, or maybe there were just fewer posts to "compete" with at the time (this was before the recent write-everything-with-AI-and-launch-it-out-there craze).
Finally, I'm not making any moral judgments here, and if someone feels they need to do this to get the attention they want, then who am I to tell you otherwise. But we should be aware of what we're giving up when we overall tend to behave in such a way, even if it's the inevitable outcome.
The total size isn't what matters in this case but rather the total number of files/directories that need to be traversed (and their file sizes summed).
I've seen claims of providers putting IPv6 behind NAT, so don't think full IPv6 acceptance will solve this problem.
I get annoyed even when what's offered is a single /64 prefix (rather than something like a /56 or even /60), but putting IPv6 behind NAT is just ridiculous.
If that's really the case, I wish they would just come out and say it and spare the rest of us the burden of trying to debate such a decision on its technical merits. (Of course, I am aware that they owe me nothing here.)
Assuming this theory is true then, what other GPLv3-licensed "core" software in the distro could be next on their list?
Maybe the thought is that there will be more pressure now on getting all the tests to pass given the larger install base? It isn't a great way to push out software, but it's certainly a way to provide motivation. I'm personally more interested in whether the ultimate decision will be to leave these as the default coreutils implementation in the next Ubuntu LTS release version (26.04) or if they will switch back (and for what reason).
I can certainly understand it for something like sudo or for other tools where the attack surface is larger and certain security-critical interactions are happening, but in this case it really seems like a questionable tradeoff, where the benefits in this specific case are abstract (theoretically no more possibility of any memory-safety bugs) but the costs are very concrete (incompatibility issues; and possibly other, new, non-memory-safety bugs being introduced with new code).
EDIT: Just to be clear, I'm otherwise perfectly happy that these experiments are being done, and we should all be better off for it and learn something as a result. Obviously somebody has assessed that this tradeoff has at least a decent probability of being a net positive here in some timeframe, and if others are unhappy about it then I suppose they're welcome to install another implementation of coreutils, or use a different distro, or write their own, or whatever.
I'm not going to speculate about what might be ahead in regards to Oracle's forecasting of data center demand, but regarding the idea of efficiency gains leading to lower demand, don't you think something like Jevons paradox might apply here?
The industry definitely seems to be going in this hybrid PQC-classical direction for the most part. At least until we know there's a real quantum computer somewhere that renders the likes of RSA, ECC, and DH no longer useful, it seems this conservative approach of using two different types of locks in parallel might be the safest bet for now.
However, what's notable is that the published CNSA 2.0 algorithms in this context are exclusively of the post-quantum variety, and even though there is no explicit disallowing of the use of hybrid constructions, NSA publicly deems them as unnecessary (from their FAQ [0]):
NSA has confidence in CNSA 2.0 algorithms and will not require NSS developers to use hybrid certified products for security purposes.
[0] https://www.nsa.gov/Press-Room/News-Highlights/Article/Artic...
until there is actually a quantum computer that can break it
There isn't one yet (at least that the general public knows about), but that doesn't mean we don't need to do anything about it right now. See this problem, for example, which would potentially affect today's encrypted data if it were harvested and saved to storage for the long term: https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later
There's also a lunar occultation of Mars (which is near opposition itself, making it relatively bright) happening in a few days, and then again in February, which should be visible from parts of the northern hemisphere: https://in-the-sky.org/news.php?id=20250114_16_100
If you do consider paying for either Wubuntu or LinuxFX, it's worth keeping in mind that in the past, the developer's activation system and registration database have both been investigated and found to be horribly insecure. However, from the database, it looks like some 20,000 people did pay.
Even if one wanted to use it for anything serious without paying or otherwise providing any personal information in the process, this is a huge turnoff.
It looks like there's also a fix for that nested virtualization bug causing host reboots on Ryzen 7000/8000 CPUs [0]. It's nice to see that the cause appears to be known and that it's being addressed (even if the kernel here is technically not at fault).
Apparently this problem is caused by a CPU erratum (or unsupported functionality?) with some (many?) BIOSes still reporting the broken/unsupported instructions (VMLOAD/VMSAVE) as being available with these CPUs, at least according to some discussion about it on the LKML [1].
[0] https://www.phoronix.com/news/Linux-Clear-VMLOAD-VMSAVE-Zen4
For some reason this also made me think of the boundary of the Mandelbrot set...that place where all the interesting structure reveals itself.
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.
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