Galileo refers in this to a book he had published earlier, the "Starry Messenger". It is well worth reading.
Galileo had just build the first ever telescope and he describes what he has discovered: there are incredibly more stars than can be seen by the naked eye; Jupiter has satellites; there are mountains on the moon and he has figured out their height from the length of their shadows... The book is full of the quiet excitement of a man who has discovered a new world, and seen what no man had seen before.
I don't think Galileo was quite the first to make a telescope. He had heard a description of one by someone in the Netherlands, and then designed and built his own. He was the first to use it to observe and describe those otherwise invisible objects in the night sky though
If I remember correctly, in that book Galileo says he heard of someone in the Netherlands having made a microscope, but without any details about how it was made. Armed with the knowledge that something like that was possible, he designs a telescope (lenses only, not a Newton type telescope with a mirror). He build three and used the last and best to do his observations.
If you like Bach you might want to learn to listen to polyphony: the form of music in which multiple melodies are played simultaneously while forming an harmonious whole. I recommend looking & listening to videos of Stephen Malinowsky (smalin on youtube), particularly his older videos with less visual clutter. Each color is a separate melody. Initially and you should try to focus on just one melody, then see if you can easily switch your focus to an other one. Then see if you can listen/focus on two melodies at the same time, then three... https://www.youtube.com/playlist?list=PL81D26D4A47388279
In general I would not worry to much about the performer, but it might be interesting to listen to different interpretations of the same piece, particularly from composers with very idiosyncratic styles. On youtube, Ashish Xiangyi Kumar (https://www.youtube.com/c/AshishXiangyiKumar) has videos of pieces (mainly piano solo) interpreted by different artist.
I was using sed to do many replacements (hundreds) in a file and it was starting to be slow, running in O(num_replacemnts). I thought that this can be done with a state machine so the runtime could be independent of the number of replacements.
I googled a bit and found this amazing gem: it uses lex to create a custom C program that does just what you want. Posix compliant. All wrapped up in bash function.
If you specify many replacement rules in sed, it will run in O(num_replacements * num_lines). You should be able to use a state machine to do it in O(num_lines), so I google a bit and found this amazing gem: https://unix.stackexchange.com/a/137932
tl;dr: it uses lex to create a custom C program that does "just what you need", compiles it, and runs it on your input. The whole thing wrapped in a bash function. Bonus: it's POSIX compliant.
If I remember correctly, the system calls where indirect jumps where the address of the jump was in ram (it had been copied from the rom on startup): it was designed to you could hijack system calls and modify their behavior. This blew my mind as a teenager.
I wish modern system where still designed like that...
There were a handful of pointers to the routines to use for BASIC execution in RAM starting at address $300, which could be pointed elsewhere for BASIC extenders or to redirect IRQs. Apart from that, most syscall addresses where in ROM.
It allowed disabling parts of the ROM though to access the full RAM. That way you could rewrite the real jump addresses, bypassing the ROM completely.
I have heard that it is good practice to always chose the number of teeth of two gears to be relatively prime. This is because there can be impurities in the metal, and if you have a small part of a tooth that is harder than the rest it will erode the opposing gear (there is always some friction going on). By choosing the number of teeth to be relatively prime, the wear and tear is distributed uniformly on the gears, and thus they last longer.
This is a similar problem to riding a fixed gear bike. When using skidding as a braking technique, specific areas of the tyre will wear faster unless you select a gear (front chainring and rear sprocket) combo with a large amount of skid patches. This is due to the rider always engaging in a skid with their crankset in a specific position - either left or right foot at 90 degrees, and the other at 270 degrees.
That's also what I was taught as a best practice, but it's not always possible. Otherwise, best practice is to index the gears (ie mark a specific tooth on each). That way, when you disassemble the gearbox (it's bound to happen sometime for maintenance), you can make sure it's reassembled so that the same teeth will continue to mesh, preserving the wear pattern. Otherwise, wear is substantially increased.
In some/many cases there is code before the branch that does not influence the branch condition. In that case, would it be possible to architect the cpu such that it could execute the branch 'early'? I'm thinking of a special asm instruction like 'execute the next 4 instructions, and only then do the conditional jump'.
Yes, that was made explicit in the MIPS instruction set with branch (and load) delay slots, and it's implicit in out-of-order processors. As I understand it the branch delay slot paradigm did not pan out as well as was hoped and it has not found its way into many other architectures.
The issue with the branch delay slot is that it assumes there is exactly one clock cycle (I.e. one stage) between fetch and execute. This was true on some of the early 5 stage in order riscs, but hasn't been true for a while. In an high frequency in order design there are maybe a dozen stages/clock cycles which would be hard to fill with delay slots. OoO is even more complicated.
That’s called delay slots. It turns out to be so hard to work out what to put in them that they’re basically useless. Look at the massive flop that was the Itanium before you try it again!
ARMv8-M has a set of extensions for this kind of branch. There is a set of prepare-to-branch instructions as well as counted loop instructions. In order to support a variable-length delay slot, they don't have very many options. In order to handle interrupts, you still need an ordinary branch instruction from the launch point as well. So if you take an interrupt in the middle of the sequence, the ordinary branch instruction still gets executed.
Would it be possible to do a special distribution for non emacs users? I'm thinking of one download with emacs + magit + CUA mode by default + run magit-status on startup (or whatever else would be appropriate).
So it looks like a standalone git client rather than emacs.
I'm an emacs user, so I would never use this, but it's just a thought.
I intend to make Magit usable from the command-line, so `magit diff ...` would be similar to `git diff ...` except that the output would be "actionable", i.e. you can use `s` to stage, `RET` to visit the file/blob [edit: eventually even in an editor other than Emacs] etc. And `q` to return to the command line.
Packaging that up in a fail-safe fashion is a different story, I would like to do that too, but I expect it will be a lot of work and would certainly appreciate help with that. (There are some projects like Lispbox, which might give such an effort a head start.)
At least in the beginning I think "mostly fail-safe" installation instructions will have to do.
