Giving too much detail could be an issue in itself, because it starts to misrepresent what permission you're actually giving it.
If an app says "I'd like local network access to find other copies of myself", and you say yes - you're not giving it permission to find other copies of itself. You're giving it all local network access.
If you give it 'full disk access' because it wanted to access one file, and 'local network access' because it wanted to scan for copies of itself - you've given it full permission to export all of your data to your LGTV.
I've seen this mentioned a few times over the last day or two, but it's not true.
The xkcd was 2007 [0], the Debian issue was 2008 [1].
It was used in pretty much every blogpost describing the Debian issue, but it wasn't created because of the Debian issue (unless they gave Randall an 8-month head-start before disclosing it).
(I don't mean this as a "well akshully" - but for me it's more impressive that it's a truism that keeps coming true, than if it was just a swipe at them in the first place)
I actually really like having § at that position. I have it mapped to a Quake-style terminal, and § means it's not only the correct key, but I don't have to give up a useful key for it.
(This may not translate well for USians; Quake disregarded keymaps, so the console wasn't actually on ~, but on "the key that would be labelled ~ in the US". On UK-PC, that's backtick, on Uk-Mac, that's §.)
Can I confess I've never quite wrapped my head around the application of the 'inhibit' line in this?
If a write cycle is just a read cycle with a) a reversed polarity and b) you don't care about the contents of the sense line - I don't get why current coincidence is sufficient during the read cycle, but not during the write cycle?
Every description of this I've ever read, sound like inhibit and current coincidence solve the same problem - but have never left me clear on why we need to solve it twice.
The current coincidence is used to select a specific bit / core. Except it selects the same bit in every bank.
Bytes or larger words are made by stacking multiple banks together (18 in the articles case) All 18 bits would be driven in parallel by the driver over the X/Y wires to produce a coherent 18 bit value at the same moment.
The inhibit bit was so you could select which of those 18 bits (in separate banks) would be switched back to a 1, not selecting which bit across the entire bank.
ahh - I see where my dots weren't connecting, then.
I pictured having a current driver on each plane, so the data bits coming in would be enable bits for the current drivers. Which obviously means 18xQty current drivers.
I think you're describing having one big current driver for the whole job, and then data bits drive the inhibits to counter them.
I guess I'm looking through too modern a lens - pumping 18*600mA into the write cycle, plus (up to 18)*600mA into the inhibit, sounds insane to me (hitting 20A for a write) - but I can see that multiplying the current drivers may have sounded nuts in the 50s.
There are different ways of implementing core memory. The "traditional" way uses the inhibit line. The module I examined uses a "2½D" approach, which is what you originally pictured: separate current drivers for each bit and no inhibit line.
Right - I mentioned BSD because it’s what I run/am-familiar-with, and it does have *.S files [0], but those (or at least the naming convention) came from pre-existing AT&T Unix - so my example does indeed use BSD[1] first released 1978, which is after C[2], created 1972, but The Original Unix[3] (of which BSD is but an embodiment) was started in 1969, before C.
C wasn't _later_, but perhaps you're misrecalling when Thompson had his Berkley sabbatical?
The quickest source I can find this moment for my claim is an interview with Ken Thompson in IEEE magazine called "Unix and Beyond: An Interview with Ken Thompson". Here's the quote, "At one point, I took BCPL from Martin Richards at MIT and converted it into what I thought was a fairly straight translation, but it turned out to be a different language so I called it B, and then Dennis took it and added types and called it C." You can read the whole thing at https://ieeexplore.ieee.org/document/762801 (or https://www.cs.princeton.edu/courses/archive/spring03/cs333/... if you prefer plain text).
When I write the newsletter, I'm _fairly_ sure one of Thompson's big interviews on YouTube has him call this out more clearly, but if I'm misrecalling I'll be sure to write exactly what I can figure out and where I'm sourcing the ideas from.
The specific Dennis Ritchie essay that I was referring to, though, is https://www.nokia.com/bell-labs/about/dennis-m-ritchie/portp... - "Portability of C Programs and
the UNIX System". He coauthored it with Stephen Johnson, who can count Yacc amongst his many contributions to Unix.
My vague recollection is that the kernel in Unix v2 (still called UNIX in those days) was written in assembly language, but that many of the commands were written in B. Because B was interpretive on the PDP-11 (it suffered from the same problem as BCPL, in that it expected a word-addressed machine), it would have been impractical to use it in the kernel. If I recall correctly, the first Unix to reach Berkeley was some kind of v2.
The C compiler appeared in v3, and the kernel rewrite happened for Version 4, which is the version described in the paper.
Using .S for assembly language source is a historical accident, by the time the majority of code was written in C, .a was defined as the conventional filetype for archive (ar) files.
The timeline you're presenting matches what I recall, also. Nice!
That tidbit about .S vs .a is a lovely detail. "A Research Unix Reader" has other cultural details called out that're similar - https://doc.cat-v.org/unix/unix-reader/A.Research.Unix.Reade.... Two of my favourites are the idea that originally a shell script couldn't be part of a pipeline ("programs that were likely to read from shell scripts, especially sh and ed, were made to read their input one character at a time. It was impossible to pipe into a shell script because the standard input was already dedicated to the script. For the same reason a program in a shell script could not take input from a terminal except when given the terminal’s real name.") and this note from the man page for sort v1:
> A bug note in join(1) declares, ‘‘The [field-specification] conventions of join, sort, comm, uniq, look and awk(1) are wildly incongruous.’’ Although these programs are often used together, they remain, like American weights and measures, sturdily eccentric.
I remember thinking that commands were weirdly unsimilar as I was first learning them; it took this many years for me to see one of the early authors wrote an oopsie about them :)
A correction. I can find no evidence of a Unix v2 at Berkeley, it looks like it was v4. (I was told long ago by someone who was at Berkeley then that they had had v2, but there is no evidence of this in the usual sources of information.)
You didn't use the query feature of journalctl, so you basically had it do an entire table conversion. Of course that's not going to show its performance value.
This is what you should be running for a proper comparison:
If an app says "I'd like local network access to find other copies of myself", and you say yes - you're not giving it permission to find other copies of itself. You're giving it all local network access.
If you give it 'full disk access' because it wanted to access one file, and 'local network access' because it wanted to scan for copies of itself - you've given it full permission to export all of your data to your LGTV.
reply