> I've forgotten more things in this field than I'm comfortable with today. I find it a bit sad that I've completely lost my Win32 reverse engineering skills I had in my teens
I'm a bit younger (33) but you'd be surprised how fast it comes back. I hadn't touched x86 assembly for probably 10 years at one point. Then someone asked a question in a modding community for an ancient game and after spending a few hours it mostly came back to me.
I'm sure if you had to reverse engineer some win32 applications, it'd come back quickly.
That's a skill onto itself, and I mean the general stuff does not fade or at least come back quickly. But there's a lot of the tail end that's just difficult to recall because it's obscure.
How exactly did I hook Delphi apps' TForm handling system instead of breakpointing GetWindowTextA and friends? I mean... I just cannot remember. It wasn't super easy either.
I want to second this. I'm 38 and I used to do some debugging and reverse engineering during my university days (2006-2011). Since then I've mainly avoided looking at assembly since I mostly work in C++ systems or HLSL.
These last few months, however, I've had to spend a lot of time debugging via disassembly for my work. It felt really slow at first, but then it came back to me and now it's really natural again.
It's interesting that China does not have exact data. Don't they require everyone to register their address? I know foreigners must do it, and chatting with the locals they told me they were registered as well.
I would have imagined that the data could be used to get mostly accurate numbers.
Even if they required it that's no guarantee people actually do it. I have lived for a couple of years at an address different than the one I was registered at. Illegal in my country, but easy to conceal. (I had to because the apartment I lived in didn't strictly allow people of my sort to permanently reside in it.)
I used to work in the semiconductor industry writing internal tools for the company. Hardware very rarely missed a deadline and software was run the same way.
Things rarely went to plan, but as soon as any blip occured, there'd be plans to trim scope, crunch more, or push the date with many months of notice.
Then I joined my first web SaaS startup and I think we didn't hit a single deadline in the entire time I worked there. Everyone thought that was fine and normal. Interestingly enough, I'm not convinced that's why we failed, but it was a huge culture shock.
> I used to work in the semiconductor industry writing internal tools for the company. Hardware very rarely missed a deadline and software was run the same way.
Former Test Engineer here. It was always fun when everyone else’s deadline slipped but ours stayed the same. Had to still ship on the same date even if I didn’t have silicon until much later than originally planned.
I think you were estimating time to build things that were out of R&D and you had specifications that were actual specifications you were building up to.
In SaaS my experience is: someone makes up an idea not having any clue how existing software is working or is laid out, has no specifications beside vague not organized bunch of sentences. Software development team basically starts R&D to find out specifications and what is possible - but is expected to deliver final product.
I had the same experience when doing an exercise implementing `mmap` for `xv6` -- that was the last lab. There was no specification except for a test file. Passing that test file is relatively easy and I could game it. I consulted the manpage of `mmap` but it is pretty far from a specification, so eventually I had to write a lot of tests in Linux to figure out what it can do and what it can't do (what happens when I over-mmap? what happens when I write back pass EOF? etc.), and write the same tests for `xv6` so that I could test my implementation. Not sure about hardware, but it is really hard to get a clear specification for software.
This aligns with my experience in the semi industry. SWEs tend to see trimming scope as moving the goalpost and do not consider as an option. Providing advance notice is mostly about client management, and clients are often surprisingly receptive to partial solutions.
That's fun to read, I remember when NoSQL was getting cargo-culted, it was specifically because it was more "agile". The reason being you don't need to worry about a schema. Just stick your data in there and figure it out later.
Interesting to hear now that the opinion is the opposite.
Unfortunately, nowadays writing userscripts is much harder than it used to be. Most websites are using some sort of reactive FE framework so you need to make extensive use of mutationObservers (or whatever the equivalent is in jQuery I guess).
I'm not a frontend dev but I came up with this and use it a lot in my userscripts. It's not the most efficient (it can certainly be refactored to create a MutationObserver singleton and then have each call hook into that) but it works well enough for my needs and lets me basically use an old-school to dealing with reactive sites (so long as you are fine with using async):
function awaitElement(selector) {
return awaitPredicate(selector, _ => true);
}
function awaitPredicate(selector, predicate) {
return new Promise((resolve, _reject) => {
for (const el of document.querySelectorAll(selector)) {
if (predicate(el)) {
resolve(el);
return;
}
}
// Create a MutationObserver to listen for changes
const observer = new MutationObserver((_mutations, obs) => {
// You could search just inside _mutations instead of the entire DOM.
// Efficiency will depend primarily on how precise your selector is.
for (const el of document.querySelectorAll(selector)) {
if (predicate(el)) {
resolve(el);
obs.disconnect(); // Don't forget to disconnect the observer!
break;
}
}
});
// Start observing the document
observer.observe(document.documentElement, {
childList: true,
subtree: true,
attributes: false,
characterData: false,
});
});
}
Very true. I guess that depends on what websites you find issues with? I just checked mine and all of those are quality of life improvements for fully server rendered sites like HN or phpBB forums.
Yeah, I mostly use it for QoL improvements but for work related things. So Jira, Bitbucket, GitHub, Linear etc. basically whatever my employer uses. Back in the early 2010s most of that software was fully server rendered. Nowadays it's pretty rare for that to be the case.
I just try and get LLMs to do it for me because I'm lazy, and they like to use setInterval instead of mutationObservers and if it works, I just live with the inefficiency.
The Atlassian stack is particularly bad to extend IMHO given that there are sooooo many API endpoints that their UI calls and most of them are dog slow.
Super interesting to hear about those concepts from another language/culture. While you are right that in software pretty much everything is "scaffolding" in the semiconductor the scaffolding vs steel applies.
To simplify it as much as possible, to make a chip multiple masks are created for different layers. The top layers are metal(scaffolding) and the base layers are silicon(steel). The metal layer masks are much cheaper to make than the base layers. So we add extra unused cells in the base layers and then if there are issues we try to fix them only in the metal layers.
It's not really an art nowadays, since it's been refined so much with tooling and processes. But your analogy is very applicable, I might try to refer to it in the future if I ever need to explain the concept to someone.
@doix, thank you for the fascinating deep dive into semiconductor design. To make sure I’ve grasped your point correctly, let me try to summarize it:
- Base Layer (Silicon) = "Steel": Re-manufacturing it is extremely costly, so it must be perfect from the start.
- Top Layer (Metal) = "Scaffolding": The wiring layers. These are much cheaper to produce, allowing for "patches" or corrections later on.
- The Wisdom of "Unused Cells": By embedding spare cells in the base layer upfront, you can fix bugs later just by changing the metal layers.
Did I get that right?
If so, this logic deeply resonates with what I’ve seen in Japanese "Shinise" (long-standing businesses) as a banker. Specifically, two practices that might look "inefficient" in a modern business model are, in my view, the "Unused Cells" of our Base Layer:
1. Not firing employees easily:
While some models treat labor like a "Metal layer" to be cut and replaced for quick optimization, Shinise treat people as part of the "Silicon layer." We keep them even in hard times so that when a big crisis hits, we can "re-wire" their roles to survive together.
2. Keeping high cash savings:
Many modern companies prefer to spend all their cash to maximize growth speed. However, Shinise keep a lot of cash. This is like the spare cells in your silicon—it allows us to finance our own "re-wiring" when the market crashes, without the foundation collapsing.
Your insight has given me a powerful new framework for why some organizations survive for 500 years while others vanish in three. Thank you!
I had similar thoughts to the author, but I opted to just optimize those actions out of my life. If you only eat Huel(or any other powdered food thing) at home then pretty much everything described in the article is no longer an issue.
No more dealing with dishes, dishwashers, stray items on the table, boiling water etc. The only thing you need to worry about is cleaning your one huel cup which you can do right before you prepare your next shake.
I did it for a few years, eating breakfast + lunch at the office and then Huel for dinner or eating out at restaurant.
> Plex allows you to stream without opening up your firewall to others.
It relies on their hosted services/infrastructure. I avoid Plex for that reason. I just host my media with nginx + indexing enabled. Wireguard for creating the tunnel between the server-client and Kodi as the frontend to view the media (you can add an indexed http server as a media source).
Works great, no transcoding like Plex, but that's less of an issue nowadays when hardware accelerated decoders are common for h264 & h265.
> It relies on their hosted services/infrastructure.
Only if you want it to. Your local Plex server is always available on port 32400 - which can be opened up for others as well. But using Plex’s authentication is more convenient, of course.
Yeah, I was specifically talking about the "firewall" bypassing the parent mentioned (most likely combined with NAT punch-through as well). You could of course use Plex without that and use wireguard (or just make it available to the internet) and not rely on their infra.
I'm a bit younger (33) but you'd be surprised how fast it comes back. I hadn't touched x86 assembly for probably 10 years at one point. Then someone asked a question in a modding community for an ancient game and after spending a few hours it mostly came back to me.
I'm sure if you had to reverse engineer some win32 applications, it'd come back quickly.