141–150 of 162 posts
Earlier quoted context omitted.
Anyone can sue anyone else over anything. If those grocery companies actually fought them in court instead of caving in, Apple would get their ass handed to them.
I welcome you to try sueing your neighbor for murdering you. Courts do not accept all lawsuits.
Earlier quoted context omitted.
TIL that " duck tape" is actually the correct/original version, and " duct tape" is a modern derivative. I had always assumed it was the other way round, and some people simply don't know what a duct is so they substitute a similar-sounding, more common word.
Ironically the kind of tape you actually use on metal ducting isn't even duck tape, instead it's a thin aluminum foil tape. Duck tape kind of sucks for most temporary applications as it leaves so much residue behind. Gaffer tape is an awesome replacement (although quite a bit pricier).
Their acceptance speech was written in Seussian rhyme. "Do not use duct tape on ducts. Do not use it: t'won't stay stuck."
Earlier quoted context omitted.
> Null separators between fields is structured data. It might just be the simplest that can possibly work (because the null character is outside the normal data range for text, unlike the newline, which demonstrably doesn't work in that sense) but it is structure. A list structure, specifically. Sometimes I daydream about a parallel universe in which the designers of Unix decided on record-oriented IO instead of stre…
What if most standard Unix commands had a new option to insert into their output those nifty separators ? (FS, GS, RS, US) That ought to make life simpler for downstream commands that try to go beyond processing a text stream.
That's not what I mean by record-oriented IO though. That's signalling record boundaries in-band. I'm talking about signalling them out-of-band. So you have record lengths kept separately from the data, and passed around by APIs separately from the data bytes.
Earlier quoted context omitted.
What if most standard Unix commands had a new option to insert into their output those nifty separators ? (FS, GS, RS, US) That ought to make life simpler for downstream commands that try to go beyond processing a text stream.
> What if most standard Unix commands had a new option to insert into their output those nifty separators ? (FS, GS, RS, US) That's not what I mean by record-oriented IO though. That's signalling record boundaries in-band. I'm talking about signalling them out-of-band. So you have record lengths kept separately from the data, and passed around by APIs separately from the data bytes.
Telecoms uses both concepts (in-band signaling and out-of-band signaling) but I guess the Unix developers didn't get the memo ?
Earlier quoted context omitted.
Sometimes I daydream about a parallel universe in which the designers of Unix decided on record-oriented IO instead of stream-oriented IO. I would attack you with tea bags and waxed paper, if you tried to alter the timeline, and make this so. On the other hand, I would happily sing your praises, if you invented another kind of pipe, to your specs, it sounds like a great additional. Imagine combining the two, in one s…
> On the other hand, I would happily sing your praises, if you invented another kind of pipe, to your specs, it sounds like a great additional Already exists - Unix domain sockets. Some shells (in particular some versions of ksh) use them to implement pipes. And, on some platforms (Linux yes, but I think maybe not macOS???) Unix domain sockets support record-oriented operation (SOCK_SEQPACKET). The problem is that fo…
Thanks for the FYI.
This article links to https://en.wikipedia.org/wiki/Vesta_Stoudt , which links to https://en.m.wikipedia.org/wiki/Cotton_duck , which explains that the word "duck" here comes from the Dutch doek , or "linen canvas".
Earlier quoted context omitted.
How would you deal with a tree?
Newick trees https://en.wikipedia.org/wiki/Newick_format
FS=, RS=; GS=( US=)
Earlier quoted context omitted.
How would you deal with a tree?
Who cares? It deals with 99.99% of uses cases that pipes are being used for right now. That's more than good enough. If you really needed to output a tree using only rs and fs characters, and since they are only a single byte each, you could cover that 1 in a 1000 use case by using empty fields for depth of a record, and attaching any record to the current parent until the depth changes.
Depth of a record seems useful, but then you'll have to make fields mandatory to indicate between real records and depth. slowing down the parsing.
Earlier quoted context omitted.
> Bash (which is actually a decent programming language) How so? I tried to seriously learn Bash a few days ago, and once I learned about word splitting, [[ ]] vs. [ ], "${MY_VAR}" just to properly reference a variable it seemed even more full of technical debt that Wat-full [1] Javascript. I figured it would be obsoleted by a modern shell language alternative by the time I will be 30 (currenty 18), it's not worth it…
There is a zero percent chance that Bash will be gone by the time you're 30. I recommend you use some of that youthly neuroplasticity of yours to get used to it; it is too valuable a skill to give up on simply because it's "wat-full". It is in part a valuable skill to have precisely because it is "wat-full".
Earlier quoted context omitted.
> What if most standard Unix commands had a new option to insert into their output those nifty separators ? (FS, GS, RS, US) That's not what I mean by record-oriented IO though. That's signalling record boundaries in-band. I'm talking about signalling them out-of-band. So you have record lengths kept separately from the data, and passed around by APIs separately from the data bytes.
I've had the same idea. It would (I guess) rewriting the kernel from the ground up to turn every stream into two streams ? Telecoms uses both concepts (in-band signaling and out-of-band signaling) but I guess the Unix developers didn't get the memo ?
Many (but not all) Unix implementations already have support for “record-oriented pipes” in the kernel, it is just that support has rarely been used. Linux has record-oriented Unix domain sockets (SOCK_SEQPACKET), but few use them.
> Telecoms uses both concepts (in-band signaling and out-of-band signaling) but I guess the Unix developers didn't get the memo ?
The original Bell Labs Unix team created STREAMS, which does support true record-oriented IO. Most commercial Unix implementations (such as Solaris and AIX) support it (or at least did at one point). But Berkeley Sockets won the mindshare competition, and open source Unix-likes (such as Linux and BSDs) never added streams support. There was a project to add it to Linux, but Linus was opposed to the idea, so it never got merged, and I think it has since been abandoned.
Even before STREAMS, Unix supported record-oriented IO in the terminal subsystem (cooked mode). But it wasn’t general, it was very specific to the needs of interactive use. STREAMS was intended as a generalisation but it never caught on. So even today all Unix-likes have a purpose-specific (rather than general) record-IO implementation in their tty subsystems, pseudoterminals, etc