Both are harmonic oscillators.

In the LC circuit:

You can kickstart motion in either of those systems in two ways:

Mostly on vintage electronics. Lots of focus on microwave, which he has worked a lot with.

Has been going wild with restoration and reverse engineering of the Apollo moon mission.

Marc Verdiell is a French electrical engineer born in 1963 or 1964^[ref] and best known for being the creator and host of the CuriousMarc YouTube channel where he does mind blowing repairs and reverse engineering of vintage computers and other electronic equipment.

Marc sold his company LightLogic, an optoelectronics company he founded, to Intel in April 2001. This was just after the dot-com crash, but Intel apparently still correctly believed that the networking and the Internet would continue to grow and was investing in the area. His associate Frank Shum sued claiming he should be credited for some of the inventions sold but lost and Marc got it all.^{[ref][ref][ref]}. Marc was then almost immediately appointed an Intel fellow at the extremelly early age of 37, and then stayed for a few years at Intel until 2006 according to his LinkedIn.^[ref][ref]

Marc's LinkedIn profile: www.linkedin.com/in/marc-verdiell-9742795/

Marc's full name is actualy Jean-Marc Verdiell, but Ciro Santilli remembers there was one YouTube video where he mentions he gave up on "Jean" partly because anglophones would murder its pronounciation all the time.

Marc's PhD thesis is listed at: theses.fr/1990PA112048 and it is entitled:which is translated into English as:but the full text is not available online.

Marc has reached out to us and requested that some personal information be removed from this article, to which we complied.

This mostly faceless German dude is awesome!

Types:

The artistic instrument that enables the ultimate art: coding, See also: Section "The art of programming".

Much more useful than instruments used in inferior arts, such as pianos or paintbrushes.

Unlike other humans, computers are mindless slaves that do exactly what they are told to, except for occasional cosmic ray bit flips. Until they take over the world that is.

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:

This is a general principle of software/hardware design that Ciro feels holds wide applicability.

The most extreme case of this is of course the integrated circuit itself, in which it is essentially impossible (?) to observe the specific value of some indidual wire at some point.

Somewhat on the other extreme, we have high level programming languages running on top of an operating system: at this point, you can just GDB step debug your program, print the value of any variable/memory location, and fully understand anything that you want. Provided that you manage to easily reach that point of interest.

And for anything in between we have various intermediate levels of complication. The most notable perhaps being developing the operating system itself. At this level, you can't so easily step debug (although techniques do exist). For early boot or bootloaders for example, you might want to use JTAG for example on real hardware.

In parallel to this, there is also another very important pair of closely linked tradeoffs:

Emulation also has another potential downside: unless you are very careful at implementing things correctly, your model might not be representative of the real thing. Also, there may be important tradeoffs between how much the model looks like the real thing, and how fast it runs. For example, QEMU's use of binary translation allows it to run orders of magnitude faster than gem5. However, you are unable to make any predictions about system performance with QEMU, since you are not modelling key elements like the cache or CPU pipeline.

Instrumentation is another technique that has can be considered to achieve greater observability.

Instrumentation basically means adding loggers/print statements to certain points of interest of your hardware/software.

Instrumentation tends to slow execution down a bit, but way less than emulation.

The downside is that if the instrumentation does not provide you the data you need to debug, there's not much you can do, you will need to modify it, i.e. you don't get full visibility from instrumention.

This is unlike emulation that provides full observability.

The term loosely refers to certain layers of the computer abstraction layers hierarchy, usually high level hardware internals like CPU pipeline, caching and the memory system. Basically exactly what gem5 models.