saner defaults, easier configurability (esp. mouse/keyboard, where the documentation can be less-than-clear; and imported config files, where the path doesn't always resolve cleanly), user-friendly documentation available in multiple forms (Alacritty has declared they will never do this: manpage and website only!), lack of dismissive attitude from devs (in addition to manpage stubbornness? no to "smart copy", no "example config", no "reset and clear scrollback" which was a 6-line ready-to-go PR, no "confirm quit" when tasks are active or even when the user prefers it), better integrated with GTK libraries and GNOME extensions (no strange Alt+Tab popup behavior, unresolved IBus weirdness), good proof of concept for an alternative new-ish programming language, Alacritty is generally not faster or leaner or bug-free compared to some other terminals: every now and then I would open top and alacritty would be at 8 or 9 percent while just being open in the background (and with reasonably high physical memory usage; just because my machine has the RAM doesn't mean I want the OS to allocate it to over-hungry Rust utilities)
I can think of a dozen excellent reasons to stop using Alacritty (and not in favor of Kitty) and I did because of some of them.
Yet another analogy is designing and presenting a radar detector/jammer but never using it on public roads.
Until the author has used the tool on the UW server during registration, he is not violating their policies and procedures: He hasn't attempted to tamper with records. He admittedly hasn't used their registration system with this tool. Those are the two key phrases in their policy. The text goes on to specifically describe abuse as "use" of a script or robot. There isn't anything forbidding a student from authoring a script.
One problem here is that by releasing the source, it makes it easier for another student to exploit the system. In the case where another student uses this tool during registration, the other student is fully responsible.
Besides all that, it's a great project idea because everyone in his program would instantly relate to the problem.
It's easy to understand the University's overreaction---and it is an overreaction. The better solution from UW would have been to sternly inform the student(s), "The website can never go live. It dies as a proof of concept. Please use your own dummy data; no API access. A disclaimer must be added to any class demos (presentations, code, etc.) with the Tampering and Abuse policy, and that this only uses generated data. Our efforts to improve the registration system in the future will be X, Y, Z."
This student has done nothing wrong (yet) (based on what he revealed) and is getting punished for being near the border.
"Awful" would be a kind description of this keyboard. The bottom two rows are aligned, which is the new anti-ANSI laptop trend. Page up and down are now Fn keys. Insert is a function key. PrtSc is long gone. F key font is miniscule. F keys are no longer grouped (unless you count that tiny fillet as a grouping). I'm willing to bet they still haven't added Alt+MicMute as an alias to Alt+F4 (since virtually nobody in the history of computing has needed a keyboard modifier with the MicMute button). Delete is awkwardly wide. Control is sunken in so you can't press it with the outside of your hand anymore. Up and down arrows share one over-wide key. These look like low-travel chiclets. Of course it has Microsoft branding.
I'm willing to bet the ISO variant of this machine is even dumber, with that key that rides right up against Enter.
I hate the Trackpoint. I shed no tears if it goes. It isn't a pleasant experience in Linux and doesn't save any time over keyboard and touchpad, and the entire subsystem is just more crap to debug and waste energy. On the other hand, the ThinkPad keyboard is the only laptop input I consider decent for heavy terminal use and programming.
...as far as copying Apple? At least Apple had the decency to ditch differently sized arrow key pairs. Unless Lenovo offers large gamut IPS or more than 2 watts of speakers or anything at all special, this is "just another" PC laptop.
I owned a Z13 Gen 1 and it was a horrendous piece of crap. I constantly had crashes, hangs, faulty suspend, keyboard problems, dock problems, audio problems, and so much more from the very beginning.
I very reluctantly purchased a X1 Carbon Gen 12 and am much more satisfied with the Linux implementation.
My Z13 most definitely was defective, although after seeing a few similar cases, I wonder if they had a bad batch or if that was just an unstable platform. Even after getting it serviced (which was a joke, because they don't diagnose Linux machines at the service center even though Lenovo sells them) nothing improved.
Strangely fortunate: it got stolen in Dublin and was covered by insurance.
Some of the early Microprose games used this, and it was clever for two reasons:
First, more functionality. The minigames and intro/conclusion scenes were their own executables that made use of the original, generated game data. These got loaded into RAM on top of the original executable and then called.
Second, graphics and sound were also overlays. Rather than having useless-to-most Roland MT-32 code in the binary, this was only loaded if requested. There were overlays for Sound Blaster, PC speaker, and Adlib. If your monitor only supported four colors (CGA) there was an overlay for that.
A post would be nice, although you basically described most of it. An .OVL file with a non-zero overlay number is loaded into memory with INT 3Fh (although strangely enough any interrupt number could be chosen?, and the interrupt also would call the desired function after loading into memory). These overlays are loaded as-needed into a shared memory space.
I'd be more curious to see how one would have programmed those overlays in Microsoft C Compiler 3.0. More recent compilers seemed to have better menus and documentation for the memory models, but it seems like they were clairvoyant by squeezing every bit of functionality out of version 3.0 that was made easier by Watcom/Borland/MS 5.0. (Then again, they would have evolved their build system with every successful release and every new hire, plus it was their full time job to "figure that crap out", and maybe Microsoft improved their approach to overlays in response to Microprose and others calling all the time)
The documentation states only one EXE is generated, but Microprose had multiple EXE files. Is it possible those weren't overlays but something very similar? Or did they just change the file extensions? The docs also show the syntax "Object Modules [.OBJ]: a + (b+c) + (e+f) + g + (i)" where everything in parentheses is an overlay. But this isn't elaborated. What are the plus signs? How are these objects grouped? Would their list look like "preload + (cga + mcga + ega + vga) + (nosound + tandy + pcspkr + roland + sb) + (intro) + (newgame) + (maingame) + (minigamea) + (minigameb) + (outro)"? Or would every module be individually parenthesized, and those with plus symbols are interdependent (e.g. not alternatives)? (One website using BLINK seems to suggest the latter.)
I know there are a lot of DOS tutorials (FreeDOS YT channel, blog posts) but I haven't found one that does a start-to-finish overlay example.
Awesome! That's my reading material for the next week.
Now I wonder if MISC.EXE and xGRAPHIC.EXE were the same across different games e.g. Covert Action vs F15 SE2... (I just checked. MISC is different. Some routines are nearly similar, but newer versions have additional machine code and updated strings.)
Interestingly, although Civilization uses an almost identical setup menu and also contains multiple exes that look like sound and graphic drivers based on their name, the overlay header format of those seems to be different, and could not be parsed by my tool. Seems likey they were updating the scheme as they went along (Civ 1 came out 1991, so after F15-II).
My guess is that they constantly updated their libraries game by game, as both hardware and software/dev tools in those times were moving really fast.
The original X-COM (aka UFO: Enemy Unknown), despite being 32-bit, had two completely separate executables for the strategy part and the tactical combat part. The game basically dumped the relevant state like inventory to disk and then exited and relaunched the other process at switch points.
There are a few things that helped me or someone I know to understand some concepts:
e: Hot/cold stuff passively reaching ambient temperature (why does it get colder quicker right at the beginning but so slowly at the end??) as well as the time constant for capacitors (which you could analogize with how long it would take for water to drain out of a broken dam: quickly at first, slowly as the water level decreases)
integrals: My brother designed a boat that he would build. He wanted to know how much volume it would displace until water would spill inside. The walls were not straight nor right-angled. Using the slicing method and estimates of "this is somewhere between an oval and rectangle, so the area of this slice will be between those shapes", he was able to figure out the ballpark volume.
derivatives, and this one takes a LOT of care to avoid confusion... position, velocity, acceleration. I would start with straight distance examples, but it's also cool to note: On a Merry Go Round, the rider's acceleration would only be toward the center if the rotating speed stays the same. It has to! If it were even a little backwards, you'd slow down! If the Merry Go Round were wider, the acceleration would be not so strong. If the Merry Go Round were so wide that it's impossible to tell you are spinning, there would be nearly no acceleration.
When you drop that ball from a window, gravity is its acceleration. Gravity never changes its direction or gets stronger. That is intuitive. The velocity will keep getting larger, but at the same rate for a while (until real life interferes aka drag). The position, you can plot that and see that every second it is a farther interval. That also makes sense: A ball thrown upward doesn't bounce off the air at the top and come down right away at the same speed. It hangs for a brief moment. But it doesn't hang anywhere else after its peak because the position is the second derivative of acceleration, and that second derivative only has one point where it stays nearly the same for a brief moment.
It might not stick for everyone, but you can explain that 6 dB is always "twice as loud". Thus, 12 dB is "2x2 times as loud" and 18 dB is "2x2x2, or 8 times, as loud". The dB amount is always addition, but the "as loud" part is multiplied.
Similarly, every 10 to 30 years (usually about 20) the value of money drops in half due to inflation. You're adding years but multiplying or dividing value. That lets you know that there's a power/logarithmic relationship.
One other concept is more useless but fun for me... There's product-over-sum. It shows up in "how long does it take N lawnmower pushers of varying efficiency to trim so-and-so acres of lawn?" (If Joe does a lawn in 20 and Jake in 30, they do it in 12 together.) but also in things like parallel resistance. In this case, I tend to think of the electrons as the blades of grass in the lawn and the resistors as lawnmower pushers. The electrons don't care who "trims" them, and whichever resistor becomes available to process an electron (at its own given efficiency e.g. conductance/anti-resistance) will do it.
I am a big fan of the Street Fighting Math series from MIT, but I feel like there were much better resources for explaining the concepts (e.g. videos, lectures) than I can find today. The book is not as approachable as the concepts themselves when explained at an audience-appropriate level. The only downside it its lack of general practicality, but it does move some advanced concepts into the napkin math domain.
In one part, Dr. Mahajan shows that because the derivative of the LN function is very close to the derivative of x at 1 (that is, 1), you can approximate powers close to 1 by subtracting 1 to get them into the log domain and multiplying by their exponent. This probably doesn't make sense, so I'll solve an example from the book...
"If 5% of bacteria are mutated during a radiation round, how many bacteria are unmutated after 140 rounds?"
You can eventually figure it will be (.95)^140 by starting with simpler examples (all heads in two coin flips, three coin flips). Once you have the equation, it means that you can approximate its answer by subtracting 1 and multiplying by 140: -0.05x140 = -7. The answer would be quite near e^-7, which is 0.09%. (Beyond that, if you recognize that e^-5 would be five time constants e.g. just below 1%, then e^-10 is 1% of 1%, so then e^-7.5 would be the halfway point; somewhere below but also close to 0.1%.) The right answer is approx. 0.08%.
An actual game that is engaging and shows one math concept (probability/statistics) in-depth? Dope Wars. The entire thing runs off random chance and expectation. You could probably even simulate the outcome of various strategies over many simulations (the same way that a decent investment recommendation would be a percentage of bonds/cash equal to your age with the remainder in stocks)
Even stuff like Pythagorean Theorem isn't as important to an everyman as its moral. "If you cut through the grass, it's less walking." This also extends to the value of social networks (Metcalfe's Law) or understanding why a small bump in speed limit takes a relatively large increase in gas consumption (Ignoring wind resistance, kinetic energy is proportional to v^2, so going 55 mph takes roughly the same energy as someone going 50 plus someone else going 23.)
This is all a really lovely list. Thank you for your answer.
I love Street Fighting Mathematics too, but it's tough even for me. Meaning, it makes sense as I see the explanation, but these techniques of estimation have to be practiced over and over again to feel natural.
As for the gravity example, a small game using Scratch was enough to get them to appreciate acceleration, by associating velocity with audio. You intuitively know what a vehicle sounds like when it is maintaining constant speed, vs when it is accelerating or decelerating (negative acceleration)
From there it was a small delta to showing horizontal launch velocity but no acceleration, and how you can deal with the x and y components independently, and how a ball automatically traces a quadratic curve.
This. There's a lot to be said about understanding registers and assembly and different languages and how a USB packet is constructed, but efficiency in reverse engineering comes down to effective pattern recognition.
A binary is likely to have a reasonable amount of often-called code for memory operations (memset, memcpy, strcat, strlen, sscanf, log) and a lot of library code (Flexcomm_Init, Clock_AttachClk, SPI1_Handler, NVIC_EnableIRQ) and then probably fairly little actual application code. For Ghidra users, being able to ignore the boilerplate (mem and BSP code) and quickly find and analyze the application code saves a TON of time.
(Conversely, if I know a binary is written using FreeRTOS, finding the task creation function would be my first step, as this reveals nearly all of the application code.)
There are techniques to help (setting a flash memory region as non-write so string references are recognized and disassembled correctly, loading a chip SVD so all the library code is more obvious) but those come with experience or a good hands-on tutorial, and they still won't tell you everything about the application code.
In my own breakdown of one Cortex-M binary (bare metal, no objects known) the only reason I was able to get the firmware in the first place was by noticing and decoding a base64 string in an unpacked Electron app used for USB communication with the device. This ended up holding plaintext credentials for their update server which had two channels: one for encrypted production binaries and the other for unencrypted development binaries.
In this specific case, it helped to know what base64 looks like, but that's like how knowing different methods of slicing onions might help you figure out a recipe by tasting a cooked meal. Very often such background knowledge is irrelevant. Once in a while it will be the only realistic way forward.
