Oh great, I missed that end of the page. The "Round 2 details" links back to the blog and it is hard to see the FAQ on mobile (needs manual scrolling to the end).
Google search and Perplexity failed when I tried, too. Google search has caught up now (haven't retried Perplexity)
A 41.5mm diameter sounds good. That's a whopping 10mm/20% smaller than my current watch. Should be really neat given the thickness.
I pre-ordered because I loved the Pebble Round - especially the size and look. My intended use case is for formal dress codes and special events (weddings, new years, ...) wheretny fennix 51mm does not fit in (literally and figuratively).
That said: I can't find full dimensions for the new round 2. I can guesstimate that it should be 10-20% smaller in diameter and less than 2/3 the thickness.
Would you mind sharing full dimensions or even update the post?
And congratulations! I really like this. I hope there will be enough of a market to support this project long term.
I tried a few times as some BIOS have a hidden or disabled setting but I never got past a plain crash. Device and CPU vendor support for classic S3 is shrinking. E.g. on framework laptops the Intel CPU(!) does not officially support S3 sleep.
So I can understand that there is no option for it if all you can get is out of spec behavior and crashes.
Also note that it is incompatible with some secure boot and system integrity settings.
Is it? The article lists 2015 as the year where things improved a lot, 2017 is well past that. The numbers are low and even that's inflated due to recalls.
I've seen >>10 year old laptops where the battery is still good enough to go from charger to charger. Just go to ebay and check out 2009 MacBooks. That's ~15 years now.
I don't think this is unrealistic if you can live with the heavier degradation.
IIRC the /etc/network/interfaces does a reconfiguration that's pretty disruptive.
Things like brctl and ethtool worked on the fly without issues (note though that I mostly used Arista years ago).
It is usually non-disruptive if it gets applied as deltas. If your config tool does a teardown/recreate then that's disruptive. Within the bounds of ethernet and routing protocols (OSPF DR/DBR changes are disruptive, STP can be fun, ....).
Depends on what you are doing. But you can take the path of app / os images.
My home network is just openwrt, and I use make plus a few scripts and imagebuilder to create images that I flash, including configs.
For rpi I actually liked cloud-init, but it is too flaky for complicated stuff. In that case I would nowerdays rather dockerize it and use systemd + podman or a kubelet in standalone mode. Secrets on a mount point. Make it so that the boot partition of the rpi is the main config folder. That way you can locally flash a golden image.
Anything that mutates a server is brittle as the starting point is a moving target. Building images (or fancy tarballs like docker) makes it way more likely that you get consistent results.
The issue talks about one vs. multiple frames. That's exactly the issue. It's not a matter of complexity, it's a matter of bad compromises.
The issue can be easily played through. The most simplistic encoding where the issue happens is RLE (run length encoding).
Say we have 1MB of repeated 'a'. Originally 'aaa....a'. We now encode it as '(length,byte)', so the stream turns into (1048576,'a').
Now we would want to parallelize it over 16 cores. So we split the 1MB into 16 64k chunks and compress each chunk independently. This works but is ~16x larger.
Similar things happen for window based algorithms. We encode repeated content as (offset,length), referencing older occurrences. Now imagine 64k of random data, repeated 16 times. The parallel version can't compress anything (16x random data), the non-parallel version will compress it roughly 16:1.
There is a trick to avoid this downside. The lookup is not unlimited, there is a maximum window size to limit memory usage. For compatibility it's 8MB for zstd (at level 19), but you can go all the way to 2GB (ultra, 22, long=31).
As you make chunks significantly larger than the window you are only loosing out on the new ramp up. E.g. if you use 80MB chunks then you have a bit less than 10% of the file encoded worse. You could still double your encoded size with a well crafted file.
If you don't care about parallel decompression then you are able to only parallelize parts like the lookup search. This gives good speedup, but only on compression. That's the current parallel compression approach in most cases (iirc) leading to a single frame, just faster. The problem is that back-references can only be resolved backwards.
The whole problem is not implementation complexity. It's something you algorithmically can't do with current window based approaches without significant tradeoffs on memory consumption, compression ratio and parallel execution.
For bzip2 the file is always chunked at 900kb boundaries at most. Each block is encoded independently and can be decoded independently. It avoids this whole tradeoff issue altogether.
I would also disagree with "no need". Zstd easily outperforms tar, but even my laptop SSD is faster than the zstd speed limits. I just don't have the _external_ connectivity to get something onto my disk fast enough. I've also worked with servers 10 years ago where the PCIe bus to the RAID card was the limiting factor. Again easily exceeding the speed limits.
Anyway, as mentioned a few times it's an odd corner case. And one can't go wrong by choosing zstd for compression. But it is real fun to dig into these issues and look at them, I hope this sparks some interest in it!
There is one thing you can't with most algorithms: prallelize decompression. That's because most compression algorithms use sliding windows to remove repetitive sections.
And decompression speed also drops as compression ratio increases.
If you transfer over say a 1GBit link then transfer speed is likely the bottleneck as zstd decompression can reach >200MB/s. However if you have a 10GBit link then you are CPU bound on decompression.
See e.g. decompression speed at [1].
Bzip2 is not window but block based (level 1 == 100kb blocks, 9 == 900kb blocks iirc). This means that, given enough cores, both compression and decompression can parallelize. At something like 10-20MB/s per core. So somwhere >10 cores you will start to outperform zstd.
Granted, that's a very very corner case. But one you might hit with servers. That's how I learned about it. But so far I've converged on zstd for everything. It is usually not worth the hassle to squeeze these last performance bits out.
This looks really good, I remember looking into BWT ad a kid. It's a true "wat" once you understand it.
And once you understand it, why does it compression so well? Because suffixes tend to have the same byte preceeding them.
Bzip2 is still highly useful because it is block based and can thus be scaled nearly linearly across cou cores (both on compress and decompress)! Especially at higher compression levels. See e.g. lbzip2.
Bzip2 is still somewhat relevant if you want to max out cores. Although it has a hard time competing with zstd.
One thing everyone should keep in mind about this NVIDIA/AMD battle right now: CUDA has been published for 16 years, it's been a huge push by NVIDIA to do GPGPU computation. I remember seeing it as a new thing in university back then, after the advanced shaders that were only available on NVIDIA.
NVIDIA pretty rightful has the lead there, because they worked and invested into it for something like 20 years (you could do pretty advanced shaders on NVIDIA pre-CUDA).
It only started to pay off recently, and especially with the AI hype (GPU mining was nice, too).
Now everybody is looking at the profits and goes like "OMG, I want a part of that cake!", either by competing (AMD / Intel) or by paying less for the cards (basically everyone else in the AI space).
But you have to catch up to 16 years of pretty solid software and ecosystem development. And that's only going to work if you have good enough hardware. NVIDIA did the hard work here. They have earned this lead.
I am saying this as someone who would rather not buy NVIDIA. I really wish I can soon throw 1-2 7900XTX into a machine and use it for LLMs without issues. But I would also bet that it takes at least a few more years to catch up, even with the massive global interest.
Not sure if that's still available but it was a fun poster that I can highly recommend.