Ciro Santilli @cirosantilli 35

Ciro's word of caution for 2019 aspiring system programmers: Should you waste your life with systems programming?

This is basically a direct consequence of backward design.

The higher the level you can operate at, the better.

C is better than assembly, userland better than kernelland.

The ideal level to operate at, and one of humankind's greatest ambitions is "AGI, make me money", the highest possible level.

Only go down a level when it seems necessary.

symmetric bilinear maps that is also a bilinear form.

Skew-symmetric bilinear map that is also a bilinear form.

The opposite of quasiparticle, see notaby: quasiparticles vs elementary particles.

These are some users Ciro Santilli particularly respects, mostly due to their contributions to systems programming subjects:

Ciro also really likes the following users, a bit less like Gods, and bit more like friends:

Other interesting people:

Issue report at: github.com/ourbigbook/ourbigbook/issues/198 Suppose you had:

programming-language.ciro

= Programming language

\Image[https://raw.githubusercontent.com/cirosantilli/media/master/python-logo.jpg]
{title=The \x[python-programming-language] logo}

== Python
{c}
{disambiguate=programming-language}

logos-i-like.ciro

= Logos I like

\x[image-the-python-logo]

Now, when rendering \x[image-the-python-logo], we would need to fetch two IDs:

But after group all SQL queries together was done, there was no way to know that rendering image-the-python-logo would imply also fetching python-programming-language.

This was solved by adding a new database entry type, REFS_TABLE_X_TITLE_TITLE to the existing References table, which tracks dependencies between IDs.

After this was setup, we can now know that image-the-python-logo depends on image-the-python-logo, and then fetch both of them together in a single JOIN.

Please, use AsciiDoc and one page to rule them all.

Borrow from the Internet Archive for free: archive.org/details/supermenstory00murr

Initial chapters put good clarity on the formation of the military-industrial complex. Being backed by the military, especially just after World War II, was in itself enough credibility to start and foster a company.

It is funny to see how the first computers were very artisanal, made on a one-off basis.

Amazing how Control Data Corporation raised capital IPO style as a startup without a product. The dude was selling shares at dinner parties in his home.

Very interesting mention on page 70 of how Israel bought CDC's UNIVAC 1103 which Cray contributed greatly to design, and everyone knew that it was to make thermonuclear weapons, since that was what the big American labs like this mention should be added to: en.wikipedia.org/wiki/Nuclear_weapons_and_Israel but that's Extended Protected... the horrors of Wikipedia.

Another interesting insight is how "unintegrated" computers were back then. They were literally building computers out of individual vacuum tubes, then individual semiconducting transistors, a gate at a time. Then things got more and more integrated as time went. That is why the now outdated word "microprocessor" existed. When processors start to fit into a single integrated circuit, they were truly micro compared to the monstrosities that existed previously.

Also, because integration was so weak initially, it was important to more manually consider the length of wire signals had to travel, and try to put components closer together to reduce the critical path to be able to increase clock speeds. These constraints are also of course present in modern computer design, but they were just so much more visible in those days.

The book does unfortunately not give much detail in Crays personal life as mentioned on this book review: www.goodreads.com/review/show/1277733185?book_show_action=true. His childhood section is brief, and his wedding is described in one paragraph, and divorce in one sentence. Part of this is because he was very private about his family most likely note how Wikipedia had missed his first wedding, and likely misattribute children to the second wedding; en.wikipedia.org/wiki/Talk:Seymour_Cray section "Weddings and Children".

Crays work philosophy is is highlighted many times in the book, and it is something worthy to have in mind:

Cray's final downfall was when he opted to try to use a promising but hard to work with material gallium arsenide instead of silicon as his way to try and speed up computers, see also: gallium arsenide vs silicon. Also, he went against the extremely current of the late 80's early 90's pointing rather towards using massively parallel systems based on silicon off-the-shelf Intel processors, a current that had DARPA support, and which by far the path that won very dramatically as of 2020, see: Intel supercomputer market share.