This is wrong, despite the Rust library in question's naming convention. You're not creating a UDP socket. You're creating an IP (AF_INET), datagram socket (SOCK_DGRAM), using protocol ICMP (IPPROTO_ICMP). The issue is that the rust library apparently conflates datagram and UDP, when they're not the same thing.

You can do the same in C, by calling socket(2) with the above arguments. It hinges on Linux allowing rootless pings from the GIDs in

  $ sysctl net.ipv4.ping_group_range
  net.ipv4.ping_group_range = 999 59999

EDIT2: more spelling mistakes

I didn't want Microsoft to poll my machine for data Microsoft would not describe to me in detail, so I uninstalled the patch and deselected it so it wouldn't re-install. I generally didn't read through the patches at the time, and and usually just let Microsoft update do it's thing, so I wasn't really in the habit of refusing Windows updates, though.

The problem with KB2952664 was that Microsoft kept re-issuing this stupid patch, which re-selected it for upgrades. This happened quite a number of times. Then, when they discovered that people kept blocking KB2952664, they re-issued the patch, again, but this time numbered KB3068708 so it wouldn't be blocked, and did in fact bypass my then-current setting that disabled automatic Windows updates.

Then, Microsoft added the telemetry, again, but this time they included it with a patch labeled as a security update: KB4507456.

Right before Windows 10 came out, Microsoft added what they called an optional prompt to allow Windows to automatically upgrade to 10. I refused the upgrade, but on launch day, came downstairs to find that Microsoft had upgraded my PC anyway, and did so clean - I lost every file on my system.

The dark patterns that Microsoft uses to trick non-computer-savvy people into using OneDrive, or non-local accounts are downright diabolical. They couch the OneDrive setup in terms like "Your computer and your data are not protected! You are at risk of lowered file and computer security. Click here to resolve these issues."

Microsoft relies on ignorance to push this absolute bullshit on unsuspecting people, and in a just world, the execs that dreamed this up would be prosecuted under RICO.

And yet, there are serious computer professionals that clearly understand what Microsoft is doing here, but continue to use Windows. Convenience trumps all, apparently.

[1] https://pages.cs.wisc.edu/~remzi/Naur.pdf

[2] https://x.com/elonmusk/status/1980221072512635117

  Settings > Accessibility > Display & Text Size > Reduce Transparency
  Settings > Accessibility > Display & Text Size > Increase Contrast
  Settings > Accessibility > Display & Text Size > Differentiate Without Colour
  Settings > Accessibility > Motion > Reduce Motion
  Settings > Accessibility > Motion > Prefer Cross-Fade Transitions

My recommendation for happiness with Linux is: Always use native apps. Don’t use WINE. Don’t try to be compatible to inherent hostile things. Don’t use VMs. And especially don’t use Dual-Boot. It sucks.

Basically migrate and go full Linux. Don’t look back :)

Proton (which is WINE derivative) works somehow, because Valve invests every single day tremendous efforts into it. But that’s the problem, tremendous efforts.

The good news. Every bit invested in high quality API/ABI on Linux pays off. Valve contributions to MESA and amdgpu are invaluable. Valve should honor native AAA-Titles and Indie-Titles for Linux - with exclusive Steam Awards. There is awesome stuff like Unrailed. Make the game developers think:

    “I better should do a proper port. And it should not be done by the Win32 developer. Task the Linux developer.”

PPS: I use a Mac for two incompatible applications (Garmin Express and Zwift). Less maintenance than Windows. Less possibilities than Linux. Horrible file-browser. Window management is a pain. But it covers the gap without ruining my day. I have to admit, the Mac cannot run Counter-Strike 2. That’s a task for Linux :)

> OpenAI: We would like six gigawatts worth of your chips to do inference.

> AMD: Terrific. That will be $78 billion. How would you like to pay?

> OpenAI: Well, we were thinking that we would announce the deal, and that would add $78 billion to the value of your company, which should cover it.

