Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
ESR: Fix your security, Microsoft!

By Signal 11 in MLP
Mon Oct 22, 2001 at 10:40:34 AM EST
Tags: News (all tags)
News

Newsforge has a short piece by Eric S. Raymond deriding Microsoft's request that people stop publishing exploits and vulnerability reports.


Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o short piece
o Eric S. Raymond
o Also by Signal 11


Display: Sort:
ESR: Fix your security, Microsoft! | 49 comments (24 topical, 25 editorial, 0 hidden)
Missing the Point (3.37 / 8) (#3)
by MrAcheson on Sat Oct 20, 2001 at 05:20:52 PM EST

ESR is once again missing the point. It is a bad idea to publish chapter and verse security holes to the general public. It is an even stupider thing to do in the case of closed source software.

Why? Well in the case of an OS program, the hole may be patched by the general public. Its not likely to be the case mind you, most security patches still come from a relatively small group of developers, but it could theoretically happen. In the case of closed source software, it is impossible for the general public to fix the problem. They should be told there is a problem certainly and be made aware of who may be in trouble, but the specifics of how to perform the exploit is not something the public needs to know or should be told in most cases. The only people such a disclosure can possibly help are the black hats.

As for the MS bashing, I really don't know enough about the nature of these IIS exploits to critique him. If it something similar to the stupidity of MS outlook, then yes microsoft deserves some blame. If not then not. No program is completely secure.


These opinions do not represent those of the US Army, DoD, or US Government.


Look into the MS bashing (4.00 / 5) (#12)
by roystgnr on Sat Oct 20, 2001 at 06:38:20 PM EST

If you are under the impression that your proprietary software vendor is "here to help", and will leap to your rescue with no expectation of future revenue in return, you're too often wrong.

I've discussed Microsoft's past behavior here before, in particular. Suffice it to say that they've improved quite a bit in the past 5 years; a company that used to go 6 months with remote DoS attacks in their most popular products now generally manages to make patches available within weeks of a security hole's discovery. Perhaps they've had a change of heart and discovered a renewed commitment to quality in that time... but I think it's more likely that they're just sick of being publicly embarrassed. So, if you discover a Microsoft bug, and you want it fixed, the best way to get that accomplished is to prove to them that not fixing it will be embarrassing. I remember a couple (I think at least one from EEyes) security hole discoveries that were first made public with a disclaimer along the lines of "we notified Microsoft about this a month ago; now they're not returning our calls."

"'That vulnerability is entirely theoretical.'-- Microsoft;
L0pht, making the theoretical practical since 1992."


[ Parent ]

Re: Missing the Point (5.00 / 1) (#41)
by b1t r0t on Mon Oct 22, 2001 at 08:36:31 AM EST

The only people such a disclosure can possibly help are the black hats.

Not true. It also helps the white hats working on intrusion detection software (not to be confused with virus detection). This is the software that looks for script kiddies and worse trying to get into your systems intentionally, rather than just a mindless virus. Unfortunately, Microsoft has been bad about giving even the IDS people enough information to identify many of these exploits in action.

-- Indymedia: the fanfiction.net of journalism.
[ Parent ]

Poorly reasoned rhetoric from ESR (3.90 / 10) (#18)
by Carnage4Life on Sat Oct 20, 2001 at 09:13:51 PM EST

When I clicked on the link I expected to see the same rhetoric I'd read on Slashdot and agree with but instead was treated to a poorly reasoned, propaganda piece that had little grounding in fact and instead was just an excuse to bash MSFT. Here are my opinions on various parts of the article:
Culp's rant is a transparently self-serving and dishonest attempt to shift the onus for epidemics like Code Red, Lion, and NIMDA away from where it belongs, which is squarely on Microsoft's shoddy architecture and negligent engineering.
Even the most partisan people will agree that a lot of the blame for the widespread nature of these worms is the fact that admins didn't patch their boxes.

That said, MSFT deserves blame for having buffer overflows in software in the year 2001 when people have known how to prevent them for over 20 years.

Culp is certainly right that no software will ever be perfectly secure -- but we know it's possible to do a great deal better, before and after the fact, than either Microsoft's operating-system design group or Mr. Culp's bumbling bunch of Keystone Kops has ever managed.
What exactly do the IIS holes have to do with Operating Systems design? Does he think IIS is written by the Windows team?
Open-source developers are not frightened of what Culp calls "information anarchy". That's because we have confidence (a confidence justified by the track record of Linux, the BSD operating systems, and Apache) that our security holes will be infrequent, the compromises they cause will be relatively minor, and fixes will be rapidly developed and deployed.
Bullshit. BSD and Apache have relatively infrequent security holes but to claim that Linux lacks security holes or that they are relatively minor is gross misrepresentation at best and an outright lie at worst.

Cryptographers and security experts have known for years that peer review of open source code is the only reliable way to verify the effectiveness of encryption systems and other security software.
Wrong. The only reliable way to verify the effectiveness of encryption or other security software is via formal proofs using rigorous Mathematical methods. Everything else is hand waving. It is partcularly amusing that he thinks that peer review can only occur if the product is Open Source. This is incorrect. For instance, a closed source product that is reviewed by an internal research department, a number of seperate development teams and college professors from top notch CS departments under NDA will be more effectively peer reviewed than a random project on SourceForge where the most the developer has done to get it peer reviewed is to link it in his Slashdot signature.
So Microsoft's closed-source mode of development guarantees that customers will continue getting cracked and Microsoft will continue pointing the finger of blame everywhere except where it actually belongs. (In Microsoft-speak, this sort of thing is called `innovation'.)
Again, with the quips that closed source and security are anathema while Open Source is the ONE TRUE WAY. If this is the case, how come the platforms with the least amount of known exploits versus the number of users are closed source? Specifically I mention MacOS and HP-UX.
Here's what I have to say to Mr. Culp: "If you can't stand the heat, get out of the kitchen. And if your OS can't stand an environment where attack tools are instantly disseminated, you don't belong in the operating-system business."
OK, it's the end of the article and he hasn't mentioned how IIS and Outlook worms are an OS problem. Yet, people wonder why it is difficult to take Open Source advocates seriously. Well it's because some of their spokespeople sometimes make comments full of rhetoric that belie their ignorance and are rather illogical but full of venomous yet irrational hostility.

Carnage4Life voted -1 on this story

But (4.00 / 3) (#21)
by dvNull on Sun Oct 21, 2001 at 01:22:13 AM EST

"Even the most partisan people will agree that a lot of the blame for the widespread nature of these worms is the fact that admins didn't patch their boxes. "

Okay I'll bite. NOw how about if no flaw information was made public? Do you think that Microsoft would have had a patch up on their in that period of time? Do you think that admins would have known about the hole so they could have tried to prevent it ?

Its when a flaw is made public that people who want to know when there are security holes can at the very least bug the vendor about it. If noone knows then only the people with malicious intent will know and they will make full use of that knowledge.

Even with the flaw published, Microsoft hasnt been very speedy with their patches and quite a few of the times the patches themselves open up another hole.




If you can see this, then the .sig fell off.
[ Parent ]
Not defending MSFT but... (4.00 / 2) (#22)
by Carnage4Life on Sun Oct 21, 2001 at 02:54:58 AM EST

...the issue isn't whether security flaws should be made public but if they should be made public with exploit code as well. There are two sides to this argument (probably more but there are two main sides).

On one side are the people who feel that from past experience companies are slow to fix security holes that don't include exploit code because they call the holes theoretical.

On the other hand are people that feel that including exploit code allows all the 5CR1p7 K1DDI3Z to crack vulnerable boxes before the patch can be developed or universally applied.

My opinions on whether reports on security vulnerabilities should include exploit code are ambivalent since I empathize with both sides of the argument. I guess I'd advocate including exploit code only after the company has been slow to fix the patch after being given a reasonable time frame.

[ Parent ]
Kernel (3.00 / 2) (#25)
by Robert S Gormley on Sun Oct 21, 2001 at 04:00:33 AM EST

IIS has several hooks into the OS kernel... Which is I think what ESR is saying

[ Parent ]
Thanks for the anti-Open rhetoric (3.60 / 5) (#32)
by regeya on Sun Oct 21, 2001 at 02:37:25 PM EST

regeya almost rated Carnage4life's comment at 1, but decided to reply instead

Bullshit. BSD and Apache have relatively infrequent security holes but to claim that Linux lacks security holes or that they are relatively minor is gross misrepresentation at best and an outright lie at worst.

Blame this one on ESR's blatantly vague, ambiguous drivel. IMHO I think he meant that Linux bugs are exposed to the public, rather than being made secret unless the bug is severe. Unlike, say, OpenBSD, where local 'sploits are often fixed in the CVS tree without so much as a confirmation.

Wrong. The only reliable way to verify the effectiveness of encryption or other security software is via formal proofs using rigorous Mathematical methods. Everything else is hand waving. It is partcularly amusing that he thinks that peer review can only occur if the product is Open Source. This is incorrect.

Amusing that you're so certain that he's so damned wrong, yet agree with his odd logic to a certain degree:

For instance, a closed source product that is reviewed by an internal research department, a number of seperate development teams and college professors from top notch CS departments under NDA will be more effectively peer reviewed than a random project on SourceForge where the most the developer has done to get it peer reviewed is to link it in his Slashdot signature.

Trollish, inaccurate, but at least you acknowledge what ESR, in his own, odd way, was alluding to: peer review. I suppose the recent local 'sploit discovered in the Linux kernel was discovered due to someone's Slashdot sig.

Again, with the quips that closed source and security are anathema while Open Source is the ONE TRUE WAY. If this is the case, how come the platforms with the least amount of known exploits versus the number of users are closed source? Specifically I mention MacOS and HP-UX.

MacOS? Surely you jest.

OK, it's the end of the article and he hasn't mentioned how IIS and Outlook worms are an OS problem. Yet, people wonder why it is difficult to take Open Source advocates seriously. Well it's because some of their spokespeople sometimes make comments full of rhetoric that belie their ignorance and are rather illogical but full of venomous yet irrational hostility.

Surely we've all seen, right here in your comment, a prime example of venomous yet irrational hostility.

Carnage4Life voted -1 on this story

And of course, I could have found that out simply by checking the voting record. Perhaps I should rate your comment at 1 for being redundant.

[ yokelpunk | kuro5hin diary ]
[ Parent ]

Peer Review and other things (5.00 / 2) (#33)
by Carnage4Life on Sun Oct 21, 2001 at 03:02:46 PM EST

Amusing that you're so certain that he's so damned wrong, yet agree with his odd logic to a certain degree:

Anyone involved in cryptography or anyone with a degree in CS will tell you the same thing I did. Post ESR's drivel to sci.crypt and see how many people agree with him versus those that will tell you that only rigorous formal proofs are the way to verify that a piece of encryption software is reliable.

There are other factors as well such that can influence the quality of the code such as code reviews from competent people willing to review it who have the prerequisite background to know what they are looking for, testing, choosing to use a type safe language, and careful design,

None of these is as important as using formal mathematical methods (i.e. rigorous proofs) to guarantee the quality of the software.

Trollish, inaccurate, but at least you acknowledge what ESR, in his own, odd way, was alluding to: peer review. I suppose the recent local 'sploit discovered in the Linux kernel was discovered due to someone's Slashdot sig.

The point is peer review is not limited to Open Source and a proprietary piece of software can be reviewed by more people with more competence than an Open Source project.

This is a fact, if you want to get into a religious argument about it, I'm sorry but I'l have to turn you down this time.

That said, a popular Open Source project is typically more likely to be peer reviewed than most proprietary software, and the Linux kernel is a very good example of this.

[ Parent ]
When I look in my logs I see addresses like... (none / 0) (#46)
by SIGFPE on Mon Oct 22, 2001 at 02:37:38 PM EST

...adsl-xxx-xxx-xxx-xxx.dsl.snfc21.pacbell.net attached to nimda and code red attacks. There's unlikely to be a system administrator looking after these machines. That looks like a dynamically allocated domestic dsl connection to me.
SIGFPE
[ Parent ]
I hate to even sympathise with anything ESR says (3.62 / 8) (#20)
by jd on Sat Oct 20, 2001 at 11:25:41 PM EST

Although I do believe that ESR is so self-centered, I'm amazed that the world hasn't started revolving around his ego, he is still capable of understanding WHAT arguments are important.

And this is one such time.

The argument that closed-source should be immune from disclosure of one type of failure or another is stupid and naive. If Microsoft had claimed that people should not disclose the color of the page showing kernel panics, people would laugh. So what's the big f'ing difference?

The difference is that these specific faults give Microsoft a Bad Name, especially at a time when security is such a Big Issue. That's it.

(Actually, under the Unified Copyright Act, even the publication of the color of the GPF screen would be a Federal Offence.)

However, sticking with sanity for a moment, what is the big deal if someone published the statement that doing X, Y and Z will give you system admin priviliges? Who, seriously, even WANTS access to a Microsoft box???

However, let's assume that someone does, and is not in therapy or hospitalized. First, what the hell is a mision-critical box doing exposed on the Internet, with no firewall?

Ok, ok, admins can be naive and bloody stupid, and don't deserve to be boiled in hot oil for it. Well, not usually. However, this gets to the second point.

The second point is that the failures exist, whether they are known about or not. Worse, when there is one error, there are usually a whole host of related errors. Non-fatal bugs are still bugs, and can cause data corruption.

So, we have a choice. "Crackers" corrupting data, or users doing all on their own, in total ignorance. Ignorance may be bliss, but bliss is a piss-poor excuse to give your boss, if you can't give him/her your reports on time.

This leads me to the third point - the absolute requirement imposed on ALL other merchandise: that it be fit for the purpose for which it was designed. This law should be imposed on ALL merchandise. If that means programmers need to work a little harder, so be it. I don't mind purtting in a few extra minutes to fix the bugs in my code.

Yes, I did say minutes. Ooops! You mean, Microsoft coders are incompetent? You think that would pass by a judge, if it was a company making electric heaters, which kept burning houses down?

How could I possibly fix my bugs in minutes? It's called good coding practices, good design practices, some intelligence, and the wonders of a good compiler development kit (gcc and gdb).

If you program in BASIC (visual or otherwise), the liklihood of an error is high. It's unstructured beyond belief, and coders are typically the dregs of society, never mind the programming world.

Is that elitism? Probably. On the other hand, not all elitism is undeserved. SIXTY FIVE THOUSAND known bugs in Windows 2000, when it was released? Sorry, but there is no excuse for such a pathetic showing. Even assuming slow progress and poor communication, a competent team of programmers should be able to fix 1 bug per programmer per 10 minutes of work.

So, 10 programmers (a typical team size) should resolve 1 bug per minute, on average. So, 10 coders should have been able to fix the entire of Windows 2000 in 27 working weeks. Don't even begin to tell me that the overrun was less than that, and that Microsoft couldn't afford 10 debuggers.

Conclusion: Microsoft's "request" (read: demand) is in moral (although not legal) violation of the Consumer Protection legislation, is endangering users by exposing their work to concealed hazards, and is promoting dangerous network practices.

Last point, and then I'll shut up. Let's say that Microsoft knows that doing X, Y and Z will provide admin privs, but has not released this information publicly. (How can I possibly believe that they'd do that? Because there are 65,000+ such examples.) Let's say a terrorist gets into Microsoft and finds this flaw. You think they'll do the Right Thing and throw that information away? Not Bloody Likely!

What kind of coding experience do you have? (5.00 / 5) (#23)
by Carnage4Life on Sun Oct 21, 2001 at 03:08:09 AM EST

Is that elitism? Probably. On the other hand, not all elitism is undeserved. SIXTY FIVE THOUSAND known bugs in Windows 2000, when it was released? Sorry, but there is no excuse for such a pathetic showing. Even assuming slow progress and poor communication, a competent team of programmers should be able to fix 1 bug per programmer per 10 minutes of work.

Really what world do you live in that it takes 10 minutes to understand, fix, debug and verify a patch to a multimillion lines of code programming project? This also besides the fact that industry studies have shown that 1 bug is added for every two bug fixes made to a project it is hard to imagine how viable your 10 minute number is even if all the developers where operating systems gurus more knowledgeable and capable than Ingo Molnar, Linus Torvalds and Alan Cox combined.

Do you think it takes 10 minutes to fix a bug where when the user has a Voodoo2 card and is running some OpenGL apps, the OS automatically reboots? But the reboots are completely random, only occur with Voodoo2 cards and not with all OpenGL apps. This isn't a real bug just something similar to one I've heard.

PS: Microsoft bug databases hold all sorts of issues including stuff about docs, UI look & feel as well as regular code bugs of varying importance so I wouldn't exactly put much weight in 65K bugs being in the bug database. After all, Debian has hit 100,000 bugs as has Mozilla

[ Parent ]
Certainly. (4.33 / 3) (#34)
by jd on Sun Oct 21, 2001 at 03:42:57 PM EST

My experience with programming is with both small and large projects. Small projects include an Expert System shell for radio-nuclide identification from gamma ray energies, which I developed for my A-Level computer studies project. Tested it on live data from Chernobyl fallout. Near-100% accuracy.

Large projects include EUROGAM, a distributed system that used Tcl/Tk, C and LISP, using RPC for networking, across SunOS and VxWorks OS', for reading, analyzing, storing, and processing (in real-time) data from 50 gamma-ray detectors sitting at the end of a nuclear accelerator.

As you can probably tell, I'm not your Joe "Hello World" Bloggs type of coder. Some might enjoy sitting in their little cubes, coding Yet Another Accounting System, but I don't regard such people as programmers. That's stuff you expect high school students to churn out, single-handed, in a week. Not stuff serious programmers do for pay.

Adding bugs is a sign of a mind too diluted on toxic or noxious substances to be of any real value to society. If you drove like that, you'd be pulled over for reckless/drunk driving. Why should your work be taken any less seriously than the journey to get there?

The "industry studies" are by half-wits of half-wits. I'm sorry to be blunt, but sometimes a 2x4 is the only way to get through to some people. If you add a bug for every 2 you remove, then your bug list will halve by every unit of time. In other words, your bug database has a half-life. In reality, we don't see this. The number of bugs in Linux version x.y.z has no bearing on the number of bugs in version a.b.c. The relationship is not merely poor, it's totally non-existant.

As for tracing bugs, it is very, very simple. I'll spell this out in terms that even the most clueless can follow, easily.

  • RULE NUMBER ZERO: Draw A Diagram! This is the Law of Exams, but it is also the Law of Software Engineering, and it is immutable. If you don't understand what is actually happening, you cannot understand what is NOT happening, or why.
  • Design from the top-down, write from the bottom-up, test from the start to the finish. There is a reason for all this. If you don't see the "Big Picture", then you can't understand enough to place the pieces in it. But when placing pieces, you cannot start with the "Big Picture". That is where you end. You start with one piece, get that working and tested, then move onto the next. Testing from start to finish tests the logic as it actually is, not as you think it aught to be. There is often a difference, and that difference is invariably where the problems lie.
  • Test with a test harness, not by hitting keys. You aren't a monkey, you don't have an infinite length of time, and you aren't writing the works of Shakespere. A test harness allows you to test each component, or each cluster of components, just by knowing what can go in and what should come out. You don't even have to have a complete program. In fact, it's often best if you test each component on construction, not on complete assembly.
  • If you are having a sporadic bug, a non-fatal bug or a bug that only recurs under exact but seemingly-independent conditions, then you are looking at a simple logic bug. You have made an assumption (a stupid thing to do in the rest of your life, why assume computers would be different?) and that assumption has proved invalid. Because these are bugs which may or may not appear in any given version, they can be hard to track, if you favour debug tools over writing the code correctly to begin with. For these, you absolutely have to stress-test in a test-harness, if you're to find the bug before you plan on retiring. It's most likely a buffer, stack or queue that is overflowing or underflowing, but it can also be attempts to use data as pointers to code, using self-modifying code (unless you are VERY VERY careful, and amazingly good), accessing an uninitialized pointer (always fun!), or other trivial but stupid mistakes. If you're using C, then pay attention to lint. It may not be "great" as tools go, but it's not there for the fun of it, either.
  • Last, but by no means least, NEVER, EVER, EVER, EVER, EVER ASSUME! Yes, I know that's been the theme of every other point, but it's so vital to good coding that it can't be stressed enough. If you assume your code works, then you will never find the bugs in it. If you assume the libraries are correct, you will never identify the bugs in those. If you assume the compiler is generating correct code, you will never find the bugs in that, either. If doctors made assumptions, there would be no FDA and every patient would be a guinea pig in the largest experiment on humans ever conducted. Fortunately, they grew a bit brighter (though only a bit, at times) and modern practices are sane, in comparison to the Olde Times. Coders aren't exempt from this universal principle. You can either be a Computer Witch Doctor, or a Software Engineer. Choose. You've only your professional pride, your morals, your sense of ethics, and your reputation at stake.


[ Parent ]
well then... (5.00 / 3) (#35)
by rebelcool on Sun Oct 21, 2001 at 07:01:37 PM EST

You should know that '10 minutes to fix a bug' is a load of shit.

Either you're making up your importance (what programmer doesnt?), or you're another one of those pompous asshole programmers whom is secretly despised by his coworkers for his blustery crap.

Go find your audience among the peons of slashdot. They'll be more receptive to this kind of bullshit.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

yeah yeah (5.00 / 3) (#37)
by streetlawyer on Mon Oct 22, 2001 at 02:06:41 AM EST

.. on the internet, nobody knows you're a dog.

Sorry, folks, it may be that I am doing this guy a terrible injustice and there are indeed out there people with huge fantastic programming brains who just happen to be unable to write coherent English, who think that bugs can be found at a rate of one per ten minutes, and who give little unsolicited didactice lectures which look suspiciously similar to the results of a web search. But for the time being, I'll continue to believe that there ain't.

--
Just because things have been nonergodic so far, doesn't mean that they'll be nonergodic forever
[ Parent ]

Real world experience (1.00 / 1) (#45)
by ucblockhead on Mon Oct 22, 2001 at 02:21:19 PM EST

So when do you graduate?
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
crazy graphics bugs (5.00 / 1) (#36)
by rebelcool on Sun Oct 21, 2001 at 08:06:21 PM EST

oy, graphics hardware. When I installed win2k and the latest drivers for my asus geforce card the thing would randomly reboot itself. The error (when I managed to catch it) was pretty non-obvious though I guessed it was a video driver problem.

After a few days of perusing asus forums someone had posted a link to an msft kb article about paging problems on certain athlon system configurations. The solution was to downgrade to an asus beta driver (to this day, I cannot use their newest final drivers) and apply some kind of registry patch listed in the kb article... talk about an obscure problem!

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

100,000 bugs (none / 0) (#42)
by dorward on Mon Oct 22, 2001 at 08:58:22 AM EST

Are those 100,000 OPEN? More to the point - are the open in a release marked as stable?

[ Parent ]
No. (none / 0) (#47)
by Shalom on Mon Oct 22, 2001 at 08:27:20 PM EST

That's total 100,000. See here. Around 19,000 of those are still open. At least a few of those are absurd or not bugs at all, and many of them are requests for enhancement. Still, the number of actual bugs is probably currently around 10,000-14,000, as a very rough estimate. Remember that this is for the entire suite--browser, mail/news, and chat, and everything that goes along with it like the JavaScript debugger.

[ Parent ]
Nice quote (4.00 / 1) (#26)
by bugmaster on Sun Oct 21, 2001 at 05:42:13 AM EST

While I find it difficult to believe that any human being can diagnose and fix a non-deterministic bug in a multimillion-line piece of software, the following quote
If you program in BASIC (visual or otherwise), the likelihood of an error is high. It's unstructured beyond belief, and coders are typically the dregs of society, never mind the programming world.
is absolutely true :-) Visual Basic programmers are the drunk, stinky bums of the programming world.
>|<*:=
[ Parent ]
Say What? (5.00 / 1) (#28)
by Gupi on Sun Oct 21, 2001 at 11:17:34 AM EST

If you program in BASIC (visual or otherwise), the liklihood of an error is high. It's unstructured beyond belief, and coders are typically the dregs of society, never mind the programming world.

Would you like to debate which language is more structured VB or C? lets start with error handling.

Now C is much more error prone in many ways, most notable is the lack of memory managment built into the language. Sure, you need it sometimes, but it is still error prone.

I program in VB. I can program in C as well, but I like building graphical front ends, and C doesn't fit as well. In fact no other language fits as well. Not under windows.

Now can it be that those "dregs of society" are simply doing their job, in the language that fits the task?

[ Parent ]

Have you tried Delphi? (4.00 / 1) (#30)
by fluffy grue on Sun Oct 21, 2001 at 02:17:24 PM EST

From what little experience I've had in programming Windows applications, I've found that Delphi is easier than Visual Basic, and is actually based on a decent, strongly-typed, robust, and properly object-oriented language (Turbo Pascal, not to be confused with standard Pascal which is crappy).
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Controls (none / 0) (#49)
by PhillipW on Tue Oct 23, 2001 at 03:46:05 PM EST

Very true. Delphi rocks if you ask me. And, unlike VB, the controls are layed out in a logical way, rather than just tossing all of them into a big rectangle.

-Phil
[ Parent ]
Microsoft security bulletins (none / 0) (#48)
by h4b1t on Tue Oct 23, 2001 at 09:32:49 AM EST

personally i think windows is great.... for running some sound apps and games, making the occasional pics in photoshop or something, etc, but if you really think about it, the idea of using closed-source software (which, as far as we know, ppl have already hacked M$ site and ripped the sources, last i heard, for 2k, and spread it to their EViL friends most likely) is silly. i mean think about it, you have no idea if its secure or not or how it works or what it really does, someone else, probably someone EViL, knows more about YOUR os, on which your company or household or livelihood depends, than you do. you NEVER can 100% secure it! you can never know whats broken until someone exploits it. i personally am subscribed to the M$ security updates email list, and i get at LEAST 1-2 of these security bulletins a week telling of the newest hole in windows nt/98/me/xp/2k/whatever. every week... holes holes holes... how often do service packs come out? uh... every few months? so you will end up with a directory with several hundred Q192834719823471982.EXE files if you are really trying to keep your systems secure, and deploying that to all your systems? ha. besides, i don't know who i'm more worried about having break into my system, EViL hackers or micro$oft??
[clint.anderson.:.is.:.habit.:.techno+technology.] [icq.7158752.h4b1t@hotmail.com.dalnet.#jungle-mp3] [drumnbass.idm.buzz.psycle.soundtracker.linux.etc]
ESR: Fix your security, Microsoft! | 49 comments (24 topical, 25 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!