A lot of "why TF would anyone you do this?" questions can be answered with variations like this. Borrowing from economics, the discount rate defines how much more valuable something is RIGHT NOW vs at some point in the future. If the system is down and we're losing money by the minute until it is up; if the company will be broke next week unless we make customer X happy; if you have to get to the airport in 2 hours - it is completely rational to make the quick fix. The costs of not doing so outweigh the costs of doing it again properly.
It really becomes a problem when the same short term calculation becomes the standard - you can quickly rack up costs that future you or future company will never pay down.
I sometimes wonder about the commercial impact of source code leaks. In this case, nobody noticed until the product was commercially irrelevant, but what might have happened if some competitor had noticed?
My guess is probably nothing. Having the interpreter source code is a liability for other companies in case of an infringement lawsuit. Are there good examples where a source code leak actually led to significant consequences for a company?
My hunch is that companies tend to be paranoid and vastly overestimate the commercial importance of their source code. Are there really that many realistic opportunities to copy secrets from one mature source tree to another and commercially benefit from it? These code bases are likely totally different, use different design patterns, different internal APIs, data models are different, maybe even different languages.
Anyone who has done integration work between two totally foreign-to-each-other code bases knows that the integration effort is often greater than just writing the code from scratch.
The biggest risk is probably someone getting their hands on the entire project, including code, art assets, build infrastructure, and just compiling an identical program to release under their own name. But that would be obvious and probably easy to prove/litigate.
> Are there really that many realistic opportunities to copy secrets from one mature source tree to another and commercially benefit from it? These code bases are likely totally different, use different design patterns, different internal APIs, data models are different, maybe even different languages.
When you're stuck failing to make something work, it can be a large benefit to be able to look at how somebody else managed to make it work. Sometimes it's a bit you forgot to set on a register somewhere, sometimes it's a sequence of operations that tickles a hardware bug which can be avoided by doing things in a different order. On a higher level, sometimes the issue is that the A API is implemented as "return <error>" and only the corresponding W API is actually implemented. Or the trick to make the API work is to cast one of the many objects you already got into a non-intuitive poorly-documented interface, allowing you to call a method which returns yet another object which allows you to do what you actually want. And so on.
This was one of the ideas pursued in the Reagan-era Strategic Defense Initiative, aka Star Wars. They weren't able to develop a system that would work against ICBMs. Powering an aircraft is both easier and harder; the aircraft presumably isn't making evasive maneuvers and trying to stop you from powering it, but the economic and safety constraints are harder.
IIRC, one of the problems with SDI was that at the time the only way to make lasers powerful enough to destroy an ICBM was to pump the lasing medium with a nuke, making them one-shot devices.
Sensing may still be a problem today, especially as stealth is also improving, but detection in general is much easier than it was in the Regan era.
That doesn't sound like an airline I would care to fly!
During takeoff a 747 consumes power at a rate of about 90MW. Having something outside the plane, whether in orbit or ground-based, pumping that much power into the plane while I'm in it, sounds quite alarming. Not to mention issues with aiming, power loss, etc.
To power a plane with renewable sources, it seems most practical to generate power on the ground and use that to produce synthetic fuel.
"zero-error policy" as described here is a remarkable euphemism. You might hope that the policy is not to make any errors. In fact the policy is not to acknowledge that errors can occur!
Yes, because it is rational. Maybe taking it this far isn’t when you consider personal impact, but questioning things is very rational, and there are more than enough legitimate examples (MKULTRA, Operation Northwoods, and countless other declassified operations that were regarded as conspiracies in their time) to justify not accepting things at face value.
There are declassified documents from the Warren Commission where they basically concede that parts of the CIA could have been involved. And there IS significant fishiness around 9/11 (the missing trillions, back when that was a lot, building 7, etc), it should be questioned. That doesn’t mean assuming US involvement, it just means not assuming that there wasn’t any. Because there it should be clear by now that most of government does not have the people as a priority.
The Epstein island was a “conspiracy theory” at least a decade before it was known, and it’s still considered “conspiracy thinking” to say it was an intelligence operation, when that’s the only rational explanation given all the details. And there was someone that had him suicided under the public eye, it’s not inconceivable to me that those same people would facilitate a domestic terror attack. Especially after reading declassified CIA documents proposing similar false flags.
He had a real gift for making theoretical topics interesting. I read his book The New Turing Omnibus (https://archive.org/details/newturingomnibus0000dewd_q3p6) as a teenager, and credit it with a decent part of getting me into computer science. Rest easy.
Another thankful note from me for The New Turing Omnibus. It’s recommended to students entering Cambridge University in the UK, and I read it as a young teenager. I was already familiar with a lot of the concepts contained, but it was a really good stitching together of a variety of disciplines. It gives just enough of a peek into each of them to spur curiosity about the things you might want to study more — and at least makes you aware of the things that you might be less interested in.
I spent an excessive amount of time playing with an animated version of Dewdney's wallpaper algorithm from The Turing Omnibus, first with 286 fixed point arithmetic and later with 486 FPU code.
Hah, I went through a similar cycle with Mandelbrot stuff - first with custom fixed point on a 6502, then I somehow got my hands on a prototype Apple ][ FPU card of some sort, then there was the 386/387 (sweet sweet 80 bit floats!), etc.
> "Apple APU. The Model 7811 B Arithmetic Processor Unit is intended to increase the execution speed of Applesoft II programs and the number of math functions available. The system employs an AMD9511 APU and plugs into one of the Apple expansion slots. The CCSoft interpreter is loaded from the diskette provided, and the system is ready to, go. The CCSoft interpreter is identical to Applesoft, except that CCSoft sends arithmetic functions to the APU for fast execution. Additional functions include AsiN(x), ACOS(X), LOGIO(X), SINIH(x), COSH(x), TANH(X), INVERSE(x) and PI. "
It really becomes a problem when the same short term calculation becomes the standard - you can quickly rack up costs that future you or future company will never pay down.