> AMD: …

> OpenAI: …

> AMD: No I’m pretty sure you have to pay for the chips.

> OpenAI: Why?

> AMD: I dunno, just seems wrong not to.

> OpenAI: Okay. Why don’t we pay you cash for the value of the chips, and you give us back stock, and when we announce the deal the stock will go up and we’ll get our $78 billion back.

> AMD: Yeah I guess that works though I feel like we should get some of the value?

> OpenAI: Okay you can have half. You give us stock worth like $35 billion and you keep the rest.

https://www.bloomberg.com/opinion/newsletters/2025-10-06/ope...

https://archive.is/tS5sy

1. It creates a bitmap where each bit is a pixel in the image, if from frame 0 to frame 1 a given pixel changed, the corresponding bit is 1, otherwise it is 0.

2. All the 1s are added to the bloom filter, hashing their offsets. Now the bloom filter will be positive for all such indexes plus a percentage of false positive indexes.

3. We query the bloom filter to see all the indexes that are positive, and for all such pixels we store the raw pixel data of what changed. So we can reconstruct the next frame easily.

You can think at this like as storing the delta between two frames as: x,y,r,g,b of all the pixels that changed, but compressing a lot the x,y part at the cost of storing a bit more r,g,b than needed.

I have the feeling that since the pixels that changes from frame 0 to frame 1 are often similar (in their location) to what will change from frame 1 to frame 2, there is the possibility of further compressing that as well, by setting the right flags in the next frame and storing verbatim the only offsets that changed in addition to the previous or alike.

It didn't take very long to learn, and it turned out to be extremely important in the work I did during the early days at Waymo and later at Motional.

I wanted to pass along this fun video from several years ago that discusses HDR: https://www.youtube.com/watch?v=bkQJdaGGVM8 . It's short and fun, I recommend it to all HN readers.

Separately, if you want a more serious introduction to digital photography, I recommend the lectures by Marc Levoy from his Stanford course: https://www.youtube.com/watch?v=y7HrM-fk_Rc&list=PL8ungNrvUY... . I believe he runs his own group at Adobe now after leading a successful effort at Google making their pixel cameras the best in the industry for a couple of years. (And then everyone more-or-less caught up, just like with most tech improvements in the history of smartphones).

These tools are brand new and have proven kinks (hallucinations, for example). But instead of being, rightly, in my view, skeptical, the majority of people completely buy into the hype and already have full automation bias when it comes to these tools. They blindly trust the output, and merrily push forth AI generated, incorrect garbage that they themselves have no expertise or ability to evaluate. It's like everyone is itching to buy a bridge.

In some sense, I suppose it's only natural. Much of the modern economy sustains itself on little more than hype and snake oil anyway, so I guess it's par for the course. Still, it's left me a bit incredulous, particularly when people I thought were smart and capable of being critical seemingly adopt this nonsense without batting an eye. Worse, they all hype it up even further. Makes me feel like the whole LLM business is some kind of ponzi scheme given how willingly users will schill for these products for nothing.

Fire up Emacs and open a text file containing a lot of human-readable text. Something off Project Gutenberg, say. Then say M-x dissociated-press and watch it spew hilarious, quasi-linguistic garbage into a buffer for as long as you like.

Dissociated Press is a language model. A primitive, stone-knives-and-bearskins language model, but a language model nevertheless. When you feed it input text, it builds up a statistical model based on a Markov chain, assigning probabilities to each character that might occur next, given a few characters of input. If it sees 't' and 'h' as input, the most likely next character is probably going to be 'e', followed by maybe 'a', 'i', and 'o'. 'r' might find its way in there, but 'z' is right out. And so forth. It then uses that model to generate output text by picking characters at random given the past n input characters, resulting in a firehose of things that might be words or fragments of words, but don't make much sense overall.

