ddj.com · Domains · Slashdot Mirror

Re:Dr. Dobbs did this first? by aldain · 2003-08-17 03:21 · Score: 3, Informative · on SCO Nigerian Spam

A link that actually works :) http://www.ddj.com/documents/s=7896/ddj0309m/

Re:Dr. Dobbs did this first? by aldain · 2003-08-17 03:12 · Score: 1, Informative · on SCO Nigerian Spam

The Dr Dobb's version is available online at http://www.ddj.com/documents/s=7896/ddj0309m/

Agreed by turgid · 2003-07-31 21:55 · Score: 1 · on Designing And Building A New Pragmatic Language

And here's the evidence to back it up.

Spiritual Robots by joepa · 2003-07-24 01:55 · Score: 2, Informative · on Will Humanoid Robots Take All the Jobs by 2050?

A very well attended symposium was held at Stanford in 1999 that covered this very topic (in even more optimistic depth, in the case of the majority of the speakers). Entitled, Will Spiritual Robots Replace Humanity By 2100?, the symposium was organized by Doug Hofstadter and was themed around two books that expoused very similar views and were written independently of each other around that time: Ray Kurzweil's The Age of Spiritual Machines and Hans Moravec's Robot.

Kurzweil has actually been preaching about this for quite a while now, and the details of Marshall Brain's article are eerily reminiscent of both of the above mentioned books.

Ransom Love's Linuxworld 2000 Keynote Speech by NZheretic · 2003-07-10 09:23 · Score: 5, Informative · on OSCON Panel: SCO Lawsuit About the Money

The SCO Group is currently suing IBM for breach of contract for apparently putting Unixware/Monterey "technology" in Linux. SCO/Caldera's complaint depends critically on certain historical and technical assertions which are materially false and (apparently quite intentionally) misleading.

The SCO group, and both Old SCO and Caldera before it, directly acknowledged and assisted IBM with the scalablity of Linux

In August 2000, just days after Caldera purchased the Old SCO server division, the then CEO of Caldera, Ransom Love, made a keynote speech at LinuxWorld 2000. A RealPlayer video stream of the event can be found at DrDobbs Journal's Technetcast

In the question and answer session at the end of the keynote, Love was asked about the possible conflict over Monterey and Linux IA-64

A mp3 capture of the following transcribed portion

Q: What happens about Project Monterey, because that conflicts with the AI-64 Linux, 64-bit Linux?
Love: OK. I don't -- if we do our job right in making Linux scale over like UnixWare to the degree that everybody, that we know we can... May I ask, some people have said, "Well, people have tried this in the past, but they haven't been that successful," may I suggest: we don't have any ulterior motives for not making it successful. Technologically has not been the reason why it hasn't done it before. There's always some other motive, right? And so to talk about Monterey, clearly we want to make sure we have the same level of Linux integration on Monterey that we would have in our Unixware product. Now, we don't control, I mean, we have a great relationship... it's a joint development relationship with IBM which we intend to preserve ... but they have similar interests and so this is really a very synergistic, uh, this transaction is great for all of the major partners as they have already wanted to embrace Linux moving forward.
Now, let me address one other aspect of your question, which is that the Monterey Project is in conflict with the IA-64 Linux Project. I don't believe it's in conflict at all. Now, clearly, we have tremendous vested interest in the IA-64 Linux Project and with the acquisition of SCO, they've been doing a lot, so you combine those, and we've got one of the more comprehensive offerings, I believe, on the IA-64 Linux. So that's clearly an area that we're very committed to. But like Unixware, there's elements of the Monterey kernel that are more scalable, OK? Now, on the IA-64 platform, I don't know how long of window that is, but today, it's a little bit more robust and more scalable than the IA-64 Linux is today. Now, I'm not saying that over time that won't change.
But, and let me address one other thing. Sorry, (laughs) you're getting all of it through one question. But clearly we are going to add components back to the Linux kernel on both IA-32 and IA-64 platforms. We'll work with Linus and everyone in order to make that available. That will take some time. And as I mentioned earlier, I don't know that over time you can have a single kernel -- in fact I know you can't -- that will scale, you know, the breadth of IT technology needs. So I think we're looking, in the Linux community, at having multiple kernels, so...
Q: Multiple Linux kernels? Or multiple UNIX kernels?
Love: Multiple Linux kernels as well, over time.
Q: Thank you.
Love: You bet.

I am not a lawyer, but even I can see that The SCO Group has put itself into an intractable situation, any judge will listen to evidence from the above and laugh the SCO group out of court.

It's about time to reexamine the recent claims of The SCO group and call in the lawyers and maybe the authorities

Ransom Love's Linuxworld 2000 Keynote Speech by NZheretic · 2003-07-08 09:33 · Score: 4, Interesting · on Linux vs. SCO: The Decision Matrix

The SCO group, and both Old SCO and Caldera before it, directly acknowledged and assisted IBM with the scalablity of Linux

In August 2000, just days after Caldera purchased the Old SCO server division, the then CEO of Caldera, Ransom Love, made a keynote speech at LinuxWorld 2000. A RealPlayer video stream of the event can be found at DrDobbs Journal's Technetcast

In the question and answer session at the end of the keynote, Love was asked about the possible conflict over Monterey and Linux AI-64

A mp3 capture of the following transcribed portion

