Having worked on libp2p‘s DHT (Double Hashing for rust-libp2p) for a bit two years ago, it’s really great to see that there are improvements.
To get to CDN level speeds though on dense networks, I still see it as an architectural flaw to not somehow encode network topology into the PeerID / identity in the DHT. A start would be to use the five RIRs. If you want to be more sophisticated, and I spent a lot of time theorising about this, you could have a dezentrally governed anycast IP address of Geo DNS to bootstrap new peers into their neighbourhood and couple that into their DHT identity. But do you want to put BGP into the hands of a decentralised system? Could you even do it in the governance structure of the internet?
Btw when we were working on our project HyveOS, we used Batman-advs routing table to quickly (really really quick) bootstrap new peers into the system.
It says 8 Arm Neoverse N2 cores in the blog post. So not directly ARM Cortex, derived from ARM Cortex-X3 but same family as NVIDIA Grace, Google Axion and AWS Graviton4.
Not across all features, but certainly in specific ones. There are more advanced WiFi 6 chips, more advanced Bluetooth chips and faster MCUs. But they are all separate chips or companion ICs.
From the EXIF we can infer that every setting was left at the default. No exposure comp, no contrast, no HSL, no lens correction and a linear tone curve. Just the default Adobe Color profile at 5400K.
That’s fair but when there is an async version of the driver or Hal available it should be pretty straightforward to port it to synchronous, right? Maybe Claude code can even do it with minimal supervision…
I am a big fan of the embassy project and it’s a great example of why async Rust is so great: Because this is possible. It works without a heap, is a really low cost abstraction and you can do stuff concurrently on a single core chip (where you can’t just spawn a new “thread”) and you don’t have the complexity of an RTOS. I believe there is a great future for embassy ahead and it’s so great how far the team has come.
Rust embedded was really never actually better then C or C++ but embassy for me is a big reason why I now make my buying decision based on how well I can use Rust on the MCU.
Maybe stuff has changed a lot in the last year but I didn’t experience that problem so far. For me it was the other way around mostly. Where did you encounter that?
Interesting thought but you would need a lot of these gasses on the one hand and on the other hand it doesn’t help in working against the greenhouse effect. The greenhouse effect depends on the absolute amount of CO2 in the atmosphere, not the percentage. How much infrared light is absorbed by CO2 primarily depends on the amount of CO2 in the atmosphere.
Maybe they felt the increase in capability is not worth of a bigger version bump. Additionally pre-training isn't as important as it used to be. Most of the advances we see now probably come from the RL stage.
This course is actually mandatory in the first year of the CS undergraduate program here at ETH. I remember it very fondly for its great (and passionate) lecture and the hands on experience building a MIPS cpu in the exercise sessions. Probably the best lecture in my undergraduate.
These seem like the first features that Rust in Linux bring to the Rust language that are not almost exclusively useful to the kernel. In my perception the focus on bringing features for the kernel has held up development in other parts of the language and the standard library.
It's great that they finally target all three mayor platforms! Let's see how developers using Windows treat them.
I used to be a Neovim purist, spending days on my config and I have barely touched it since I moved to Zed. It's so much nicer to use then VScode (and it's forks) because it's so snappy.
I hope they ship leap.nvim (https://github.com/ggandor/leap.nvim) support soon, then I am completely happy!
It's great that they finally target all three mayor platforms! Let's see how developers using Windows treat them.
I used to be a Neovim purist, spending days on my config and I have barely touched it since I moved to Zed. It's so much nicer to use then VScode (and it's forks) because it's so snappy.
That's sadly true, over in x86 land things don't look much better in my opinion. The corresponding accelerators on modern Intel and AMD CPUs (the "Copilot PCs") are very difficult to program as well. I would love to read a blog post on someone trying though!
You probably wouldn’t with a Pro but you might between an iPad Pro and an MacBook Air.
With the foundation models API they basically said that there will be one size of model for the entire platform, making smarter models on a MacBook Pro unrealistic and only faster ones possible.