LLMs are doing the same thing. They're picking the next token (word or word fragment) given a certain number of previous tokens. And that's ALL they're doing. The only differences are really matters of scale: the tokens are larger than single characters, the model considers many, many more tokens of input, and the model is a huge deep-learning model with oodles more parameters than a simple Markov chain. So while Dissociated Press churns out obvious nonsensical slop, ChatGPT churns out much, much more plausible sounding nonsensical slop. But it's still just rolling them dice over and over and choosing from among the top candidates of "most plausible sounding next token" according to its actuarial tables. It doesn't think. Any thinking it appears to do has been pre-done by humans, whose thoughts are then harvested off the internet and used to perform macrodata refinement on the statistical model. Accordingly, if you ask ChatGPT a question, it may well be right a lot of the time. But when it's wrong, it doesn't know it's wrong, and it doesn't know what to do to make things right. Because it's just reaching into a bag of refrigerator magnet poetry tiles, weighted by probability of sounding good given the current context, and slapping whatever it finds onto the refrigerator. Over and over.

What I think Yann LeCun means by "energy" above is "implausibility". That is, the LLM would instead grab a fistful of tiles -- enough to form many different responses -- and from those start with a single response and then through gradient descent or something optimize it to minimize some statistical "bullshit function" for the entire response, rather than just choosing one of the most plausible single tiles each go. Even that may not fix the hallucination issue, but it may produce results with fewer obvious howlers.

If you are willing to launch four spacecrafts to visit four planets, the alignment restrictions are much relaxed. You do need to be careful about your launch window to get a nice boost, but it's measured in years between windows, not so much centuries.

It's been on my radar for a long time and I have prototypes for one that are bitrotting on gitlab. There are three major design pieces of it.

First, It has an executable that runs in your development container (environment/etc) which means you can load libraries/typelibs/girs/etc just like the app would without crashing the IDE (or Glade in the old days).

Second, everything is an AST node so doing fun manipulations, unlimited undo, etc is just tree mutations.

Third the worker process does the rendering to a render node tree which is then shipped over to the Designer process to render.

The cambalache author and I are friends, so we occasionally talk about how we can make things work to integrate from Builder.

As for blueprint, that is outside of my knowledge area. I still do everything in XML and would prefer a designer to work with trees anyyway. Not sure I'd go the route of mutating a blueprint AST, but I hear it has back-and-fro to XML so that would probably be fine.

Also, if you want to make this a higher priority, lobby my employer (Red Hat) to make sure they know it's important to you.

Secondly, help me with _any_ of my other projects so I have some cycles to dedicate to it. People rarely notice but Builder, Sysprof, Text Editor, D-Spy, Manuals, Ptyxis, etc... are all one-man (split between many) projects and libraries.

I've been writing a metaverse client in Rust for several years now. Works with Second Life and Open Simulator servers. Here's some video.[1] It's about 45,000 lines of safe Rust.

Notes:

* There are very few people doing serious 3D game work in Rust. There's Veloren, and my stuff, and maybe a few others. No big, popular titles. I'd expected some AAA title to be written in Rust by now. That hasn't happened, and it's probably not going to happen, for the reasons the author gives.

* He's right about the pain of refactoring and the difficulties of interconnecting different parts of the program. It's quite common for some change to require extensive plumbing work. If the client that talks to the servers needs to talk to the 2D GUI, it has to queue an event.

* The rendering situation is almost adequate, but the stack isn't finished and reliable yet. The 2D GUI systems are weak and require too much code per dialog box.

* I tend to agree about the "async contamination" problem. The "async" system is optimized for someone who needs to run a very large web server, with a huge number of clients sending in requests. I've been pushing back against it creeping into areas that don't really need it.

* I have less trouble with compile times than he does, because the metaverse client has no built-in "gameplay". A metaverse client is more like a 3D web browser than a game. All the objects and their behaviors come from the server. I can edit my part of the world from inside the live world. If the color or behavior or model of something needs to be changed, that's not something that requires a client recompile.

