Re: I did something similar as a rookie
This sounds like such a nightmare frankenputer. The idea of such a system using a cluster of 6509s...
I have programmed assembly for a 6509. There is joy in its simplicity, but also pain.
692 publicly visible posts • joined 3 Aug 2020
Just a point, traffic lights have special filters on them so they can be clearly distinguished by colorblind people (relative position isn't that useful when it's night time, and you can only see one light).
The sole exception in the entire universe is the traffic light at the exceptionally cursed offramp from the A15 Decarie Avenue to Decarie Boulavard in Montreal.
I have a counterpoint to this, which I'm afraid I must heavily anonymize.
Friend: "Most of our customers carefully plan out their infrastructure, with years from acquisition to full rollout. However, there is ONE HUGE client that is from another industry and they basically just build stuff at random".
Me: "Who?"
Friend: "I really can't tell you, you know, security and such."
Me: "It's definitely $MASSIVE_WELL_KNOWN_COMPANY."
Friend: "...I said I can't tell you that you are correct."
IMO, writing either "first" is a mistake.
If you write the documentation before writing any code, what you are creating is an idealized version of the program in your mind. Reality is going to bite you in the ass, yo often won't be able to implement the API or process that you want/
If you write the code before writing any documentation, then you are probably going to have an API or process driven more by convenience of implementation than the quality of experience you are delivering to the end-user.
I think the best thing is to write them in tandem with one another. Figure out how the feature can be implemented, write some documentation based on that code and decide whether it makes you feel like a war criminal, modify the code to match something better, repeat until both are finished at the same time.
There are many many reasons to write documentation. They are the same reasons that your operations will benefit from having a process and culture that respects the importance of said documentation.
I believe that when people say "documentation is pointless because it's always wrong and nobody reads it", what they mean is "documentation is pointless because I can't be arsed to do it correctly, and by the way that means you shouldn't bother reading any of mine". It's a self-fulfilling prophecy.
Somewhat related, I'm given to understand that Alpha's memory model was...cursed...non-existent...a nightmare.
Thus, I'm kind of glad it went the way of the dodo. If it hadn't, sed::atomic might have something much MUCH worse kicking about than memory_order_relaxed.
I worked on a graphics system which needed to assign a unique number to each graphics object.
If you somehow manage to create (over the lifetime of one instance of the system) enough graphics objects, it will say something to the effect of "You have managed to overflow a signed 64-bit integer. Save a seat for me at Milliways."
I wonder if I'm going to get a very annoyed text message from my old boss one day...
Hmmm, except that software often goes through periods where performance is not acceptable during development. If you give the devs minimum spec machines, then you are needlessly hampering them during those times. Also, sometimes there are features which simply require more grunt than the minimum specs.
Example, I was working on a 3D Display system. Most users were on integrated graphics, but I had an Nvidia card. When working with high detail objects (especially those with transparency), the Intel GPU was nowhere. We developed a system to degrade those objects automatically, but developing that system obviously required lots of testing and fine-tuning. If I had been stuck with the Intel the whole time, that process would have been painful on the deepest levels.
Something else to consider, is that a lot of software safety gains have come from performance improvements (and then been consumed by the complexity enabled).
Consider a checked array access. Without branch prediction, it is totally impractical to check whether every array access is out of bounds. With it, your easily predictable jump effectively blows away like dust.
Another example, shared state is the enemy of correct coding. If `malloc` is fast, and memory is plentiful, maybe you can just duplicate that data structure rather than having to manage multiple users of the same copy.
So some of the efficiency loss in software is because of a shift to techniques that are marginally slower but a lot easier to manage in a large complex program. That said, I think for most uses these gains have already been made.
The point is that most people, regardless of their job, are going to be annoyed about being required to do things they deem to be pointless. It's just that what is pointless changes depending on what you do.
My brother works in hardware testing. He is required to wear ESD shoes. Nobody questions this because the reasons are obvious.
I used to work in a grocery store. I wouldn't have ever thought to complain about needing to come into work...because well...that's where the food is. But imagine if I had been told I needed to buy ESD shoes. I'd be livid, because it would be inconveniencing me for no reason. Let me wear cheap shoes that I find comfortable, I do not need to be ESD safe. (This never happened, just a hypothetical).
So my point is, it doesn't matter that some people can WFH and some can't. The solidarity between workers that should make this relatable to everybody is that we hate being required to do things for the company that inconvenience us without good reason.
THE UNIONS FOREVER! DE-FEND-ING OUR RIGHTS. POWER TO THE FACT-RIES! THE WORRRKERS UNITE!
So on and so forth.
Microsoft today revealed that the next Windows release (Windows 12) will require no installation, and instead will load directly from two 30TB LTO-8 tapes.
"We've packed more features than ever into Windows 12" said Micros~1 CEO Satya Nadella. "We didn't want you to have to wait to install our robust, AI-driven operating system experience. Your next OS will therefore have no install process, simply load Windows Tape 12A (WT12A) into your LTO drive and go. It's our most seamless setup process yet."
When asked whether he was worried that the requirement of an LTO drive would limit uptake of the new spyware, Nadella had this to say:
"Nobody wants to be kept behind by technology. Current SSD and HDD technology simply isn't capable of delivering the storage capacity performance that modern users expect and that a fully reactive, AI-driven operating system experience requires. We are always forward looking; keeping pace with the technology in your next computer, not your current one."
He added, "In any case, your current laptop has a broken F12 key, so why wouldn't you want to replace it?"
Well for one thing, in my little MX-5 which weighs less than a ton, dropping 7 KG would be a huge reduction :p. It's also the sort of thing where as a driver you wouldn't notice, but if deployed to the global fleet it would save huge amounts of gas.
The other thing is that in most cars, the battery is up front and takes up a large section of the engine bay. Thus, making it smaller and lighter would improve weight distribution, and allow car designers more freedom in packaging (possibly leading to more legroom).
To start with these are much worse than FDIV. That bug was only relevant to a very small subset of users. Having a CPU that can leak information that is supposed to be secret is bad news bears.
Secondly, somehow or another a password system requires the password to to be stored AT AN ABSOLUTE MINIMUM in the CPUs registers long enough to be hashed and validated. In practice, it is going to have the live in memory too. When you type your password into a password box on a website, where do you think it lives? It's not stored in some magical netherrealm...and even if it was, the CPU is going to need access to that netherrealm to read it at some point. The problem with these sorts of flaws is that the friendly and hostile programs are both executed by the same CPU, and that CPU has final say about which programs can access what.
The idea of a password system that does not at any point store a password/key in plaintext in a place accessible by some processor that can hash/validate it does not make sense. The CPU is the start of your chain of trust.