Q: What happens about Project Monterey, because that conflicts with the IA-64 Linux, 64-bit Linux?
Love: OK. I don't -- if we do our job right in making Linux scale over like UnixWare to the degree that everybody, that we know we can... May I ask, some people have said, "Well, people have tried this in the past, but they haven't been that successful," may I suggest: we don't have any ulterior motives for not making it successful. Technologically has not been the reason why it hasn't done it before. There's always some other motive, right? And so to talk about Monterey, clearly we want to make sure we have the same level of Linux integration on Monterey that we would have in our Unixware product. Now, we don't control, I mean, we have a great relationship... it's a joint development relationship with IBM which we intend to preserve ... but they have similar interests and so this is really a very synergistic, uh, this transaction is great for all of the major partners as they have already wanted to embrace Linux moving forward.
Now, let me address one other aspect of your question, which is that the Monterey Project is in conflict with the IA-64 Linux Project. I don't believe it's in conflict at all. Now, clearly, we have tremendous vested interest in the IA-64 Linux Project and with the acquisition of SCO, they've been doing a lot, so you combine those, and we've got one of the more comprehensive offerings, I believe, on the IA-64 Linux. So that's clearly an area that we're very committed to. But like Unixware, there's elements of the Monterey kernel that are more scalable, OK? Now, on the IA-64 platform, I don't know how long of window that is, but today, it's a little bit more robust and more scalable than the IA-64 Linux is today. Now, I'm not saying that over time that won't change.
But, and let me address one other thing. Sorry, (laughs) you're getting all of it through one question. But clearly we are going to add components back to the Linux kernel on both IA-32 and IA-64 platforms. We'll work with Linus and everyone in order to make that available. That will take some time. And as I mentioned earlier, I don't know that over time you can have a single kernel -- in fact I know you can't -- that will scale, you know, the breadth of IT technology needs. So I think we're looking, in the Linux community, at having multiple kernels, so...
Q: Multiple Linux kernels? Or multiple UNIX kernels?
Love: Multiple Linux kernels as well, over time.
Q: Thank you.
Love: You bet.

SCO has NO effective case against either IBM, HP or anyone else.

Dr. Dobb's by d3a350 · 2003-07-02 03:35 · Score: 2, Informative · on Knowledge by Ear?

Dr. Dobb's has quite a few technical presentations in MP3 format at their TechNetCast site:

http://technetcast.ddj.com/

They've got a pretty good set of presenters and topics. I've only listened to a couple, but I like what I've heard so far.

Re:Uncontrollable kneejerk reaction by TitanBL · 2003-06-14 12:09 · Score: 1, Flamebait · on Microsoft Kills Off Mac IE, Blames Safari

"Hate to break it to you, but only the part that is open source, is what they stole from open source community...and if you knew anything about programming, you would know that it takes more than just source from the UNIX portion to write software."

Oh, I see... You know little or nothing about OS X... Please take some time to learn what you are talking about as to not seem like a jackass in the future. Darwin was not stolen... It is still open source with concurrent x86 builds. Cocoa is an amazing API. Project Builder is pretty nice as well. Does Microsoft provide developers with this? Sure they do, right? Is Microsoft's Windows Media Server open source; and will it run on Linux, Solaris and Windows NT/2000 - hmmm...

MSDN.com just gives you the info you need when you need it right? "Cut and Dry - it is not bloated at all. ;-)

"I work in the radio field, and the only decent application that runs on Mac is Protools. Everything else we use is PC only"

Ah, Radio... what a cutting edge field... I hear that is where things are headed - FM. Ha. Developers are all over it.

Protools is nice, but I am sure you have heard of Logicand Cubase right? BTW, no more Logic for pc - mac bought Emagic.

Radio Automation software - you mean a digital media player with an integrated database? (a few open source apps that cover this)

News Delivery Software.... You mean a newswire?

Satellite Control Software - well - you sure that WIN32 is the only platform supported?

All these apps that you claim are not being written for mac - where are they? You use WIN32 applications at the 'radio station' - woohoo. Your point?

Why isn't Microsoft getting any of these or these? When is the last time that Microsoft invented something as influential as Firewire? Where are these apps you speak of?

Yes, please go on - moron.

Re:useless by reynaert · 2003-06-11 04:07 · Score: 4, Informative · on Why Java Won't Have Macros

No, in Lisp macro's aren't used for inline functions , but for syntax extensions. For a demonstration of what real macros can do, look at The Swine Before Perl. That presentation shows how easy it is to implement special syntax for automatons in Scheme, and how natural & simple the result looks.

The AARD code story is immortal. by vegetablespork · 2003-05-21 09:45 · Score: 5, Informative · on Caldera vs. Microsoft Court Documents To Be Shredded

And available here.

Mentally Contaminated by CyberGarp · 2003-05-15 03:35 · Score: 2, Interesting · on SCO To Show Copied Code

I had the pleasure of seeing a lecture, A History of UNIX and UNIX Licenses, by Peter Salus at Setec recently.

He was a witness in the 1993 lawsuit between UNIX System Laboratories versus BSDI. The prosecution accused him of being Mentally Contaiminated for having viewed both sets of source code. Someone went out an made big red laquer buttons that said this and everyone who had seen source wore one to the trial. The contempt of court argument begins, and since it was a statement made by the prosecutor and not objected to by the court, then the buttons got to stay.

This case has some interesting similarities to the SCO accusations. SCO has much less of a leg to stand on.

I want a mentally contaiminated laquered button. If you've seen source code, then you are mentally contaminated. Maybe it's the start of a movement.

Wouldn't be the first time. by death+to+hanzosan · 2003-05-06 11:04 · Score: 5, Insightful · on Microsoft Sued for Defective Software

Google: AARD:

A Serious Message and the Code That Produced It.

Microsoft included a bug in the Win 3.1 Beta that caused Dr. DOS users to crash.

Unsurprisingly the makers of Dr. DOS lost their jobs, like many other victims of malicious code.

Done Before by Anonymous Coward · 2003-04-30 00:38 · Score: 1, Informative · on Ink Cartridges with Built-In Self-Destruct Dates

DDJ had an article about this sort of thing (I think thats the one, pay-to-read). It was the same thing with a HP 2000C. The biggest problem arose when one was trying to refill a cartridge and, of course, the cartridge would plainly deny it had any ink. Stupid - and low too.

Re:Why is NASA doing this? by WegianWarrior · 2003-04-15 20:26 · Score: 3, Interesting · on NASA Wires Chips With Nanotubes

