It's very hard if not impossible to do predictions over century timescales. How relevant are 1926 resource problems to today? If you wrote your comment in 1926 you would be talking about rubber, fertilizer, coal, wood or oil, and 4 out of those 5 are mostly solved today.
At those timescales, mining the moon or Jupiter for helium might be realistic, so the limits of earth are no longer upper bounds.
I agree century timescales are tough, I'm not convinced 4 of 5 of your listed things have been solved.
Rubber has been replaced with oil.
Fertilizer has been replaced with Natural Gas that comes from the same place as oil.
Coal usage has been replaced/displaced primarily by natural gas, see above.
Wood, or deforestation, was a real problem in the 1920's, but many uses were replaced by plastics (oil) and natural gas. Sustainable forestry helped a ton here too once it hit the paper industry's bottom line.
Oil is certainly not solved, so we solved 4 out of 5 with the 5th.
Exactly -- that means that any analysis based on the current (as of 1926) 'reserves' or 'production capacity' for rubber/fertilizer/coal/wood would have been invalidated as soon as we switched to using oil instead. Imagine if instead of harvesting helium directly we find an economic way to split nitrogen (somehow, who knows). At that point, what you'd have to have forecasted would be the 'reserves' of nitrogen, which are functionally infinite.
That still amounts to magical thinking. And the point of the post that you’re replying to is that we didn’t actually make things better. We actually accelerated our exploitation of other resources to make up for the shortage of the others which had serious other negative side effects.
Since we’re dealing in magical hypotheticals, what if this new economical way to split nitrogen generated so much pollution that it poisoned natural water supplies? Also the “economic way” is misleading. If prices shoot up enough, then crazy things become economical like missions to other planets to retrieve it. But that’s an insane cost that has to be borne out by all humanity. Historically that worked because you increased how many people were on earth so it spread the cost out. However, it’s pretty clear the Earth is at carrying capacity for humans with our current technology which is why the population growth has slowed drastically. So increasing costs threaten to become a weight the next generation can’t lift resulting in societal collapse.
> Imagine if instead of harvesting helium directly we find an economic way to split nitrogen (somehow, who knows).
This is nonsense, from the physics point of view.
The reason why rubber/fertilizer were replaced by oil/gas products is that
oil/gas has the energy needed for the (relatively simple) chemical transformations needed to obtain rubber/fertilizer from the feedstocks.
Splitting nitrogen into helium is a nuclear reaction that requires copious amounts of energy.
At least using fusion or collecting helium from Moon/Jupiter are physically sane, if economically insane.
I'm glad it works that way there. In the Netherlands, I've never seen a fiber duct laid in residential areas, it seems just plain fiber cables are buried.
Worse, two companies are chasing each other, so you have the ground being opened, closed, and within half a year the other company does the same. Even worse, they let the fiber cables stick out of the ground until the house subscribes to them, so a lot of houses have 1 or 2 ugly orange cables sticking out of the ground for years near the front door.
This is such a good decision. It's one of those things that's incredibly confusing initially, but you get so used to it over the years, I even forgot it was a quirk.
In the modern world there is no plausible scenario where this would compromise a password that wouldn't otherwise also be compromised with equivalent effort.
I also think it is a good decision.
Nevertheless it breaks the workflow of at least one person. My father's Linux password is one character. I didn't knew this when I supported him over screen sharing methods, because I couldn't see it. He told me, so now I know. But the silent prompt protected that fact.
It is still a good decision, an one character password is useless from a security standpoint.
I may or may not use a single char password on a certain machine. This char may or may not be a single space. It may or may not be used in FDE. It's surprising what (OS installers) this breaks.
Drats, you're right. I thought it'd be worse, but the ratio seems to only depend on the number of letters in your character set: 1/count(letters in alphabet).
For ascii at 95 printable chars you get 0.9894736842. Makes intuitive sense as the "weight" of each digit increases, taking away a digit matters less to the total combos.
Maybe I'll start using one Japanese Kanji to confuse would be hackers! They could spend hours trying to brute force it while wondering why they can't crack my one letter password they saw in my terminal prompt. ;)
I’ve occasionally contemplated using some non-ASCII character like • or š in a password, but have backed off for fear of needing access from a device that doesn’t support input of those characters.
When the IME inserts the character, it'll be made up of multiple bytes because of the nature of UTF-8, so it may appear as multiple asterisks regardless.
Most software, traditional sudo included, would respect the LC_CTYPE being set to an UTF-8 (or any of the older multi-byte encodings), and do proper character counting.
At the very least, all GNU tools put a lot of focus on localization support, and I hope sudo-rs is the same.
Having LC_CTYPE bit set to utf8 would be my worry. Would suck to not be able to logging because the LC* lang changed.
Hmmm, hopefully sudo-rs respects LC* env vars. I recall reading a few years back that some Rust Unix tools skipped that and won big on benchmarks until folks realized they weren’t handling NC localization properly.
It could also give useful priors for targeted attacks, "Their password is 5 characters, and their daughters name is also 5 characters, let's try variations of that".
Some system accessible to hackers who can see the length of the password /and/ having a single 5 char password has a security of a key under a doormat.
And just sticking to counting, a not exceptionally well-trained ear could already count how many letters you typed and if you pressed backspace (at least with the double-width backspace, sound is definitely different)
Yeah I recall that there was an attack researchers demonstrated years back of using recordings of typing with an AI model to predict the typed text with some accuracy. Something to do with the timings of letter pairings, among other things.
93% - 95% accuracy and it wasn't even a good quality recording
> When trained on keystrokes recorded by a nearby phone, the classifier achieved an accuracy of 95%, the highest accuracy seen without the use of a language model. When trained on keystrokes recorded using the video-conferencing software Zoom, an accuracy of 93% was achieved, a new best for the medium.
Notably, I believe this has to be tuned to each specific environment. The acoustics of your keyboard are going to be different from mine. Which is not much of a barrier, given a long enough session where you can presumably record them typing non password-y things.
"Let's look at their screen and see how long their password is." This article is about silent sudo.
Have you ever watched a fast touch typist, someone that does over 100 words per minute? Someone who might be using an keyboard layout that you're not familiar with? When the full password is entered in less than a second it can be very difficult to discern what they typed unless you're actually recording with video.
But sure, if you're watching someone who types with one finger. Yes, I can see that.
In the early days we all shared computers. People would often stand behind you waiting to use it. It might even not have a screen, just a teletype, so there would be a hard copy of everything you entered. We probably didn't have account lockout controls either. Knowing the length of a password (which did not tend to be long) could be a critical bit of info to reduce a brute force attack.
Nowadays, not so much I think. And if you are paranoid about it, you can still set it back to the silent behaviour.
> In the modern world there is no plausible scenario where this would compromise a password that wouldn't otherwise also be compromised with equivalent effort.
Not sure about that. I'm no expert but for high risk scenarios one might have to worry about binoculars from the building opposite your window, power line monitoring, and timing attacks. All scenarios where the attacker cannot see your hands/keyboard.
Typed passwords can be reliably determined only through timing, so exposing the timing of the input can be exploited. e.g. screen sharing, or anyone who can see your screen
Those care about quickly sending compact messages over the network, but most of them do not create a sparse in-memory representation that you can read on the fly. Especially in javascript.
This lib keeps the compact representation at runtime and lets you read it without putting all the entities on the heap.
Amazon Ion has some support for this - items are length-prefixed so you can skip over them easily.
It falls down if you have e.g. an array of 1 million small items, because you still need to skip over 999999 items to get to the last one. It looks like RX adds some support for indexes to improve that.
I was in this situation where we needed to sparsely read huge JSON files. In the end we just switched to SQLite which handles all that perfectly. I'd probably still use it over RX, even though there's a somewhat awkward impedance mismatch between SQL and structs.
You really cannot see? The experience is vastly inferior: the required dongles have a huge list of annoyances, and you either cannot charge at the same time or have to use an ever more finicky splitting dongle.
> Without something like UCP, you are stuck doing [...] crawling.
I don't work in the area, but isn't this by design? Of course shops want to be discoverable by Google, but stopping competities from crawling and undercutting them is also very important.
Maybe this is different now that Amazon is the gatekeeper which can (ab)use this information anyway, and the incentive for shops to enable competing marketplaces is greater than frustrating competitors
I'm significantly younger but also programmer for two decades since my early teens and am experiencing something similar. CC is so freeing in that it makes those "nice but no time" ideas into reality by doing it next to your main project, almost feels like a drug.
It suddenly turns that dead time while you're waiting for CI, review or response into time where you can work on the fun or satisfying side projects by firing up a few prompts, check an iteration or 2, and then pause again until the next time or while the agent is doing its thing
At those timescales, mining the moon or Jupiter for helium might be realistic, so the limits of earth are no longer upper bounds.
reply