Slashdot Mirror

Well, the reports simply state that, in the 360 files they checked (most of them header files) they found 29 cases of a potential NULL pointer dereference and 2 potentially uninitialized variables. This is from the Apache 2.1 codebase as of 31st Jan this year, about 58k lines of code.

Their automated checker also searched for out-of-bounds array accesses, memory leaks, and bad deallocations. It found none.

They also state that they ran the same checks against other codebases, and found that they did marginally better, on average.

In short, this report says that OLD development code for an unreleased opensource project is nearly as good as current commercial offerings. That's at best, when you consider the huge gamut of possible defects that this checker won't pick up. That margin probably disappears in the +/- of the sampling if you were to do a proper statistical analysis.

The report is fairly useless. It certainly should not be taken as a reason to not trust Apache; to do so would be foolhardy particularly given Apache's track record.

Oh, and Reasoning's webserver is being pounded into the ground. You can get my local copy of the reports from here.

I recently created a website with a group of friends for a University project which went on to discuss why a P3 may well be quicker than a P4... take a look but more specifically, take a look at the editorial to find a short piece of C++ code to test your machine with. Compile the code and run it on your machine to find out how slow it really can be, the results might surprise you!

I recently created a website with a group of friends for a University project which went on to discuss why a P3 may well be quicker than a P4... take a look but more specifically, take a look at the editorial to find a short piece of C++ code to test your machine with. Compile the code and run it on your machine to find out how slow it really can be, the results might surprise you!

background reading on the subject can be found here, and here, and pretty much everywhere else google knows about.

if this kind of "boycott" did any good, slashdot would be using PNGs by now, wouldn't they? *cough* in this case, it's only a good idea if the linux community can come up with absolute, solid, will-hold-up-in-court proof that SCO is talking out of their collective asses about this.

and even then, who cares? SCO's unix products blow chunks anyway. SCO is irrelevant. they're being petty. why descend to their level?

I'd like to see this fly, since there are some really kewl games out ther for the cube, w/ decent quality graphics. But, i wonder.. I found out that those sly engineers at Nintendo thought up a brilliant copy protection method. The Gamecube uses a Constant Linear Velocity read method, instead of the conventional Constant Angular Velocity. CAV is what CD's and such use, where the speed of the data disc is variable but the reading motion stays the same... whereas CLV keeps the speed of the spinning at a set rate, but the optic is variable in movement. (better explaination, here). So the speed of the disc would not effect the GC's copy to an ISO as much as the optic speed would... the possibilities seem endless here.

They are publishing source code for the virus. It IS the same thing. It may not be the ORIGINAL source but it is the source for the virus.

To claim any text transformable into a given program is that program's "source code" dilutes the meaning of the term to the point of uselessness.

Of course it's a programming language. Not only was it designed as a programming language (thus the "script" in Postscript), but it easily passes the test of producing a quine, as can be witnessed here and here.

Yuck!

Davak

Your post relates directly to the Halting Problem. In short, you cannot prove that an ARBITRARY program won't hang. I don't know if this means you can't write a crash-proof OS, however. As someone mentioned, the Halting Problem basically says you can't write a program that will tell you whether a program crashes. But a crash-proof OS would be an OS that could recover from any misbehaving program, enabling you to terminate it without jeapordizing the stability of the system. So you're right, you can't predict the outcome for every case. But does this mean we can't create a system that survives the malfunctions of an arbitrary program?

So if these are like drag races, would walking disk drives be the equivalent of a tractor pull/monster truck event?

"the implementors choose not to be fully ANSI-compliant. You won't notice it at first, but if you get into advanced object-system hacking CLISP will become unsuitable."

"Also, it's a byte-code interpreter system. This severely affects performance (except in bignums, due to some numerical methods magic), but it does have a smaller memory footprint. And it's widely ported."

"I use libraries like AllegroServe (HTTP server)"

"You can investigate GCL or ECLS, which compile to C and may work under mingw."

"Well, most Scheme implementations aren't anywhere near the same quality as the CL ones (with a few notable exceptions) and they all have to implement incompatible supersets of the language (because R5RS defines approximately nothing)."

Indeed.

A few years ago, I started a PhD in plasma physics, studying the high speed electron transport effects in short pulse, high intensity laser-plasma interactions. You are of course quite correct in your assertion that this sort of laser fires extremely brief pulses.

In plamsa physics, such a pulse is used to rapidly (read, near-instanteously) heat the surface of a target. The rapid heating causes the surface to ablate, which in turn causes the rest of the target to be compressed and heated. Get it right, and fusion ocurrs.