Faster, smaller, lighter computers are usefull for spacetravel. Just because they sendt a man to the moon with an onboard computer with less calculating power than a cheap pocket calculator and a weight of about 70 lbs (in addition to the 17.5 lbs DSKY) don't means that we should be satisfied with that sort of perfomance in the future.

BTW, more info on the Apollo guidance computer can be found at "One Giant Leap: The Apollo Guidance Computer" for those interested.

Re:Via C3 by stanmann · 2003-04-08 05:33 · Score: 1 · on End of Intel-Pin-Compatible CPUs?

I know ....Replying to myself

Here is Intel's history not very thorough, but complete.

And here is a much more complete rendition from DDJ

Re:CODE MONKEY!!! by Anonymous Coward · 2003-03-30 21:20 · Score: 0 · on Are Programmers Engineers?

I think he's talking about the f00f bug.

http://x86.ddj.com/errata/dec97/f00fbug.htm

Re:Many comments here prove the point by NickFitz · 2003-03-27 13:49 · Score: 1 · on Too Cool For Secure Code?

I can't argue with you, and don't want to. I think, though, that you're talking about writing software you will use; I'm sadly trapped in the hideous world of doing stuff to pay the rent. (Not that there is any stuff to do the moment, but we all have to tighten our belts in wartime ;-)

And, I like the libraries I can get for C++. CPAN's great, but... I genuinely *like* C++.

Love the language that works for you, but as the song says, "If you can't be with the one you love, love the one you're with" :-) I have to say that if there's one language I really like to work in, it's Forth. I've written my own Forth language implementation and development environment before now (for the Atari ST) ; ultimately, when I'm working for my own pleasure, I want the language I like, and the devil take the hindmost. (I haven't had the chance to get paid for it since 1989, but I still solve Countdown's Numbers game on a stack in my head.)

Unfortunately, those people who employ - or fail to employ - consultants like me want stuff to work on their systems, and so I sell my soul. How much work does a Forth specialist get these days, as a regular gig?

Specifically, if we don't have a lot of money (I definitely don't) we can't afford a particularly fast machine. For example, I use a Pentium 167MMX laptop with 96MB of Ram and 4GB of disk at home.

My PC, brushing against my leg as I type, started life as an empty case that I put my dad's old 286 motherboard in; believe me, I know about making do with what you can afford. (FWIW, it's currently a 500MHz AMD I got as the cheapest available from the local computer shop when the second-hand AMD 100MHz went west. Still got a 4Gb drive in it.) I'm thinking about philosophical differences between approaches.

The reason we regarded people who programmed in C with a degree of pity (this was 1987 - 88) was because setting up and breaking down all those stack frames used up valuable cycles. On an 8086, a

mov ax,0

was less efficient than a

sub ax,ax

or (my opcode of choice) a

xor ax,ax

by a couple of cycles. That meant everything when a single byte read from/write to a CGA card's video RAM cost betwen ~20 to ~50 wait states for an 8MHz 8086. That's the level we were working to when I developed my dislike of C; my dislike of later manifestations of C and C++ comes down to reading those ads in Doctor Dobbs Journal saying "Can you tell where the bug is? PC-Lint can!". I should be able to tell where the bug is; I wrote it, for goodness sake!

I just feel that the point in the original article about us programmers being more attracted to cool, tricky stuff than to meeting real-world requirements was right generally, as well as in the context of application security. I have to combat my desire to do cool stuff every day, because I have to do stuff that satisfies my customers' desire for functional, safe stuff. It's boring, but it keeps me off the streets - or, at the moment, fails to.

BTW, I don't actively recommend or discommend Perl; I think Perl is just bizarre. If that's how Larry Wall thinks about programming (see the Camel Book intro), I'm just glad there's room for a lot of opinions in this world :-)

As an aside, can I ask, do you optimize your stuff by dropping into assembler for critical portions of your code? I'd highly recommend it, because in my experience, anybody who appreciates the power available from C or C++ really gets off on assembler. (Sorry if that sounds patronising; don't want to teach my grandmother to suck eggs.)

I don't have anything against any language, and I certainly appreciate your situation as regards processing power

Re:Why Didn't They Ask The Metrics Question? by paranoic · 2003-03-20 05:59 · Score: 2, Informative · on Scott Trappe's Answers About Code Quality

You might want to look at the Jan. issued of Dr. Dobbs, Automated Defect Identification by
by Kevin Smith
They are probably counting lint or other types of compiler warnings.

Re:Oh dear god... by Anonymous Coward · 2003-03-16 13:04 · Score: 0 · on RMS Turns 50

Hmmmmm.

http://technetcast.ddj.com/img/rms-nyu-01-200.jpg

http://media.bonnint.net/ksl/0/22/2238.jpg

Re:Verity Stob by a2800276 · 2003-03-04 21:17 · Score: 2, Interesting · on Aspect-Oriented Programming with AspectJ

Yep, can't believe nobody picked up on that. While Dr. Dobbs has a fair amount of weird ecclectic columns (Swaine, Campervan-jazz-musician-what's-his-name, etc.) Verity Stob is by far the best of them. One of my favourites is the lifecyle of the desktop PC: State of Decay (It's so true.)

Nicely written, informative book review, too, by the way. Hope we see more of her here!

Speaking of weird things to like about Dr. Dobbs, does anyone else look forward to the PC-Lint advert/riddles every month? -- Asking that feels strangely embarassing, similar to asking "Does anyone else ever find that they've been talking to themselves for the last hour with the office door open?" :-)

Verity Stob by Dylan2000 · 2003-03-04 05:15 · Score: 3, Informative · on Aspect-Oriented Programming with AspectJ

is not really a real person but is one of the funniest tech writers out there. She is famous for the history of the microcomputer, and is widely and deeply revered by everybody who's read her

She also did a parody of our own Slashdot, which is absolutely f*cking hilarious.

I strongly recommend anyone who hasn't read any stob to go and check out the archives and then laugh yourself stupid for half an hour.

Verity Stob by Dylan2000 · 2003-03-04 05:15 · Score: 3, Informative · on Aspect-Oriented Programming with AspectJ

