One of the most critical items here is that the Supreme Court `without comment or dissent' declined to overturn Judge Jacksons findings of fact that MS is a monopoly and acts in anticompetetive ways.
This is important, people!
It means that the last door on this ruling has now closed for good (well, as much as anything closes for good in the legal system). That opens up two critical items.
First, the case that is now before the new judge is no longer contaminated by any doubt about the facts. MS, which might have been taking a delaying tactic in hopes of still getting the facts overturned, has lost that hope. That doesn't mean they won't delay as much as possible, but it does mean that they're now limited. As long as there was a possibility of overturning the findings of facts, they could spin delays to their hearts content. If a settlement was imposed, an injunction would almost certianly have been granted while the findings of fact were still in question. That finding is no longer in legitimate question, so that avenue is gone.
Second, and probably more important in the long term, the solidification of the findings of fact opens the door for damage suits against MS. IMHO it was not a co-incidence that MS settled with DR shortly after the initial finding. But there are many more suits pending, and some of the plaintiffs have no reason to hold back.
The idea is great, but I can see a number of improvements already. In particular, a set of enclosed finger holes in a solid pyramid is not a good idea. It will lead to sweaty smelly fingers. It can't adjust for different folks hand sizes. As a proof of concept on this, go check out bowling balls.
The finger and thumb placements are right, but the selection of pyramid seems merely a convenient choice based on those placements. The mistake is choosing a solid. A better choice would be a multiple grip design, each grip loosely based on an old-fashioned telephone handset. That handset was and is a masterpiece of ergonomic design. Applying it to this keyboard could yield something wonderful.
Instead of using a solid pyramid, mount two roughly handset-shaped grips onto a platform. Put keys under the fingertips, using the same finger arrangement as in the pyramid design. Between the two grips, mount a small thumbs keyboard again containing the central keys from the pyramid.
Now you have a mostly-open design that is much more susceptible to adjustment for a given users hand size, position, and desk placement. No issues with fingers getting sweaty in enclosed places. No issues with getting your fingers into and out of a bunch of holes when you need to grab the mouse. No pyramid edges to be holding your hands against all day -- instead, comfy grips.
By getting away from the solid, you also make it possible to have an adjustable device. The grips should be on some sort of pivot so the user can select the angle of choice in all directions. It should be possible to move the closer and further aparts, and up and down the arm. The center keypad should be adjustable as well. And all those adjustable parts can be obtained `off the shelf'; go by a music store and look at a good microphone stand.
Check your premises, something is wrong
on
Software Aesthetics
·
· Score: 3, Interesting
michael says:
Most software is so bad, in fact, that if it were a bridge, no one in his or her right mind would walk across it. If it were a house, we would be afraid to enter. The only reason we (software engineers) get away with this scam is the general public cannot see inside of software systems. If software design were as visible as a bridge or house, we would be hiding our heads in shame.
I'm sorry, Michael, but I must disagree. This weekend I had two wonderful counterexamples.
We had our house built, in fine detail. That included making decisions about such seeming trivia as the knobs on the closet doors. It was a pain in the ass. But we got a helluva well-built house out of it.
One part of this detailed process was selecting a builder. We knew from wandering thru unfinished houses that there were some real corner-cutters out there. It wasn't that their houses didn't meet code or fell down, but there's the letter of the rule, the spirit of the rule, and (best) is the urge to do it right. Our builder did it right.
But he's the exception, not the rule. Open up the drywall on any house (or better yet, try to install some paneling) and you'll be surprised how much your house is out of true. We all get it, we all live with it.
Even as well-done as ours is, tho, there are still some things that are hard to do. Like the pain we had this weekend running 10-baseT cable and coax to my teenagers rooms. Too damned many solid things in the way. Yeah, we didn't think of it in advance -- and twenty years ago, who did? Is this a design flaw? Nope, even the best of houses has errors.
The other example from this weekend is building a computer for my sister. She doesn't need much; an older system will do the trick. So I went down into the Eschasi's Basement of Dead Computers and started scrounging stuff together.
You know what? The mechanical design on most legacy PCs is light years ahead of their more `advanced' cousins, the workstation. My SS-10 is much harder to work on than the average PC. And let's not think about some of the other old systems out there...DECStation 3100, anyone?
Why are PCs relatively good? Because they're designed to be cheap to assemble, and because economies of scale have helped made components standardized. So you get simple parts that plug together simply. For a counter-example, look at any automobile. It doesn't use standard components, so parts are custom-designed for ease of assembly.
A modern PC, in spite of idiocy like the BIOS and DOS's legacy, is a thing of technical beauty. And so is some of the software we write.
What distinguishes the good from the bad is (as so many have pointed out here) is (a) what you have to work with, and (b) what you're incented to do. With good tools and good standards and an environment where the software lifecycle is understood, good code is written. I do it damned near every day.
And you should all check out the lyrics to
Duane Elms' wonderful song
Threes, Rev. 1.1.
Deep in engineering, down where mortals seldom go,
A manager and customer go looking for a show,
They pass amused among us, and they sign in on the log;
They've come to see our pony and they've come to see our dog.
This was told to me by a Burroughs employee who claimed to have witnessed the middle part.
Back in the olden days, oh my precious, tapes were nothing like they are now. None of the other things in computing were was like they are now, but that's irrelevant.
Burroughs sold an interesting little (well, big) device called a `key to tape' system. It was designed for data entry clerks to do keypunching without actually producing punch cards. Instead, a set of keypunch operators would type away at things that looked like keypunch machines (Eh? Punch cards. We're talking punch cards here.) but the data was actually written (one card image at a time) to a tape.
This was considered a major advance, which will kind of put things into perspective.
There was a central station with a Real CRT (oooooooo) for the master operator. When the tape was full, the operator was prompted to put in the next one. This had to be done fairly quickly, as keypunch operators were cheap and fast, but memory was expensive and tapes were slow.
The system had been optimized and made `user friendly' in the best possible way, and was ready to go. The salesman set up a demo for A Major Customer at the customers site. The demo was extremely well-controlled. Keypunch operators entered pre-assembled data in a controlled way. When the tape filled, up popped the prompt:
Insert next tape, asshole.
The salesman adroitly stepped in front of the machine, blocking the monitor from view, while the master operator inserted next tape. The demo concluded without further incident, and the salesman returned to the plant. . .
Where he went on a rant which can only be imagined. Some skepticism was expressed. To prove the case, the offending machine was set up, the operators were brought in, the same data was entered and written to the same tape, and the prompt came up:
Insert next tape, please.
The salesman was treated with general derision, and people wandered away with another fine story to tell.
Needless to say, this story got around. And not too long after that, a software patch came out. It seems that there was a little joke embedded in the control system. If the number of records on the tape modulo this number times that number equaled some other number, the tape insertion prompt was, well, different. The patch removed this feature.
This left open the question, tho, of why using the exact same data and exact same tape did *not* result in the exact same prompt. It should have, and maybe if they'd used a *new* tape, it would have. You see, back in those days tapes stretched when used. This one stretched enough that the second use got one more record onto the tape.
This is an old story, and one that makes people immediately leap to the wrong conclusions. Executive summary: fibre is the easy, cheap part. You want fibre to your home? Sure, I can do that cheap. But if you want to connect it to something else at fibre speeds, well, that's another story.
I live in a small town in Michigan (Dexter, 12 scenic miles from Hell). We have a major Sprint node in town. A civic group of local civic technologists would love to tap into that, getting our tiny town some huge bandwidth. We love living here, and would like to see the internet connectivity being fast and cheap enough to attract Internet-based businesses.
But we can't currently generate enough $$$ to make it worthwhile. What Sprint has in place is basicly an optical repeater. To expand it into data service, they'd have to install an OC-XX router, where XX is probably greater than 12.
Ever priced an OC-12 router? Or facilities to support it remotely? The DS-3 cards and T1 cards to step down those speeds? The lines from your home or office to that router? The maintenance agreement on all that equipment?
But everyone would use it if it were available you say? Show me. Figure out that cost, go talk to your neighbors. See what you can get the cost per connection down to. We went thru that exercise for getting gas lines installed out here. Even with a three year payback, people weren't interested in anything over about $1000 one time cost. I'd be shocked if your neighborhood was willing to go $1000/ea plus $100/mo for ethernet to every home.
As an example proof of fibre being the easy part, I believe that WilTel some years ago sold their entire fibre infrastructure to some other company for quite a nice price. They retained one (count it) one strand in each bundle. That's been enough to handle all their traffic. It was brilliant, just frigging brilliant. Now someone else has to pay all their fibre infrastructure costs, and they just get one card in someone elses equipment.
I made this same search a few months back; wound up buying some Panasonic `Panaflo' 80mm fans, model L1A. They're at least an order of magnitude quieter than the ones that came with my case but move about 1/3 less air. I fixed that by removing two and installing three.:-)
There's a lot of interesting stuff out there that people have done or things you can buy; here's a
set of bookmarks I assembled a few months back:
The original article was something you don't see too often -- a slanted
article that nonetheless included a lot facts that counter it. You can
use those facts to make a better `apples-to-apples' comparison of the
two technologies.
The slant (IMHO) was pro-diesel and how the US was potentially missing
out on a big energy-saving technology. Fair enough, we need to look
at anything that might work. But . . . here are some of the countering
facts which the article was good enough to include:
Diesel fuel is cheaper in Europe due to different taxing strategies.
In the US it's not nearly as pronounced. In the US in wintertime, when
diesel refining is competing with home fuel oil refining, the price of
diesel rises to about the price of gasoline -- in spite of the slight
tax advantage. Increase diesel usage to the about 50% of the market,
and watch the price rise even further.
US diesel fuel and European diesel fuel are two different beasts.
The Euro fuel is `much dirtier', including much more sulphur.
Further refinement will absolutely be required, and probably purchase
of low-sulphur (and therefore more expensive) crude.
Take those two together, and the actual cost of diesel will almost surely
be higher than gasoline.
Another point is soot emissions. Soot emissions from diesels have
improved, but are still not anywhere near what US standards are. Let's
leave aside for a moment whether or not those standards are rational (and
just so you know my prejudices, I think they are rational). The article
states ``Albrecht Schmidt, a top expert on energy issues for Germany's
Green Party [said] "The big problem with diesel is the small particulates,
but we think that problem can be solved with new particulate filters."''
That's an encouraging statement, but it also plainly says ``the problem
isn't solved yet.'' In other words, like a lot of other technologies this
looks good but still can't meet all the requirements we current have of
gasoline IC engines.
The article makes a somewhat misleading point about European vs US fuel
economy, saying ``the average new car [in Germany] has improved its fuel
efficiency steadily since 1990 and now gets about 32 miles a gallon. The
average diesel car gets about 40 miles a gallon. By contrast, the average
efficiency of new vehicles in the United States has deteriorated steadily
over the period as ever more sport utility vehicles have been sold,
and was just 24.5 miles a gallon last year.'' That's certainly true, but
it's not apples and apples. SUVs and trucks aren't considered cars for
the purpose of mileage calculations in the US, and are permitted far worse
mileage. If you only look at US cars, MPG has been pretty much flat the
last few years.
SUVs/trucks need to be pulled under the same rules as everything else.
Trucks were originally exempted for the same reasons diesels and diesel
fuel were -- a desire not to drive up the cost of commerce (or to cater
to a rich and influential business lobby, if you prefer). The end result
was that consumers reacted by buying the cheaper vehicle that got poorer
mileage. That almost inexorably led to the SUV explosion we see today.
Want to change this? Easy. Put SUVs and trucks under the same mileage
rules as cars. In five years, you'd probably see a 25% or move
improvement in MPG of the average US `car'.
Don't want to hurt the small farmer? OK, keep the gas mileage rules on
*real* pickups the same (ie, put vans and SUVs under `car' rules), but
require them to have commercial plates and pay commercial taxes.
My point here is not that diesel is bad or that we couldn't get some
improvements from using it.
It's that the article oversells it, and many of the selling
grounds have more to do with tax and regulatory policy than
quality of technology.
It's perfectly clear that nothing is clear here. I Am Not A Lawyer, but here's something I'm pretty sure of for copyright law:
For you to claim copyright on a work which would otherwise be a work for hire or otherwise encumbered, you need a formal release of same from the appropriate authority. So the following questions are unanswered:
Would the work have been a work for hire or was it done under conditions where you would not normally be the copyright holder?
Did you receive a formal assignment of copyright?
Did the releasor have the authority to do that release?
Was the assignment of copyright for the entire work?
Or were you allowed to take a copy and
release it under GPL, while the original holder retained
rights to the non-GPL original?
And there are more I've probably not thought of.
All of these questions interact. You may have everything stated clearly
in writing from your supervisors, but if they weren't authorized to
release the copyright then you're on shakey ground.
The short answer is that if they want to pull the GPL, you need to get a real lawyer who can tell you if your receipt of copyright was valid and to what degree. Folks here can say all they want, but none of us is a lawyer and none have seen the detailed needed to make a determination.
C on the PDP-10 is a *bitch*
on
PDP-10 Revival
·
· Score: 5
I have fond memories of the PDP-10, a machine on which I did far too much assembler hacking. Not to mention editing in TECO, debugging with DDT (dynamic debugging tool), and playing Adventure over a 300-baud line on a DECWriter (a paper trail was worth its weight in gold for that game.) A year of programming in BLISS-10 was great preparation for my first exposure to C.
We (ADP Network Services) had a C compiler for it back in late '82 or early '83. We'd started doing some UNIX work on 8086s, liked it and C, and management wanted to know if we could back-port some of our C stuff to TOPS-10. BLISS-10 seemed kind of an existence proof that C was possible for PDP-10s. So fella named Don Wakelin ported one from (I think) a Harris mini. We picked that one because the Harris had 18-bit words and the PDP-10 had 36.
36 bit words, 18-bit word addresses, and bit-addressable memory made for a rather, er, idiosyncratic C compiler. We chose to use 7bit characters (a stock PDP-10 type), which meant each word had one bit left over. If you think the assumption that (sizeof)* == (sizeof)int broke a lot of programs, you should *see* what happens when characters weren't 8 bits and were immutably unsigned. For the record, most ASCII data on PDP-10s was stored as 7bit characters packed five per 36-bit word with one bit left over.
The only reason that worked well (and yes, it worked quite well) was because memory on the 10 was bit-addressable. It had these peculiar things called `byte pointers'. An 18-bit word address was stuck into a 36-bit word. The other 18 bits indicated the number of bits offset into the word, and the number of bits to be obtained on a fetch. Good byte pointer users could fetch 1 bit, then the next 5, then 3, etc, etc. Brought a whole new level of complexity to incrementing your pointers. Most folks just used them for characters, tho, setting fetch size to 7. Machine-level instructions did the heavy lifting on pointer incrementing - take code like
char *i = "abcefg"; char c; c = *i++;
The first line caused a byte pointer to be created with the address of the word containing the start of the string. The offset was 0, the fetch size was 7. The last line was done with just two assembler instructions. One fetched 7 bits from the address pointed to into a register and incremented the offset portion of the byte pointer by seven bits; the second just stored the register contents into the variable c. After you fetch the fifth character using i, the auto-increment instruction added 1 to the 18-bit address and reset the offset to 0.
Address zero was addressable -- it happened to be register zero. In fact, all the registers were addressable as 0-15. But when the null pointer successfully loaded and stored data, programs did a whole 'nuther set of interesting things.
Another fellow at ADP successfully headed a project to port University Ingres to TOPS-10. He told the most amazing horror stories for years afterwards...
And will the true story ever be told of PDP-10 follow-on machine, the Jupiter? It was supposed to be a truly huge (for the day) PDP-10, intended to compete with the IBM System 370. It was constantly started and cancelled and started and cancelled. We (ADP) finally concluded that it was just a feint so we wouldn't switch to some other hardware before DEC got the equally-late Venus project done. When Venus finally did ship, DEC called it the VAX. At an East Coast SF convention in the late '80s I bumped into someone wearing a faded `36 bits forever' t-shirt. When I asked what happened to the 10 projects, she refused to answer
and looked *really* pissed.
There have been a number of PDP-10 clones built over the years, at least two companies are still making them. One of them is the company sponsoring the port; big surprise, eh? The target customers are folks who wants to run TENEX (UNIX-alike for PDP-10s) or ITS (Incompatible Timesharing System), MIT LISP refugees, and hardcore TOPS-10/TOPS-20 sites, maybe including ADP.
There's a subtext to your question which isn't said explicitly. Here it is:
Once these people are trained to the point they're worth three times what they are currently paid, how can we retain them without having to pay them three times what they are currently paid.
And the answer is, You can't.
I've seen this situation come up for 20 years, and I expect it'll be happening 20 years from now. If your employees are worth $50K/yr and you're paying them $40K, you're going to lose them - and that's only a 20% difference. Three to one? No way you hold onto those folks. Period, end of discussion.
That's not to say that you can get close. A good place to work is often worth 10% of salary. To me, with a nice nest egg and retirement 10 years away, it's even more than 10%. But you can't pay people $20K when they're worth $60K. It just doesn't fly.
So as to your managements quandry -- yeah, they're in a hole. If the market they're in demands workers who are worth $60K/yr and they're paying 20, they're out of business.
Attempting to put restrictions on what an employee can do after being trained is, at best, a delaying tactic. There's a limit on how restrictive those clauses can be (I am not a lawyer, yadda yadda), and requiring the training be paid back only helps until you find the next job and can afford to pay it back.
If you have correctly represented the situtation, this company has to change its business model either by increasing employee pay or searching for a service they can offer which doesn't require such skilled employees.
Mike was also a regular at the early LISA conferences. I recall him lamenting that RAID stood for `Redundant Array of Inexpensive Disks' because BRL needed incredible capacity. He asked for `Redundant Arrays of Expensive Disks' (which at the time were the 380MB Fujitsu Eagles), and commented that `RAED' sounded kind of like `RAID' said with a bad southern US accent.
He published quite a bit of code that went into good use around the world, tho ping is undoubtably the most long-lived.
He'll be missed. Here's to you, Mike, wherever you are. May your roundtrips be low, your bandwidth high, and your storage farm at 100% uptime.
Lawsy lawsy, this is 80% of what we need, maybe 90%. I've got cases and P/S and old PCI boards coming out my ass. They'd make perfect passive backplanes for banks of dedicated Linux processors that I could leave up 100% of the time without worrying about the rest of the system going belly-up. Load 'em via DHCP as needed. Let 'em nfs-mount a server if needed. Jerk out one of those enet ports and put in a USB, a serial, and a phone jack (you can fit all four in a single PCI end). Better yet, you can make a DSP-controlled soft-switchable RJ-45 jack that could be used as enet, serial, phone, etc. You could make X10 controllers, high-quality telephone answering machines, and yes, even a firewall, all off of a single hardware design (which means big volume which means cheap). Excuse me, I gotta go drop a bug in these guys' ear.....
This smacks of the proofs that bumblebees can't fly. What nonsense.
There's a huge assumption up front -- that dino necks and their anatomy
were effectively identical to modern creatures. We already know that
this isn't true c. f. the secondary `brains' that the brontos had in
their hindquarters. It's quite possible that the necks had secondary
pumping mechanisms. I'm not saying they did, I'm saying it's possible -
and probably can't be determined without soft tissue analysis.
On a separate front, this proposal leaves us with the question of just
what those necks were for. Yeah, I can see it now, herds of brontos
scurrying across the plains with their heads 60 feet ahead of the bodies
and 6 feet off the ground...yeah, right.
Slashdot Mirror
This is important, people!
It means that the last door on this ruling has now closed for good (well, as much as anything closes for good in the legal system). That opens up two critical items.
First, the case that is now before the new judge is no longer contaminated by any doubt about the facts. MS, which might have been taking a delaying tactic in hopes of still getting the facts overturned, has lost that hope. That doesn't mean they won't delay as much as possible, but it does mean that they're now limited. As long as there was a possibility of overturning the findings of facts, they could spin delays to their hearts content. If a settlement was imposed, an injunction would almost certianly have been granted while the findings of fact were still in question. That finding is no longer in legitimate question, so that avenue is gone.
Second, and probably more important in the long term, the solidification of the findings of fact opens the door for damage suits against MS. IMHO it was not a co-incidence that MS settled with DR shortly after the initial finding. But there are many more suits pending, and some of the plaintiffs have no reason to hold back.
The finger and thumb placements are right, but the selection of pyramid seems merely a convenient choice based on those placements. The mistake is choosing a solid. A better choice would be a multiple grip design, each grip loosely based on an old-fashioned telephone handset. That handset was and is a masterpiece of ergonomic design. Applying it to this keyboard could yield something wonderful.
Instead of using a solid pyramid, mount two roughly handset-shaped grips onto a platform. Put keys under the fingertips, using the same finger arrangement as in the pyramid design. Between the two grips, mount a small thumbs keyboard again containing the central keys from the pyramid.
Now you have a mostly-open design that is much more susceptible to adjustment for a given users hand size, position, and desk placement. No issues with fingers getting sweaty in enclosed places. No issues with getting your fingers into and out of a bunch of holes when you need to grab the mouse. No pyramid edges to be holding your hands against all day -- instead, comfy grips.
By getting away from the solid, you also make it possible to have an adjustable device. The grips should be on some sort of pivot so the user can select the angle of choice in all directions. It should be possible to move the closer and further aparts, and up and down the arm. The center keypad should be adjustable as well. And all those adjustable parts can be obtained `off the shelf'; go by a music store and look at a good microphone stand.
Most software is so bad, in fact, that if it were a bridge, no one in his or her right mind would walk across it. If it were a house, we would be afraid to enter. The only reason we (software engineers) get away with this scam is the general public cannot see inside of software systems. If software design were as visible as a bridge or house, we would be hiding our heads in shame.
I'm sorry, Michael, but I must disagree. This weekend I had two wonderful counterexamples.
We had our house built, in fine detail. That included making decisions about such seeming trivia as the knobs on the closet doors. It was a pain in the ass. But we got a helluva well-built house out of it.
One part of this detailed process was selecting a builder. We knew from wandering thru unfinished houses that there were some real corner-cutters out there. It wasn't that their houses didn't meet code or fell down, but there's the letter of the rule, the spirit of the rule, and (best) is the urge to do it right. Our builder did it right.
But he's the exception, not the rule. Open up the drywall on any house (or better yet, try to install some paneling) and you'll be surprised how much your house is out of true. We all get it, we all live with it.
Even as well-done as ours is, tho, there are still some things that are hard to do. Like the pain we had this weekend running 10-baseT cable and coax to my teenagers rooms. Too damned many solid things in the way. Yeah, we didn't think of it in advance -- and twenty years ago, who did? Is this a design flaw? Nope, even the best of houses has errors.
The other example from this weekend is building a computer for my sister. She doesn't need much; an older system will do the trick. So I went down into the Eschasi's Basement of Dead Computers and started scrounging stuff together.
You know what? The mechanical design on most legacy PCs is light years ahead of their more `advanced' cousins, the workstation. My SS-10 is much harder to work on than the average PC. And let's not think about some of the other old systems out there...DECStation 3100, anyone?
Why are PCs relatively good? Because they're designed to be cheap to assemble, and because economies of scale have helped made components standardized. So you get simple parts that plug together simply. For a counter-example, look at any automobile. It doesn't use standard components, so parts are custom-designed for ease of assembly.
A modern PC, in spite of idiocy like the BIOS and DOS's legacy, is a thing of technical beauty. And so is some of the software we write.
What distinguishes the good from the bad is (as so many have pointed out here) is (a) what you have to work with, and (b) what you're incented to do. With good tools and good standards and an environment where the software lifecycle is understood, good code is written. I do it damned near every day.
Deep in engineering, down where mortals seldom go,
A manager and customer go looking for a show,
They pass amused among us, and they sign in on the log;
They've come to see our pony and they've come to see our dog.
Not on record anywhere as far as I know.
This was told to me by a Burroughs employee who claimed to have witnessed the middle part.
Back in the olden days, oh my precious, tapes were nothing like they are now. None of the other things in computing were was like they are now, but that's irrelevant.
Burroughs sold an interesting little (well, big) device called a `key to tape' system. It was designed for data entry clerks to do keypunching without actually producing punch cards. Instead, a set of keypunch operators would type away at things that looked like keypunch machines (Eh? Punch cards. We're talking punch cards here.) but the data was actually written (one card image at a time) to a tape.
This was considered a major advance, which will kind of put things into perspective.
There was a central station with a Real CRT (oooooooo) for the master operator. When the tape was full, the operator was prompted to put in the next one. This had to be done fairly quickly, as keypunch operators were cheap and fast, but memory was expensive and tapes were slow.
The system had been optimized and made `user friendly' in the best possible way, and was ready to go. The salesman set up a demo for A Major Customer at the customers site. The demo was extremely well-controlled. Keypunch operators entered pre-assembled data in a controlled way. When the tape filled, up popped the prompt:
Insert next tape, asshole.
The salesman adroitly stepped in front of the machine, blocking the monitor from view, while the master operator inserted next tape. The demo concluded without further incident, and the salesman returned to the plant. . .
Where he went on a rant which can only be imagined. Some skepticism was expressed. To prove the case, the offending machine was set up, the operators were brought in, the same data was entered and written to the same tape, and the prompt came up:
Insert next tape, please.
The salesman was treated with general derision, and people wandered away with another fine story to tell.
Needless to say, this story got around. And not too long after that, a software patch came out. It seems that there was a little joke embedded in the control system. If the number of records on the tape modulo this number times that number equaled some other number, the tape insertion prompt was, well, different. The patch removed this feature.
This left open the question, tho, of why using the exact same data and exact same tape did *not* result in the exact same prompt. It should have, and maybe if they'd used a *new* tape, it would have. You see, back in those days tapes stretched when used. This one stretched enough that the second use got one more record onto the tape.
I live in a small town in Michigan (Dexter, 12 scenic miles from Hell). We have a major Sprint node in town. A civic group of local civic technologists would love to tap into that, getting our tiny town some huge bandwidth. We love living here, and would like to see the internet connectivity being fast and cheap enough to attract Internet-based businesses.
But we can't currently generate enough $$$ to make it worthwhile. What Sprint has in place is basicly an optical repeater. To expand it into data service, they'd have to install an OC-XX router, where XX is probably greater than 12.
Ever priced an OC-12 router? Or facilities to support it remotely? The DS-3 cards and T1 cards to step down those speeds? The lines from your home or office to that router? The maintenance agreement on all that equipment?
But everyone would use it if it were available you say? Show me. Figure out that cost, go talk to your neighbors. See what you can get the cost per connection down to. We went thru that exercise for getting gas lines installed out here. Even with a three year payback, people weren't interested in anything over about $1000 one time cost. I'd be shocked if your neighborhood was willing to go $1000/ea plus $100/mo for ethernet to every home.
As an example proof of fibre being the easy part, I believe that WilTel some years ago sold their entire fibre infrastructure to some other company for quite a nice price. They retained one (count it) one strand in each bundle. That's been enough to handle all their traffic. It was brilliant, just frigging brilliant. Now someone else has to pay all their fibre infrastructure costs, and they just get one card in someone elses equipment.
There's a lot of interesting stuff out there that people have done or things you can buy; here's a set of bookmarks I assembled a few months back:
http://blacktree.homepage.com/basement/pstweak.ht
http://blacktree.homepage.com/basement/blackbox.h
http://www.3dfxcool.com/
http://www.coolermaster.com/products/systemcase.h
http://www.coolerguys.com/
http://www.coolerxtreme.com/
Just recently I stumbled across this one, which has real numbers on cooling but only subjective on noise: http://www.tweakmax.com/html/fs020_2/fs020_2-1.cfm
The slant (IMHO) was pro-diesel and how the US was potentially missing out on a big energy-saving technology. Fair enough, we need to look at anything that might work. But . . . here are some of the countering facts which the article was good enough to include:
Diesel fuel is cheaper in Europe due to different taxing strategies. In the US it's not nearly as pronounced. In the US in wintertime, when diesel refining is competing with home fuel oil refining, the price of diesel rises to about the price of gasoline -- in spite of the slight tax advantage. Increase diesel usage to the about 50% of the market, and watch the price rise even further.
US diesel fuel and European diesel fuel are two different beasts. The Euro fuel is `much dirtier', including much more sulphur. Further refinement will absolutely be required, and probably purchase of low-sulphur (and therefore more expensive) crude.
Take those two together, and the actual cost of diesel will almost surely be higher than gasoline.
Another point is soot emissions. Soot emissions from diesels have improved, but are still not anywhere near what US standards are. Let's leave aside for a moment whether or not those standards are rational (and just so you know my prejudices, I think they are rational). The article states ``Albrecht Schmidt, a top expert on energy issues for Germany's Green Party [said] "The big problem with diesel is the small particulates, but we think that problem can be solved with new particulate filters."''
That's an encouraging statement, but it also plainly says ``the problem isn't solved yet.'' In other words, like a lot of other technologies this looks good but still can't meet all the requirements we current have of gasoline IC engines.
The article makes a somewhat misleading point about European vs US fuel economy, saying ``the average new car [in Germany] has improved its fuel efficiency steadily since 1990 and now gets about 32 miles a gallon. The average diesel car gets about 40 miles a gallon. By contrast, the average efficiency of new vehicles in the United States has deteriorated steadily over the period as ever more sport utility vehicles have been sold, and was just 24.5 miles a gallon last year.'' That's certainly true, but it's not apples and apples. SUVs and trucks aren't considered cars for the purpose of mileage calculations in the US, and are permitted far worse mileage. If you only look at US cars, MPG has been pretty much flat the last few years.
SUVs/trucks need to be pulled under the same rules as everything else. Trucks were originally exempted for the same reasons diesels and diesel fuel were -- a desire not to drive up the cost of commerce (or to cater to a rich and influential business lobby, if you prefer). The end result was that consumers reacted by buying the cheaper vehicle that got poorer mileage. That almost inexorably led to the SUV explosion we see today.
Want to change this? Easy. Put SUVs and trucks under the same mileage rules as cars. In five years, you'd probably see a 25% or move improvement in MPG of the average US `car'.
Don't want to hurt the small farmer? OK, keep the gas mileage rules on *real* pickups the same (ie, put vans and SUVs under `car' rules), but require them to have commercial plates and pay commercial taxes.
My point here is not that diesel is bad or that we couldn't get some improvements from using it. It's that the article oversells it, and many of the selling grounds have more to do with tax and regulatory policy than quality of technology.
For you to claim copyright on a work which would otherwise be a work for hire or otherwise encumbered, you need a formal release of same from the appropriate authority. So the following questions are unanswered:
And there are more I've probably not thought of.
All of these questions interact. You may have everything stated clearly in writing from your supervisors, but if they weren't authorized to release the copyright then you're on shakey ground.
The short answer is that if they want to pull the GPL, you need to get a real lawyer who can tell you if your receipt of copyright was valid and to what degree. Folks here can say all they want, but none of us is a lawyer and none have seen the detailed needed to make a determination.
We (ADP Network Services) had a C compiler for it back in late '82 or early '83. We'd started doing some UNIX work on 8086s, liked it and C, and management wanted to know if we could back-port some of our C stuff to TOPS-10. BLISS-10 seemed kind of an existence proof that C was possible for PDP-10s. So fella named Don Wakelin ported one from (I think) a Harris mini. We picked that one because the Harris had 18-bit words and the PDP-10 had 36.
36 bit words, 18-bit word addresses, and bit-addressable memory made for a rather, er, idiosyncratic C compiler. We chose to use 7bit characters (a stock PDP-10 type), which meant each word had one bit left over. If you think the assumption that (sizeof)* == (sizeof)int broke a lot of programs, you should *see* what happens when characters weren't 8 bits and were immutably unsigned. For the record, most ASCII data on PDP-10s was stored as 7bit characters packed five per 36-bit word with one bit left over.
The only reason that worked well (and yes, it worked quite well) was because memory on the 10 was bit-addressable. It had these peculiar things called `byte pointers'. An 18-bit word address was stuck into a 36-bit word. The other 18 bits indicated the number of bits offset into the word, and the number of bits to be obtained on a fetch. Good byte pointer users could fetch 1 bit, then the next 5, then 3, etc, etc. Brought a whole new level of complexity to incrementing your pointers. Most folks just used them for characters, tho, setting fetch size to 7. Machine-level instructions did the heavy lifting on pointer incrementing - take code like
char *i = "abcefg" ;
;
char c;
c = *i++
The first line caused a byte pointer to be created with the address of the word containing the start of the string. The offset was 0, the fetch size was 7. The last line was done with just two assembler instructions. One fetched 7 bits from the address pointed to into a register and incremented the offset portion of the byte pointer by seven bits; the second just stored the register contents into the variable c. After you fetch the fifth character using i, the auto-increment instruction added 1 to the 18-bit address and reset the offset to 0.
Address zero was addressable -- it happened to be register zero. In fact, all the registers were addressable as 0-15. But when the null pointer successfully loaded and stored data, programs did a whole 'nuther set of interesting things.
Another fellow at ADP successfully headed a project to port University Ingres to TOPS-10. He told the most amazing horror stories for years afterwards...
And will the true story ever be told of PDP-10 follow-on machine, the Jupiter? It was supposed to be a truly huge (for the day) PDP-10, intended to compete with the IBM System 370. It was constantly started and cancelled and started and cancelled. We (ADP) finally concluded that it was just a feint so we wouldn't switch to some other hardware before DEC got the equally-late Venus project done. When Venus finally did ship, DEC called it the VAX. At an East Coast SF convention in the late '80s I bumped into someone wearing a faded `36 bits forever' t-shirt. When I asked what happened to the 10 projects, she refused to answer and looked *really* pissed.
There have been a number of PDP-10 clones built over the years, at least two companies are still making them. One of them is the company sponsoring the port; big surprise, eh? The target customers are folks who wants to run TENEX (UNIX-alike for PDP-10s) or ITS (Incompatible Timesharing System), MIT LISP refugees, and hardcore TOPS-10/TOPS-20 sites, maybe including ADP.
Once these people are trained to the point they're worth three times what they are currently paid, how can we retain them without having to pay them three times what they are currently paid.
And the answer is, You can't.
I've seen this situation come up for 20 years, and I expect it'll be happening 20 years from now. If your employees are worth $50K/yr and you're paying them $40K, you're going to lose them - and that's only a 20% difference. Three to one? No way you hold onto those folks. Period, end of discussion.
That's not to say that you can get close. A good place to work is often worth 10% of salary. To me, with a nice nest egg and retirement 10 years away, it's even more than 10%. But you can't pay people $20K when they're worth $60K. It just doesn't fly.
So as to your managements quandry -- yeah, they're in a hole. If the market they're in demands workers who are worth $60K/yr and they're paying 20, they're out of business.
Attempting to put restrictions on what an employee can do after being trained is, at best, a delaying tactic. There's a limit on how restrictive those clauses can be (I am not a lawyer, yadda yadda), and requiring the training be paid back only helps until you find the next job and can afford to pay it back.
If you have correctly represented the situtation, this company has to change its business model either by increasing employee pay or searching for a service they can offer which doesn't require such skilled employees.
He published quite a bit of code that went into good use around the world, tho ping is undoubtably the most long-lived.
He'll be missed. Here's to you, Mike, wherever you are. May your roundtrips be low, your bandwidth high, and your storage farm at 100% uptime.
Lawsy lawsy, this is 80% of what we need, maybe 90%. I've got cases and P/S and old PCI boards coming out my ass. They'd make perfect passive backplanes for banks of dedicated Linux processors that I could leave up 100% of the time without worrying about the rest of the system going belly-up. Load 'em via DHCP as needed. Let 'em nfs-mount a server if needed. Jerk out one of those enet ports and put in a USB, a serial, and a phone jack (you can fit all four in a single PCI end). Better yet, you can make a DSP-controlled soft-switchable RJ-45 jack that could be used as enet, serial, phone, etc. You could make X10 controllers, high-quality telephone answering machines, and yes, even a firewall, all off of a single hardware design (which means big volume which means cheap). Excuse me, I gotta go drop a bug in these guys' ear.....
This smacks of the proofs that bumblebees can't fly. What nonsense. There's a huge assumption up front -- that dino necks and their anatomy were effectively identical to modern creatures. We already know that this isn't true c. f. the secondary `brains' that the brontos had in their hindquarters. It's quite possible that the necks had secondary pumping mechanisms. I'm not saying they did, I'm saying it's possible - and probably can't be determined without soft tissue analysis. On a separate front, this proposal leaves us with the question of just what those necks were for. Yeah, I can see it now, herds of brontos scurrying across the plains with their heads 60 feet ahead of the bodies and 6 feet off the ground...yeah, right.