944 karma · joined December 5, 2010
Most IoT stuff I own had a good track record. The only stuff that screwed me over was the logitech harmony smart remote.
But I usually pick the more open ecosystems and vendors. E.g.heating is on shelly.
I wanted Wifi 7e recently (upgraded to really fast fiber) and went with Ubiquity for that.
I did find the Totolink X5000R extremely good. 50€, WiFi 6 on both bands, fast. But I couldn't find a 7e upgrade I would be happy with.
Not sure if that's still available but it was a fun poster that I can highly recommend.
I was pleasantly surprised that HDR also means you can control brightness - it is all software I that case!
And the brightness keys on an external Apple keyboard work.
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.
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.
My openvpn config was a long list of commonly accepted ports on either tcp or udp.
Startup would take a while but the number of times it worked was amazing.
Looking at the members on the repository this seems to be a Microsoft project?
This is the case if the 2 license aren't at odds. Usually one license is stricter and you have to adhere to that one for the combined work.
A counter-example is GPLv2 and Apache license. Those 2 are incompatible. This was fixed with GPLv3 and you can often upgrade to GPLv3.
So no, this won't allow you to relicense as GPLv2. But you can use GPLv2 code.
This is especially relevant if you have such code redistribution clauses.
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.
I would love to have a UEFI I can compile....
It does work very well for this screen resolution.
And what else would you do with this media given it's a feature phone?
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, ....).
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 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!
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.
[1] https://gregoryszorc.com/blog/2017/03/07/better-compression-...
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.
The math and algorithms behind it are fun to learn but hard. And then you need to implement it both performant and correct.
Only a few people build up the algorithmic background to do this. And the gains once an implementation is there are marginal (optimizations).
The only larger one seems to be zstd, and I haven't wrapped my head around ANS/tANS...
Libsystemd was moving to a dlopen architecture for its dependencies.
This means that the backdoor would not load as the sshd patch only used libsystemd for notify, which does not need liblzma at all.
So they IMHO gave it a last shot. It's OK if it burns as it would be useless in 3 months (or even less).
The collateral is the backdoor Binary, but given enough engineering power it will be irrelevant in 2-3 months, too.
Generally plenty of RAM plus many fast PCIe lanes is not something most ARM chips offer.
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.
It can then after compilation benchmark these, generate a wisdom file for the hardware and pick the right implementation.
Compared with that "a few" implementations of the core math kernel seem like an easy thing to do.
So you review would need to guess from 2 new test files that those are, decompressed, a backdoor and could be injected which was never in the git history.
This was explicitly build to evade such reviews.
It is unclear what exploiting means. The backdoor is doing _something_ for 0.5s if RSA key exchange happens.
So even a valid login might trigger not yet known side effects. It might just tunnel commands over dns for example (DNS being a well known side effect of ssh anyway).
So "exploiting" might mean as little as "used ssh".
It was said he is on an internet break at the moment, so I hope this doesn't ruin weeks for him. It's thankless enough to maintain something like xz.
The backdoor is not fully analyzed as of now. As such nothing can be said about the system besides "it is potentially compromised".
You should use ultra settings and >=19 as the compression level. E.g. arch used 20 and higher compression levels do exist, but they were already at a <1% increase.
It does beat xz for these tasks. It's just not the default settings as those are indeed optimized for the lzo to gzip/bzip2 range.
So it's just odd that the tags and release tarballs diverge.
My TLDR is that I would regard all commits by JiaT75 as potentially compromised.
Given the ability to manipulate gitnhistory I am not sure if a simple time based revert is enough.
It would be great to compare old copies of the repo with the current state. There is no guarantee that the history wasn't tampered with.
Overall the only safe action would IMHO to establish a new upstream from an assumed good state, then fully audit it. At that point we should probably just abandon it and use zstd instead.