The bane of multicellularity.
Only people who need to drive a car should be allowed to drive a car anywhere near a city, e.g. people who work door to door, people who are disabled, etc.
Countryside driving is fine. If going to a city, you just have to drive to a parking outside of the city where you then take the public transport. And those who live in cities must leave their cars there too.
Everyone else must walk or cycle from home to public transport.
Cars just destroy everything, they make everything ugly:
- this was extremely clear to Ciro Santilli as a cyclist. He previously lived in a place with few cars and the countryside was so pleasant. Then he moved to a place with more cars and it was shocking. It's a mixture of pollution, noise, and the fact that roads cut up the countryside that just make things not pleasant at all. Dual lane roads in particular are just a terrible thing. You can hear them from afar, much before you see them.
- even within cities, cars completely dehumanize the streets. For example, Ciro once lived in a small dead end street, and he would have gladly opened his front window more often to meet the neighbours. But just the noise of cars passing by every so often makes it impractical to work like that.
The Zatoichi effect applies well to the problem of cyclists:This is the main drama faced by cyclists.
- they are not really pedestrians, and pedestrian paths are not suitable to them because they are too narrow, of not smooth, or curved. But pedestrians will always have enough political power to have their paths, because they live around the paths
- they are not really motor vehicles, because motor vehicle paths are too wide and too fast for them. But motor vehicles will always have enough political power to have their paths, because people are lazy and stupid, and because as the world stands, individually you just don't have any reasonable choice to go anywhere.
Lobbying groups:
When a disconnected space is made up of several smaller connected spaces, then each smaller component is called a "connected component" of the larger space.
See for example the
- When condensed matter physics became king by Joseph D. Martin (2019): physicstoday.scitation.org/doi/10.1063/PT.3.4110
- www.youtube.com/watch?v=RImqF8z91fU&list=PLtTPtV8SRcxi91n9Mni2xcQX4KhjX91xp Solid State Physics" course by Sergey Frolov taught at the University of Pittsburgh in the Fall 2015 semester
Alfred Leitner - Liquid Helium II the Superfluid by Alfred Leitner (1963)
Source. Original source: www.alfredleitner.com.The opposite of elementary particle.
A computer is a highly layered system, and so you have to decide which layers you are the most interested in studying.
Although the layer are somewhat independent, they also sometimes interact, and when that happens it usually hurts your brain. E.g., if compilers were perfect, no one optimizing software would have to know anything about microarchitecture. But if you want to go hardcore enough, you might have to learn some lower layer.
It must also be said that like in any industry, certain layers are hidden in commercial secrecy mysteries making it harder to actually learn them. In computing, the lower level you go, the more closed source things tend to become.
But as you climb down into the abyss of low level hardcoreness, don't forget that making usefulness is more important than being hardcore: Figure 1. "xkcd 378: Real Programmers".
First, the most important thing you should know about this subject: cirosantilli.com/linux-kernel-module-cheat/should-you-waste-your-life-with-systems-programming
Here's a summary from low-level to high-level:
- semiconductor physical implementation this level is of course the most closed, but it is fun to try and peek into it from any openings given by commercials and academia:
- photolithography, and notably photomask design
- register transfer level
- interactive Verilator fun: Is it possible to do interactive user input and output simulation in VHDL or Verilog?
- more importantly, and much harder/maybe impossible with open source, would be to try and set up a open source standard cell library and supporting software to obtain power, performance and area estimates
- Are there good open source standard cell libraries to learn IC synthesis with EDA tools? on Quora
- the most open source ones are some initiatives targeting FPGAs, e.g. symbiflow.github.io/, www.clifford.at/icestorm/
- qflow is an initiative targeting actual integrated circuits
- microarchitecture: a good way to play with this is to try and run some minimal userland examples on gem5 userland simulation with logging, e.g. see on the Linux Kernel Module Cheat:This should be done at the same time as books/website/courses that explain the microarchitecture basics.
- instruction set architecture: a good approach to learn this is to manually write some userland assembly with assertions as done in the Linux Kernel Module Cheat e.g. at:
- github.com/cirosantilli/linux-kernel-module-cheat/blob/9b6552ab6c66cb14d531eff903c4e78f3561e9ca/userland/arch/x86_64/add.S
- cirosantilli.com/linux-kernel-module-cheat/x86-userland-assembly
- learn a bit about calling conventions, e.g. by calling C standard library functions from assembly:
- you can also try and understand what some simple C programs compile to. Things can get a bit hard though when
-O3is used. Some cute examples:
- executable file format, notably executable and Linkable Format. Particularly important is to understand the basics of:
- address relocation: How do linkers and address relocation work?
- position independent code: What is the -fPIE option for position-independent executables in GCC and ld?
- how to observe which symbols are present in object files, e.g.:
- how C++ uses name mangling What is the effect of extern "C" in C++?
- how C++ template instantiation can help reduce link time and size: Explicit template instantiation - when is it used?
- operating system. There are two ways to approach this:
- learn about the Linux kernel Linux kernel. A good starting point is to learn about its main interfaces. This is well shown at Linux Kernel Module Cheat:
- system calls
- write some system calls in
- pure assembly:
- C GCC inline assembly:
- write some system calls in
- learn about kernel modules and their interfaces. Notably, learn about to demystify special files such
/dev/randomand so on: - learn how to do a minimal Linux kernel disk image/boot to userland hello world: What is the smallest possible Linux implementation?
- learn how to GDB Step debug the Linux kernel itself. Once you know this, you will feel that "given enough patience, I could understand anything that I wanted about the kernel", and you can then proceed to not learn almost anything about it and carry on with your life
- system calls
- write your own (mini-) OS, or study a minimal educational OS, e.g. as in:
- learn about the Linux kernel Linux kernel. A good starting point is to learn about its main interfaces. This is well shown at Linux Kernel Module Cheat:
- programming language
Count: 0.
2021-04 clogged
There are unlisted articles, also show them or only show them.