Environmental concerns are legitamate - the problem is that a large number of environmentalists are extremist lunatics. But really, its no different then if we had people like RMS and JonKatz speaking up for us computer people. Just because the people you hear about in a movement are idiots doesn't mean the movement is wrong.
True, but there is also a decisive lack of concrete evidence (non-circumstancial) that would say the climactic shift has anything to do with humans. Natural cycles of planetary systems modify temperature, as do ocean currents (which do change frequently) so I personally don't think humanity is doing much to contribute one way or the other. If the ocean currents stop or slow, we'll have a mini-ice age, then all your climactic shift concerns will be going for the other way.
For another thing, humans will occasionally make a mistake. Poof, security hole. Compilers don't make those kind of mistakes. Why not let the compiler do it, both for coding speed and security reasons?
Which is why most security-based applications (aside from openSSH, which I wont get into) don't have many problems aside from implementation logic issues. If you design and code with security in mind, it's a moot point.
Classic "uh-oh, I'm losing the argument" cop-out. Oh well.
No, it's the "I'm arguing with an idiot with no scope of reality" statement. I didn't say you said that verbatim, but what you did say was just as idiotic. You shouldn't spend less time auditing. You should not sacrifice security if the application should be secure (always). Any developer of mine that decides he doesn't need to audit, or spend less time than what should be applied, will find himself quickly unemployed.
Since there are (for example) no double free errors in Java, you don't have to check for them.
Pairing alloc/free's in properly designed code takes all of about a tenth of a second. Auditing code ensures good design, not syntactic checking. Good design will eliminate most of those problems. It seems you don't know C well enough to know that at a quick glance you should be able to see any of the conventional mishap-bugs (double free, buffer overflows) relatively easy.
I agree they can track to a large but limited extent what I do now, however in 5 years when this tech has matured they will be able to track everybody in a ruthlessly efficient manner and easily share this data with anybody willing to pay for it.
You just don't understand that all of this is available today. Anybody who wants to pay for it can get it. End of story, nothing new to see here, move along.
Thanks by the way for the backhanded compliment, its nice to see that you at least found it creative in some way:)
Creative, yes. But again, there are so many ways around privacy invasion that RFID tires on your vehicle shouldn't hit the bar. You do realize no one in the world would care about RFID tires if there were transmitter boxes in cars similar to whta the rental cars use? RFID are a pointless step in doing only what they are designed to do. Other methods are worth getting worked up for, this is just pointless.
Java isn't any less "free" than C even though it is a much more secure language.
Garbage collection is not secure. Safe pointers is not secure. Java is not secure. C is not secure. A language can be as insecure as the coder tells it to be. Nothing you want to believe will change this.
If you use a language with security features built in you spend less time auditing and more time being productive.
If you worked with me, you would be fired right now. This is the exact mentality that leads to security problems in the first place. "The language is secure so I don't need to audit"
No offense, but you really just destroyed your credibility with me by saying this, and I'm done talking to you.
Yes, absolutely. At the beginning of college I was a total C cowboy, but I have grown out of that. Now I am studying programming languages for my PhD so I have more refined tastes.;) But unlike a lot of programming language researchers, I really do a lot of practical programming. I don't think C was designed to be bad, but I do think that it is no longer an appropriate design for application languages.
Ok, most of these security problems happen in one function that would have failed auditing. Whether it is a C, Java, Perl, Pascal, VB program.. doesn't matter. The point is, it will always, always, without exception, rely upon the developer not fucking up. If you remove the capacity for pointers, they'll find some other way to exploit the system. There is no such thing as security.
I'd like to respond to every part of your comment, but that's a lie. I really wouldn't. You are amazingly paranoid. Everybody can track you just as much as they want to, right now. RF transmitters require a reader within 2'.
OCR + Camera equipment is dirt cheap too, so they can take a snapshot of every vehicle passing every quarter mile. But who is going to? Who really cares? Who wants the data? Nobody. That's right, you aren't that special that people are going to invest billions of dollars to track you. It'll be used for it's purpose because you just aren't that special.
Expect toll boths, and other government locations will only use it both to aid in capture (reference vehicles with oustanding tickets or whose owner has a warrant) and for automated billing. If you think that marketing firms are going to invest in the technology, make a deal with every city/state roadway system, and have targetted adverts that show up for that 1/10th of a second that you and other drivers are sharing, you are a plain idiot.
Why don't you put your creative energy towards something beneficial instead of finding idiotic ways your privacy can be invaded that can already happen? I can buy a CD that has your VIN, address, and all sorts of personal information on it, right now -- go educate yourself and you will realize that your privacy now is only available because no one cares about you.
But if the language is inherently insecure, it is also partly the fault of the language.
Ok, the language isn't insecure... well, you can make it secure, and have setuid wrappers on all your scripts and have a truly secure implementation. It would constrict freedom. The language allows people to write insecure code. All the recent SSH notifications on CERT were implementation, and not C-specific problems.
The important thing is that people realize that C programmers make security mistakes because C is an insecure language, and don't use C in security-critical areas, or review security-related C code extremely thoroughly before release.
C programmers make mistakes because they get lazy and don't properly audit their code. After every function you write, simply give it another good look and make sure it cleans up after itself, and maintains proper design. It's perfectly fine then. Like I said in another comment, I've worked on a project that had a bit over 600K lines. You could have done the same in about 250K or so, but it was 600K because everything was modularized. Taking design queues from Knuth, it was extremely robust and very stable. No memory leaks, no buffer overflow problems. Everything that got alloc'd actually had a comment where the variable would get free'd at.
It's called good design of software, not good design of language.
This is totally wrong. How can you claim this?? Safe languages would NOT have been vulnerable to the integer overflow attacks. The only recent ssh flaw (AFAIK) that was language-neutral was the one where the passwd file was being improperly interpreted on some platforms. The rest would not have been exploitable if sshd were written in Java, SML, O'Caml, or another safe language, period.
There are not enough daemons written in other languages to determine if security exploits would be present in them. No one thought bind and sendmail were so insecure when they implemented them. A careful look would have revealed that, just because Java so far doesn't look insecure doesn't mean it is.
But you are wrong about SSH, go to CERT and search for SSH. The first 5 (that's all I checked) were implementation problems _NOT_ buffer overflow problems.
C behaving as it is designed is no consolation if the design is bad
The design isn't bad. At the time it was developed (1970s) it was revolutionary with what it could do. Programmers had a better sense of constraint (working in smaller memory spaces) as well as more discipline. I'm curious, but do you actually know C? I mean really know it. Know the caveats of realloc? If so, I'd find it odd that you think C is bad by design.
Yeah but people just can't secretly scan your VIN every time you go through a tollbooth, stop at a traffic light (You KNOW that those wires in the road don't really make the light green), or drive through McDonalds.
You are definitely right, it's absolutely absurd that they're doing this. Next thing we're going to be given an identification number that we have to prominently display on our car that is linked to our VIN that _anybody_ can see and find out information about us!
I think you must have never written any big software, because it's not as simple as you think. Sorry, but buffer overflows are that simple.
Look at the complexity of the recent SSH bugs, for instance. Human error is universal, even if you are trying hard, and even if you are an excellent programmer (see the list in my previous post). And it is extremely dangerous. Regardless of whether this is C's "fault" (can a tool really be at "fault"?) or the programmer's "fault" for choosing a tool that is so dangerous, it is clear to me that C is a bad language for writing security-critical software.
Again, C operates exactly as designed. The SSH exploits could exist regardless of what language. Saying the reason why there are security exploits is because software is written in C is exactly like saying car crashes occur because people drive sports cars.
I think you missed my point: The authors of *gcc*, which is THE quintessential C program (in a strong sense), have found it so difficult to manage memory manually that they've resorted to using a garbage collector, despite its deficiencies. If anything is a testament to the inappropriateness of C, that is.
Did I ever say it wasn't a pain in the ass? No. I said it operates exactly as it is designed, and nothing more. There is nothing else aside from that. I'm an advocate for best-tool-for-the-job, if that requires C than it's the best tool.
Accusing a language which functions according of spec of being dead and the cause of security concerns is stupid. Yes, C is harder to write secure applications in. No, it doesn't mean it should die. Yes, you must be very vigilant while writing C.
As for GCC, the C based garbage collection is not bad when used properly. It is not as full featured as Java, but it still works. I'll still code in C++ for most of the projects I work on because it is a good trade-off for power/security.
The faults of everything you list are the faults of people. I've worked on 600K lines of software written in C. It was all very self-contained, and didn't have any buffer overflow style problems. Why was it so big? Because it was designed with security in mind, and was very verbose and robust in what it did. If you audit every function thoroughly, garbage collection becomes useless.
I was working on this piece of network code that was written in C, I had an off-by-one error that was really screwing everything up. My code was very tight, and had another set of eyes look at it and was easily able to spot my mistake.
Well written code, regardless of language, will do exactly what you tell it to do, regardless of the complexity of how you tell it to do it.
Well I guess that makes all VB coders geniuses then, since they never get buffer overflows. They must just be the greatest bunch of programmers around.
It's just hard to kill people when you are driving a go-cart in a predefined track.
That means assuming coders will make mistakes, no matter how good they are. Even the best coders do make mistakes. In a language designed to be secure, the impact of coding mistakes is minimized.
C was never designed to be secure. Blame C programmers for insecure code, not the language. There are plenty of steps you can take to ensure safe C code. If you expect a secure application, and you use C, than take the proper steps to make it secure. It's user error.
It's not a stupid attitude, it's a philosophical attitude. I'm not defending C, but it works exactly as designed. End of story.
I blame the language. The reason is this: C makes it so easy, and so dangerous, to make such bugs, that they are extremely common, even among the best programmers. I challenge you to explain why some of the most revered software created by some of the most revered C hackers has had buffer overflows, if it's not the language's fault:
The language operates exactly as it is designed. It is human error. Not language error. Just because a gun makes it easy to kill people, doesn't mean guns kill people.
Things like the operating system kernels are not so easy to rewrite in a modern safe language, but network daemons are an *obvious choice* and are also the most dangerous!!
It really is not so hard to never use an unbounded function (snprintf instead of sprintf) or to count malloc() and frees() and if you do your code well structured, than it works. If you test your code with code that will cause buffer overflows everywhere, you will find them. If you do your math correctly, you will find them. If you don't, it's human error.
By the way, C garbage collection is crappy compared to built in support in a modern language: It needs to be conservative, and can't compact the heap. (Of course, that doesn't stop the authors of gcc from using it!)
Anything external will usually be less reliable and robust than something built-in to the language specifications. But, I would trust the authors of gcc more than you, no offense mate.
I was under the impression that first post usually signified the first top-level post in a thread.
That's "Frost Pist!", this is merely the first response talking about the parent's parent's parent's fascination with peepholes. Still a first post, otherwise it would be redundant instead of funny.
Anyway, we're way off-topic. I didn't realize that people actually cared about getting the first reply to a reply to a topic.
Yeah, off-topic is fun. If it's funny, people care about getting it first otherwise they turn into another redundant post.
I looked at the advisory expecting to see the words "buffer overflow", and instead saw "malloc mistake" (same pointer can get freed twice in some circumstances). Both of these amount to the same thing, getting nailed by C's lack of automatic memory protection and garbage collection.
It's not the language, it's the coder. Just like it's not the car, it's the driver, if someone causes an accident. Replacing every sports car with a Kia isn't going to stop accidents. Educating drivers on good practices is....it needs to be scrutinized very carefully before deployment.
Uhm, no shit? I think you should write a book! Seriously, saying that there should be code reviews before software gets deployed? That's an awesome idea, I think I'll start implementing it into my own development.
Again, the problem is not the language, it's the coder. People make mistakes, languages do not (compilers on the other hand). Don't blame a language for operating exactly as it's designed to.
You can do garbage collection in C just fine, with external libraries.
Isn't it funny how innovative and useful ideas stem so naturally from free ideas in the public domain?
Or maybe it's funny how innovative ideas stem from products that are heavily patented and protected. Hence how capitalism works.
Now if Microsoft or Palm had the patent on scrolling virtual windows we may never have seen this new implementation at all (not to mention how difficult it would be to play some RTS games).
Wonderful FUD, I applaud your troll. Even got modded up, very nice. The problem with this is that Xerox would have had the first patent on it. If Apple would have patented it, Xerox would have stepped in. It was the non-innovative approach. Anybody would do it, as scrolling was around since there were text terminals.. so what if it's on a "virtual window" -- your scroll lock key was there long before hand. Oh wait, this actually dates back to the BCs with scrolls that you wound or unwound manually.
It's a good thing that everybody irrationally hates patents, otherwise you people would pull your heads out of your ass and come up with a legitimate reason why they're bad.
You posted a reply to a comment and thought you might get first post? Your low user id betrays you!
Uhm, "first post on this" meaning the first post discussing the parents peephole affinity.
The bus left. Everyone was on it. Except you.
Re:What is it going to take
on
F'd Companies
·
· Score: 1
As a start-up today, one of the biggest hurdles is getting a potential customer to take you seriously.
If you have a sound business model and don't stress being a ".com", than no, potential customers will do what they can to save money with a reliable solution. Potential partners and investors, those are hard to find. At least ones you want.
I have to work very hard to convince a potential customer that i'll still be here in 12 months time, and it takes human intervention - i've not yet figured out how to do it through the website.
Provide a good site, with low overhead, and say that you are profitable. If they still think you're going belly up in 12 months, they're idiots and you probably don't want to do business with them anyway.
pilot That should be polite. I was setting up my palm pilot over the weekend, and typed pilot more times than I can count.. autopilot is a great thing...
I installed it for my girlfriend as well. But finding decent drivers for peripherals is still a pain in the ass.
Which ones? I have a Sony CLIE, digital camera, all sorts of things that work flawlessly. The hardest thing I have to get running was the CLIE which required editing the devfsd conf to chmod the permissions and add myself to the group. Anyone with rudimentary knowledge should be able to do that.
As it stands now, a casual user can get by with Windows as they can simply go to the manufacturers site and grab a Windows driver on their own. If I asked her to grab the tarball and install it, she wouldn't know where to start.
Now it's RPMS. Or debs. Or whatever. On my desktop machines, it's RPM based because I want it not only standardized, but a target install that requires little intervention on my part. I'm a bit more strict on my workstation, but for other systems (something that isn't going to have software developed on it) most rpm's work better than any windows installer I've come across. Of course I don't use windows all that often.. most games require you to choose not to install a bunch of stupid things, or click next a few times for no apparent reason other than to display a few panes of path information or system information that less than 5% of the population can understand, either by choice or by knowledge.
Linux is just as ready for the desktop as Windows is, the problem is it's different. If someone starts with Linux they'll be just fine using it than Windows or Mac OSX. It's upgrading and, as you said, unsupported peripheral devices that have issues. A ton of devices are supported at this time however, at least most of the common ones.
Personally i like oyu understand the system but wheni try to show people around linux they use it in much different ways.
My girlfriend, a massage therapist. She clicks on the icons and it works. The only thing I had to explain to her is shift+space is the kanji key.
It seems to me to be very easy to jsut check email under linux and at first i assumed anyone could do it untill i saw people try. They have difficulty and it made me realize no matter what i wont see a computer just like any casual user.
Install KDE. Click "K" button. Networking -> Mail -> Choose One. There is no "Try" here, Linux is suitable for the desktop just fine now, but it's not idiot proof and idiots break their computers all the time.
Ok Mr. Software developer you sure do represent the casual user.
What about my girlfriend who uses KDE? How does Lindows support Japanese input? Is it as easy as it is in Red Hat or Mandrake? Especially if she buys it from WalMart?
I'm not that different than a casual user, because when I'm not programming, I am that casual user. I check my email, browse the web, use AIM. It doesn't matter to me what system I use as long as it works. I do not want to mess around with any form of system maintenance when I need to work, or when I just want to relax and read the news.
My servers are for customization and optimization, a desktop computer is supposed to work. Red Hat does that very well.
Desktop users dont use Redhat or United Linux, they want something for the desktop,not for hosting servers.
Uhm no. Desktop users do use Red Hat, and Red Hat isn't a server distribution. It is a desktop distribution. It's install is very easy, just as easy as Mandrake.
I use Mandrake, and I'm a software developer. I like an operating system that works. Red Hat works, Mandrake works, Debian works. These are all operating systems that are, in fact, easy to install.
Slashdot Mirror
Environmental concerns are legitamate - the problem is that a large number of environmentalists are extremist lunatics. But really, its no different then if we had people like RMS and JonKatz speaking up for us computer people. Just because the people you hear about in a movement are idiots doesn't mean the movement is wrong.
True, but there is also a decisive lack of concrete evidence (non-circumstancial) that would say the climactic shift has anything to do with humans. Natural cycles of planetary systems modify temperature, as do ocean currents (which do change frequently) so I personally don't think humanity is doing much to contribute one way or the other. If the ocean currents stop or slow, we'll have a mini-ice age, then all your climactic shift concerns will be going for the other way.
For another thing, humans will occasionally make a mistake. Poof, security hole. Compilers don't make those kind of mistakes. Why not let the compiler do it, both for coding speed and security reasons?
Which is why most security-based applications (aside from openSSH, which I wont get into) don't have many problems aside from implementation logic issues. If you design and code with security in mind, it's a moot point.
Classic "uh-oh, I'm losing the argument" cop-out. Oh well.
No, it's the "I'm arguing with an idiot with no scope of reality" statement. I didn't say you said that verbatim, but what you did say was just as idiotic. You shouldn't spend less time auditing. You should not sacrifice security if the application should be secure (always). Any developer of mine that decides he doesn't need to audit, or spend less time than what should be applied, will find himself quickly unemployed.
Since there are (for example) no double free errors in Java, you don't have to check for them.
Pairing alloc/free's in properly designed code takes all of about a tenth of a second. Auditing code ensures good design, not syntactic checking. Good design will eliminate most of those problems.
It seems you don't know C well enough to know that at a quick glance you should be able to see any of the conventional mishap-bugs (double free, buffer overflows) relatively easy.
I agree they can track to a large but limited extent what I do now, however in 5 years when this tech has matured they will be able to track everybody in a ruthlessly efficient manner and easily share this data with anybody willing to pay for it.
:)
You just don't understand that all of this is available today. Anybody who wants to pay for it can get it. End of story, nothing new to see here, move along.
Thanks by the way for the backhanded compliment, its nice to see that you at least found it creative in some way
Creative, yes. But again, there are so many ways around privacy invasion that RFID tires on your vehicle shouldn't hit the bar. You do realize no one in the world would care about RFID tires if there were transmitter boxes in cars similar to whta the rental cars use? RFID are a pointless step in doing only what they are designed to do. Other methods are worth getting worked up for, this is just pointless.
Java isn't any less "free" than C even though it is a much more secure language.
Garbage collection is not secure. Safe pointers is not secure. Java is not secure. C is not secure. A language can be as insecure as the coder tells it to be. Nothing you want to believe will change this.
If you use a language with security features built in you spend less time auditing and more time being productive.
If you worked with me, you would be fired right now. This is the exact mentality that leads to security problems in the first place. "The language is secure so I don't need to audit"
No offense, but you really just destroyed your credibility with me by saying this, and I'm done talking to you.
Yes, absolutely. At the beginning of college I was a total C cowboy, but I have grown out of that. Now I am studying programming languages for my PhD so I have more refined tastes. ;) But unlike a lot of programming language researchers, I really do a lot of practical programming. I don't think C was designed to be bad, but I do think that it is no longer an appropriate design for application languages.
Ok, most of these security problems happen in one function that would have failed auditing. Whether it is a C, Java, Perl, Pascal, VB program.. doesn't matter. The point is, it will always, always, without exception, rely upon the developer not fucking up. If you remove the capacity for pointers, they'll find some other way to exploit the system. There is no such thing as security.
I'd like to respond to every part of your comment, but that's a lie. I really wouldn't. You are amazingly paranoid. Everybody can track you just as much as they want to, right now. RF transmitters require a reader within 2'.
OCR + Camera equipment is dirt cheap too, so they can take a snapshot of every vehicle passing every quarter mile. But who is going to? Who really cares? Who wants the data? Nobody. That's right, you aren't that special that people are going to invest billions of dollars to track you. It'll be used for it's purpose because you just aren't that special.
Expect toll boths, and other government locations will only use it both to aid in capture (reference vehicles with oustanding tickets or whose owner has a warrant) and for automated billing. If you think that marketing firms are going to invest in the technology, make a deal with every city/state roadway system, and have targetted adverts that show up for that 1/10th of a second that you and other drivers are sharing, you are a plain idiot.
Why don't you put your creative energy towards something beneficial instead of finding idiotic ways your privacy can be invaded that can already happen? I can buy a CD that has your VIN, address, and all sorts of personal information on it, right now -- go educate yourself and you will realize that your privacy now is only available because no one cares about you.
But if the language is inherently insecure, it is also partly the fault of the language.
Ok, the language isn't insecure... well, you can make it secure, and have setuid wrappers on all your scripts and have a truly secure implementation. It would constrict freedom. The language allows people to write insecure code. All the recent SSH notifications on CERT were implementation, and not C-specific problems.
The important thing is that people realize that C programmers make security mistakes because C is an insecure language, and don't use C in security-critical areas, or review security-related C code extremely thoroughly before release.
C programmers make mistakes because they get lazy and don't properly audit their code. After every function you write, simply give it another good look and make sure it cleans up after itself, and maintains proper design. It's perfectly fine then. Like I said in another comment, I've worked on a project that had a bit over 600K lines. You could have done the same in about 250K or so, but it was 600K because everything was modularized. Taking design queues from Knuth, it was extremely robust and very stable. No memory leaks, no buffer overflow problems. Everything that got alloc'd actually had a comment where the variable would get free'd at.
It's called good design of software, not good design of language.
This is totally wrong. How can you claim this?? Safe languages would NOT have been vulnerable to the integer overflow attacks. The only recent ssh flaw (AFAIK) that was language-neutral was the one where the passwd file was being improperly interpreted on some platforms. The rest would not have been exploitable if sshd were written in Java, SML, O'Caml, or another safe language, period.
There are not enough daemons written in other languages to determine if security exploits would be present in them. No one thought bind and sendmail were so insecure when they implemented them. A careful look would have revealed that, just because Java so far doesn't look insecure doesn't mean it is.
But you are wrong about SSH, go to CERT and search for SSH. The first 5 (that's all I checked) were implementation problems _NOT_ buffer overflow problems.
C behaving as it is designed is no consolation if the design is bad
The design isn't bad. At the time it was developed (1970s) it was revolutionary with what it could do. Programmers had a better sense of constraint (working in smaller memory spaces) as well as more discipline. I'm curious, but do you actually know C? I mean really know it. Know the caveats of realloc? If so, I'd find it odd that you think C is bad by design.
Yeah but people just can't secretly scan your VIN every time you go through a tollbooth, stop at a traffic light (You KNOW that those wires in the road don't really make the light green), or drive through McDonalds.
You are definitely right, it's absolutely absurd that they're doing this. Next thing we're going to be given an identification number that we have to prominently display on our car that is linked to our VIN that _anybody_ can see and find out information about us!
I think you must have never written any big software, because it's not as simple as you think.
Sorry, but buffer overflows are that simple.
Look at the complexity of the recent SSH bugs, for instance. Human error is universal, even if you are trying hard, and even if you are an excellent programmer (see the list in my previous post). And it is extremely dangerous. Regardless of whether this is C's "fault" (can a tool really be at "fault"?) or the programmer's "fault" for choosing a tool that is so dangerous, it is clear to me that C is a bad language for writing security-critical software.
Again, C operates exactly as designed. The SSH exploits could exist regardless of what language. Saying the reason why there are security exploits is because software is written in C is exactly like saying car crashes occur because people drive sports cars.
I think you missed my point: The authors of *gcc*, which is THE quintessential C program (in a strong sense), have found it so difficult to manage memory manually that they've resorted to using a garbage collector, despite its deficiencies. If anything is a testament to the inappropriateness of C, that is.
Did I ever say it wasn't a pain in the ass? No. I said it operates exactly as it is designed, and nothing more. There is nothing else aside from that. I'm an advocate for best-tool-for-the-job, if that requires C than it's the best tool.
Accusing a language which functions according of spec of being dead and the cause of security concerns is stupid. Yes, C is harder to write secure applications in. No, it doesn't mean it should die. Yes, you must be very vigilant while writing C.
As for GCC, the C based garbage collection is not bad when used properly. It is not as full featured as Java, but it still works. I'll still code in C++ for most of the projects I work on because it is a good trade-off for power/security.
The faults of everything you list are the faults of people. I've worked on 600K lines of software written in C. It was all very self-contained, and didn't have any buffer overflow style problems. Why was it so big? Because it was designed with security in mind, and was very verbose and robust in what it did. If you audit every function thoroughly, garbage collection becomes useless.
I was working on this piece of network code that was written in C, I had an off-by-one error that was really screwing everything up. My code was very tight, and had another set of eyes look at it and was easily able to spot my mistake.
Well written code, regardless of language, will do exactly what you tell it to do, regardless of the complexity of how you tell it to do it.
Well I guess that makes all VB coders geniuses then, since they never get buffer overflows. They must just be the greatest bunch of programmers around.
It's just hard to kill people when you are driving a go-cart in a predefined track.
That means assuming coders will make mistakes, no matter how good they are. Even the best coders do make mistakes. In a language designed to be secure, the impact of coding mistakes is minimized.
C was never designed to be secure. Blame C programmers for insecure code, not the language. There are plenty of steps you can take to ensure safe C code. If you expect a secure application, and you use C, than take the proper steps to make it secure. It's user error.
It's not a stupid attitude, it's a philosophical attitude. I'm not defending C, but it works exactly as designed. End of story.
I blame the language. The reason is this: C makes it so easy, and so dangerous, to make such bugs, that they are extremely common, even among the best programmers. I challenge you to explain why some of the most revered software created by some of the most revered C hackers has had buffer overflows, if it's not the language's fault:
The language operates exactly as it is designed. It is human error. Not language error. Just because a gun makes it easy to kill people, doesn't mean guns kill people.
Things like the operating system kernels are not so easy to rewrite in a modern safe language, but network daemons are an *obvious choice* and are also the most dangerous!!
It really is not so hard to never use an unbounded function (snprintf instead of sprintf) or to count malloc() and frees() and if you do your code well structured, than it works. If you test your code with code that will cause buffer overflows everywhere, you will find them. If you do your math correctly, you will find them. If you don't, it's human error.
By the way, C garbage collection is crappy compared to built in support in a modern language: It needs to be conservative, and can't compact the heap. (Of course, that doesn't stop the authors of gcc from using it!)
Anything external will usually be less reliable and robust than something built-in to the language specifications. But, I would trust the authors of gcc more than you, no offense mate.
I was under the impression that first post usually signified the first top-level post in a thread.
That's "Frost Pist!", this is merely the first response talking about the parent's parent's parent's fascination with peepholes. Still a first post, otherwise it would be redundant instead of funny.
Anyway, we're way off-topic. I didn't realize that people actually cared about getting the first reply to a reply to a topic.
Yeah, off-topic is fun. If it's funny, people care about getting it first otherwise they turn into another redundant post.
I looked at the advisory expecting to see the words "buffer overflow", and instead saw "malloc mistake" (same pointer can get freed twice in some circumstances). Both of these amount to the same thing, getting nailed by C's lack of automatic memory protection and garbage collection.
...it needs to be scrutinized very carefully before deployment.
It's not the language, it's the coder. Just like it's not the car, it's the driver, if someone causes an accident. Replacing every sports car with a Kia isn't going to stop accidents. Educating drivers on good practices is.
Uhm, no shit? I think you should write a book! Seriously, saying that there should be code reviews before software gets deployed? That's an awesome idea, I think I'll start implementing it into my own development.
Again, the problem is not the language, it's the coder. People make mistakes, languages do not (compilers on the other hand). Don't blame a language for operating exactly as it's designed to.
You can do garbage collection in C just fine, with external libraries.
mis-dailed.
Say it with me: dial. dial.
There ya go
Isn't it funny how innovative and useful ideas stem so naturally from free ideas in the public domain?
Or maybe it's funny how innovative ideas stem from products that are heavily patented and protected. Hence how capitalism works.
Now if Microsoft or Palm had the patent on scrolling virtual windows we may never have seen this new implementation at all (not to mention how difficult it would be to play some RTS games).
Wonderful FUD, I applaud your troll. Even got modded up, very nice. The problem with this is that Xerox would have had the first patent on it. If Apple would have patented it, Xerox would have stepped in. It was the non-innovative approach. Anybody would do it, as scrolling was around since there were text terminals.. so what if it's on a "virtual window" -- your scroll lock key was there long before hand. Oh wait, this actually dates back to the BCs with scrolls that you wound or unwound manually.
It's a good thing that everybody irrationally hates patents, otherwise you people would pull your heads out of your ass and come up with a legitimate reason why they're bad.
You posted a reply to a comment and thought you might get first post? Your low user id betrays you!
Uhm, "first post on this" meaning the first post discussing the parents peephole affinity.
The bus left. Everyone was on it. Except you.
As a start-up today, one of the biggest hurdles is getting a potential customer to take you seriously.
If you have a sound business model and don't stress being a ".com", than no, potential customers will do what they can to save money with a reliable solution. Potential partners and investors, those are hard to find. At least ones you want.
I have to work very hard to convince a potential customer that i'll still be here in 12 months time, and it takes human intervention - i've not yet figured out how to do it through the website.
Provide a good site, with low overhead, and say that you are profitable. If they still think you're going belly up in 12 months, they're idiots and you probably don't want to do business with them anyway.
pilot
That should be polite. I was setting up my palm pilot over the weekend, and typed pilot more times than I can count.. autopilot is a great thing...
Is the pen as bad as it is made out to be? Did you ever run in to trouble or not get along with the other inmates?
Is this just a pilot way of asking if he got raped?
I installed it for my girlfriend as well. But finding decent drivers for peripherals is still a pain in the ass.
Which ones? I have a Sony CLIE, digital camera, all sorts of things that work flawlessly. The hardest thing I have to get running was the CLIE which required editing the devfsd conf to chmod the permissions and add myself to the group. Anyone with rudimentary knowledge should be able to do that.
As it stands now, a casual user can get by with Windows as they can simply go to the manufacturers site and grab a Windows driver on their own. If I asked her to grab the tarball and install it, she wouldn't know where to start.
Now it's RPMS. Or debs. Or whatever. On my desktop machines, it's RPM based because I want it not only standardized, but a target install that requires little intervention on my part. I'm a bit more strict on my workstation, but for other systems (something that isn't going to have software developed on it) most rpm's work better than any windows installer I've come across. Of course I don't use windows all that often.. most games require you to choose not to install a bunch of stupid things, or click next a few times for no apparent reason other than to display a few panes of path information or system information that less than 5% of the population can understand, either by choice or by knowledge.
Linux is just as ready for the desktop as Windows is, the problem is it's different. If someone starts with Linux they'll be just fine using it than Windows or Mac OSX. It's upgrading and, as you said, unsupported peripheral devices that have issues. A ton of devices are supported at this time however, at least most of the common ones.
Personally i like oyu understand the system but wheni try to show people around linux they use it in much different ways.
My girlfriend, a massage therapist. She clicks on the icons and it works. The only thing I had to explain to her is shift+space is the kanji key.
It seems to me to be very easy to jsut check email under linux and at first i assumed anyone could do it untill i saw people try. They have difficulty and it made me realize no matter what i wont see a computer just like any casual user.
Install KDE. Click "K" button. Networking -> Mail -> Choose One. There is no "Try" here, Linux is suitable for the desktop just fine now, but it's not idiot proof and idiots break their computers all the time.
Ok Mr. Software developer you sure do represent the casual user.
What about my girlfriend who uses KDE? How does Lindows support Japanese input? Is it as easy as it is in Red Hat or Mandrake? Especially if she buys it from WalMart?
I'm not that different than a casual user, because when I'm not programming, I am that casual user. I check my email, browse the web, use AIM. It doesn't matter to me what system I use as long as it works. I do not want to mess around with any form of system maintenance when I need to work, or when I just want to relax and read the news.
My servers are for customization and optimization, a desktop computer is supposed to work. Red Hat does that very well.
Desktop users dont use Redhat or United Linux, they want something for the desktop,not for hosting servers.
Uhm no. Desktop users do use Red Hat, and Red Hat isn't a server distribution. It is a desktop distribution. It's install is very easy, just as easy as Mandrake.
I use Mandrake, and I'm a software developer. I like an operating system that works. Red Hat works, Mandrake works, Debian works. These are all operating systems that are, in fact, easy to install.