The people using C# and Unity on the same problem are making much faster progress.

[1] https://video.hardlimit.com/w/7usCE3v2RrWK6nuoSr4NHJ

I'm disinclined to believe that any AAA game will be written in Rust (one is free to insert "because Rust's gamedev ecosystem is immature" or "because AAA game development is increasingly conservative and risk-averse" at their discretion), yet I'm curious what led you to believe this. C++ became available in 1985, and didn't become popular for gamedev until the turn of the millenium, in the wake of Quake 3 (buoyed by the new features of C++98).

While seemingly obsolete, there are a ton of pre-heap / pre-stack algorithms for dynamically changing arrays or other data structures.

The book also builds up to garbage collection and how to implements Lisp-lists. The kind of encyclopedic knowledge you'd expect from Knuth.

-------

One of my favorites is how to have two Arrays dynamically take up one space.

Have one array grow normally from location#0, and the second array grow backwards from location#End.

Now both arrays take up the statically allocated space efficiently sharing.

This can be extended to an arbitrary number of arrays, but at that point you might as well use Malloc and Realloc. Or at least, the techniques therein are really close to a malloc-like routine IMO.

A single modern CPU core is superscalar and has a deep instruction pipeline. With your help, it will decode and reorder many instructions and execute many instructions concurrently. Each of those instructions can operate on a lot of data.

As famous online controversial opinion haver Casey Muratori tells us, most software just sucks, like really really bad (e.g. commonly people will post hash table benchmarks of high-performance hash tables that do bulk inserts in ~100ns/op, but you can do <10ns/op easily if you try), and using SIMD instructions is table stakes for making good use of the machinery inside of a single CPU core. SIMD instructions are not just for math! They are tools for general purpose programming. When your program needs to make decisions based on data that does not contain obvious patterns, it is often a lot cheaper to compute both possible outcomes and have a data dependency than to have a branch. Instructions like pshufb or blendv or just movemask and then using a dang lookup table can replace branches. Often these instructions can replace 32 or 64 branches at a time[0]. Wojciech Muła's web site[1] is the best collection of notes about using SIMD instructions for general-purpose programming, but I have found some of the articles to be a bit terse or sometimes incorrect, and I have not yet done anything to fix the issue. "Using SIMD" ends up meaning that you choose the low-level layout of your data to be more suitable to processing using the instructions available.

Inside your single CPU core there is hardware for handling virtual -> physical address translation. This is a special cache called the translation lookaside buffer (TLB). Normally, chips other than recent Apple chips have a couple hundred entries of 1 4KiB page each in the TLB, and recent Apple chips have a couple hundred entries of 1 16KiB page each. Normal programs deal with a bit more than 1 meg of RAM today, and as a result they spend a huge portion of their execution time on TLB misses. You can fix this by using explicit huge pages on Linux. This feature nominally exists on Windows but is basically unusable for most programs because it requires the application to run as administrator and because the OS will never compact memory once it is fragmented (so the huge pages must be obtained at startup and never released, or they will disappear until you reboot). I have not tried it on Mac. As an example of a normal non-crazy program that is helped by larger pages, one person noted[2] that Linux builds 16% faster on 16K vs on 4K pages.

Inside your single CPU core is a small hierarchy of set-associative caches. With your help, it will have the data it needs in cache almost all the time! An obvious aspect of this is that when you need to work on some data repeatedly, if you have a choice, you should do it before you have worked on a bunch of other data and caused that earlier data to be evicted (that is, you can rearrange your work to avoid "capacity misses"). A less obvious aspect of this is that if you operate on data that is too-aligned, you will greatly reduce the effective size of your cache, because all the data you are using will go into the same tiny subset of your cache! An easy way to run into this issue is to repeatedly request slabs of memory from an allocator that returns pretty-aligned slabs of memory, and then use them all starting at the beginning. That this could cause problems at all seems relatively unknown, so I would guess lots and lots of software is losing 5-10% of its performance because of this sort of thing. Famous online good opinion haver Dan Luu wrote about this here[3]. The links included near the bottom of that post are also excellent resources for the topics you've asked about.

