IMO there is actually a very low hanging fruit here, even without P2P or DHTs we could have an URI scheme that consists of a domain and document hash. It is then up to the user to add alternate mirrors for domains. Aside from privacy, it doesn't really matter who answers these requests since the documents are self-signing.
>The known_hosts file is verification of host keys
I think the point was that those devices typically generate host keys dynamically and therefore the host key verification is usually turned off, leaving you just with encryption (which is still better than telnet - at least you're safe against passive adversaries). At least that's what I've seen in practice.
Host key verification is a client feature and is on by default. Have you really never gotten the giant warning after a reinstall? That's what that is. SSH is telling you that the server has changed and isn't what you think.
Well, sure. You can turn off host key checking in ssh! But that isn't responsive to a point that (1) host key validation exists in ssh and (2) host key validation is on by default in ssh.
Exactly. But 'passive encryption' isn't helpful; if you can see the traffic, you can MITM it. Just RST the connection, wait for the reconnect, intercept.
The array indexing thing is a special case in [[...]] which is otherwise more-or-less secure (no expansion occurs under typical unquoted variable access). https://news.ycombinator.com/item?id=46631811
I haven't given this more than 5 seconds of thought, but wouldn't it make sense to only enable the timing attack prevention for pseudo-terminal sessions (-t)?
It can be about as fast if you set key repeat delay to minimum and repeat speed to maximum. I used it for a while and got quite precise with it. Works well until someone else needs to use your computer for a moment...
Hm, I doubt the precision can match and avoid under/overshootings, especially at high enough repeat speed to match, and it's a global change that can affect even regular typing, so you're suggesting specialized training (to minimizeerrors) for a less effective workflow
The main issue with precise jumps (for me) is that they require you to
- already exactly know where you want to go
- figure out the relative distance either by looking to the side at relative line numbers or calculating
- move your hands to the numbers row to input numbers and back (I don't have small hands, but that still translates into a small amount of arm movement for me).
Whereas just using repeat input on jklhwe... only requires you to have a rough idea initially and leaves you plenty of time to figure out where exactly you want to stop while you're already getting there.
Besides: I don't like to think about random numbers while I'm coding. Doesn't exactly make the cursor feel like an extension of my body (imagine you had to tell your hand "move 10 centimeters left")
Another quite intuitive way I navigate is using "/something" and cycling through hits - usually you know some text that appears near the area you want to go. That was pretty much instant muscle memory.
Same as with moving down by 1x10? How are you even choosing cursor direction if you don't know where to go to?
> - figure out the relative distance either by looking to the side
Ok, how is that an issue? You also have to figure out the distance by looking down when moving down with the arrows, so eyes still move?
> move your hands to the numbers row to input numbers and back
No, you could maintain your hands on the home row and use a numpad layer containing it
> imagine you had to tell your hand "move 10 centimeters left"
Imagine you had to tell your hand "move 1 centimeter left 10 times"? The mouse is that extension where you don't "move by 1 pixel X times" and move in an analog way
Oh. Now I get why we're talking past each other. There's a thing most computers are configured to do out of the box, but yours might be different for some reason.
I'm going to assume you're using Windows. In that case go to Settings > Accessibility > Keyboard and configure "Character Repeat". What this will do is repeat a key you're holding as if you're pressing it multiple times! Configure it until it feels natural.
This is what people were referring to when we said we're holding a key. We're not pressing it 10 times, just holding it down and having the computer automatically repeat it until we're happy with the result (such as having moved where we wanted to). It's a bit like moving a mouse cursor, where you're also not calculating the offset you want to move your mouse in advance.
> It's slower to "stop precisely"on key hold/release
For longer distances, unless your repeat speed is very slow, you're often either holding a key repeat and stop before a few lines and then tap or overshooting and tap to go back. So ok, it's not 1x10, but 7+1x3 or 12-1x2
(but yes, the initial leg of the journey is more mouse-like "natural", but still not that because you can't vary speed on most keyboards unlike with they mouse/hand)
For smaller distances you could just tap a few times.
No one is doing 1x10 key presses. That's now how humans process information. You repeatedly press a key one time until what you see on screen is what you want. The further away you are the faster you do it.
I personally use ((...)) for arithmetic tests and [[...]] for all other tests as I just target new versions of BASH and don't care much about POSIX compatibility.
Yeah there are, Linux supports parameters FALLOC_FL_INSERT_RANGE and FALLOC_FL_COLLAPSE_RANGE for fallocate(2). Like most fancy filesystem features, they are not used by the vast majority of software because it has to run on any filesystem so you'd always need to maintain two implementations (and extensive test cases).
Interesting that after decades of file system history, this is still considered a "fancy feature", considering that editing files is a pretty basic operation for a file system. Though I assume there are reasons why this hasn't become standard long ago.
File systems aren’t databases; they manage flat files, not structured data. You also can’t just insert/remove random amounts of bytes in RAM. The considerations here are actually quite similar, like fragmentation. If you make a hundred small edits to a file, you might end up with the file taking up ten times as much space due to fragmentation, and then you’d need the file system to do some sort of defragmentation pass to rewrite the file more contiguously again.
In addition, it’s generally nontrivial for a program to map changes to an in-memory object structure back to surgical edits of a flat file. It’s much easier to always just serialize the whole thing, or if the file format allows it, appending the serialized changes to the file.
File systems aren't databases, but journaling file systems use journals just like databases. It can theoretically define any granularity for something that might happen to a file to become an irreversible transaction. I suppose that file systems have to remain “general purpose enough” to be useful (otherwise they become part of the specific program or library), and that's why complex features which might become a pitfall for the regular users who expect “just regular files” rarely become the main focus.
But appending changes is a terrible solution, even if it is "much easier" to implement. Not only because it causes data leakage, as in this case, but also because it can strongly inflate the file size. E.g. if you change the header image of a PDF a few times.
Indeed, also userspace-level atomicity is important, so you probably want to save a backup in case power goes out at an unfortunate moment. And since you already need to have a backup, might as well go for a full rewrite + rename combo.
What this does on typical extent-based file systems is split the extent of the file at the given location (which means these operations can only be done with cluster granularity) and then insert a third extent. i.e. calling INSERT_RANGE once will give you a file with at least three extents (fragments). This, plus the mkfs-options-dependent alignment requirements, makes it really quite uninteresting for broad use in a similar fashion as O_DIRECT is uninteresting.
Well, better an uninteresting solution than a solution which is actively terrible: appending changes to a PDF, which will inflate its size and cause data leakage.
reply