is not really a real person but is one of the funniest tech writers out there. She is famous for the history of the microcomputer, and is widely and deeply revered by everybody who's read her

She also did a parody of our own Slashdot, which is absolutely f*cking hilarious.

I strongly recommend anyone who hasn't read any stob to go and check out the archives and then laugh yourself stupid for half an hour.

Verity Stob by Dylan2000 · 2003-03-04 05:15 · Score: 3, Informative · on Aspect-Oriented Programming with AspectJ

is not really a real person but is one of the funniest tech writers out there. She is famous for the history of the microcomputer, and is widely and deeply revered by everybody who's read her

She also did a parody of our own Slashdot, which is absolutely f*cking hilarious.

I strongly recommend anyone who hasn't read any stob to go and check out the archives and then laugh yourself stupid for half an hour.

Re:programming vs scripting by algebraist · 2003-02-25 12:03 · Score: 1 · on Do Scripters Suffer Discrimination?

Dr Dobbs has a section devoted to scripting languages as well as one devoted to lightweight languages.

Re:programming vs scripting by algebraist · 2003-02-25 12:03 · Score: 1 · on Do Scripters Suffer Discrimination?

Dr Dobbs has a section devoted to scripting languages as well as one devoted to lightweight languages.

Re:programming vs scripting by algebraist · 2003-02-25 12:03 · Score: 1 · on Do Scripters Suffer Discrimination?

Dr Dobbs has a section devoted to scripting languages as well as one devoted to lightweight languages.

Re:Why I buy Intel by Loki_1929 · 2003-02-03 16:31 · Score: 1 · on Intel's Itanium 2: Succeed or Fail?

" I buy Intel because their chips and chipsets are rock solid stable, at least compared to other PC chips and chipsets. And for ultimate stability you can even go with an Intel motherboard. Besides stability they are also compatible with a wide range of hardware. You don't have to worry about filling up every DIMM and PCI slot, it will just work."

Amazing how Intel again demonstrates alongside Microsoft that good marketing and a brand name more than makes up for shoddy workmanship. Lets examine the facts, shall we?

Pentium Floating-point division bug (it's close enough, isn't it?)
Invalid Operand Instruction crashes original Pentiums Pentium crash codes
Pentium Pro/II still having problems with floats Unable to convert to int
Pentium III can't even start up You went faster with an 8088
SSE is great for when you want your PIII to crash Pretty blue screens abound.
PIII Xeon, quality you can count on, except at high CPU usage Watch the task manager, Phil.
Yay, PIII MTH crashes! Does MTH stand for Meth?
Total Recall 2: PIII@1.13GHz Fastest crashes ever.
Total Recall 3: PIII Xeons@800/900Mhz More Xeon quality in a box.
Total Recall 4: CC820 How many defects? Can't recall...
Pentium 4 overwriting data Hope it wasn't something important.
Pentium 4 chipset bug Fast video performance? Naaa.
P4 Oracle/Sun problems More workarounds than work
Itanium shipments halted That's an expensive oops.

So, as for your comment about Intel's reliability and and stability, I can't help but laugh. These aren't theoretical problems, these are real-world problems. It will just work? Hardly; the coppermine CPUs often wouldn't even boot, Xeons crashing, chips recalled, chipsets slowing performance, and a history dating at least back to 1994 of Intel - Inept Inside.

Is any CPU perfect? Absolutely not - but don't go glorifying Intel as the pinnacle of stability when it obviously isn't the case.

Xmingwin vs. Visual-MinGW by Lumpish+Scholar · 2003-02-03 08:56 · Score: 2, Interesting · on Xmingwin For Cross Generation Applications

Like a lot of people here, I don't get it the point. Cross compilers are for developing for platforms that can't host development tools. When I did cross platform (Windows, Solaris, HP-UX) development, my tools were Vim and CVS plus the native compiler. Which platform would I edit on? Whichever was most convenient that moment.

On the other hand, for those who want to use MinGW for Windows development, check out the GPL Visual-MinGW. Al Stevens had some very nice things to say about it in the December 2002 issue of Dr. Dobb's. (The article isn't online, but the issue's table of contents is here.)

There are some significant licensing differences between MinGW and Cygwin. The Cygwin runtime is GPL (not LGPL!), but can be licensed for non-open use. The MinGW runtime is public domain.

Way back machine. by Kefaa · 2003-01-31 16:17 · Score: 1 · on Define -- "Software Engineering"

One of the better descriptions or perhaps essay, to the principle of being a software engineer was in an editorial by Charles Connell in Dr. Dobbs several years ago. Why Software Engineering is not BS

Interesting note, while a Systems Engineer for a top two IT company, we were told that they would be renaming the Architects. It appears that some words (Engineer, Architect) have legal meanings in some states. Apparently in some states you cannot call yourself an engineer unless you can prove certification by a standards body.

IANAL, but I would be interested in hearing from one on how that gets resolved.

Kerberos ( was Re:This sounds nice...) by frankie_guasch · 2003-01-29 03:54 · Score: 1 · on iCommune Retools Itself as Standalone Open Source App

kerberos

Embrace, Extend, Extinguish: Three Strikes And You're Out
Microsoft extended Kerberos with undocumented proprietary features in an effort to prevent interoperability

Re:lint is horrible by Interrupting+Cow · 2003-01-22 17:04 · Score: 0 · on Using Redundancies to Find Errors

Wow. I don't know where to start. Do you have any idea what you're talking about? Before you start let me answer, "No".

castind [sic] the return of every void function

Um, void functions don't return anything. A simple return will suffice.

Am i really going to have to step through tens of thousands of lines of code

Yes, if you have crap that is returning something in void functions.

If you want to know some of the things lint can look for that are perfectly legal code constructs look at this list.

Compiling is not the same as error analysis.

zerg by Lord+Omlette · 2003-01-18 06:50 · Score: 1 · on SVG On the Rise