When coordinating between multiple CPU cores, as noted in TFA, it is helpful to avoid false sharing[4]. People who write trading systems have mostly found that it is helpful to avoid sharing *at all*, which is why they have work explicitly divided among cores and communicate over queues rather than dumping things into a concurrent hash map and hoping things work out. In general this is not a popular practice, and if you go online and post stuff like "Well, just don't allocate any memory after startup and don't pass any data between threads other than by using queues" you will generally lose imaginary internet points.

There are some incantations you may want to apply if you would like Linux to prioritize running your program, which are documented in the Red Hat Low Latency Performance Tuning guide[5] and Erik Rigtorp's web site[6].

Some other various resources are highload.fun[7], a web site where you can practice this sort of thing, a list of links associated with highload.fun[8], Sergey Slotin's excellent online book Algorithms for Modern Hardware[9], and Dendi Bakh's online course Perf Ninja[10] and blog easyperf[11].

> Off topic: What level of sophistication about modern CPUs is _good_ to have?

Probably none? These skills are basically unemployable as far as I can tell.

[0]: https://github.com/lemire/despacer

[1]: http://0x80.pl/articles/index.html

[2]: https://twitter.com/AtTheHackOfDawn/status/13338951151741870...

[3]: https://danluu.com/3c-conflict/

[4]: https://rigtorp.se/ringbuffer/

[5]: https://access.redhat.com/sites/default/files/attachments/20...

[6]: https://rigtorp.se/low-latency-guide/

[7]: https://highload.fun/

[8]: https://github.com/Highload-fun/platform/wiki

[9]: https://en.algorithmica.org/hpc/

[10]: https://github.com/dendibakh/perf-ninja

[11]: https://easyperf.net/notes/

However, the best review I’ve found that actually transmits what is possible and what it is like to use is Brian Tong’s 55 minute review video: https://youtu.be/GkPw6ScHyb4

I’m not familiar with him, but unlike other reviews I’ve seen, he spends less time evaluating or summarizing, and more time trying to actually use the device. I didn’t even realize that you can seamlessly use your Mac to control your visionOS apps, for example.

To be honest, Linux as a desktop environment is already more usable than many people realize. People kept expecting a Big Bang where someone would put out The Release That Solves Everything, but what happened instead is that it just kept creeping up and creeping up. A similar thing happened to Linux gaming; Valve never put out a big Here's Linux For Games release, it just crept up and crept up to the point that it basically runs my entire library, and single-player gaming is now to the point that anything that doesn't run in Linux is the exception, not the rule.

And Microsoft's problem is that if they let this happen, they're going to be in a world of hurt when they decide to get in gear and fix it, because of their reverse compatibility support. Fixing all that up and trying to make everything go fast is going to be hard with all these systems interacting with each other. While we Linux users may piss and moan about systemd transitions or all the audio transitions, in the Linux world, as new subsystems come in, the old ones actually go away, and it isn't dragging anywhere near as much reverse compatibility baggage around. Helps that there aren't any project managers to demand Windows LDAP for COM Apartments Over Embraced And Extended USB to be jammed in to be supported 10 years later because one big client uses it and that mean the rest of us get to be running a WLCAEEUSB service on our computers for the next 15 years, causing occasional mysterious crashes when it spuriously grabs a USB device.

It seems to me Microsoft is in grave danger of walking itself into an MBA trap, where investement in Windows doesn't pay off this quarter so they don't, repeat for 15 or 20 quarters, and then waking up one day and realizing that one quarter at a time they threw away one of the most useful business positions in the history of the world.

This never occurs voluntarily, and people will wail and thrash about even as you try to help them get out of their rut.

