67,000 MWh = 67 GWh, not 67 TWh.
The meta-Turing test counts a thing as intelligent if it seeks to devise and apply Turing tests to objects of its own creation.
--Lew Mammel, Jr.
The only thing I can think is it works like a refrigerator.
The shock wave compress the the dust, which raises its temperature, so it radiates heat (a lot of heat: P ~ T^4).
When the shock wave passes, the dust expands and cools back down below its original temperature.
I'm older than that and still employed.
I've made my career building out new applications that are enabled by advancing computer technology. These jobs only last for a few years. A basic product development cycle is maybe 2 to 5 years, at which point you've either
- succeeded, and don't need people like me any more
- failed, and definitely don't need people like me any more
When the job goes away, I find a new one. Sometimes I find a new job at the same company, but that is inessential.
The short tenure of these jobs doesn't have much to do with me. It is driven by the staggering speed at which the underlying computer technology is advancing and changing.
DigiComp I was a plastic, hand-cranked, 3-bit state machine, with some restrictions on the allowed state transitions.
You programmed it by pushing little plastic tubes on to little plastic tabs.
I had one when I was 9 or 10 years old.
I've been a hacker ever since.
I figured this out twenty-mumble years ago.
I was doing data analysis in spreadsheets, and realized that I had no way to audit them.
The data and the analysis were all just...there...in the spreadsheet.
As soon as I got a grip on my data, I changed over to C programs that I could test, and document, and validate, and run at any time to demonstrate that input X generated output Y.
I heard an interview with Torvalds where they asked him why there was no kernel ABI.
He explained that the reason people want ABIs is so they can link object code into the kernel w/o releasing the sources,
and then that code breaks, and he ends up having to debug kernels with incomplete sources.
And he doesn't want to do that.
So no kernel ABI.
I don't know that I'd call that arrogant. Selfish, maybe...
The good news is that because the Linux kernel has no ABIs,
the sources are all necessarily available,
which means that you can get the sources, and fork them, and add ABIs, and create a binary driver compatibility layer,
so that people can link in drivers w/o sources,
and then you'll be running a kernel with incomplete sources,
and then....ummm....wait....what was the good news again?
My reading speed moves up and down to maintain a constant information density.
In a low-density text, like, ummm, Slashdot comments, I skim.
In a medium-density text, like a novel, I read every word.
In a high-density text, like a math book, I *study* every word.
And it's not something that I have to think about either: it happens automatically.
My subjective experience is that I'm managing a tradeoff between boredom (too slow) and incomprehension (too fast).
I'm Pappy. I'm not dead, but my kids have been hearing me bitch about Microsoft as long as they can remember. At this point, they probably think of it like a fixture of the landscape: the old man doesn't like Microsoft.
So my oldest finally graduates college, and gets his first real job. He's an engineer; industrial controls. The vendors only write drivers for Windows, so everyone uses Windows, and no one cares. He's provisioning servers in plants, and doing Windows installs, and running VMs, and trying to automate things. And it's all done in Windows Power Shell.
After a few months, I start getting calls from him. He's astonished: "This thing really sucks!" he tells me. It kind of a broken, crippled, over-engineered, badly implemented shell. It's always in his way. Everything is a needless problem. He talks about what a relief it is to go home on weekends, and work on his own systems, in Linux, running bash, and being able to work on the actual problem, instead of spending all his time fighting with the system and the tools. And every time he calls, it's the same refrain with more exclamation points: "This thing really sucks!!!"
So, yeah, he learned it from me, but then he learned it for himself.
local variables can cause stack overflows.
I've seen this assertion in two comments now.
How do local variables cause stack overflow?
If you aren't using recursion, then total stack space requirements can be computed from static code analysis.
If you are using recursion, then you can overflow the stack with return addresses alone.
BTW, I did read most of the expert testimony, and some of the expert report.
The suspect software is catastrophically bad.
I threw a monkey wrench into the engine of my car, and it ran slower. Maybe if throw something different into it, it will run faster
The late Senator Ted Kennedy was famously put on this list as well.
They wouldn't let him board a flight from Boston to Washington, so he was stuck in Boston for a few days until someone removed his name. Then he flew to Washington.
I was very disappointed by this. I was hoping that he would stay camped out at Logan airport, and pledge not to fly until the government created a procedure for people who aren't United States senators to get their names off of the list.
If you are a contractor, and "there's plenty of jobs you can take", then you really don't have a problem here. Let's take it by cases.
1. You just don't want to deal with this app/code base/company/assignment
Then leave for one of those other jobs. That's part of what being a contractor is all about: being able to drop clients that you don't want to deal with.
You don't have to be rude or snarky about it. Give notice, complete whatever term or notice period is specified in your contract, and move on. If they ask why, tell them simply and honestly. Providing such information (if asked) is part of your service to them.
2. You are willing and able to do the work
Great! You've got a good gig, and from the sound of it, it could keep you in peanut butter and iPhones for a long time.
If the code base is a horrid mess--that's their problem, not yours.
If everything takes 2, or 5, or 10 times a long as it "should"--that's their problem, not yours.
If every time you fix a bug, the app breaks in two other places--that's their problem, not yours.
If they ask for schedules, give them your best estimates, based on what you know about the code base.
If they demand to know why everything takes so long, give them your best (diplomatic) explanation of the problems with the app. Speak only in terms of the code as it stands. The history of who wrote it and how it got that way is irrelevant.
If they decide you are incompetent and dismiss you, then you are back to case 1, above.
If they decide to cancel the whole project and terminate your contract, then you are back to case 1, above.
Part of what a company gets when they hire contractors is the ability to dump scut work on them (so that the "well respected" people don't have to do it), and the ability to dismiss them when circumstances change (w/o paying unemployment, etc.) If you're OK with that deal--the work, the scut, being low man on the totem pole, no job security--then give them the best 8 hours of your working day, cash their checks, and sleep soundly. The day you're not OK with it--the day you wake up thinking, "I *just* *can't* do this any more"--that's the day you give notice and move on.