I've posted about MySQL's problems before; they could get about a 15% performance improvement on Linux and a huge performance improvement on MacOS X just by pipelining their requests. This would require a library change (2/3s of the improvement) and a change to the way requests are dequeued on the server (about 1/3).
The R problem is 50% him not passing "-O2 -fstrict-aliasing" to the compiler, and 50% him using the system malloc instead of dlmalloc like it says to use in the R admin manual.
I have to agree with the parent poster on this one; I wouldn't have said things quite that way, but then the guy who did the R "benchmark" was pretty inflamatory in his comments, too.
In 1991, the Honda CRX HF was introduced with an EPA estimated 49/52 MPG.
Like most competition, the U.S. auto manufactures lobbied for the introduction of a lot of new destructive safety tests that their cars were known to already be capable of surviving, but the CRX HF was not. They actually had to go out an buy a bunch of them themselves to take them apart to see what sheer stresses they could apply that the HF would not survive.
And so, like the Yugo before it (which didn't have good gas mileage, but was kicking their teeth in on price), they saved The American Way Of Life by keeping the foreign competition out of their markets.
I have no doubt the SMART will suffer similarly, if the Santa Clara people who have the exclusive $10M import deal fail to mark it up sufficiently to drive people away from buying them instead of American cars.
"Case sensitivity is the single greatest user interface botch in Unix"
The greatest UI botch in UNIX is actually not doing it's regex expansion below the user/kernel boundary. It means that you can't do interesting things, like only copying back the directory data that matches your regex across the expensive protection domain crossing of the U/K boundary. It also means that you can't do *very* interesting things, like real versioning support at the FS layer (unless the name you're looking up is considered a regex, you can't default the version suffix in the name space, like VMS did).
The second greatest UI botch was puting the processes environment in user space, and exposing a "char **environ" variable into the process name space, so it was impossible to move the implementation into the kernel proper, and deal with environmental inheritance, like the historical process, group, and system logical name tables. Without this, it is practically impossible to provide reasonable support for things like variant symbolic links.
The third greatest UI botch was vowel compression in command names to fit them into the 14 character file name limit.
The fourth greatest UI botch was not having a regular command line argument syntax for all commands.
I could continue on the whole top-20 list, but I won't.
Case sensitivity, on the other hand, is what makes 7 bit NRCS-based internationalization, UTF-8, and other arbitrary character set encodings work so well. Windows has to carry around encoding tables for its encoding tables to deal with it's 16 bit Unicode characters vs. the current code page, in order to represent a locale, and it's limited to the early Unicode specifications because it doesn't support the full 32 bit wchar_t type.
UNIX made a lot of early mistakes, which, as engineers, we've stupidly carried forward with us instead of correcting, but initial case sensitivity for file names wasn't among them.
BlueTooth syncing via drag-and-drop only works if OBEX - OBject EXchange - has not been specifically disabled, which it is on Verizon phones. This is because file exchange requires mode 22 on the phone, which by default likes to talk in mode 0 or mode 2, and take AT commands.
For phones which are composite devices (which is pretty much all of them), it also requires that the drivers recognize a change of actual device ID (USB or otherwise, if you do not use USB interconnect), which is not always practical (e.g. when supporting OBEX over USB, you usually have to write the OBEX code yourself, as it's not considered a line discipline or streams layer that's stackable on top of USB).
The drag-and-drop has an additional limitation, in that on a number of phones, you have to delete the index of files and let the phone rebuild it. If you don't do this, then you can't access the new files on the phone directly, since they won't show in the menus. Effectively, it means there's an implicit data interface, which is undocumented by the phone vendors, for communicating data changes to the phone.
That basically means you must inflict intentional "damage", and then depend on your phone's error recovery mechanisms to rebuild the index for you. This generally works, although there are known problems with some phones with some revisions of firmware from various vendors.
The bottom line is that mobile phone synching and integration is currently about as advanced as mobile phone UI itself, which is to say, not very.
It depends on your carrier, and the software sucks...
Verizon will lock you out of your phone; if you go online and try to grab a copy of Motorolla Phone tools (yes, I know this is a Windows application suite), they specifically note that they have disabled thing, like the ability to download background images and ring tones, at the request of Verizon.
For other carriers, whether you can sync with Linux is a function of which SourceForge package you download, and how long your phone has been out. The best ones seem to be for Nokia phones (Nokia is popular in Europe, despite the exploding battery issue) and because the E.U. has a law permitting reverse engineering for the purposes of interoperability, a lot of phone hacking happens there.
For MacOS X, iSync will handle your address book and data connection. If you want the camera portion of your phone to show up in iPhoto, it's not going to happen. If you want the background picture to show up there, too, and be downloadable to the phone, that's also not there. If you want to take an iTunes song and use it as a ring tone, that's also not there.
To be fair, this takes extra software on both the Mac and the PC - not just the Mac - and, again, your carrier can lock you out of it, if they choose to do so.
For third party applications for doing the transfers, you're normally talking about needing a WAP enabled phone, and your computer uploads the content to a web site, and then you pay text and data transfer charges to get the URL, then the content itself, down to your phone, unless you get software designed to talk to the phone over USB (also needs a data cable, anmd extra expsense - at least Motorola uses standard 5 pin minim USB 'A'/'B' cables for many of its phones).
I've personally purchased an application that is considered the best out there for image and ring tone transfers (it's basically a piece of crap, so I won't name names, but it runs on both Mac and PC, and it's considered the best of the lot, for both platforms); it wasn't useful for ring tones or image cut down until I downloaded 3 or 4 other packages from freeware/open source sites, and even then, editing was somewhat hinky.
The bottom line is that the phone companies (or should I say "phone company", now that AT&T has reassembled itself like a Terminator II) control the code on your phone, and as long as they do, they own what you can and can't do with the phone. And if next Tuesday, that means not syncing with Linux or MacOS X, then that's what it means.
``And in what universe is anyone who can intelligently speak about (much less code around) memory and VM management [be called] an "incompetent idiot"?''
To put things in perspective, the EEOC itself is moving to online claims filing.
As far as Kroger's is concerned, there is an online version of the form, which you should be able to get at, if you are able to post on Slashdot.
In the online form, it clearly states:
Foods Co will provide reasonable accommodation as necessary in the application process upon request consistent with applicable law.
By proceeding you are indicating that you have carefully read and understand the preceding statement.
indicating that they will accomodate you if you are legitimately disabled; illiteracy is not a disability. Although there are disabilities which can interfere with someone becoming literate, there is generally no disability that would prevent it completely (look at Helen Keller - both deaf and blind, but a successful author).
So even if you have a case, it's not a case until they fail to accomodate you within applicable law.
Your argument seems to come down to "kiosks suck, and this should be an EEOC violation, which is a false assertion of entitlement on your part.
-- Terry
Even well written code can have problems
on
Porting to 64-bit Linux
·
· Score: 2, Insightful
Even well written code can have problems.
Specifically, say I have a 64 bit platform capable of running both LP64 code and ILP32 (legacy) code.
I use a shared memory segment to communicate between my legacy 32 bit applications, and it has internal use of pointers to perform self-reference on data.
[Rather than complicating things, let's just assume that the pointers are internally based off the base address of the shared memory segment, rather than being based off of 0, so there is no requirement of mapping the memory into the same location in each process]
I'm now adding a 64 bit computation engine (perhaps my application is a rendering system that uses plug-ins, and being able to work on large data sets with the large address space afforded to 64 bit processes is critical, but when it comes to displaying the results, I can live easily in a 32 bit address space, so I'm not trying to port my whole tool over to 64 bits).
So now I have to deal with the internal pointers in the shared memory segment. I can do one of several things:
(1) I can use structure coercion to treat the pointers as if they were integer offsets instead, and coerce them into pointers internally in the 64 bit code (on LP64, pointers are 64 bit).
(2) I can intenrally store 64 bit pointers, rather than 32 bit pointers. This means I need the same round-tripping, but it can take place in the 32 bit applications, rather than the 64 bit applications, and the Integer representation is as "long long" as far as its concerned.
(3) I can support either a "short void *" in 64 bit applications, or a "long void *" in 32 bit applciations.
If I go with approach #3, I get to keep my type checking. With the other two approaches, I have explicit coercion, and I lose my type checking and boundary/range checking: the explicit casts quiet the warnings, even when they are used incorrectly.
If I go further, and allow the segment to be mapped anywhere in memory, it may be mapped over 4G. I might also have relative base addressing (e.g. listerner converts), where I store the internal base address in the provider as part of the data being provided). This may sound like a strange scenario (e.g. it's like DCE RPC, in that it becomes the receiver's responsibility to convert, if a conversion is needed), but it's very useful. It has the following attributes:
(a) If I use homogeneous consumer/providers, no conversion is necessary
(b) My "work horse" application can do their work, and it's up to my "viewer" applciation to do the conversion; presumably, it's not doing much other than interacting with a slow human, so this ends up being the best division of labor
(c) As time goes forward, the rest of my application is likely to migrate to 64 bit as well, so I get performance improvements over time, as the coversion requirements drop out.
You could argue that because the program was not 64 bit clean, it's not "well written". You could also argue that losing the compiler warning checking is "OK, because it's your own fault for not porting everything" (if you didn't believe in closed source third party plugins over which you had no control).
I would argue that you can expect someone to accurately predict future users of their software, and there's only so much work you can do to make sure that things don't break horribly at some arbitrary point in some arbitrary compilation environment.
For the most part, we have to rely on our tools.
And our tools do not tell us when this type of problem happens, because this type of problem is relatively new.
This is on an ILP32 machine with the current GCC 4.x. It also fails to warn in GCC 3.x, so this is not a "4.x branch thing".
I would similarly expect a warning when using an integer as an lvalue for an expression containing a long when running on an ILP32 machine, but there is no warning - any overflow occurs silently.
In particular, the GNU toolchain has a very poor ability to complain about long/int coercion. It also doesn't have a 64 bit pointer type for use in 32 bit code - so any 32 bit code you need to talk to from 64 bit ends up handing around a long long, and since this is just an integer type, there's no problem with assigning it to another integer type, and potentially losing resolution (and bits off the pointer, should it be converted/passed back).
Minimally, the tools need to have a flag that complains about integer assignment between 32 and 64 bit values. Ideally, they would also include a "long void *" or some other pointer type whose type coercion would result in a warning being generated, unless the coercion was done with explicit casts.
The assignment warning has been asked for many times in the past by people trying to move ILP32 code into an LP64 environment, and of course, the tools people have objected to the idea because it would cause additional warnings that they'd have to explain how to coeerce around.
The objection to adding a 64 bit pointer type for use in 32 bit code, I can somewhat sympatize with - but they added "long long" well before it was standardized, even when it was obvious that the most correct thing to call it would be a single token like "quad" so it could be defined in and out, without having to typedef or replace explicit types. So the argument against it is very weak.
They've also messed up and refused to correct things that are obvious breakage (e.g. "typedef char *caddr_t; const caddr_t foo" results in a "char const *foo", rather than a "const char *foo", and "caddr_t const fee" results in a a "char const *fee" instead of a "char * const fee" -- meaning it's impossible to use typedef'ed values in function declarations using const in some circumstances).
Speaking of all of which -- when are we going to get a flag so that "typedef char *caddr_t; extern void fum(char *); caddr_t foo;... fum(foo); results in a type warning?!?
The vast majority of problems that arise when porting between ILP32 and LP64 are things which would be trapped by the addition of a few warnings to the compiler - but without those warnings, it becomes a Herculean task requiring a level of detail work and precision very difficult to keep up over the amount of time necessary for a large project porting effort. It's no wonder this is becoming a visibility issue, as 64 bit hardware becomes more prevalent, and people decide they want to run their code over there.
"The problem is that while technology advanced, we have not built new reactors to take advantage of it."
By "We", I assume you mean the United States, since France and others have been using fast breeder reactors and fuel recycling that never results in weapons grade Plutonium at any point in the cycle, and reduces the actual long term waste to nearly nothing.
The US has held itself back over its continuing collective guilt over ending WWII by using nuclear weapons on Japan. Japan, on the other hand, has 34% of it's electical power coming form 53 reactors, of which the majority are breeder reactors (generate their own plutonium for use as fuel in themselves and other reactors), so it seems they're a heck of a lot less fearful of it than the US is (the US only gets 10% of our electrical power from reactors). http://www.cscap.nuctrans.org/Nuc_Trans/locations/ japan/wna-japan.jpg
At IBM we called this (with much skepticism) "Maintaining an on *grunt* going *grunt* customer *grunt* relationship".
Being able to charge a subscription fee for your software and continue to get paid, rather than have to make money by continuing to get unit sales, is the holy grail of any software company.
Microsoft tried to force all their customers to this model without a heck of a lot of success. In my opinion, it's not because they couldn't have had this model, it's just that they tried too late - and found out that once something is "good enough", people simply don't spend the money to "upgrade" to something that's the software equivalent of road bed materials: an OS exists only to permit people to run applications, and once they run, you're done buying OS's.
Frankly, I think the best thing that has happened to Microsoft upgrade sales in a couple of years has been that iTunes doesn't run on Windows 98.
I still run Win98 on my Sony laptop. There are a lot of reasons:
(1) I'm still convinced that the last "update" was intended to make machines suck for the people who didn't want to pay for XP... "Here, free update! Now pay for XP, dammit, or your machine stays unusable".
(2) Under 98, Sony has recovery disks that are truly excellent; with Windows XP, "recovery" means repartitioning the machine and losing my other partitions, because the recovery disks are incapable of directly writing to an NTFS partition. This has been the same for every XP distribution I've ever gotten my hands on. This is damn unfriendly for third party OS's (which I guess is the point), but it's also damn unfriendly for a backup/data partition so that if your machine gets p0wned, you can recover and be running again in under 5 minutes.
(3) Third party Sony software doesn't meet "upgrade/install" requirements. Microsoft Software is the worst: it won't let you install the OEM software, including Word, onto the machine, and it won't recognize the CDROM with Word on it as a valid installation of Word, if you want to get off with the "cheap" version of "Office" instead of the "bend over" version of office (the upgrade recognizes an installed "Word" as a qualifying product).
(4) My third party *firewall* software runs without intereference from Microsoft's "firewall" software
(5) My software still runs, without me having to "upgrade" everything because of ABI differences in XP
(6) No yearly MS tax on my machine for an "ongoing customer relationship" that I'd rather not relate to
(7) No automatic updates behind my back
(8) No Windows Media deinstalling/breaking other software because they're allowed to by the new EULA
(9) No "you must connect to the Internet so I can tell Microsoft about your machine, or it's going to quit working in 30 days", unlike XP
(10) Works with standard boot managers, like "BootMagic" or anything else you'd care to install
Frankly, I can't think of *one* reason to put XP on a machine that has 98 on it already; no matter how you look at it, XP is a *downgrade*.
I'm pretty much against the poster when it comes to gratuitous Bill-bashing. But your defense in this particular case is ill-founded; both Bill's company and the ISPs are at considerable fault in this case.
It's called "an attractive nuisance", and that's what Bill's company has created in millions upon millions of homes and offices around the world.
The description in Wikipedia is particularly apt in this case. Bill and the ISPs are the landowners -- "the condition must be one of which the landowner is or reasonably should be aware, and the landowner should also have reason to know that children might be in the area" -- and the people whose machines are getting infected are the trespassing children "who are unable to appreciate the risk posed by the object or condition".
But if you only have about 2000 authorized users, it seems to me you could modify the software to white list them.
Then anyone not on the white list gets a random time back (with appropriate checks to make sure that it isn't anywhere near the correct time).
As soon as it starts looking like a bug in their product, they wil take the problem seriously. But don't expect them to take it seriously until it actually becomes *their* problem.
CEOs do not last; you want to be CTO, especially if VC is involved.
Expect that whoever is CEO will be pushed out in favor of whoever the VC's want to run the business. This won't happen during Angel funding, but it *will* happen in either the first or second round of VC funding, if your company gets that far.
In general, the CEO is a titular position, and it's one where you normally bring in a good schmoozer, and give him stock grants and options on top of that so that he or she hopefully acts in the best interests of the company, rather than in their own best interests (i.e. you try and make it their best interest to act in the best interests of the company).
Some people also try to elect themselves as board chairman: that's another position you won't be able to keep, when your founders have two board members, and you have a number of other people on your board, the VC's are generally going to get what they want out of things that come to a vote. If you try to control this by *not* bringing in other people on your board, you're making a bad business mistake, since these are the people who are going to get your product initially adopted into other companies, and who will get your product talked up to other companies at other board meetings (i.e. your Uncle Bob is not a good choice for board member, unless Uncle Bob is already on the board of a Fortune 500 company).
In my experience at startups, one of the founders starts out as CEO, and then get pushed out of that position. Also, in general, the CFO and CTO positions are less likely to get pushed out of the management structure, as time goes on. At the very least, you will need a fallback, or your will have formed a company only to get a lot of stock and become an employee (and *maybe* a board member; maybe not, depending on the amount of stock).
Bottom line is that if you are going to take VC money, and you want some control over your company direction, make sure that when you get pushed out of the CEO/President/other top role, that you have a fallback position that the VC's aren't going to want to take from you.
And they are still selling their "Harmony" product. Apple grumbled at them, but there wasn't (AFAIK) a lawsuit or anything that resulted from that, and they are still encoding music in DRM'ed FairPlay format.
It's not that hard to reverse engineer; the other people trying to be in the market are just being lazy.
"Do people really think that apple having "easy" to use software is so special? Nothing Apple does is really all that unique, it's just a matter of quantities of production and spending the time to develop the interface right."
And that *is* unique. The UI on most cell phones suck. I don't know one software engineer with a cell phone who wouldn't pay a reasonable amount of money to get the firmware source code - even if only for the UI part of things - so that they could hack a decent UI onto the thing.
I haven't seen one cell phone with a decent UI (or I'd own the thing, no matter who I had to sign up with to get it).
I've done some technical editing; the most lucrative of my gigs was for Prentice Hall on a UNIX Internals book, and other than a "thanks" in the book, I got a couple hundred dollars as an "honorarium" - basically, a small token amount. Other books, I've pretty much done for even less, mostly because I've thought that the boks needed written, or needed to be out there.
For the technical books I've been involved in, the publisher's overhead for technical editing has always been practically nothing. From talking to other people who've done the same, it's pretty clear to me that of all the pieces of a technical book, the technical editing is pennies compared to anything else.
The *primary* reason that more books aren't written, at least for me, is that my last several employers demanded editorial control, if the book was going to talk about anything related to current or potential future business of the company. One even demanded that I not list myself as an author on the book, to prevent people from trying to hire me away because of the book. Add to that that the minimum amount of effor you can expect to spend is ~2080 hours (one man year), and you have a sterling recipe for "it's not worth it".
"Can't make your car payment? Then you can't get it started"
This type of device (no, this is not the only OEM of such devices) is frequently used in the sub-prime credit market for people who would have a tendency to not make their car payments, but still need a car in order to live their lives.
Or to put it another way, it's a way to get deadbeats to pay who live in conditions of suburban sprawl, where jobs people are qualified for, or which pay at least what they are willing to accept, are not located near places people can afford, or at least want, to live.
No social or individiual delayed gratification commentary intended, there, of course...
It's a flocking behaviour... and you *must* take it into account when choosing software.
Q: "What function of Word that wasnt available in Word 6.0 and is now requires this insane increase of performance need?"
A: The ability to open and read documents sent to you by third parties using the newer tools.
For example, when your lawyer buys a new computer, and installs a new version of Office, and writes up a contract for you, you are not going to be able to read it using your machine running an older version of the application. And the newer version doesn't run on the older platform.
Don't worry - the first copy of a program that has this continuous upgrade path lock-in is free witht he machine.
The intent, at least in France, is to get laws in place for Vivendi/Universal Music Group and establish individual fines per song for content downloads without royalty payment, under cover of "rationalizing" French law with EU law.
The side effect of this is a DRM mandated by the companies - effectively it makes it legal to comply by transcoding the songs into another DRM format, and it makes it *technically* legal to crack DRM in theory, but difficult in practice.
This is basically a shot at business models that allow content in multiple places without multiple payments, and return of control of content distribution to the music industry, now that it's been proven that digital music sales can make money.
The provisions of this bill give them about 6 barriers with which they could shut down the iTMS from the French market, and potentially elsewhere. At the same time, you can be guaranteed that Vivendi will not distribute content that's not DRM'ed, so effectively and non-DRM'ed content they see on the network will be content that falls under the penalties of the new law.
So it's still a ploy to put in place Draconian DRM and throw everything else out of the market; you might have read my comment as referring to Microsoft's WMA format, but in fact I was speaking about Vivendi.
I can't tell you how many times I've seen engineers puttering along on inadequate hardware because the executives had the shiny, fast new boxes that did nothing more on a daily basis than run "OutLook".
Just as McKusick's Law applies to storage - "The steady state of disks is full" - there's another law that applies to CPU cycles, which is "There are alwways fewer CPU cycles than you need for what you are trying to do".
Consider that almost all of the office/utility software you are going to be running in a couple of years is being written by engineers in Redmond with monster machines with massive amounts of RAM and 10,000 RPM disks so that they can iteratively compile their code quickly, and you can bet your last penny that the resulting code will run sluggishly at best on the middle-tier hardware of today.
I've often argued that engineers should have to use a central, fast compilation software, but run on hardware from a generation behind, to force them to write code that will work adequately on the machines the customers will have.
Yeah, I'm an engineer, and that applies to me, too... I've even put my money where my mouth was on projects I've worked on, and they've been the better for it.
I expect that someone in the French government will talk to someone technical before this becomes law there. If they do, I expect they will scrap the plan.
What they are effectively demanding is a common DRM standard, and anyone who doesn't play by having another mechanism will have to also implement the standard mechanism, and permit transcoding into that mechanism. And this will mean more restrictions, not fewer.
To me, this looks like a ploy backed by someone who wants their DRM to become standard, but can't achieve this by making products that people want to buy, so they want to force everyone to adopt their DRM or die. And I expect that the DRM will be the most draconian DRM imaginable, since conversion will be viral in terms of supporting more restrictions.
Transcoding data from one DRM format to another is problematic, if you want the DRM to continue to be effective. The problem is that there is a potential impedence mismatch in license terms.
First, what if I'm translating music from a format that permits only a single copy, and no burning to CDROM, to (to take the current example), the iTunes format, which permits installation on multiple computers, an infinite number of iPods, and burning to a CD multiple times, based on a playlist?
If this happens, my only real option to maintain the licensing restrictions properly is to use one type of DRM, or to choose the most restriction union of both sets of DRM. So the *most* restrictive DRM will become viral, and limit what you can do with anyone's DRM.
Second, how many times - how many different instances/formats - am I permitted to do this transcoding? If the answer is "infinite", then there's effectively no DRM. Again, the most restrictive DRM wins.
Third, how would this impact limited node-locking? With iTunes, you are node-locked to a limited number of nodes, but those nodes can change over time - you are permitted to authorize and deauthorize nodes. With this capability, you could authorize any number of nodes, one at a time, to use the transcoding capability to copy from a limited node-locked format into an unlimited node-locked format. So say goodbye to the "limited" in "limited node-locking". Again, a virus.
People have said that Apple's DRM is tolerable - and they've said that any DRM is intolerable. For the first group, you would take away most of what permits Apple's DRM to be tolerable. For the second group - they're not going to be happy anyway, as long as DRM is permitted at all, and that's not one of the options on the table here.
(PS: I'm mostly in the second group - I think DRM is the moral equivalent of telling your customer you don't trust them).
-- Terry
I worked for IBM when this trend started...
on
No More Next Big Thing?
·
· Score: 4, Interesting
I worked for IBM when this trend started... they bought the company I worked for, and, unlike many in companies bought by IBM, I stayed around for a couple years (compare 54% attrition in a year vs. 6% attrition in a year for most Cisco acquisitions).
One really stupid thing that happened before I left was that they decided that each of the major labs would have to come up with at least one product every 6 months, instead of dedicating themselves to research. This was one of Lou Gerstner's last gasps, but it redirected the company focus from doing things that no one else could do, to doing things that made short term profit.
Then others in the company (Sam Pamisano, Bill Etherington, et. al.) decided that individual contributors compensation would be based on the overall profit more than division or personal performance, and that managers and above would still have it based on division, personal performance, then overall profit, in that order.
Either they believed the engineers working for them had never had any higher math in the area of game theory, or they were simply ignorant that the emergent property of that type of staging is to keep your boss pleased by keeping the division up at the expense of the rest of the company, so the boss is happy and cuts you in on the cake.
Finally, it was a matter of pride to IBM Global Services that they had so much consulting effort that had been sold that they had a 2 year backlog - WTF? Who could *possibly* be proud of promising something you're unable to deliver in the timeframe you promised it, or having an organization that can't meet the demands of its market?
It's really unfortunate when a large company that people have depended upon for their livelihoods starts a tumble into short term thinking, and from there, into mediocrity.
Slashdot Mirror
Obvious problems with R, MySQL "benchmarks"...
I've posted about MySQL's problems before; they could get about a 15% performance improvement on Linux and a huge performance improvement on MacOS X just by pipelining their requests. This would require a library change (2/3s of the improvement) and a change to the way requests are dequeued on the server (about 1/3).
The R problem is 50% him not passing "-O2 -fstrict-aliasing" to the compiler, and 50% him using the system malloc instead of dlmalloc like it says to use in the R admin manual.
I have to agree with the parent poster on this one; I wouldn't have said things quite that way, but then the guy who did the R "benchmark" was pretty inflamatory in his comments, too.
-- Terry
Interestingly, the same thing happened in 1991.
In 1991, the Honda CRX HF was introduced with an EPA estimated 49/52 MPG.
Like most competition, the U.S. auto manufactures lobbied for the introduction of a lot of new destructive safety tests that their cars were known to already be capable of surviving, but the CRX HF was not. They actually had to go out an buy a bunch of them themselves to take them apart to see what sheer stresses they could apply that the HF would not survive.
And so, like the Yugo before it (which didn't have good gas mileage, but was kicking their teeth in on price), they saved The American Way Of Life by keeping the foreign competition out of their markets.
I have no doubt the SMART will suffer similarly, if the Santa Clara people who have the exclusive $10M import deal fail to mark it up sufficiently to drive people away from buying them instead of American cars.
-- Terry
"Case sensitivity is the single greatest user interface botch in Unix"
The greatest UI botch in UNIX is actually not doing it's regex expansion below the user/kernel boundary. It means that you can't do interesting things, like only copying back the directory data that matches your regex across the expensive protection domain crossing of the U/K boundary. It also means that you can't do *very* interesting things, like real versioning support at the FS layer (unless the name you're looking up is considered a regex, you can't default the version suffix in the name space, like VMS did).
The second greatest UI botch was puting the processes environment in user space, and exposing a "char **environ" variable into the process name space, so it was impossible to move the implementation into the kernel proper, and deal with environmental inheritance, like the historical process, group, and system logical name tables. Without this, it is practically impossible to provide reasonable support for things like variant symbolic links.
The third greatest UI botch was vowel compression in command names to fit them into the 14 character file name limit.
The fourth greatest UI botch was not having a regular command line argument syntax for all commands.
I could continue on the whole top-20 list, but I won't.
Case sensitivity, on the other hand, is what makes 7 bit NRCS-based internationalization, UTF-8, and other arbitrary character set encodings work so well. Windows has to carry around encoding tables for its encoding tables to deal with it's 16 bit Unicode characters vs. the current code page, in order to represent a locale, and it's limited to the early Unicode specifications because it doesn't support the full 32 bit wchar_t type.
UNIX made a lot of early mistakes, which, as engineers, we've stupidly carried forward with us instead of correcting, but initial case sensitivity for file names wasn't among them.
-- Terry
BlueTooth syncing via drag-and-drop only works if OBEX - OBject EXchange - has not been specifically disabled, which it is on Verizon phones. This is because file exchange requires mode 22 on the phone, which by default likes to talk in mode 0 or mode 2, and take AT commands.
For phones which are composite devices (which is pretty much all of them), it also requires that the drivers recognize a change of actual device ID (USB or otherwise, if you do not use USB interconnect), which is not always practical (e.g. when supporting OBEX over USB, you usually have to write the OBEX code yourself, as it's not considered a line discipline or streams layer that's stackable on top of USB).
The drag-and-drop has an additional limitation, in that on a number of phones, you have to delete the index of files and let the phone rebuild it. If you don't do this, then you can't access the new files on the phone directly, since they won't show in the menus. Effectively, it means there's an implicit data interface, which is undocumented by the phone vendors, for communicating data changes to the phone.
That basically means you must inflict intentional "damage", and then depend on your phone's error recovery mechanisms to rebuild the index for you. This generally works, although there are known problems with some phones with some revisions of firmware from various vendors.
The bottom line is that mobile phone synching and integration is currently about as advanced as mobile phone UI itself, which is to say, not very.
-- Terry
It depends on your carrier, and the software sucks...
Verizon will lock you out of your phone; if you go online and try to grab a copy of Motorolla Phone tools (yes, I know this is a Windows application suite), they specifically note that they have disabled thing, like the ability to download background images and ring tones, at the request of Verizon.
For other carriers, whether you can sync with Linux is a function of which SourceForge package you download, and how long your phone has been out. The best ones seem to be for Nokia phones (Nokia is popular in Europe, despite the exploding battery issue) and because the E.U. has a law permitting reverse engineering for the purposes of interoperability, a lot of phone hacking happens there.
For MacOS X, iSync will handle your address book and data connection. If you want the camera portion of your phone to show up in iPhoto, it's not going to happen. If you want the background picture to show up there, too, and be downloadable to the phone, that's also not there. If you want to take an iTunes song and use it as a ring tone, that's also not there.
To be fair, this takes extra software on both the Mac and the PC - not just the Mac - and, again, your carrier can lock you out of it, if they choose to do so.
For third party applications for doing the transfers, you're normally talking about needing a WAP enabled phone, and your computer uploads the content to a web site, and then you pay text and data transfer charges to get the URL, then the content itself, down to your phone, unless you get software designed to talk to the phone over USB (also needs a data cable, anmd extra expsense - at least Motorola uses standard 5 pin minim USB 'A'/'B' cables for many of its phones).
I've personally purchased an application that is considered the best out there for image and ring tone transfers (it's basically a piece of crap, so I won't name names, but it runs on both Mac and PC, and it's considered the best of the lot, for both platforms); it wasn't useful for ring tones or image cut down until I downloaded 3 or 4 other packages from freeware/open source sites, and even then, editing was somewhat hinky.
The bottom line is that the phone companies (or should I say "phone company", now that AT&T has reassembled itself like a Terminator II) control the code on your phone, and as long as they do, they own what you can and can't do with the phone. And if next Tuesday, that means not syncing with Linux or MacOS X, then that's what it means.
-- Terry
``And in what universe is anyone who can intelligently speak about (much less code around) memory and VM management [be called] an "incompetent idiot"?''
The Universe In Which Spock Has A Beard?
-- Terry
To put things in perspective, the EEOC itself is moving to online claims filing.
As far as Kroger's is concerned, there is an online version of the form, which you should be able to get at, if you are able to post on Slashdot.
In the online form, it clearly states:indicating that they will accomodate you if you are legitimately disabled; illiteracy is not a disability. Although there are disabilities which can interfere with someone becoming literate, there is generally no disability that would prevent it completely (look at Helen Keller - both deaf and blind, but a successful author).
So even if you have a case, it's not a case until they fail to accomodate you within applicable law.
Your argument seems to come down to "kiosks suck, and this should be an EEOC violation, which is a false assertion of entitlement on your part.
-- Terry
Even well written code can have problems.
Specifically, say I have a 64 bit platform capable of running both LP64 code and ILP32 (legacy) code.
I use a shared memory segment to communicate between my legacy 32 bit applications, and it has internal use of pointers to perform self-reference on data.
[Rather than complicating things, let's just assume that the pointers are internally based off the base address of the shared memory segment, rather than being based off of 0, so there is no requirement of mapping the memory into the same location in each process]
I'm now adding a 64 bit computation engine (perhaps my application is a rendering system that uses plug-ins, and being able to work on large data sets with the large address space afforded to 64 bit processes is critical, but when it comes to displaying the results, I can live easily in a 32 bit address space, so I'm not trying to port my whole tool over to 64 bits).
So now I have to deal with the internal pointers in the shared memory segment. I can do one of several things:
(1) I can use structure coercion to treat the pointers as if they were integer offsets instead, and coerce them into pointers internally in the 64 bit code (on LP64, pointers are 64 bit).
(2) I can intenrally store 64 bit pointers, rather than 32 bit pointers. This means I need the same round-tripping, but it can take place in the 32 bit applications, rather than the 64 bit applications, and the Integer representation is as "long long" as far as its concerned.
(3) I can support either a "short void *" in 64 bit applications, or a "long void *" in 32 bit applciations.
If I go with approach #3, I get to keep my type checking. With the other two approaches, I have explicit coercion, and I lose my type checking and boundary/range checking: the explicit casts quiet the warnings, even when they are used incorrectly.
If I go further, and allow the segment to be mapped anywhere in memory, it may be mapped over 4G. I might also have relative base addressing (e.g. listerner converts), where I store the internal base address in the provider as part of the data being provided). This may sound like a strange scenario (e.g. it's like DCE RPC, in that it becomes the receiver's responsibility to convert, if a conversion is needed), but it's very useful. It has the following attributes:
(a) If I use homogeneous consumer/providers, no conversion is necessary
(b) My "work horse" application can do their work, and it's up to my "viewer" applciation to do the conversion; presumably, it's not doing much other than interacting with a slow human, so this ends up being the best division of labor
(c) As time goes forward, the rest of my application is likely to migrate to 64 bit as well, so I get performance improvements over time, as the coversion requirements drop out.
You could argue that because the program was not 64 bit clean, it's not "well written". You could also argue that losing the compiler warning checking is "OK, because it's your own fault for not porting everything" (if you didn't believe in closed source third party plugins over which you had no control).
I would argue that you can expect someone to accurately predict future users of their software, and there's only so much work you can do to make sure that things don't break horribly at some arbitrary point in some arbitrary compilation environment.
For the most part, we have to rely on our tools.
And our tools do not tell us when this type of problem happens, because this type of problem is relatively new.
-- Terry
You are incorrect.
The following is some code that does not warn that the resolution of "long l" is potentially insufficient to store the value contained in "long ll":This is on an ILP32 machine with the current GCC 4.x. It also fails to warn in GCC 3.x, so this is not a "4.x branch thing".
I would similarly expect a warning when using an integer as an lvalue for an expression containing a long when running on an ILP32 machine, but there is no warning - any overflow occurs silently.
-- Terry
64 bit porting is more of a compiler problem.
... fum(foo); results in a type warning?!?
In particular, the GNU toolchain has a very poor ability to complain about long/int coercion. It also doesn't have a 64 bit pointer type for use in 32 bit code - so any 32 bit code you need to talk to from 64 bit ends up handing around a long long, and since this is just an integer type, there's no problem with assigning it to another integer type, and potentially losing resolution (and bits off the pointer, should it be converted/passed back).
Minimally, the tools need to have a flag that complains about integer assignment between 32 and 64 bit values. Ideally, they would also include a "long void *" or some other pointer type whose type coercion would result in a warning being generated, unless the coercion was done with explicit casts.
The assignment warning has been asked for many times in the past by people trying to move ILP32 code into an LP64 environment, and of course, the tools people have objected to the idea because it would cause additional warnings that they'd have to explain how to coeerce around.
The objection to adding a 64 bit pointer type for use in 32 bit code, I can somewhat sympatize with - but they added "long long" well before it was standardized, even when it was obvious that the most correct thing to call it would be a single token like "quad" so it could be defined in and out, without having to typedef or replace explicit types. So the argument against it is very weak.
They've also messed up and refused to correct things that are obvious breakage (e.g. "typedef char *caddr_t; const caddr_t foo" results in a "char const *foo", rather than a "const char *foo", and "caddr_t const fee" results in a a "char const *fee" instead of a "char * const fee" -- meaning it's impossible to use typedef'ed values in function declarations using const in some circumstances).
Speaking of all of which -- when are we going to get a flag so that "typedef char *caddr_t; extern void fum(char *); caddr_t foo;
The vast majority of problems that arise when porting between ILP32 and LP64 are things which would be trapped by the addition of a few warnings to the compiler - but without those warnings, it becomes a Herculean task requiring a level of detail work and precision very difficult to keep up over the amount of time necessary for a large project porting effort. It's no wonder this is becoming a visibility issue, as 64 bit hardware becomes more prevalent, and people decide they want to run their code over there.
-- Terry
"The problem is that while technology advanced, we have not built new reactors to take advantage of it."
/ japan/wna-japan.jpg
By "We", I assume you mean the United States, since France and others have been using fast breeder reactors and fuel recycling that never results in weapons grade Plutonium at any point in the cycle, and reduces the actual long term waste to nearly nothing.
The US has held itself back over its continuing collective guilt over ending WWII by using nuclear weapons on Japan. Japan, on the other hand, has 34% of it's electical power coming form 53 reactors, of which the majority are breeder reactors (generate their own plutonium for use as fuel in themselves and other reactors), so it seems they're a heck of a lot less fearful of it than the US is (the US only gets 10% of our electrical power from reactors). http://www.cscap.nuctrans.org/Nuc_Trans/locations
-- Terry
At IBM we called this (with much skepticism) "Maintaining an on *grunt* going *grunt* customer *grunt* relationship".
Being able to charge a subscription fee for your software and continue to get paid, rather than have to make money by continuing to get unit sales, is the holy grail of any software company.
Microsoft tried to force all their customers to this model without a heck of a lot of success. In my opinion, it's not because they couldn't have had this model, it's just that they tried too late - and found out that once something is "good enough", people simply don't spend the money to "upgrade" to something that's the software equivalent of road bed materials: an OS exists only to permit people to run applications, and once they run, you're done buying OS's.
Frankly, I think the best thing that has happened to Microsoft upgrade sales in a couple of years has been that iTunes doesn't run on Windows 98.
-- Terry
I still run Win98 on my Sony laptop. There are a lot of reasons:
(1) I'm still convinced that the last "update" was intended to make machines suck for the people who didn't want to pay for XP... "Here, free update! Now pay for XP, dammit, or your machine stays unusable".
(2) Under 98, Sony has recovery disks that are truly excellent; with Windows XP, "recovery" means repartitioning the machine and losing my other partitions, because the recovery disks are incapable of directly writing to an NTFS partition. This has been the same for every XP distribution I've ever gotten my hands on. This is damn unfriendly for third party OS's (which I guess is the point), but it's also damn unfriendly for a backup/data partition so that if your machine gets p0wned, you can recover and be running again in under 5 minutes.
(3) Third party Sony software doesn't meet "upgrade/install" requirements. Microsoft Software is the worst: it won't let you install the OEM software, including Word, onto the machine, and it won't recognize the CDROM with Word on it as a valid installation of Word, if you want to get off with the "cheap" version of "Office" instead of the "bend over" version of office (the upgrade recognizes an installed "Word" as a qualifying product).
(4) My third party *firewall* software runs without intereference from Microsoft's "firewall" software
(5) My software still runs, without me having to "upgrade" everything because of ABI differences in XP
(6) No yearly MS tax on my machine for an "ongoing customer relationship" that I'd rather not relate to
(7) No automatic updates behind my back
(8) No Windows Media deinstalling/breaking other software because they're allowed to by the new EULA
(9) No "you must connect to the Internet so I can tell Microsoft about your machine, or it's going to quit working in 30 days", unlike XP
(10) Works with standard boot managers, like "BootMagic" or anything else you'd care to install
Frankly, I can't think of *one* reason to put XP on a machine that has 98 on it already; no matter how you look at it, XP is a *downgrade*.
-- Terry
I'm pretty much against the poster when it comes to gratuitous Bill-bashing. But your defense in this particular case is ill-founded; both Bill's company and the ISPs are at considerable fault in this case.
It's called "an attractive nuisance", and that's what Bill's company has created in millions upon millions of homes and offices around the world.
http://en.wikipedia.org/wiki/Attractive_nuisance
The description in Wikipedia is particularly apt in this case. Bill and the ISPs are the landowners -- "the condition must be one of which the landowner is or reasonably should be aware, and the landowner should also have reason to know that children might be in the area" -- and the people whose machines are getting infected are the trespassing children "who are unable to appreciate the risk posed by the object or condition".
-- Terry
Far be it for me to give PHK advice...
But if you only have about 2000 authorized users, it seems to me you could modify the software to white list them.
Then anyone not on the white list gets a random time back (with appropriate checks to make sure that it isn't anywhere near the correct time).
As soon as it starts looking like a bug in their product, they wil take the problem seriously. But don't expect them to take it seriously until it actually becomes *their* problem.
-- Terry
CEOs do not last; you want to be CTO, especially if VC is involved.
Expect that whoever is CEO will be pushed out in favor of whoever the VC's want to run the business. This won't happen during Angel funding, but it *will* happen in either the first or second round of VC funding, if your company gets that far.
In general, the CEO is a titular position, and it's one where you normally bring in a good schmoozer, and give him stock grants and options on top of that so that he or she hopefully acts in the best interests of the company, rather than in their own best interests (i.e. you try and make it their best interest to act in the best interests of the company).
Some people also try to elect themselves as board chairman: that's another position you won't be able to keep, when your founders have two board members, and you have a number of other people on your board, the VC's are generally going to get what they want out of things that come to a vote. If you try to control this by *not* bringing in other people on your board, you're making a bad business mistake, since these are the people who are going to get your product initially adopted into other companies, and who will get your product talked up to other companies at other board meetings (i.e. your Uncle Bob is not a good choice for board member, unless Uncle Bob is already on the board of a Fortune 500 company).
In my experience at startups, one of the founders starts out as CEO, and then get pushed out of that position. Also, in general, the CFO and CTO positions are less likely to get pushed out of the management structure, as time goes on. At the very least, you will need a fallback, or your will have formed a company only to get a lot of stock and become an employee (and *maybe* a board member; maybe not, depending on the amount of stock).
Bottom line is that if you are going to take VC money, and you want some control over your company direction, make sure that when you get pushed out of the CEO/President/other top role, that you have a fallback position that the VC's aren't going to want to take from you.
-- Terry
Real reverse engineered FairPlay
And they are still selling their "Harmony" product. Apple grumbled at them, but there wasn't (AFAIK) a lawsuit or anything that resulted from that, and they are still encoding music in DRM'ed FairPlay format.
It's not that hard to reverse engineer; the other people trying to be in the market are just being lazy.
-- Terry
Easy to use software *IS* special!
"Do people really think that apple having "easy" to use software is so special? Nothing Apple does is really all that unique, it's just a matter of quantities of production and spending the time to develop the interface right."
And that *is* unique. The UI on most cell phones suck. I don't know one software engineer with a cell phone who wouldn't pay a reasonable amount of money to get the firmware source code - even if only for the UI part of things - so that they could hack a decent UI onto the thing.
I haven't seen one cell phone with a decent UI (or I'd own the thing, no matter who I had to sign up with to get it).
-- Terry
Disagree: technical editing not expensive
I've done some technical editing; the most lucrative of my gigs was for Prentice Hall on a UNIX Internals book, and other than a "thanks" in the book, I got a couple hundred dollars as an "honorarium" - basically, a small token amount. Other books, I've pretty much done for even less, mostly because I've thought that the boks needed written, or needed to be out there.
For the technical books I've been involved in, the publisher's overhead for technical editing has always been practically nothing. From talking to other people who've done the same, it's pretty clear to me that of all the pieces of a technical book, the technical editing is pennies compared to anything else.
The *primary* reason that more books aren't written, at least for me, is that my last several employers demanded editorial control, if the book was going to talk about anything related to current or potential future business of the company. One even demanded that I not list myself as an author on the book, to prevent people from trying to hire me away because of the book. Add to that that the minimum amount of effor you can expect to spend is ~2080 hours (one man year), and you have a sterling recipe for "it's not worth it".
-- Terry
It's here today: http://www.payteck.cc/news.html
"Can't make your car payment? Then you can't get it started"
This type of device (no, this is not the only OEM of such devices) is frequently used in the sub-prime credit market for people who would have a tendency to not make their car payments, but still need a car in order to live their lives.
Or to put it another way, it's a way to get deadbeats to pay who live in conditions of suburban sprawl, where jobs people are qualified for, or which pay at least what they are willing to accept, are not located near places people can afford, or at least want, to live.
No social or individiual delayed gratification commentary intended, there, of course...
-- Terry
It's a flocking behaviour... and you *must* take it into account when choosing software.
Q: "What function of Word that wasnt available in Word 6.0 and is now requires this insane increase of performance need?"
A: The ability to open and read documents sent to you by third parties using the newer tools.
For example, when your lawyer buys a new computer, and installs a new version of Office, and writes up a contract for you, you are not going to be able to read it using your machine running an older version of the application. And the newer version doesn't run on the older platform.
Don't worry - the first copy of a program that has this continuous upgrade path lock-in is free witht he machine.
-- Terry
You need to read the original article.
The intent, at least in France, is to get laws in place for Vivendi/Universal Music Group and establish individual fines per song for content downloads without royalty payment, under cover of "rationalizing" French law with EU law.
The side effect of this is a DRM mandated by the companies - effectively it makes it legal to comply by transcoding the songs into another DRM format, and it makes it *technically* legal to crack DRM in theory, but difficult in practice.
This is basically a shot at business models that allow content in multiple places without multiple payments, and return of control of content distribution to the music industry, now that it's been proven that digital music sales can make money.
The provisions of this bill give them about 6 barriers with which they could shut down the iTMS from the French market, and potentially elsewhere. At the same time, you can be guaranteed that Vivendi will not distribute content that's not DRM'ed, so effectively and non-DRM'ed content they see on the network will be content that falls under the penalties of the new law.
So it's still a ploy to put in place Draconian DRM and throw everything else out of the market; you might have read my comment as referring to Microsoft's WMA format, but in fact I was speaking about Vivendi.
Cheers,
-- Terry
"...getting a couple [for the executives]..."
I can't tell you how many times I've seen engineers puttering along on inadequate hardware because the executives had the shiny, fast new boxes that did nothing more on a daily basis than run "OutLook".
Just as McKusick's Law applies to storage - "The steady state of disks is full" - there's another law that applies to CPU cycles, which is "There are alwways fewer CPU cycles than you need for what you are trying to do".
Consider that almost all of the office/utility software you are going to be running in a couple of years is being written by engineers in Redmond with monster machines with massive amounts of RAM and 10,000 RPM disks so that they can iteratively compile their code quickly, and you can bet your last penny that the resulting code will run sluggishly at best on the middle-tier hardware of today.
I've often argued that engineers should have to use a central, fast compilation software, but run on hardware from a generation behind, to force them to write code that will work adequately on the machines the customers will have.
Yeah, I'm an engineer, and that applies to me, too... I've even put my money where my mouth was on projects I've worked on, and they've been the better for it.
-- Terry
I expect that someone in the French government will talk to someone technical before this becomes law there. If they do, I expect they will scrap the plan.
What they are effectively demanding is a common DRM standard, and anyone who doesn't play by having another mechanism will have to also implement the standard mechanism, and permit transcoding into that mechanism. And this will mean more restrictions, not fewer.
To me, this looks like a ploy backed by someone who wants their DRM to become standard, but can't achieve this by making products that people want to buy, so they want to force everyone to adopt their DRM or die. And I expect that the DRM will be the most draconian DRM imaginable, since conversion will be viral in terms of supporting more restrictions.
Transcoding data from one DRM format to another is problematic, if you want the DRM to continue to be effective. The problem is that there is a potential impedence mismatch in license terms.
First, what if I'm translating music from a format that permits only a single copy, and no burning to CDROM, to (to take the current example), the iTunes format, which permits installation on multiple computers, an infinite number of iPods, and burning to a CD multiple times, based on a playlist?
If this happens, my only real option to maintain the licensing restrictions properly is to use one type of DRM, or to choose the most restriction union of both sets of DRM. So the *most* restrictive DRM will become viral, and limit what you can do with anyone's DRM.
Second, how many times - how many different instances/formats - am I permitted to do this transcoding? If the answer is "infinite", then there's effectively no DRM. Again, the most restrictive DRM wins.
Third, how would this impact limited node-locking? With iTunes, you are node-locked to a limited number of nodes, but those nodes can change over time - you are permitted to authorize and deauthorize nodes. With this capability, you could authorize any number of nodes, one at a time, to use the transcoding capability to copy from a limited node-locked format into an unlimited node-locked format. So say goodbye to the "limited" in "limited node-locking". Again, a virus.
People have said that Apple's DRM is tolerable - and they've said that any DRM is intolerable. For the first group, you would take away most of what permits Apple's DRM to be tolerable. For the second group - they're not going to be happy anyway, as long as DRM is permitted at all, and that's not one of the options on the table here.
(PS: I'm mostly in the second group - I think DRM is the moral equivalent of telling your customer you don't trust them).
-- Terry
I worked for IBM when this trend started... they bought the company I worked for, and, unlike many in companies bought by IBM, I stayed around for a couple years (compare 54% attrition in a year vs. 6% attrition in a year for most Cisco acquisitions).
One really stupid thing that happened before I left was that they decided that each of the major labs would have to come up with at least one product every 6 months, instead of dedicating themselves to research. This was one of Lou Gerstner's last gasps, but it redirected the company focus from doing things that no one else could do, to doing things that made short term profit.
Then others in the company (Sam Pamisano, Bill Etherington, et. al.) decided that individual contributors compensation would be based on the overall profit more than division or personal performance, and that managers and above would still have it based on division, personal performance, then overall profit, in that order.
Either they believed the engineers working for them had never had any higher math in the area of game theory, or they were simply ignorant that the emergent property of that type of staging is to keep your boss pleased by keeping the division up at the expense of the rest of the company, so the boss is happy and cuts you in on the cake.
Finally, it was a matter of pride to IBM Global Services that they had so much consulting effort that had been sold that they had a 2 year backlog - WTF? Who could *possibly* be proud of promising something you're unable to deliver in the timeframe you promised it, or having an organization that can't meet the demands of its market?
It's really unfortunate when a large company that people have depended upon for their livelihoods starts a tumble into short term thinking, and from there, into mediocrity.
-- Terry