I can't find it on their website, but according to an email I got, the March '03 issue of Dr. Dobbs Journal is supposed to have an article on SVG if any of you are not content to read about it online.

Re:Big deal by merger · 2003-01-17 07:35 · Score: 1 · on Scaling Server Performance

Last average I heard for google was around 10,000 low cost servers. Therefore it isn't that big of deal if 100 or so servers go down. There is a really good .mp3 interview with Jim Reese, the Chief Operations Engineer available. It may be a little old but still a good listen.

Re:VB has one of those debuggers by dubl-u · 2003-01-08 08:25 · Score: 5, Insightful · on How Would You Improve Today's Debugging Tools?

Now, the problem begins when this little program grows. If you try to write big apps with VB you'll fairly soon start hitting its limitations, writing workarounds, having to put up with completely idiotic bugs like project files that break by themselves... and you end with a complete piece of crap.

Amen. If people knew that whenever they needed write a program longer than a page that they should switch away from VB, I'd have no complaints with it. Instead, it is marketed in such a way that it gives amateurs the notion that they're just as good as any professional programmer. It's as if people thought that buying a Tinkertoy kit made them able to build houses.

I don't know how many projects I've seen where someone has knocked together a prototype in some half-baked language like VB. Then people want another feature and another, and nobody is willing to say: "Stop! We must throw this crap out and start again using appropriate tools."

