Long ago, I worked for a little company in one state, that bought a big company in another state (don't ask), and the big company had a union shop. At some point they were trying to negotiate something with the union, and they weren't getting what they wanted, so the next week they advertise 300 job openings in the local city paper, like they were going to move the entire shop in-state and just cut the union loose.
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'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.
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.
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.
Along about 3rd grade, most schools offer musical instruction for a semester or a year. The kids come home one day carrying a flute or a trumpet or a drum kit, and they go to band practice once or twice a week and learn to make some noise\b\b\b\b\bmusic.
Some have no interest and no aptitude and drop it pretty quickly. Some have some interest and aptitude and stay with it until they find other interests. Some go on to become musicians.
I'd offer programming instruction on the same basis. But I'd put it off until age 12 to 14 (when the capacity for abstract thought develops).
Most of the code that I see exhibits what I can only describe as a kind of aggressive indifference. It's not just that they don't care. They *totally* don't care. And they're going to make sure you know it. And suffer for it.
After a while, dealing with this stuff is just depressing. Especially if you do care.
You already have your algorithm running in electronic hardware, right? Your current gate count is the sum of
* the gate count of your CPU
* the gate count of your RAM
* the gate count of your program ROM
So that's an upper bound on the gate count. If that number is too big for your manufacturing partner, then you have an optimization problem.
At this point, I think we'd be better off if the NSA's efficacy were reduced to zero (infinitely weaker: 1/x -> 0). Then we could rebuild it from the ground up with proper political, legal, and operational controls.
In fact, I suspect that the NSA retains most--if not all--of its operational capabilities.
The NSA doesn't face any significant legal restrictions. The law allows them to do most of what they want, and they just do the rest anyway, secure in the knowledge that the courts won't(?) can't(?) shut them down.
The NSA does have a political problem right now. It's not much of a political problem: most of the political establishment wants them to keep doing what they are doing. They wouldn't have any political problem at all if their P.R. weren't so inept. Hayden yammering about "defectors" and "treason" and "infinite weakness" is just more P.R.
This tunnel was locally controversial, with opponents arguing that - it was expensive - it wouldn't help with Seattle's traffic problems, AND - these monster boring machines have a track record of getting stuck underground, and then what are you going to do? Call Roto-Rooter?
Counting is an algorithm, like long division or the use of logarithmic tables--in this case an algorithm for assessing the exact numerosity of a set of objects. It consists of reciting a memorized stretch of blank verse ("one, two, three, four, five,...") while uniquely pairing each foot in the poem with an object in the spotlight of attention, without skipping an object or landing on one twice. Then, when no object remains unnoticed, you announce the last foot you arrived at in the poem as the numerosity of the set.
This is just one of many possible algorithms for ascertaining numerosity. In some societies, people pair up the objects with parts of their body, and I know several computer programmers who count like this: "Zero, one, two three, four. There are five."
Slashdot Mirror
Long ago, I worked for a little company in one state, that bought a big company in another state (don't ask), and the big company had a union shop. At some point they were trying to negotiate something with the union, and they weren't getting what they wanted, so the next week they advertise 300 job openings in the local city paper, like they were going to move the entire shop in-state and just cut the union loose.
Nothing ever came of it.
I think for the cost of the shuttle program, you could treat the HST as disposable, and just keep building and launching them until you get it right.
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.
http://world.std.com/~swmcd/st...
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.
Along about 3rd grade, most schools offer musical instruction for a semester or a year.
The kids come home one day carrying a flute or a trumpet or a drum kit,
and they go to band practice once or twice a week and learn to make some noise\b\b\b\b\bmusic.
Some have no interest and no aptitude and drop it pretty quickly.
Some have some interest and aptitude and stay with it until they find other interests.
Some go on to become musicians.
I'd offer programming instruction on the same basis.
But I'd put it off until age 12 to 14 (when the capacity for abstract thought develops).
Most of the code that I see exhibits what I can only describe as a kind of aggressive indifference.
It's not just that they don't care.
They *totally* don't care.
And they're going to make sure you know it.
And suffer for it.
After a while, dealing with this stuff is just depressing.
Especially if you do care.
Or maybe they both stood their ground.
Or something.
And this is what we want, right?
Half the country in the morgue, and the other half in prison, because, because...stand your ground!
Or something...
I knew a guy (Hi, Tom!) who identified the code as coming from the Apple ][ ROMs (which were 6502)
He said he recognized some of the code comments.
You already have your algorithm running in electronic hardware, right?
Your current gate count is the sum of
* the gate count of your CPU
* the gate count of your RAM
* the gate count of your program ROM
So that's an upper bound on the gate count.
If that number is too big for your manufacturing partner,
then you have an optimization problem.
Optimization is a hard problem...
At this point, I think we'd be better off if the NSA's efficacy were reduced to zero (infinitely weaker: 1/x -> 0). Then we could rebuild it from the ground up with proper political, legal, and operational controls.
In fact, I suspect that the NSA retains most--if not all--of its operational capabilities.
The NSA doesn't face any significant legal restrictions. The law allows them to do most of what they want, and they just do the rest anyway, secure in the knowledge that the courts won't(?) can't(?) shut them down.
The NSA does have a political problem right now. It's not much of a political problem: most of the political establishment wants them to keep doing what they are doing. They wouldn't have any political problem at all if their P.R. weren't so inept. Hayden yammering about "defectors" and "treason" and "infinite weakness" is just more P.R.
This tunnel was locally controversial, with opponents arguing that
- it was expensive
- it wouldn't help with Seattle's traffic problems, AND
- these monster boring machines have a track record of getting stuck underground, and then what are you going to do? Call Roto-Rooter?
Sounds like it's starting to come true...
Counting is an algorithm, like long division or the use of logarithmic tables--in this case an algorithm for assessing the exact numerosity of a set of objects. It consists of reciting a memorized stretch of blank verse ("one, two, three, four, five, ...") while uniquely pairing each foot in the poem with an object in the spotlight of attention, without skipping an object or landing on one twice. Then, when no object remains unnoticed, you announce the last foot you arrived at in the poem as the numerosity of the set.
This is just one of many possible algorithms for ascertaining numerosity. In some societies, people pair up the objects with parts of their body, and I know several computer programmers who count like this: "Zero, one, two three, four. There are five."
--Steven Pinker, The Stuff of Thought, p. 141