You'll see cat FILE | all the time because it's just a natural start to a pipeline. You cat FILE to see the content unfiltered before filtering it with further commands.
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)
This idiot (Gabriel) probably thinks exclusively in the real world paper line analog.
Typical of Internet discourse to just immediately brand someone you disagree with an idiot... That "idiot" is one of the designers of common lisp, among other things. You're allowed to disagree with a smart person too you know
The engine is a single C file (c/glm.c, ~2,400 lines)
That file is almost 6k lines. The style also makes my eyes bleed. Why do people pretend stuffing 6k lines of code with almost no whitespace and meaningless variable names into a single file is a good thing? I've seen this a lot recently
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.
I imagine the low level form of each model being free indefinitely, possibly ad supported. It's already probably becoming the most consistent "we're pretty sure this is from a human" training data they have.
"Difficult to recover from" was referencing setting all of your accounts back up. I should have also included "lost" and "broken" to make that more obvious. Many hardware (most? all?) passkeys do not allow for backup and restore.
But I do see an issue with stolen hardware passkeys being used for access too if they're a primary factor. With the mitigations you mentioned hopefully holding up.
They will almost certainly lead to vendor lock in. Why do you think they won't? Apple's password manager is definitely an example of vendor lock in. Many others have a simple to use export feature to CSV or something that others can understand
Edit: it could be that you don't know what the WebAuthn/FIDO2 specification says or we understand it differently? Do you know how the attestation mechanism works? That ties the key to a device or software authenticator (the software authenticator is likely going to tie it to the device somehow, possibly even via a TEE).
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.
I once again cannot disagree more strongly. This is the BS that has been pushed by the mobile phone world. It couldn't be more wrong. Well designed root access to your own device would dramatically increase its security for those who chose to use it.
Here are a few things you simply cannot do on a phone and would be considered terrible in any other context:
Control system, root level services running on your device. The idea that you can't do this is a security nightmare. It is the single most basic security tenant I can think of that is grossly violated. You have no control over your device's attack surface
Control privileged non-root applications
Control network traffic. You have no low level control over your device's firewall without root. You want egress rules? Sorry.
Linux namespaces. You literally are banned from accessing the single greatest Linux security feature since UIDs and GIDs. Network namespace isolation? You can't do it. UID remapping? Nah. Mount namespaces? Nope.
SELinux policy. Android relies heavily on SELinux and you have no control over it at all.
Device handling. There was a great root exploit a long time ago with just a plugged in USB that would have never existed on devices that sanely disabled automounting.
There is so much more. I can't even imagine calling a device I had no root access to "secure" in a personal threat model. Business? Sure. Personal? God no. Not even close.
Reminds me of https://youtu.be/6gFnL-M7UxA
You'll see
cat FILE |all the time because it's just a natural start to a pipeline. Youcat FILEto see the content unfiltered before filtering it with further commands.That's exactly what I said...
I assume they'd cycle through a list of valid user agents. That might make their noise a constant for all major OS's if they did that
For the record, if anyone is in a serious situation and needs rescue, SAR is free in the US. A medical helicopter, on the other hand, is not.
I initially agreed with your take there but I actually think they're a great argument for their point.
headandtailare 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]anddata[-10:]. This abstraction mapping also shows that, imo, the tool should providedata[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 replaceheadwithsedfairly easily:sed -n '1,10p'but nottail(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
sedin then:mcase (I always forget and end up pipingheadtotail) 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)
Yea what a hot take that was, critiquing words that were never there and then calling the person an idiot.
Typical of Internet discourse to just immediately brand someone you disagree with an idiot... That "idiot" is one of the designers of common lisp, among other things. You're allowed to disagree with a smart person too you know
C is compiled; minification won't make it faster.
That file is almost 6k lines. The style also makes my eyes bleed. Why do people pretend stuffing 6k lines of code with almost no whitespace and meaningless variable names into a single file is a good thing? I've seen this a lot recently
It's actually kinda cool to see people focusing on topological quantum computing in industry. It's such a wild concept!
Cursed
Jesus, I thought this comment was a joke before reading the article
Ugh why is time on that bar graph decreasing as you move to the right?
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.
I imagine the low level form of each model being free indefinitely, possibly ad supported. It's already probably becoming the most consistent "we're pretty sure this is from a human" training data they have.
"Difficult to recover from" was referencing setting all of your accounts back up. I should have also included "lost" and "broken" to make that more obvious. Many hardware (most? all?) passkeys do not allow for backup and restore.
But I do see an issue with stolen hardware passkeys being used for access too if they're a primary factor. With the mitigations you mentioned hopefully holding up.
They will almost certainly lead to vendor lock in. Why do you think they won't? Apple's password manager is definitely an example of vendor lock in. Many others have a simple to use export feature to CSV or something that others can understand
Edit: it could be that you don't know what the WebAuthn/FIDO2 specification says or we understand it differently? Do you know how the attestation mechanism works? That ties the key to a device or software authenticator (the software authenticator is likely going to tie it to the device somehow, possibly even via a TEE).
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.
I once again cannot disagree more strongly. This is the BS that has been pushed by the mobile phone world. It couldn't be more wrong. Well designed root access to your own device would dramatically increase its security for those who chose to use it.
Here are a few things you simply cannot do on a phone and would be considered terrible in any other context:
There is so much more. I can't even imagine calling a device I had no root access to "secure" in a personal threat model. Business? Sure. Personal? God no. Not even close.
This is in addition to the privacy benefits.