I suspect the reason for the difference here may be specific use case and the implications there on the size of the files? The author's use case is Lua files to run in Minecraft, and I strongly suspect their example file at 327KB is very much closer to "typical" for that use case than a 1GB SQL file.
It wouldn't surprise me at all that "more modern" compression techniques work better on larger files. It also wouldn't surprise me too much if there was no such thing as a 1GB file when bzip was originally written, according to Wikipedia bzip2 is almost 30 years old "Initial releases 18 July 1996". And there are mentions of the preceding bzip (without the 2) which must have been even earlier than that. In the mid/late 90s I was flying round the world trips with a dozen or so 380 or 500MB hard drives in my luggage to screw into our colo boxen in Singapore London and San Francisco (because out office only has 56k adsl internet).
For large files, it is frequent to obtain much higher compression ratios when using a preprocessing method, e.g. by using lrzip (which invokes internal or external standard compressors after preprocessing the input to find long-range similarities).
For instance, "lrzip -b", which uses bzip2 for compression, typically achieves much higher compression ratios on big files than using either xz or zstd alone. Of course, you can also use lrzip with xz or zstd, with various parameters, but among the many existing possibilities you must find an optimum compromise between compression ratio and compression/decompression times.
> if you believe quantum computing will ever happen.
... and you don't believe that everything will be totally fucked when it does happen.
If there is a global passive observer, and they get quantum computing, a huge amount of supposedly encrypted private information just got popped. Whether or not I care about my dinky little private social network posts when every ssl/tls connection I've ever made is being cracked and data mined is an interesting question.
I can think of at least a couple of dozen fairly technical friends who'd be capable enough to set this up themselves, and who're at least adjacently interested in recreational paranoia. And probably another dozen or two who're definitely into recreational (or possibly delusional and/or fully deserved paranoia) who'd be willing to learn or get help setting this up.
Right now, those circles of friends are _reasonable_ well served with some combination of Mastodon (effectively zero security but with decent findability) and Signal (much more limited mostly to only people you'd be OK with having your phone number).
I will definitely take this for a spin, and start having discussions with particular groups of friends to see it I get any traction.
I think a lot of even not very technical people have gotten used to TOTP QRCodes, and being able to store screenshots of them in password managers. (And having experience in losing 2FA keys that they'll go to some lengths to not repeat.)
I wonder if there's a decent way to encode these private keys in QRCodes? You can jam about 4kB in a high density one from memory? (I know that'd be possible from a developer/technical point of view, but if this were my project I'd want a talented UX designer to have complete authority over how this is presented and explained to users.)
One other idea - maybe implement a Shamir's Secret Sharing mechanism where your private keys get sharded and encrypted to a sufficient number of selected friends, so of you lose your s@ private key it can be re assembled by convincing - say - 8 out of 12 selected friends to give you their part?
Or alternatively - automate a "recovery mechanism" where you set up a new key pair and publish it on a temporary domain/site, and can then ask a friend/follower who can authenticate your identity out-of-band - to export all you posts decryptable with your new key, then put you new key and all your old posts back into your main site.
LLMs have supercharged it though, it's so much easier to create dozens or hundreds or thousands of ultra low effort LLM written webpages and websites that it ever was before LLMs.
I'm not Dang, but I agree AI articles are a disease - but with reservations.
In this case, a Chinese developer who's not a native English speaker - I feel is _adding_ to "interesting conversations" not detracting from them but using AI assistance to publish an article like this in readable/understandable English.
I know HN and Ycombinator is _hugely_ US focused and secondarily English-speaking focused. But there's more and more interest in non US based "intellectual curiosity" where the original source material is not in English. From YC's capitalism-driven focus, they largely don't care. From my personal hacker ethic curiosity, I'd hate to miss out on articles like this just because of a prejudice against non English speakers who use AI to provide me with understandable versions.
Having said that, AI hype in general certainly feels like a disease to me. I was noting recently how the percentage of homepage like/discussions I click has gone way down. I remember the days where I'd click and read 80 or 90% of the things that made it to the homepage. These days I eyeroll my way past probably 2/3rds of them because they look at first glance (and from recent experience>) to just be AI hype in one form or another. (I've actually considered building myself a tool that'd grab the first three or so pages and then filter out everything AI related - but the other option is just to visit less often...)
I'm all for people who aren't native English speakers publishing their thoughts and opinions. But I would much prefer they still wrote down their own thoughts in their own words in their native language and machine translated it. It would be much more authentic and much more interesting--and much more worth reading.
Triple As might not, but back in the day plenty of rc planes flew just fine for an hour or three using 4 AA batteries to run the receiver and servos..
reply