Quite apart from the physical reasons why you'd use a short pulse, the ultimate goal here is to create a viable method of producing energy. The more energy you put in at the start (by using a "long" laser pulse), the more you have to get out in the long run to make it worthwhile.

When I was still on my PhD (before I got bored and quit), we had a working z-pinch in the basement. As dramatic as it would have been for the lights to dim, there were no outward signs when it was fired :-)

insufficient time combined with constantly changing requirements? In that case, given time to really do things right could make a difference.

Every project I've ever been on has insufficient time combined with changing requirements. I'm not even sure if I've heard of a project where that wasn't the case.

Given that, I think it's our responsibility to create the necessary space to do good work. Now I only offer clients two options. One is building 100% solid software. The other is building cheap, throwaway prototypes that come with absolutely no guarantees.

As far as I can tell, there's nothing in between. Software that is allowed to be only 95% solid rapidly decays until you reach critical mass. Or, in a lot of corporate situations, you put all your effort into holding together a system that is at the brink of critical mass, leaving you almost no time for improving the code. So if we're going to write garbage, we might as well do it honestly from the start, rather than sneakily or accidentally.

Now convincing bosses and clients that there are only two options isn't easy. But it's a fuck of a lot easier than spending six months working 60 hour weeks trying to keep a crappy code base together while hacking in features according to a release schedule put together by some blowdried doofus in marketing, whose interest in your wellbeing is limited to hoping you don't have a heart attack before the ship date.

I've never had the pleasure of working on a project where there was anybody to say "no" to the customer's latest wacky, impractical, last-minute ideas

You should look into the Extreme Programming practice known as the Planning Game.

The basic notion is that you break a product down into a bunch of little bite-sized features. Each one of these mini-features, called a story, and is written on an index card. The businesspeople can ask for whatever they want, and the programmers estimate it. If the estimate is more than a few days of work, then suits and geeks collaborate to break it down into separate cards that are just a few days in size.

Then the suits get to put the cards into a big stack, ordered by their notions of what's most important, and the developers must build them, a few cards at a time, in that order. The suits may designate any point in the stack as a point where the software gets shipped.

Note the important separation of powers: the suits get to order anything they want. The developers get to say how much it costs. This lets the suits, as they seem to enjoy, have endless meetings about which features get into which releases, while the developers are off coding away on the features that are at the top of the stack. If the business decides that they want to change priorities on stuff a ways down in the stack, that's not a problem; the developers haven't gotten there yet. and if they want to change something already built, that's ok too, as it's a new card that they have to schedule just like everything else.

Although there's a little more to XP scheduling, that's the essence of it. And it sounds too simple to work. But I've done it on several high-pressure projects, and the business analysts and execs have taken to it every time. They love it, as it gives them complete control over the schedule. And the developers love it, because they're not the bad guys anymore; there only job is to make solid stuff, not to resolve impossible scheduling dilemmas.
Ok, I'll stop. But if people have more questions, feel free to ask, either here for via email. After years of building software the hard way, I'm absurdly happy that building software doesn't have to hurt.

<pedantic>
Foldoc's reference is quoted from ESR's "Jargon File". (This fact foldoc does indirectly acknowledge).
</pedantic>

So far as I can tell, the Jargon File's definition is canonical in the geek community. I believe it's the oldest, anyways; I recall seeing the definition in a early-90s text version.

<pedantic>
Foldoc's reference is quoted from ESR's "Jargon File". (This fact foldoc does indirectly acknowledge).
</pedantic>

So far as I can tell, the Jargon File's definition is canonical in the geek community. I believe it's the oldest, anyways; I recall seeing the definition in a early-90s text version.

No, I picked up the phrase 'AI-complete' from some online forum, probably Slashdot. It's defined at Foldoc, although it might be better to use the definition 'a program that answers an AI-complete problem could pass a Turing Test without too much extra effort'.

I think people would have used 'Turing-complete' but that was taken :-). It's more than most ordinary folk can dream of to be associated with enough important concepts that they start being unable to name them all after you.

But, to explain the obvious, the usage here on Slashdot tends to be much more as a joke, such as this one, which usually involves pretending that one of the weakest forms of encryption in existence could actually be considered secure, or implying that someone else thinks that (and is therefore a moron), etc.

Now, having told you the secret, I'm afraid I have to kill you...

Other posters have commented on the overlap between Computer nerdism and Ham nerdism. One important difference: Ham networks can remain operative long after all other communication technology is offline. Rather handy during major civil disasters. Which is why the feds allow so much radio spectrum to a "hobby".

