• 1 Post
  • 223 Comments
Joined 3 years ago
cake
Cake day: July 3rd, 2023

help-circle



  • I initially agreed with your take there but I actually think they’re a great argument for their point. head and tail are the exact same abstraction. Their implementations will be quite different, but they both serve “provided this data, give me these lines”. Consider instead that these are simply operations on arrays and actually they map perfectly to Python slices: data[:10] and data[-10:]. This abstraction mapping also shows that, imo, the tool should provide data[n:m] and it would still be entirely consistent with the Unix philosophy. In fact, this tool exists in the Unix toolkit: sed -n n,mp. Three tools then are currently required for the simple concept of “slice lines”. I also think it’s a bit of a mess. You could replace head with sed fairly easily: sed -n '1,10p' but not tail (it is possible, but quite slow and very opaque)

    As an aside I actually found this quite frustrating myself because I don’t like reaching for sed in the n:m case (I always forget and end up piping head to tail) and ended up writing my own tool for essentially this style of slicing input, also replacing probably my least favorite use of my least favorite Unix tool, dd, to slice arbitrary byte sequences. The tool doesn’t feel overloaded and I use it quite often.

    (I’m sure many people have written this same tool. There is probably a widely known open source option that I’ve just never come across)










  • I’m with you: the experiences people have with these tools are just dramatically different from mine. They are quite good. By no means even close to perfect, but they’re just so much faster than me at pulling up some random information that would be hard to find with an Internet search myself and very good at going from nothing to something that works with code. I don’t particularly enjoy using them because I find the whole industry abhorrent, but their usefulness isn’t in question to me.





  • There is no full stop there… A password that is sufficiently long will never be cracked no matter the hashing algorithm in use. Passwords are easily transferrable and can be communicated to a third party in the event of an emergency. They also provide tunable security, where you can trade off security for convenience if you want.

    Some (not all, I know) passkeys are tied to a device. Stolen device means stolen passkey, and it’s potentially very difficult to recover from that. Passkeys are also locked to a certain standard, passwords have no such restrictions.

    Tbh I don’t understand the move for passkeys replacing passwords. They should become the second factor when a user wants additional security. They’re perfect for that niche.