Builds being slow is one of my pet peeves also. Modern "best practices" are absurdly wasteful of the available computer power, but because everyone does it the same way, nobody seems to accept that it can be done differently.

A typical modern CI/CD pipeline is like a smorgasboard of worst-case scenarios for performance. Let me list just some of them:

- Everything is typically done from scratch, with minimal or no caching.

- Synchronous I/O from a single thread, often to a remote cloud-hosted replicated disk... for an ephemeral build job.

- Tens of thousands of tiny files, often smaller than the physical sector size.

- Layers upon layers of virtualisation.

- Many small HTTP downloads, from a single thread with no pipelining. Often un-cached despite being identified by stable identifiers -- and hence infinitely cacheable safely.

- Spinning up giant, complicated, multi-process workflows for trivial tasks such as file copies. (CD agent -> shell -> cp command) Bonus points for generating more kilobytes of logs than the kilobytes of files processed.

- Repeating the same work over and over (C++ header compilation).

- Generating reams of code only to shrink it again through expensive processes or just throw it away (Rust macros).

I could go on, but it's too painful...

> portability

Sockets are just as portable, more so on UNIX descendants where one can rely on relatively consistent socket APIs. Beyond that, almost every single language and runtime (Python, Ruby, Java, OCaml ...) provides a portable socket API.

> message framing

Length-prefixed message framing winds up being 10-100 lines of code in almost any language/environment.

> super fast asynchronous I/O

Sockets have this.

> queuing

Sockets have buffers. The OS can use those buffers to implement flow control. This isn't the same as queueing, but the truth is that you rarely want blind background queueing of an indefinite number of messages that may or may not be delivered.

> support for every bloody language anyone cares about

Just like sockets.

> huge community

I don't think you can get 'huger' than the community around sockets.

> price tag of zero

Seeing as socket libraries ship with everything, does that mean they have a time/resource cost of less than zero?

> mind-blowing performance

Also, sockets.

> protection from memory overflows

This has essentially nothing to do with a networking library. Plenty of environments have safe/efficient zero-copy chained byte buffer implementations/libraries.

> loads of internal consistency checks

Library correctness isn't a unique feature.

> patterns like pub/sub and request/reply, batching

Ah-ha! Here finally we get to the meat of it!

If you need QUEUES, including pub-sub, fanout, or any other QUEUE-based messaging structure, than 0MQ is better than sockets!

> and seamless support for inter-thread transport as well as TCP and multicast

Inter-thread transport of already-serialized messages at the transport protocol layer doesn't make a ton of sense from an efficiency perspective.

> ZEROMQ IS JUST SOCKETS

No, 0MQ is a lightweight network message queue protocol. It's not competing with sockets.

Well... because it's not a myth in all cases?

    $ time rg zqzqzqzq OpenSubtitles2016.raw.en --mmap

    real    1.167
    user    0.815
    sys     0.349
    maxmem  9473 MB
    faults  0

    $ time rg zqzqzqzq OpenSubtitles2016.raw.en --no-mmap

    real    1.748
    user    0.506
    sys     1.239
    maxmem  9 MB
    faults  0

    > ripgrep may abort unexpectedly when using
    > default settings if it searches a file that
    > is simultaneously truncated. This behavior
    > can be avoided by passing the --no-mmap flag
    > which will forcefully disable the use of
    > memory maps in all cases.

Changing the workload can dramatically alter these conclusions. For example, on a checkout of the Linux kernel:

    $ time rg zqzqzqzq --mmap

    real    1.661
    user    1.603
    sys     3.128
    maxmem  41 MB
    faults  0

    $ time rg zqzqzqzq --no-mmap

    real    0.126
    user    0.702
    sys     0.586
    maxmem  20 MB
    faults  0

FWIW, I do generally disagree with your broader point, but it's important to understand that there's actually good reason to believe that using mmaps can be faster in some circumstances.