(For the record, I hear that VB.NET is a big improvement over the execrable VB6. Of course, given that all .NET languages seem to be minor syntax variations on Java, maybe that's not too surprising.)

Re:That's ludicrous by vrmlguy · 2002-12-24 07:09 · Score: 2 · on Microsoft Ordered to Carry Java

In every case I can think of where Microsoft took over a competitors marketshare it has been because the MS product line kept improving over time, whereas the competitor released a really crappy major upgrade.

I note that you don't mention DR-DOS, which predates all of your other examples.

Microsoft wasn't always a wealthy company, they became that way for a reason. Because they were willing to try things, and they were willing to risk failure. That, my friend, is how you succeed in this world!

I agree. Microsoft tried "unconventional" techniques to compete with DR-DOS, and were willing to risk failure (i.e. the court system). And thus they become a wealthy company.

For those who don't want to read the article that I referenced about, let me quote a passage near the end:

Suppose that company A manufactures a product system with two components, A1 and A2, each sold separately. Company A has monopoly power over A1, but company B competes in the market for the second component with its compatible offering, B2. Thus, consumers initially can use a product system comprised of either A1 and A2 or A1 and B2. Company A now introduces a new product system, A1' and A2', which serves roughly the same function for consumers as the old product system. Component B2, however, is incompatible with A1'. Furthermore, company A discontinues the sale of A1 or else reprices A1 substantially higher than before. As a consequence, consumers switch to the new product system and company B is driven from the market for component two.
When, if ever, should the antitrust laws sanction company A for driving B out of the market?

I would be interested in hearing your answer to that question.

You are wrong - Re:Popular science by MobyDisk · 2002-12-01 15:34 · Score: 5, Informative · on Molecular Photography

...the peculiarities that make quantum computing interesting...also make it completely inappropriate for mundane tasks. So please stop the "google in a cube" shit.

You are incorrect. Classical computers can search an indexed database in log(n) time. Grover's algorithm allows quantum searches to be much faster, perhaps even in constant time. Search engines could benefit immensely from quantum computing.

Lots of information can be found on Lov Grover's quantum search algorithm. Do a search for it on Google. Dr. Dobb's even analyzed the quantum source code for the algorithm. Pretty cool stuff.

Re:p2p isn't going away. it isn't even slowing dow by burns210 · 2002-11-29 21:29 · Score: 2, Interesting · on Cringely on P2P

This project looks interesting. I will have to read up on it more. So, for those interested, here are a couple links you might want to check out.

Basicly, this system can scale to sizes of current p2p systems and far beyond. The system would would be able to "detect bad nodes quickly, and it would incorporate enough redundancy into the system to recover gracefully from tampering."

Re:Say what you want.... by AndroidCat · 2002-11-24 12:48 · Score: 2 · on MS-DOS 1981-2002 RIP

They did morph MS SQL Server from Sybase. (I have no idea of what deals went down on that.) Damn, they bought their C compiler too, name escapes me.

They also spent at least a million$ to "buy" Anders Hejlsberg to develop C# and .NET stuff from Borland, plus whatever they settled with Borland.

You can do these things with a magical ingreediant, cash, lots of cash.

Doyle article from 1996 DDJ by marhar · 2002-11-09 06:24 · Score: 3, Informative · on Could Eolas End Microsoft's Browser Dominance?

Michale Doyle wrote a manifesto of sorts about this in 1996:

http://www.ddj.com/articles/1996/9602/

When good interfaces go crufty by Anonymous Coward · 2002-11-07 22:41 · Score: 3, Interesting · on When Good Interfaces Go Crufty

In Vernor Vinges sci-fi novel A fire upon the deep, he presents the idea of software archeology. Vinges future has software engineers spending large amounts of time digging through layers of decades-old code in a computer system like layers of dirt and rubbish in real-world archeology to find out how, or why, something works.

So far, in 2002, this problem isnt so bad. We call such electronic garbage cruft, and promise to get rid of it someday. But its not really important right now, we tell ourselves, because computers keep getting faster, and we havent quite got to the point where single programs are too large for highly coordinated teams to understand.

But what if cruft makes its way into the human-computer interface? Then you have problems, because human brains arent getting noticably faster. (At least, not in the time period were concerned with here.) So the more cruft there is in an interface, the more difficult it will be to use.

Unfortunately, over the past 20 years, Ive noticed that cruft has been appearing in computer interfaces. And few people are trying to fix it. I see two main reasons for this.

Microsoft and Apple dont want to make their users go through any retraining, at all, for fear of losing market share. So rather than make their interfaces less crufty, they concentrate on making everything look pretty.
Free Software developers have the ability to start from a relatively cruft-free base, but (as a gratuitously broad generalization) they have no imagination whatsoever. So rather than making their interfaces more usable, they concentrate on copying whatever Microsoft and Apple are doing, cruft and all.

Here are a few examples of interface cruft.

In the 1970s and early 80s, transferring documents from a computers memory to permanent storage (such as a floppy disk) was slow. It took many seconds, and you had to wait for the transfer to finish before you could continue your work. So, to avoid disrupting typists, software designers made this transfer a manual task. Every few minutes, you would save your work to permanent storage by entering a particular command.

Trouble is, since the earliest days of personal computers, people have been forgetting to do this, because its not natural. They dont have to save when using a pencil, or a pen, or a paintbrush, or a typewriter, so they forget to save when theyre using a computer. So, when something bad happens, theyve often gone too long without saving, and they lose their work.

Fortunately, technology has improved since the 1970s. We have the power, in todays computers, to pick a sensible name for a document, and to save it to a persons desktop as soon as she begins typing, just like a piece of paper in real life. We also have the ability to save changes to that document every couple of minutes (or, perhaps, every paragraph) without any user intervention.

We have the technology. So why do we still make people save each of their documents, at least once, manually? Cruft.
The original Macintosh, which introduced graphical interfaces to the general public, could only run one program at a time. If you wanted to use a second program, or even return to the file manager, the first program needed to be unloaded first. To make things worse, launching programs was slow, often taking tens of seconds.

This presented a problem. What if you had one document open in a program, and you closed that document before opening another one? If the program unloaded itself as soon as the first document was closed, the program would need to be loaded again to open the second document, and that would take too long. But if the program didnt unload itself, you couldnt launch any other program.

So, the Macs designers made unloading a program a manual operation. If you wanted to load a second program, or go back to the file manager, you first chose a menu item called Quit to unload the first program. And if you closed all the windows in a program, it didnt unload by itself it stayed running, usually displaying nothing more than a menu bar, just in case you wanted to open another document in the same program.

Trouble is, the Quit command has always been annoying and confusing people, because its exposing an implementation detail the lack of multitasking in the operating system. It annoys people, because occasionally they choose Quit by accident, losing their careful arrangement of windows, documents, toolboxes, and the like with an instantaneity which is totally disproportionate to how difficult it was to open and arrange them all in the first place. And it confuses people, because a program can be running without any windows being open, so while all open windows may belong to the file manager, which is now always running in the background menus and keyboard shortcuts get sent to the invisible program instead, producing unexpected behavior.

Fortunately, technology has improved since 1984. We have the power, in todays computers, to run more than one program at once, and to load programs in less than five seconds.

We have the technology. So why do we still punish people by including Quit or Exit menu items in programs? Cruft.
As I said, the original Macintosh could only run one program at a time. If you wanted to use a second program, or even return to the file manager, the first program needed to be unloaded first.

This presented a problem when opening or saving files. The obvious way to open a document is to launch it (or drag it) from the file manager. And the obvious way to save a document in a particular folder is to drag it to that folder in the file manager. But on the Mac, if another program was already running, you couldnt get to the file manager. What to do? What to do?

So, the Macs designers invented something called a file selection dialog, or filepicker a lobotomized file manager, for opening and saving documents when the main file manager wasnt running. If you wanted to open a document, you chose an Open menu item, and navigated your way through the filepicker to the document you wanted. Similarly, if you wanted to save a document, you chose a Save menu item, entered a name for the document, and navigated your way through the filepicker to the folder you wanted.

Trouble is, this interface has always been awkward to use, because its not consistent with the file manager. If youre in the file manager and you want to make a new folder, you do it one way; if youre in a filepicker and you want to make a new folder, you do it another way. In the file manager, opening two folders in separate windows is easy; in a filepicker, it cant be done.

Fortunately, technology has improved since 1984. We have the power, in todays computers, to run more than one program at once, and to run the file manager all the time. We can open documents from the file manager without quitting all other programs first, and we can save copies of documents (if necessary) by dragging them into folders in the file manager.

We have the technology. So why do we still make people use filepickers at all? Cruft.
This last example is particularly nasty, because it shows how interface cruft can be piled up, layer upon layer.
1. In Microsofts MS-DOS operating system, the canonical way of identifying a file was by its pathname: the concatenation of the drive name, the hierarchy of directories, and the filename, something like C:\WINDOWS\SYSTEM\CTL3DV2.DLL. If a program wanted to keep track of a file in a menu of recently-opened documents, for example it used the files pathname. For backward compatibility with MS-DOS, all Microsofts later operating systems, right up to Windows XP, do the same thing.
  
  Trouble is, this system causes a plethora of usability problems in Windows, because filenames are used by humans.
2. What if a human renames a document in the file manager, and later on tries to open it from that menu of recently-opened documents? He gets an error message complaining that the file could not be found.
3. What if he makes a shortcut to a file, moves the original file, and then tries to open the shortcut? He gets an error message, as Windows scurries to find a file which looks vaguely similar to the one the shortcut was supposed to be pointing at.
4. What happens if he opens a file in a word processor, then renames it to a more sensible name in the file manager, and then saves it (automatically or otherwise) in the word processor? He gets another copy of the file with the old name, which he didnt want.
5. What happens if a program installs itself in the wrong place, and our fearless human moves it to the right place? If hes lucky, the program will still work but hell get a steady trickle of error messages, the next time he launches each of the shortcuts to that program, and the next time he opens any document associated with the program.
6. Fortunately, technology has improved since 1981. We have the power, in todays computers, to use filesystems which store a unique identifier for every file, separate from the pathname such as the file ID in the HFS and HFS+ filesystems, or the inode in most filesystems used with Linux and Unix. In these filesystems, shortcuts and other references to particular files can keep track of these unchanging identifiers, rather than the pathname, so none of those errors will ever happen.
  
  We have the technology. So why does Windows still suffer from all these problems? Cruft.
  
  Lest it seem like Im picking on Microsoft, Windows is not the worst offender here. GNU/Linux applications are arguably worse, because they could be avoiding all these problems (by using inodes), but their programmers so far have been too lazy. At least Windows programmers have an excuse.
7. To see how the next bit of cruft follows from the previous one, we need to look at the mechanics of dragging and dropping. On the Macintosh, when you drag a file from one folder to another, what happens is fairly predictable.
8. If the source and the destination are on different storage devices, the item will be copied.
9. If the source and destination are on the same storage device, the item will be moved.
10. If you want the item to be copied rather than moved in the latter case, you hold down the Option key.
11. Windows has a similar scheme, for most kinds of files. But as Ive just explained, if you move a program in Windows, every shortcut to that program (and perhaps the program itself) will stop working. So as a workaround for that problem, when you drag a program from one place to another in Windows, Windows makes a shortcut to it instead of moving it and lands in the Interface Hall of Shame as a result.
  
  Naturally, this inconsistency makes people rather confused about exactly what will happen when they drag an item from one place to another. So, rather than fixing the root problem which led to the workaround, Microsoft invented a workaround to the workaround. If you drag an item with the right mouse button, when you drop it youll get a menu of possible actions: move, copy, make a shortcut, or cancel. That way, by spending a couple of extra seconds choosing a menu item, you can be sure of what is going to happen. Unfortunately this earns Microsoft another citation in the Interface Hall of Shame for inventing the right-click-drag, perhaps the least intuitive operation ever conceived in interface design. Say it with me: Cruft.
12. It gets worse. Dragging a file with the right mouse button does that fancy what-do-you-want-to-do-now-menu thing. But normally, when you click the right mouse button on something, you want a shortcut menu a menu of common actions to perform on that item. But if pressing the right mouse button might mean the user is dragging a file, it might not mean you want a shortcut menu. What to do, what to do?
  So, Windows designers made a slight tweak to the way shortcut menus work. Instead of making them open when the right mouse button goes down, they made them open when the right mouse button comes up. That way, they can tell the difference between a right-click-drag (where the mouse moves) and a right-click-I-want-a-shortcut-menu (where it doesnt).
  
  Trouble is, that makes the behavior of shortcut menus so much worse that they end up being pretty useless as an alternative to the main menus.
13. They take nearly twice as long to use, since you need to release the mouse button before you can see the menu, and click and release a second time to select an item.
14. Theyre inconsistent with every other kind of menu in Windows, which opens as soon as you push down on the mouse button.
15. Once youve pushed the right mouse button down on something which has a menu, there is no way you can get rid of the menu without releasing, clicking the other mouse button, and releasing again. This breaks the basic GUI rule that you can cancel out of something youve pushed down on by dragging away from it, and it slows you down still further.
16. In short, Windows native shortcut menus are so horrible to use that application developers would be best advised to implement their own shortcut menus which can be used with a single click, and avoid the native shortcut menus completely. Once more, with feeling: Cruft.
17. Meanwhile, we still have the problem that programs on Windows cant be moved around after installation, otherwise things are likely to break. Trouble is, this makes it rather difficult for people to find the programs they want. In theory you can find programs by drilling down into the Program Files folder, but theyre arranged rather uselessly (by vendor, rather than by subject) and if you try to rearrange them for quick access, stuff will break.
  
  So, Windows designers invented something called the Start menu, which contained a Programs submenu for providing access to programs. Instead of containing a few frequently-used programs (like Mac OSs Apple menu did, before OS X), this Programs submenu has the weighty responsibility of providing access to all the useful programs present on the computer.
  
  Naturally, the only practical way of doing this is by using multiple levels of submenus thereby breaking Microsofts own guidelines about how deep submenus should be.
  
  And naturally, rearranging items in this menu is a little bit less obvious than moving around the programs themselves. So, in Windows 98 and later, Microsoft lets you drag and drop items in the menu itself thereby again breaking the general guideline about being able to cancel a click action by dragging away from it.
  
  This Programs menu is the ultimate in cruft. It is an entire system for categorizing programs, on top of a Windows filesystem hierarchy which theoretically exists for exactly the same purpose. Gnome and KDE, on top of a Unix filesystem hierarchy which is even more obtuse than that of Windows, naturally copy this cruft with with great enthusiasm.

Following those examples, its necessary to make two disclaimers.

Firstly, if youve used computers for more than six months, and become dulled to the pain, you may well be objecting to one or another of the examples. Hey!, youre saying. Thats not cruft, its useful! And, no doubt, for you that is true. In human-computer interfaces, as in real life, horrible things often have minor benefits to some people. These people manage to avoid, work around, or blame on user stupidity, the large inconvenience which the cruft imposes on the majority of people.

Secondly, there are some software designers who have waged war against cruft. Word Places Yeah Write word processor abolished the need for saving documents. Microsofts Internet Explorer for Windows, while having many interface flaws, sensibly abolished the Exit menu item. The Acorns RISC OS abolished filepickers. The Mac OS uses file IDs to refer to files, avoiding all the problems I described with moving or renaming. And the ROX Desktop eschews the idea of a Start menu, in favor of using the filesystem itself to categorize programs.

However, for the most part, this effort has been piecemeal and on the fringe. So far, there has not been a mainstream computing platform which has seriously attacked the cruft that graphical interfaces have been dragging around since the early 1980s.

So far.

Discuss

Re:Vaporware tactics have worked often. by Anonymous Coward · 2002-11-05 09:57 · Score: 0 · on Microsoft takes on PDF

The story I heard was ... If that's true then MS had every reason to do that. ...

Well Mr. Microsoft appologist, You heard wrong.

Internal Microsoft memos were released containing email conversations among Microsoft executives in 1991 and 1992 that discuss deliberately crippling a beta copy of Windows 3.1 so it would produce an obscure error message if run atop DR-DOS. The code to check for the existence of DR-DOS was encrypted and obfuscated -- it was the only encrypted code in the beta

If you're unsure of their intentions in doing such a thing, here's a quote from email sent by Microsoft Senior VP Brad Silverberg in 1992:

"What the guy is supposed to do is feel uncomfortable and, when he has bugs, suspect the problem is DR-DOS and then go out to buy MS-DOS, or decide not to take the risk for the other machines he has to buy for in the office."

The obfuscated code searched for tiny cosmetic code differences between MS-DOS and DR-DOS, and when it found the latter it displayed an obscure but worrying error message: "Non-fatal error detected: Error #4D53. (Please contact Windows 3.1 Beta Support.)" The non-MS-detecting code was dropped into 5 places in the beta Win 3.1 code and, had no possible legitimate purpose in ensuring the proper functioning of Windows. The code was still present in three places in the shipping Win 3.1 product, but had a single byte flipped to disable it. Interestingly, any program running on the shipping version of Windows could change this one system bit at anytime to cause these errors to return.

For a detailed technical analysis look here

Another article can be found here (subscription required)

Not a new idea by signal+ll · 2002-10-23 03:41 · Score: 2, Interesting · on Built-in Kitchen Computer?

This is not exactly a new idea. There have been kitchen computers before, but they didn't really catch on. Look here

TNC by kxr · 2002-10-09 23:08 · Score: 5, Informative · on Educational Courses in Digital Format?

Not sure if this is the kind of thing you're after, but there's loads of really good stuff on TechNetCast. I just got myself an MP3 car-stereo, and plan to grab all the talks I haven't gotten around to listening to, so that I can listen to them in the car.

Design, Development, Deployment "load marks" by NZheretic · 2002-10-04 01:12 · Score: 5, Interesting · on Red Hat & Dell Host Open Source Security Summit

From the Plimsoll Club history

Samuel Plimsoll, M.P.
(1824-1898)
Samuel Plimsoll brought about one of the greatest shipping revolutions ever known by shocking the British nation into making reforms which have saved the lives of countless seamen. By the mid-1800's, the overloading of English ships had become a national problem. Plimsoll took up as a crusade the plan of James Hall to require that vessels bear a load line marking indicating when they were overloaded, hence ensuring the safety of crew and cargo. His violent speeches aroused the House of Commons; his book, Our Seamen, shocked the people at large into clamorous indignation. His book also earned him the hatred of many shipowners who set in train a series of legal battles against Plimsoll. Through this adversity and personal loss, Plimsoll clung doggedly to his facts. He fought to the point of utter exhaustion until finally, in 1876, Parliament was forced to pass the Unseaworthy Ships Bill into law, requiring that vessels bear the load line freeboard marking. It was soon known as the "Plimsoll Mark" and was eventually adopted by all maritime nations of the world.

The risks,issues and solutions for providing a more secure operating and application enviroment have been known for decades. Those who do not already comprehend the issues and are willing to learn, should take some time out to listen to some of the speeches at Dr. Dobbs Journal's Technetcast security archives, starting with Meeting Future Security Challenges by Dr. Blaine Burnam, Director, Georgia Tech Information Security Center (GTISC) and previously with the National Security Agency (NSA)

The "security rules" for Unix based system and application development are well known, although not widely taught. See Secure Programming for Linux and Unix by David Wheeler. Although Microsoft's NT,2000 and XP are not Unix based, a lot of the core above "rules" apply or have direct or indirect equivalents

Because some developers ignore similar above rules, the design and implementation of some applications and servers are just too unsafe to use in the "open ocean" of the internet.

Numerous security experts have railed against Microsoft's lack of security, best summed up by Bruce Schneier Founder and CTO Counterpane Internet Security, Inc who rightly stated ...

Honestly, security experts don't pick on Microsoft because we have some fundamental dislike for the company. Indeed, Microsoft's poor products are one of the reasons we're in business. We pick on them because they've done more to harm Internet security than anyone else, because they repeatedly lie to the public about their products' security, and because they do everything they can to convince people that the problems lie anywhere but inside Microsoft. Microsoft treats security vulnerabilities as public relations problems. Until that changes, expect more of this kind of nonsense from Microsoft and its products. (Note to Gartner: The vulnerabilities will come, a couple of them a week, for years and years...until people stop looking for them. Waiting six months isn't going to make this OS safer.)