(it wasn't up until 2 years ago that I found out that /usr didn't mean USER but rather Unix System Resources. WTF?)

Who told you that??

Might want to check your facts.

"Usenet, unfortunately, has no ejection mechanism." PLONK!

I think o (octet) is more useful than B (byte). It won't be mixed up with b (bit) as easily, and it's always equal to 8 bits.

I think o (octet) is more useful than B (byte). It won't be mixed up with b (bit) as easily, and it's always equal to 8 bits.

I think o (octet) is more useful than B (byte). It won't be mixed up with b (bit) as easily, and it's always equal to 8 bits.

It's nice to see an old and low-level language like raw machine code surviving over the years. The first UNIX kernel contained around 8k of raw machine code, but they later replaced most of it with assembly, which made it more portable and easier to debug but then again 50% bigger. Raw machine code is still needed to write an operating system for very low level memory management and interrupt handling code, therefore I think this language will live longer than anything else, I find that quite interesting.

WIMP also stands for "Windows, Icons, Menus, and Pointers".

DNA is credited to the inception of genetic algorithms. The main idea behind genetic algorithms is the emulatation of natural selection and evolution by means of DNA manipulation. This is accomplished by many DNA manipulation techniques; the two most prominent are crossover, where two different chromosomes swap DNA information, and genetic mutation, where a random [DNA] bit is rotated. If you're interested in genetic algorithms, check out this introduction.

