I voted for Nader in the last presidential election. The fact of the matter is I would not have been satisfied with either Gore or Bush as president. And if I hadn't voted for Nader I would have voted Libertarian (and did infact vote Liberterian for all the other candidates where a Libertarian candidate was available).
The reason why Gore lost (for varying definitions of lost) is not because of Nader. The reason Gore lost is because of Gore. Gore could have advocated policies that would have made the Nader voters vote for Gore. But he didn't. And maybe if he did he would have had less votes anyway. Hell, Gore could of even tried trumpting the successes of the administration he was a part of. But he couldn't even do that. Or Gore could of tried showing a consistent person at all debates, rather than confusing the voters with who is the real Gore. Or Gore could have done many other things differently...
Let's turn this around. Let's say Gore won (for varying definitions of won) the last election. Would a vote for the Libertarian candidate have been the same as a vote for Gore? I mean, isn't it obvious that a Libertarian would vote for the Republican candidate if they hadn't voted for the Libertarian candidate? Well, actually it's not.
The fact of the matter is that I, and obviously many others, do not want to and will not vote for the lesser of two evils.
People who would have liked to Gore win or today want Kerry to win love to say this. The fact of the matter is some of us disagree with you and don't want either of the major candidates to win.
FYI When I voted for Gore my state wasn't up for grabs. This year my state is up for grabs, but I haven't made up my mind who to vote for. Probably back to the Libertarian candidate, I'd like to see some fiscal responsibility, and I don't actually believe that Kerry will bring that and I think Bush has proven he's not up to the task. I can balance my checkbook, why can't the US Gov't? They make a lot more money than I do.
I haven't played too much with generics in C++, but it did seem to involve a lot of excess object creation which isn't too good for speed.
C++ does involve a lot of object creation. But good C++ doesn't involve a lot of object creation in the heap, it's on the stack. It's all about Resource Acquisition is Initialization. That's where you have a class, you declare it locally on the stack, and when you exit your method the class's destructor is ran. Of course, if your class is small enough all of this gets inlined. It's really a pretty elegant solution. A lot of people (probably converting C++ programmers) seem to be unhappy that you can't do the same thing in Java or.NET (the Java &.NET way to solve the problem is try/finally blocks all over the place).
Anything that you'd store in the heap would be long living objects but the major of your object creation will be on the stack. So it's really not as bad as it looks.
1. They are convinced the monitor is actually the computer. I don't know what they think that big tower does, but since they have it piled high with boxes, blankets, and it holds up their space heater, they've more than likely forgotten that its there.
Oh, come on, everyone knows the big tower is the hard drive!:)
I didn't know that the free compiler only supported C#. I stand corrected.
I hate to correct you twice, but the.NET Framework SDK includes the C++ compiler. I don't believe it does any optimizations (mov eax, [ebp-8]; add eax, 2; mov [ebp-8]; eax mov eax, [ebp-8];...), but I've actually used it to compile stuff.
C/C++ malloc routines can do the exact same thing as what you're describing.
The real advantage Java (and.NET) has is it can move memory around, defragmenting it during the process, improving locality of reference, etc... But even that can be done in C/C++ with a compacting garbage collecting memory allocator & using handles to all of your memory.
My favorite BBS memory has to be doing modifications to WWIV. It's the way I learned C and it was a lot of fun.
WWIV was the most popular BBS system in my area, and of course it had it's WWIVnet that had message boards networked across the country.
On WWIVnet people would post mods to the source code for WWIV (which was available if you registered for $50). I got $50 from my Mom so I could get the source code (being around 14 at the time). I started downloading the mods from the local BBSes and the message boards and modifying the code. After a while I started trying to make my own modifications and when successful sent them out to boards (a couple of popular ones being a conferencing system and a vertical chat modification).
Anyway, it's amazing to think about how much I sucked at programming back then, but it was a great start.
Oh, and the people were great too.:) I have many friends still to this day that I gained from BBSes. So it's really had quite an impact upon my life, amazing.
(Apparently there's a WWIV 5.0 beta now, years and years later. Occasionaly I check up what's going on, and this seems fairly new (last 6 months?). It's amazing it's taken this long though - I was able to port WWIV to ncurses on Linux in a weekend.)
And while you're right about complex problems taking a special kind of insight to solve, the truth of programming is that it's largely simplistic tasks broken up by the occasional bout of complexity. Usually, that complexity is easily decomposed into many more mundane tasks. Usually, working hard can almost be a substitute for being clever.
I think you've hit the nail on the head, but there's two sides of this I think still make the brilliant programmer stand out.
First, the brilliant programmer recognizes this and doesn't get flustered by the complexity. They just attack the problem in a thoughtful and efficient manner. That probably includes doing the appropiate amount of design work to get a non-crappy solution.
Second they can quickly implement the mundane tasks. Often times "average" people have trouble implementing even mundane tasks, it's really pretty scary.
But certainly everyone should be following coding standards. Your previous complaint seemed to be "a morass of code"; but you seem to be forgetting that any programmer, brilliant or otherwise, could produce that and still follow coding standards:). So I believe that's really an orthogonal issue to programmer brilliancy, but it certainly is an issue that should be addressed with all programmers on a project (addressed as in having code reviews that check for conformance).
On the other hand, a buffer overflow error that is introduced early on in the process isn't going to be any harder to fix later than it is if it is caught right away.
Consider the code:
void foo(char *input) {
int a; char buf[25]; int b;/* do stuff w/ a & b */
strncpy(buf, input, 25);/* a and b no longer used, do stuff w/ buf */ }
Let's consider the case of having an input string 26 bytes long including the NULL terminator. If strncpy has an off by one error it'll NULL terminate the string (write a NULL at buf[25]). buf[25] is most likely REALLY a byte in either a or b (depending on how the compiler lays things out on the stack). So buf appears properly terminated to any functions that operator on it from here on out, even though there's no NULL anywhere in buf[0] to buf[24].
But then someone notices the buffer overflow in strncpy. And they fix it. Now buf is not properly NULL terminated and the program blows up later because of this (potentially later copying string they thought was of a certain length (they used strncpy!) into the heap , overwriting a vtable, and later doing a call into some random address).
So now you either need to not fix strncpy, or fix both strncpy and this other program. If this other program happens to be a library that you don't have the source code for, and lots of people use, what do you do?
It's certainly a simplistic example. strncpy has odd semantics (not guarenteeing NULL termination), and in this case there were 2 bugs. But more complex situations like these can and do crop up when you need to maintain compatibility between multiple software components. So now you ship your "fixed" library and suddenly tons of other programs are broken in odd ways. Then they have to fix their software, and many customers are experiencing cascading upgrades (if they're lucky and can get the upgrades!)
I think the point both Jobs and McNealy were making (probably tongue in cheek in both cases) is that nobody at Dell is concerned about what a "computer" ought to be. They have been phenomenally succesful at transforming parts from a variety of suppliers into computers on people's desks, but their innovation is almost entirely in different fronts of operations management. (Not that there's anything wrong with that.) Apple and Sun, and Alienware, for that matter, define the nature of what they sell in a way that Dell doesn't.
And this leads to an obvious question. Dell is able to sell products that meet millions of customers needs. They certainly sell more computers than Apple and they certainly beat Sun on desktops. So what is the innovation that Apple and Sun are bringing to the table? After all, with almost no R&D, Dell is able to sell a highly competitive product at a lower cost. I don't think there are too many Dell customers who thought they were settling for less.
I think the answer's more obvious for Sun in the monsterous machine catagory. But even that is looking rough as x86 scales up and out.
You have a point. Any extra software I install will be left up to me to keep up to date. This is how it works with any system though, and unless we want to allow a pretty intrusive system scan by some 3rd party it is probably how it is going to continue to work.
I don't think this is true. chainsaw1 mentioned Debian, and it explicitly does enable this capability without an "intrusive system scan by some 3rd party".
All it takes is a standard format and a central package management utility that can be pointed at multiple sources for updates. Debian's implementation is a text file that points to multiple servers, and the sys admin can update it to point at their servers of choice. Debian then builds the package database from all the available servers, and allows you to select upgrades (or pretty much performs auto upgrades) from the available packages. I believe the only information sent to the third party (other than typical TCP/IP info) is the packages you want.
I don't know how secure the distributor->distrubutee channel is (I could imagine many possible implementation pitfalls), but the dpkg & apt are certainly not instrusive.
I'm sorry, this is not a design methodology. I could maybe accept a development methodology. But part of your design is defining units, and those units should be tested first.
You say "You can unit test against a hypothetical universe. The real one tends to throw you curves in places you didn't know you had places." I assume you meant can't here, not can. First, unit tests are not hypothetical. You have obvious units during development that can be tested (each class comes to mind), you should test them. Unit tests are not designed to test these curves that you don't expect. Unit tests are designed to test basic functionality to get rid of basic bugs. Once you know your basic functionality works, then you start testing the system.
Let's say that I have a program that needs me to implement a custom growable list. Am I going to write the entire program and run it and drive the program to use the list? No, I'm going to write the list, test it, and make that part of the program. Maybe, and in fact most likely, my original tests didn't cover every state. That's why we have integration testing. But it happens AFTER I've verified the basics of the component are functional. If I discover a bug that my original unit tests don't cover, ideally I should go back and add a test to cover that.
Ss for "sounds like evolution", you say that as if it's a good thing. Yes software design isn't solid at the beginning and it evolves in practice. But that does not mean that there aren't explicit units that can be tested during this evolution before the whole is tested.
I'll close with final thought (god, who the hell am I, Jerry Springer?): If you test with the smallest scope first your time spent debugging will be minimized. If you throw an entire program together, and start testing, all of a sudden the bug you're tracking down could be anywhere in the program. If you are debugging a unit test, your bug is in the unit. It's much easier and faster to debug. And THAT'S why you write unit tests first!
Just FYI: In Folder Options (Start->Control Panel->Folder Options) there's a choice on the View tab "Display the contents of system folders". You want to check this, and your "problem" will go away. No registry key setting necessary.
While that is true, it must be possible to create such a body; after all, engineers, lawyers, doctors, etc managed it, even tho' all those professions change quite rapidly. The medical profession, for example, hasn't held back the development of CAT scanners just because most of its members qualified on stethoscopes (for example). The engineering profession hasn't held back the adoption of CAD even tho' when it was founded the slide rule was the computational tool of choice.
While I'm not sure that it's impossible, I think there is a significant difference in scope between these professions and software development.
Lawyers are scoped to their state, by their state bar, and their only real requirement is to zealously protect their client (or prosecute the bad guys). Doctors are scopped to the human body, and while there's many diverse areas throughout the human body, they all pretty much have the same goal of improving health. Engineers are scopped at various different levels (Electrical, Civil, Mechanical, etc...). Generally speaking they need to build things that don't fall over within specified tolerances.
Software on the other hand crosses across many different areas: VB database front ends, applications, OSes, medical applications, nuclear power plant software, airplanes, cars, games, PVRs, microwaves, MP3 players, etc... And all of these have widely varying requirements. Should the VB database app be held to the same standard as the medical applications? Probably not.
So if every VB programmer had to be a certified Software Engineer then the price of VB developers would sky rocket. And for what benefit? The corporations are satisfied with the quality they are getting today. So do we have a certification for every different category? Do we have a certification with different levels of reliability and quality?
And to get back to the other professions, should programmers be like lawyers: they just need to do their best, and not appear incompotent to their peers? Or should they be like engineers and specify tolerances ("This program will work fine as long as all inputs are valid.":) ). Or should they be like doctors, and if they introduce bugs they're liable to be sued for malpractice? And once again, I have to ask about the VB developer (and I hate that I have to keep coming back to VB developers, but they are a large group, and they and their employers would suffer the most from legislation in this direction).
jc42 inadvertantly pointed out that there are already many certifications. I think the real "problem" is there's no demand for certified people.
What you describe is a testing methodology, not a method to increase software robustness. While you're fixing bugs that you know about if you miss one buffer overflow then the app crashes and burns. There's no safety factor there.
There are ways to increase reliability beyond this level. Examples include restartable out-of-proc components, VMs such as.NET or Java (which introduce their own problems w.r.t. unexpected memory allocations and handling those), and restartable in-proc components isolated through various techniques (seperate memory heaps per component spread throughout the process to reduce chances of corruption, structured exception handling at component boundaries, etc...). And of course if you're writing in C++ doing things like using a conservative GC to prevent one bad class from running your process out of memory is another way to introduce wiggle room.
So those are some ways to introduce REAL wiggle room in an app, but very few people go to such lengths (and not many major commercial apps run on VMs). You still need to do the testing to get rid of the bugs, but when you miss a major bug you've reduced the consequences and scope of corruption.
Also your testing methodology seems to be backwards. Unit testing last? How the hell can you start integrating stuff together if you haven't made sure the basics work yet? That's just asking for a disaster, where you have a huge pile of crap that's completely broken and undebuggable.
An electronic voting machine which should produce a printed record. Some type of blind-numbering system should be used for identities -- crypto theory has plenty of theoretical models for this.
I think we definitely need a printed record. I imagine something like an ATM machine that prints your voting results. I don't think the cryptography is necessary though, all you really need is the same hand-submission process we have today. You may want to print the place the voting occured though (in some cryptographically strong way, eg sign the ballot with the voting place's private key). I think adding anything personally identifable, even if cryptographically secured, is asking for trouble.
I would then think we would primarily use the electronic results, but we'd have a physical backup if there were ever any questions, and that backup would be more readable then the one we have today.
The best thing about a plan like this is that it's SIMPLE, and it's essentially what we have today, just modernized a little.
You say this like you can barely believe it - a small clue though, Windows XP doesn't have seperate data and boot partitions. Never has. 5 seconds of looking in "My Computer" in Windows would have shown you this.
Be all that as it may, don't make Windows out to be bad just because you assumed it worked the same way as Linux.
Not only are you correct that Windows shouldn't be blamed for this (although I think yuri's description didn't really blame Windows, it was more of a factual recount of the events) I would blame Mandrake. Mandrake is the software that is displaying "/mnt/win_c" and "/mnt/win_d". So obviously his machine had 2 partitions, one of these was probably a restore partition, but Mandrake did a poor enough job of identifying them and the user took the wrong action because of this.
Mandrake *could* look at the contents, search for a windows directory, or take some other action to properly identify the drives so this sort of user error doesn't occur in the future (eg,/mnt/win_os,/mnt/win_data1, etc...). The alternative to this would be Mandrake looking into the Windows registry to see how the user's drives are lettered so it gets things right - I'm betting that Mandrake isn't doing this (but I could be wrong).
Anyway, I'm way off topic here. Modding razors and modding the Xbox are two different issues, legally and physically. The xbox is a PC that will only run signed code. Well, stick in a modchip and it can run linux. How can that be illegal? You own the modchip (and the IP contained within is yours / you have a license), you own the xbox; you have no intention of using MS's IP. Again, how is that illegal!? You're doing the stuff to something you own.
I may be out of date, but I thought the majority of mod chips contained the XBox (or PS/2) BIOS code in the chip - only hacked. Therefore it's been a copyright violation to distribute the mod chips, and that's how the IP gets violated. It's a similar situation to IBM's BIOS needing to be cloned (as in reverse engineered, documented, and rewritten) before "IBM PC compatible" computers could come about.
Now, IANAL, it seems otherwise it's perfectly legal to hack the XBox. Of course, the DMCA may have something different to say, but I don't think Microsoft has made any DMCA claims against XBox hackers (again, I may be out of date).
(and I'd say you were pretty on topic - I was much more off topic on my previous post)
Thanks for the link - it was very interesting even though it only reinforced what I already knew: 1. Libertarian Candidate (100%)
I'm in total agreement with you here. I look at any candidate, and sure, they sound good for some things. But then there's ways that are just begging to become huge governmental wastes. And then you look at the other candidate, and it's the exact same way, but he wants to screw us from the other direction.
Unfortunately I look at Libertarian's and they're not completely on target with my beliefs, but their the least evil of all the choices.
The problem that I see with the Libertarians is that corporations get too much free rein. We give corporations an extremely large benefit over individuals (limited liability being the big one) and we should demand something (or many things) in return. The Libertarians want to remove many government intrusions, but they don't really propose how the services removed will be replaced. I think we should stick it to the corporations to solve that problem - but Libertarians don't agree (maybe some libertarians do agree though).
But that small gripe still doesn't stop me from voting Libertarian.
I don't think Gillette or Bic would start suing people for making razor blades that happened to fit their razor handle. They'd probably try to make their blades better so no one would want to use the cometitions, or they change their business model.
And you'd be wrong. Gillette will sue you if you violate their patents (and even LOOK like their product, let alone interoperate). And they have patents like this one, and this one and many more pertaining to razors. Not to mention Gillette was the company that patented the original safety razor - so they've been at this for a while.
The problem with your analogy is that in Gillette's case they patent the razor blades AND the interface between the two. That means you can't clone their blades, and you can't connect without their handle violating a patent.
Imagine if Ford invents a new way to fill your gas tank. Only licensed gas stations can use this patented nozzle. You'd effectively be paying Ford for a percentage of your gas. Could they stop you from hacking the Explorer? As long as you don't use their IP, probably not. Compatibility is something people expect in their gas tanks, so that will never happen. But most people seem fine with it happening in razors, and ditto on consoles. Consoles obviously can't patent the execution of code, but they can copyright bootloaders and BIOSes.
My quibble with explicitly checking for NULL pointers is that you're only going to catch the case when the pointer is NULL. Just about any other bad value is going to give you a segmentation fault (which is exactly what a NULL pointer is also going to give you). I would consider such a check of more value if you also bothered to check all the other pointer values it shouldn't be, but that's something which is mainly only practical at the kernel level. Otherwise, I find all the extra NULL checking pedantic.
In C++ it would be pretty easy to verify a pointer. Step one, implement your own heap with an address checker. Step two, ensure all classes have vtables. Step three, Check both the memory address & vtable of the object. It's all quite extreme to comparing a value to NULL though, and there's *still* classes of errors it won't catch (for example, passing a freed & reused address that got reused by the same type). That aside, there's a significant difference between a NULL pointer, and give a good example below. So given the simplicity of the check, and the fact that it does often have meaning, I think it's a good idea to do the check. Not necessarily for all internal APIs, but certainly public APIs. A good error return code is quicker to solve than a seg fault.
The only place where I like to put NULL checks is where passing a NULL pointer has some sort of meaning in the API (in which case, it's obviously necessary). Doing so helps signal to anyone reading the code (mainly myself) that a NULL pointer value has significance beyond a possible segmentation fault. That would be drowned out if I put a NULL pointer check everywhere just to return a marginally useful error code, which I would also have to check for, rather than the program crashing in a clean and spectacular manner (the fail fast mentality).
Now, this depends on how you implement it. If you do the old if(arg1 == NULL || arg2==NULL) return(NULL_POINTER_ERROR) at the top of every function (or throw an exception) it'd be immeditely obvious you don't accept NULL pointers on some functions - no matter what you do else where. You bring up the "fail fast mentality", and I think that generally applies to when you CAN'T handle the error. In general you can handle a NULL pointer before you dereference it. So there's no need to bring down the entire application. What if someone did:
char *buf = new buf[181]; result = fill_my_buffer(buf);
If you run out of memory you can pass a NULL pointer. Should fill_my_buffer really crash the program, or should it return a meaningful result (that could maybe be propagated up)? It is an easy error to overlook, what would you prefer an application you were using do?
In any case, you want to eliminate as many variables as possible, as best you can.
I think you're missing a big part of NSParadox's point. He said:
A level playing field is possible only by maximizing the performance of both platforms.
Instead of eliminating variables as you suggest you should replace them with the value that maximizes performance.
I think if you take "another variable that ruin the scientific process" to it's extreme you'll end up needing to get rid of other things, like AltiVec and SSE2. Sure, these two things are similar, but they're not the same. Better just stick to load, store, and arithmetic instructions, because everyone's got that.
Yes there is a VM concept in every compiled language, Fortran is a VM concept. However there is a big difference in implementation, in Java the bytecode is an actual microprocessor instruction set. In CLR it is an annotated code tree. That does not mean that.NET has a concept that is analogous to the Java sandbox VM model, it does not.
This isn't really correct. Both execute stack based instruction sets. There are differences, but they both certainly have instruction sets. Furthermore.NET does have a sandbox model - it's security policy can be fine tuned, including preventing filesystem access or reflecting over private members.
Finally, I think you've missed what makes the CLR not a VM. That is the fact that it has fairly seamless integration with unmanaged code. This is really shown w/ MS'es C++ compilers which can compile both IL and x86 assembler into the same executable. I'd say it's more of a virtual OS + component object model (which, one could argue, is part of an OS anyway) than a virtual machine.
Re:C++ will let you do anything!
on
Hijacking .NET
·
· Score: 1
There is no guarantee that your malicious class with extra members or changed access specifiers would have the same memory layout as the original for either its data members or its virtual function table (assuming it even has one, though all major implementations use that technique at present).
V-Tables only get generated for classes that have virtual members. That would include having a destructor. Otherwise the compiler will know it can just compile everything down to straight calls w/ no indirect (why pay the performance penalty?)
Re:C++ will let you do anything!
on
Hijacking .NET
·
· Score: 1
If a company really wanted to protect the implementation from most programmers, they would distribute the object code and the dot h file -- the linker won't allow changing the dot h file in this way.
This is just so obviously wrong. The linker doesn't even touch your header files, the compiler does. And the compiler doesn't touch the lib files you're linking against, the linker does. And the linker and the compiler are (generally) seperate programs. Therefore neither one has enough knowledge to prevent you from doing anything. Thanks for playing, please try again.
Slashdot Mirror
I voted for Nader in the last presidential election. The fact of the matter is I would not have been satisfied with either Gore or Bush as president. And if I hadn't voted for Nader I would have voted Libertarian (and did infact vote Liberterian for all the other candidates where a Libertarian candidate was available).
The reason why Gore lost (for varying definitions of lost) is not because of Nader. The reason Gore lost is because of Gore. Gore could have advocated policies that would have made the Nader voters vote for Gore. But he didn't. And maybe if he did he would have had less votes anyway. Hell, Gore could of even tried trumpting the successes of the administration he was a part of. But he couldn't even do that. Or Gore could of tried showing a consistent person at all debates, rather than confusing the voters with who is the real Gore. Or Gore could have done many other things differently...
Let's turn this around. Let's say Gore won (for varying definitions of won) the last election. Would a vote for the Libertarian candidate have been the same as a vote for Gore? I mean, isn't it obvious that a Libertarian would vote for the Republican candidate if they hadn't voted for the Libertarian candidate? Well, actually it's not.
The fact of the matter is that I, and obviously many others, do not want to and will not vote for the lesser of two evils.
People who would have liked to Gore win or today want Kerry to win love to say this. The fact of the matter is some of us disagree with you and don't want either of the major candidates to win.
FYI When I voted for Gore my state wasn't up for grabs. This year my state is up for grabs, but I haven't made up my mind who to vote for. Probably back to the Libertarian candidate, I'd like to see some fiscal responsibility, and I don't actually believe that Kerry will bring that and I think Bush has proven he's not up to the task. I can balance my checkbook, why can't the US Gov't? They make a lot more money than I do.
Maybe he bought some imported goods with it. That'll help the economy, just not the US economy!
We do have this massive trade deficit thing going on...
I haven't played too much with generics in C++, but it did seem to involve a lot of excess object creation which isn't too good for speed.
.NET (the Java & .NET way to solve the problem is try/finally blocks all over the place).
C++ does involve a lot of object creation. But good C++ doesn't involve a lot of object creation in the heap, it's on the stack. It's all about Resource Acquisition is Initialization. That's where you have a class, you declare it locally on the stack, and when you exit your method the class's destructor is ran. Of course, if your class is small enough all of this gets inlined. It's really a pretty elegant solution. A lot of people (probably converting C++ programmers) seem to be unhappy that you can't do the same thing in Java or
Anything that you'd store in the heap would be long living objects but the major of your object creation will be on the stack. So it's really not as bad as it looks.
1. They are convinced the monitor is actually the computer. I don't know what they think that big tower does, but since they have it piled high with boxes, blankets, and it holds up their space heater, they've more than likely forgotten that its there.
:)
Oh, come on, everyone knows the big tower is the hard drive!
I didn't know that the free compiler only supported C#. I stand corrected.
.NET Framework SDK includes the C++ compiler. I don't believe it does any optimizations (mov eax, [ebp-8]; add eax, 2; mov [ebp-8]; eax mov eax, [ebp-8]; ...), but I've actually used it to compile stuff.
I hate to correct you twice, but the
C/C++ malloc routines can do the exact same thing as what you're describing.
.NET) has is it can move memory around, defragmenting it during the process, improving locality of reference, etc... But even that can be done in C/C++ with a compacting garbage collecting memory allocator & using handles to all of your memory.
The real advantage Java (and
My favorite BBS memory has to be doing modifications to WWIV. It's the way I learned C and it was a lot of fun.
:) I have many friends still to this day that I gained from BBSes. So it's really had quite an impact upon my life, amazing.
WWIV was the most popular BBS system in my area, and of course it had it's WWIVnet that had message boards networked across the country.
On WWIVnet people would post mods to the source code for WWIV (which was available if you registered for $50). I got $50 from my Mom so I could get the source code (being around 14 at the time). I started downloading the mods from the local BBSes and the message boards and modifying the code. After a while I started trying to make my own modifications and when successful sent them out to boards (a couple of popular ones being a conferencing system and a vertical chat modification).
Anyway, it's amazing to think about how much I sucked at programming back then, but it was a great start.
Oh, and the people were great too.
(Apparently there's a WWIV 5.0 beta now, years and years later. Occasionaly I check up what's going on, and this seems fairly new (last 6 months?). It's amazing it's taken this long though - I was able to port WWIV to ncurses on Linux in a weekend.)
And while you're right about complex problems taking a special kind of insight to solve, the truth of programming is that it's largely simplistic tasks broken up by the occasional bout of complexity. Usually, that complexity is easily decomposed into many more mundane tasks. Usually, working hard can almost be a substitute for being clever.
:). So I believe that's really an orthogonal issue to programmer brilliancy, but it certainly is an issue that should be addressed with all programmers on a project (addressed as in having code reviews that check for conformance).
I think you've hit the nail on the head, but there's two sides of this I think still make the brilliant programmer stand out.
First, the brilliant programmer recognizes this and doesn't get flustered by the complexity. They just attack the problem in a thoughtful and efficient manner. That probably includes doing the appropiate amount of design work to get a non-crappy solution.
Second they can quickly implement the mundane tasks. Often times "average" people have trouble implementing even mundane tasks, it's really pretty scary.
But certainly everyone should be following coding standards. Your previous complaint seemed to be "a morass of code"; but you seem to be forgetting that any programmer, brilliant or otherwise, could produce that and still follow coding standards
On the other hand, a buffer overflow error that is introduced early on in the process isn't going to be any harder to fix later than it is if it is caught right away.
/* do stuff w/ a & b */ /* a and b no longer used, do stuff w/ buf */
Consider the code:
void foo(char *input) {
int a; char buf[25]; int b;
strncpy(buf, input, 25);
}
Let's consider the case of having an input string 26 bytes long including the NULL terminator. If strncpy has an off by one error it'll NULL terminate the string (write a NULL at buf[25]). buf[25] is most likely REALLY a byte in either a or b (depending on how the compiler lays things out on the stack). So buf appears properly terminated to any functions that operator on it from here on out, even though there's no NULL anywhere in buf[0] to buf[24].
But then someone notices the buffer overflow in strncpy. And they fix it. Now buf is not properly NULL terminated and the program blows up later because of this (potentially later copying string they thought was of a certain length (they used strncpy!) into the heap , overwriting a vtable, and later doing a call into some random address).
So now you either need to not fix strncpy, or fix both strncpy and this other program. If this other program happens to be a library that you don't have the source code for, and lots of people use, what do you do?
It's certainly a simplistic example. strncpy has odd semantics (not guarenteeing NULL termination), and in this case there were 2 bugs. But more complex situations like these can and do crop up when you need to maintain compatibility between multiple software components. So now you ship your "fixed" library and suddenly tons of other programs are broken in odd ways. Then they have to fix their software, and many customers are experiencing cascading upgrades (if they're lucky and can get the upgrades!)
I think the point both Jobs and McNealy were making (probably tongue in cheek in both cases) is that nobody at Dell is concerned about what a "computer" ought to be. They have been phenomenally succesful at transforming parts from a variety of suppliers into computers on people's desks, but their innovation is almost entirely in different fronts of operations management. (Not that there's anything wrong with that.) Apple and Sun, and Alienware, for that matter, define the nature of what they sell in a way that Dell doesn't.
And this leads to an obvious question. Dell is able to sell products that meet millions of customers needs. They certainly sell more computers than Apple and they certainly beat Sun on desktops. So what is the innovation that Apple and Sun are bringing to the table? After all, with almost no R&D, Dell is able to sell a highly competitive product at a lower cost. I don't think there are too many Dell customers who thought they were settling for less.
I think the answer's more obvious for Sun in the monsterous machine catagory. But even that is looking rough as x86 scales up and out.
You have a point. Any extra software I install will be left up to me to keep up to date. This is how it works with any system though, and unless we want to allow a pretty intrusive system scan by some 3rd party it is probably how it is going to continue to work.
I don't think this is true. chainsaw1 mentioned Debian, and it explicitly does enable this capability without an "intrusive system scan by some 3rd party".
All it takes is a standard format and a central package management utility that can be pointed at multiple sources for updates. Debian's implementation is a text file that points to multiple servers, and the sys admin can update it to point at their servers of choice. Debian then builds the package database from all the available servers, and allows you to select upgrades (or pretty much performs auto upgrades) from the available packages. I believe the only information sent to the third party (other than typical TCP/IP info) is the packages you want.
I don't know how secure the distributor->distrubutee channel is (I could imagine many possible implementation pitfalls), but the dpkg & apt are certainly not instrusive.
I'm sorry, this is not a design methodology. I could maybe accept a development methodology. But part of your design is defining units, and those units should be tested first.
You say "You can unit test against a hypothetical universe. The real one tends to throw you curves in places you didn't know you had places." I assume you meant can't here, not can. First, unit tests are not hypothetical. You have obvious units during development that can be tested (each class comes to mind), you should test them. Unit tests are not designed to test these curves that you don't expect. Unit tests are designed to test basic functionality to get rid of basic bugs. Once you know your basic functionality works, then you start testing the system.
Let's say that I have a program that needs me to implement a custom growable list. Am I going to write the entire program and run it and drive the program to use the list? No, I'm going to write the list, test it, and make that part of the program. Maybe, and in fact most likely, my original tests didn't cover every state. That's why we have integration testing. But it happens AFTER I've verified the basics of the component are functional. If I discover a bug that my original unit tests don't cover, ideally I should go back and add a test to cover that.
Ss for "sounds like evolution", you say that as if it's a good thing. Yes software design isn't solid at the beginning and it evolves in practice. But that does not mean that there aren't explicit units that can be tested during this evolution before the whole is tested.
I'll close with final thought (god, who the hell am I, Jerry Springer?): If you test with the smallest scope first your time spent debugging will be minimized. If you throw an entire program together, and start testing, all of a sudden the bug you're tracking down could be anywhere in the program. If you are debugging a unit test, your bug is in the unit. It's much easier and faster to debug. And THAT'S why you write unit tests first!
Just FYI: In Folder Options (Start->Control Panel->Folder Options) there's a choice on the View tab "Display the contents of system folders". You want to check this, and your "problem" will go away. No registry key setting necessary.
While that is true, it must be possible to create such a body; after all, engineers, lawyers, doctors, etc managed it, even tho' all those professions change quite rapidly. The medical profession, for example, hasn't held back the development of CAT scanners just because most of its members qualified on stethoscopes (for example). The engineering profession hasn't held back the adoption of CAD even tho' when it was founded the slide rule was the computational tool of choice.
:) ). Or should they be like doctors, and if they introduce bugs they're liable to be sued for malpractice? And once again, I have to ask about the VB developer (and I hate that I have to keep coming back to VB developers, but they are a large group, and they and their employers would suffer the most from legislation in this direction).
While I'm not sure that it's impossible, I think there is a significant difference in scope between these professions and software development.
Lawyers are scoped to their state, by their state bar, and their only real requirement is to zealously protect their client (or prosecute the bad guys). Doctors are scopped to the human body, and while there's many diverse areas throughout the human body, they all pretty much have the same goal of improving health. Engineers are scopped at various different levels (Electrical, Civil, Mechanical, etc...). Generally speaking they need to build things that don't fall over within specified tolerances.
Software on the other hand crosses across many different areas: VB database front ends, applications, OSes, medical applications, nuclear power plant software, airplanes, cars, games, PVRs, microwaves, MP3 players, etc... And all of these have widely varying requirements. Should the VB database app be held to the same standard as the medical applications? Probably not.
So if every VB programmer had to be a certified Software Engineer then the price of VB developers would sky rocket. And for what benefit? The corporations are satisfied with the quality they are getting today. So do we have a certification for every different category? Do we have a certification with different levels of reliability and quality?
And to get back to the other professions, should programmers be like lawyers: they just need to do their best, and not appear incompotent to their peers? Or should they be like engineers and specify tolerances ("This program will work fine as long as all inputs are valid."
jc42 inadvertantly pointed out that there are already many certifications. I think the real "problem" is there's no demand for certified people.
What you describe is a testing methodology, not a method to increase software robustness. While you're fixing bugs that you know about if you miss one buffer overflow then the app crashes and burns. There's no safety factor there.
.NET or Java (which introduce their own problems w.r.t. unexpected memory allocations and handling those), and restartable in-proc components isolated through various techniques (seperate memory heaps per component spread throughout the process to reduce chances of corruption, structured exception handling at component boundaries, etc...). And of course if you're writing in C++ doing things like using a conservative GC to prevent one bad class from running your process out of memory is another way to introduce wiggle room.
There are ways to increase reliability beyond this level. Examples include restartable out-of-proc components, VMs such as
So those are some ways to introduce REAL wiggle room in an app, but very few people go to such lengths (and not many major commercial apps run on VMs). You still need to do the testing to get rid of the bugs, but when you miss a major bug you've reduced the consequences and scope of corruption.
Also your testing methodology seems to be backwards. Unit testing last? How the hell can you start integrating stuff together if you haven't made sure the basics work yet? That's just asking for a disaster, where you have a huge pile of crap that's completely broken and undebuggable.
An electronic voting machine which should produce a printed record. Some type of blind-numbering system should be used for identities -- crypto theory has plenty of theoretical models for this.
I think we definitely need a printed record. I imagine something like an ATM machine that prints your voting results. I don't think the cryptography is necessary though, all you really need is the same hand-submission process we have today. You may want to print the place the voting occured though (in some cryptographically strong way, eg sign the ballot with the voting place's private key). I think adding anything personally identifable, even if cryptographically secured, is asking for trouble.
I would then think we would primarily use the electronic results, but we'd have a physical backup if there were ever any questions, and that backup would be more readable then the one we have today.
The best thing about a plan like this is that it's SIMPLE, and it's essentially what we have today, just modernized a little.
You say this like you can barely believe it - a small clue though, Windows XP doesn't have seperate data and boot partitions. Never has. 5 seconds of looking in "My Computer" in Windows would have shown you this.
/mnt/win_os, /mnt/win_data1, etc...). The alternative to this would be Mandrake looking into the Windows registry to see how the user's drives are lettered so it gets things right - I'm betting that Mandrake isn't doing this (but I could be wrong).
Be all that as it may, don't make Windows out to be bad just because you assumed it worked the same way as Linux.
Not only are you correct that Windows shouldn't be blamed for this (although I think yuri's description didn't really blame Windows, it was more of a factual recount of the events) I would blame Mandrake. Mandrake is the software that is displaying "/mnt/win_c" and "/mnt/win_d". So obviously his machine had 2 partitions, one of these was probably a restore partition, but Mandrake did a poor enough job of identifying them and the user took the wrong action because of this.
Mandrake *could* look at the contents, search for a windows directory, or take some other action to properly identify the drives so this sort of user error doesn't occur in the future (eg,
Anyway, I'm way off topic here. Modding razors and modding the Xbox are two different issues, legally and physically. The xbox is a PC that will only run signed code. Well, stick in a modchip and it can run linux. How can that be illegal? You own the modchip (and the IP contained within is yours / you have a license), you own the xbox; you have no intention of using MS's IP. Again, how is that illegal!? You're doing the stuff to something you own.
I may be out of date, but I thought the majority of mod chips contained the XBox (or PS/2) BIOS code in the chip - only hacked. Therefore it's been a copyright violation to distribute the mod chips, and that's how the IP gets violated. It's a similar situation to IBM's BIOS needing to be cloned (as in reverse engineered, documented, and rewritten) before "IBM PC compatible" computers could come about.
Now, IANAL, it seems otherwise it's perfectly legal to hack the XBox. Of course, the DMCA may have something different to say, but I don't think Microsoft has made any DMCA claims against XBox hackers (again, I may be out of date).
(and I'd say you were pretty on topic - I was much more off topic on my previous post)
Thanks for the link - it was very interesting even though it only reinforced what I already knew:
1. Libertarian Candidate (100%)
I'm in total agreement with you here. I look at any candidate, and sure, they sound good for some things. But then there's ways that are just begging to become huge governmental wastes. And then you look at the other candidate, and it's the exact same way, but he wants to screw us from the other direction.
Unfortunately I look at Libertarian's and they're not completely on target with my beliefs, but their the least evil of all the choices.
The problem that I see with the Libertarians is that corporations get too much free rein. We give corporations an extremely large benefit over individuals (limited liability being the big one) and we should demand something (or many things) in return. The Libertarians want to remove many government intrusions, but they don't really propose how the services removed will be replaced. I think we should stick it to the corporations to solve that problem - but Libertarians don't agree (maybe some libertarians do agree though).
But that small gripe still doesn't stop me from voting Libertarian.
I don't think Gillette or Bic would start suing people for making razor blades that happened to fit their razor handle. They'd probably try to make their blades better so no one would want to use the cometitions, or they change their business model.
And you'd be wrong. Gillette will sue you if you violate their patents (and even LOOK like their product, let alone interoperate). And they have patents like this one, and this one and many more pertaining to razors. Not to mention Gillette was the company that patented the original safety razor - so they've been at this for a while.
The problem with your analogy is that in Gillette's case they patent the razor blades AND the interface between the two. That means you can't clone their blades, and you can't connect without their handle violating a patent.
Imagine if Ford invents a new way to fill your gas tank. Only licensed gas stations can use this patented nozzle. You'd effectively be paying Ford for a percentage of your gas. Could they stop you from hacking the Explorer? As long as you don't use their IP, probably not. Compatibility is something people expect in their gas tanks, so that will never happen. But most people seem fine with it happening in razors, and ditto on consoles. Consoles obviously can't patent the execution of code, but they can copyright bootloaders and BIOSes.
My quibble with explicitly checking for NULL pointers is that you're only going to catch the case when the pointer is NULL. Just about any other bad value is going to give you a segmentation fault (which is exactly what a NULL pointer is also going to give you). I would consider such a check of more value if you also bothered to check all the other pointer values it shouldn't be, but that's something which is mainly only practical at the kernel level. Otherwise, I find all the extra NULL checking pedantic.
In C++ it would be pretty easy to verify a pointer. Step one, implement your own heap with an address checker. Step two, ensure all classes have vtables. Step three, Check both the memory address & vtable of the object. It's all quite extreme to comparing a value to NULL though, and there's *still* classes of errors it won't catch (for example, passing a freed & reused address that got reused by the same type). That aside, there's a significant difference between a NULL pointer, and give a good example below. So given the simplicity of the check, and the fact that it does often have meaning, I think it's a good idea to do the check. Not necessarily for all internal APIs, but certainly public APIs. A good error return code is quicker to solve than a seg fault.
The only place where I like to put NULL checks is where passing a NULL pointer has some sort of meaning in the API (in which case, it's obviously necessary). Doing so helps signal to anyone reading the code (mainly myself) that a NULL pointer value has significance beyond a possible segmentation fault. That would be drowned out if I put a NULL pointer check everywhere just to return a marginally useful error code, which I would also have to check for, rather than the program crashing in a clean and spectacular manner (the fail fast mentality).
Now, this depends on how you implement it. If you do the old if(arg1 == NULL || arg2==NULL) return(NULL_POINTER_ERROR) at the top of every function (or throw an exception) it'd be immeditely obvious you don't accept NULL pointers on some functions - no matter what you do else where. You bring up the "fail fast mentality", and I think that generally applies to when you CAN'T handle the error. In general you can handle a NULL pointer before you dereference it. So there's no need to bring down the entire application. What if someone did:
char *buf = new buf[181];
result = fill_my_buffer(buf);
If you run out of memory you can pass a NULL pointer. Should fill_my_buffer really crash the program, or should it return a meaningful result (that could maybe be propagated up)? It is an easy error to overlook, what would you prefer an application you were using do?
In any case, you want to eliminate as many variables as possible, as best you can.
I think you're missing a big part of NSParadox's point. He said:
A level playing field is possible only by maximizing the performance of both platforms.
Instead of eliminating variables as you suggest you should replace them with the value that maximizes performance.
I think if you take "another variable that ruin the scientific process" to it's extreme you'll end up needing to get rid of other things, like AltiVec and SSE2. Sure, these two things are similar, but they're not the same. Better just stick to load, store, and arithmetic instructions, because everyone's got that.
Yes there is a VM concept in every compiled language, Fortran is a VM concept. However there is a big difference in implementation, in Java the bytecode is an actual microprocessor instruction set. In CLR it is an annotated code tree. That does not mean that .NET has a concept that is analogous to the Java sandbox VM model, it does not.
.NET does have a sandbox model - it's security policy can be fine tuned, including preventing filesystem access or reflecting over private members.
This isn't really correct. Both execute stack based instruction sets. There are differences, but they both certainly have instruction sets. Furthermore
Finally, I think you've missed what makes the CLR not a VM. That is the fact that it has fairly seamless integration with unmanaged code. This is really shown w/ MS'es C++ compilers which can compile both IL and x86 assembler into the same executable. I'd say it's more of a virtual OS + component object model (which, one could argue, is part of an OS anyway) than a virtual machine.
There is no guarantee that your malicious class with extra members or changed access specifiers would have the same memory layout as the original for either its data members or its virtual function table (assuming it even has one, though all major implementations use that technique at present).
V-Tables only get generated for classes that have virtual members. That would include having a destructor. Otherwise the compiler will know it can just compile everything down to straight calls w/ no indirect (why pay the performance penalty?)
If a company really wanted to protect the implementation from most programmers, they would distribute the object code and the dot h file -- the linker won't allow changing the dot h file in this way.
This is just so obviously wrong. The linker doesn't even touch your header files, the compiler does. And the compiler doesn't touch the lib files you're linking against, the linker does. And the linker and the compiler are (generally) seperate programs. Therefore neither one has enough knowledge to prevent you from doing anything. Thanks for playing, please try again.