However Microsoft's products are not alone in the presence of vulnerabilities, this is a major issue for Linux/BSD and Unix as well as any other OS and vendor.

In a recent speech Fixing Network Security by Hacking the Business Climate Bruce Schneier claimed that for change to occur, the software industry must become libel for damages from "unsecure" software, however historically, this has not always been the case, since most businesses can insure against damages and pass the cost along to the consumer.

The Ford Pinto and more recently the Ford Explorer's tires are two examples of public and media pressure being more successful than just threat of lawsuits. Even so, eventually though public pressure the governments around the world have to step in and pass regulations that set up a minimum set of requirements an automobile has to meet to be deemed "road worthy". This includes crash testing as well as the inclusion of safety equipment on all models. The requirement are not constant and change to meet the expectations and demands of the public and lawmakers.

The onus is not only on the automotive industry itself but also on the users. Most countries require that all automobiles undergo regular inspection and maintain an up to date "Warrant of Fitness".

In the same way, if you want a secure IT infrastructure, eventually the software design, implementation and each deployment will have to undergo the same type of regulation and scrutiny.

For paid software distributions, this could mean just a tick list of security features and security tests to the other extreme of requiring the source code to be fully audited for government/secure deployments.

For users, this would require running a program that checks to make sure that all the required software security update/patches have been installed to the other extreme of requiring an audited deployment for government/secure deployments.

Users and vendors should be taking a more active approach, including lobbying government, to
1) set up a minimum set of expectations, in the design and implementation of internet "accessing" software ; and
2) ensure that all deployments are more securely implemented ; and/or
3) remove inherently unsecure products from the marketplace.

IMO the above three are preferable to all software vendors, including Microsoft, than attempts to allow liability lawsuits against vendors for deployments which the software vendors have very little control over.