Ahem, the VIC-20 had 5K of RAM. (Here's another link. The 3 KiB they mention is the amount of RAM available to programs after the OS and display memory are subtracted. That's probably why it's listed as "3KiB, 5KiB".)

Perhaps you're confusing the VIC-20 with the Commodore Plus/4? That thing had 64K of RAM, and four productivity apps built into ROM. So, maybe you had a VIC-20 but wished you had the Commodore 64 or Commodore Plus/4?

If GE entered the Console market would they do well ?

COMPLETELY OFFTOPIC, If GE entered the server market, what would happen?

You'd get, among other things, the GECOS (nee GCOS) field..

Just a touch of history for a saturday..

You mean, of course, CD-Rs once everyone discovers the sneakernet.

Remember Windows 2.0?

byte:
These usages are now obsolete...
...The move to an 8-bit byte happened in late 1956, and this size was later adopted and promulgated as a standard by the System/360 operating system (announced April 1964).

The point of a language is to communicate. Virtually everyone uses the word byte to mean eight bits. If you purchased 4 gigabytes of RAM, only to discover the vender redefined byte to mean one bit, you'd be hopping mad.

The ETF tower was operated by personnel from an RAF unit based in Malvern, Worcestershire.

That was probably at the Malvern DRA. I know some of the guys there read Slashdot, but I guess they can't comment on this stuff!

They do some amazing stuff there.

In support of the parent arguement, I provide this FOLDOC defintion of type.

In support of the parent arguement, I provide this FOLDOC defintion of type.

Try looking here and here. The second link gives the perfect examples:

int a = 5;
float b = a;

typedef int Date;
Date c = 12345;
int d = c;

C and C++ cannot be called strongly typed. Try Haskell instead

Try looking here and here. The second link gives the perfect examples:

int a = 5;
float b = a;

typedef int Date;
Date c = 12345;
int d = c;

C and C++ cannot be called strongly typed. Try Haskell instead

I call myself an engineer because I am a Master of Engineering, according to my University's Faculty of Engineering.

But maybe they're wrong.

Wasn't morse-code basicly a huffman compression?

here it give 1952 as date of first mention.

> (C More or Less) A subject-oriented language (SOL). Each C+- class instance, known as a subject, holds hidden members, known as prejudices, agendas or undeclared preferences, which are impervious to outside messages; as well as public members, known as boasts or claims.

The following C operators are overridden as shown:

> better than
> way better than
forget it
! not on your life
== comparable, other things being equal
!== get a life, guy!

C+- is strongly typed, based on stereotyping and self-righteous logic. The Boolean variables TRUE and FALSE (known as constants in other, less realistic languages) are supplemented with CREDIBLE and DUBIOUS, which are fuzzier than Zadeh's traditional fuzzy categories. All Booleans can be declared with the modifiers strong and weak. Weak implication is said to "preserve deniability" and was added at the request of the DoD to ensure compatibility with future versions of Ada. Well-formed falsehoods (WFFs) are assignment-compatible with all Booleans. What-if and why-not interactions are aided by the special conditional EVENIFNOT X THEN Y.

UNCOL!

See here.

I think you are badly mistaken about the role that IBM wants to take with Linux. They aren't interested in putting Linux on the desktop for the same reasons they never put AIX on the desktop. For them (and for most people) its a server OS.

Actually IBM did put AIX on the desktop in the form of RT-PC. In fact the AIX first appeared on the desktop before on a server,

Here are
some links
that say
I'm right
Here's one that says we're both right

I don't work in the industry so if you do, I'll assume that we're both correct. Perhaps black is the most common key color so that's what everyone defaults it to? Or is "key color" just printing/publishing lingo for black?

it's hard to imagine what form any language could take without the basic repettitive constructs [of structured programming]

No need to imagine ! There are plenty you can look at. They are the declarative languages.

"For those who don't know: E is an object-oriented/procedural/unpure functional/whatever language with quite a popular implementation on the amiga. It's mainly influenced by languages such as C++, Ada, Lisp etc., and features extremely fast compilation, inline assembler, large set of integrated functions, powerful module concept, flexible type-system, quoted expressions, immediate and typed lists, parametric and object polymorphism, exception handling, inheritance, data-hiding, methods, multiple return values, default arguments, register allocation, fast memory management, unification, LISP-Cells, macro-preprocessing, a very powerful source-level debugger, gui-toolkit, library linker, and then some. (oh yes: and it was designed and implemented by me :-)"

http://www.doc.ic.ac.uk/~phjk/BoundsChecking.html and http://web.inter.nl.net/hcc/Haj.Ten.Brugge/

Rich.

First of all, read what is data mining in the FOLDOC (Free On-Line Dictionary Of Computing), if you don't know.

I thought that it was initially considered for entertainment purposes only by the video industry but the r&d/tech folks involved always considered it a multi-purpose data medium. *sigh* My life has been a sham. Well, there's always the next one. Thanks for the info. Trying to find further evidence led me to these two sites for anyone interested....

http://www.nswc.navy.mil/cosip/nov97/cots1197-1.sh tml (this one's actually interesting)
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?DVD

I agree with you; people do make some very confused arguments against Microsoft on Slashdot. Their OS doesn't crash anymore, that's true. Regarding .NET being a Java ripoff- there's a grain of truth to that one, sorta, especially if you're a Java programmer, although to be fair to MS that's an extremely harsh way of putting it. I guess you could say any virtual machine is a "ripoff of Java" but I wouldn't agree with that statement since p-code predates both Java and .NET. MS has put enough work and energy into .NET that to simply call it a ripoff is being overly simplistic, even if their original starting material was their Java implementation. It's their implementation, and they can do what they want with it if they're not going to call it Java anymore.

But there are plenty of nasty things to say that are completely true, like their abuse of their monopoly in the OS market to form monopolies in other markets, their embrace/extend/encrypt/extinguish approach to open protocols and file formats, the designed incompatibility, the ridiculous reverse engineering they make people do in order to interoperate with their products, the boneheaded decisions they make (like a mail client that executes any crap that shows up in your Inbox), their conspiring with Hollywood to destroy the general purpose computer, etc. If all they did was crash a lot (which they don't anymore) and create ripoffs of good technologies (which they still do) I wouldn't have any problem with them.

Forcing MS to carry Java means .NET at least has competition present on the same machine, and that can only be a good thing for both .NET and Java. If one wins out over the other, it shouldn't be because of something stupid like a 30 MB download being required for one and not the other. That would really suck.

Although Sun has made some very bad, very ideological decisions with Java on the client. Java has an albatross hanging around its neck called Swing. Everything is drawn in the Java layer. There are no buttons, just pictures of buttons pretending to be buttons. Before that they gave us AWT, which took the opposite extreme (using the lowest common denominator of all native widgets for EVERYTHING). No tree control on AIX? Then you can't have one on Windows/Mac/etc. Hopefully IBM's SWT will take off in the Java realm. You can write a real application with it- meaning it doesn't have that cheesy Java feel that Sun's GUI libraries impart to Java applications.

I don't quite understand where this Inexpensive crap came from. RAID was around long before IDE RAID controllers started showing up and of course SCSI RAID arrays almost always use very expesive disks. It's Redunant Array of Independent Disks, always has always will be.

It probably comes from the original reseach paper... A case for redundant arrays of inexpensive disks in the Proceedings of SIGMOD International Conference on Data Management, 1988. (Pages 109-116.) SCSI drives were an inexpensive option compared to other storage technologies that offered high performance and fail over safety.

Over time the acronym expansion was changed to become "redundant array of independent disks" as RAID become more popular (and affordable) for smaller systems.

Some references: here, here and here