Re: [opensuse] Now what? Glibc bug, vulnerability
On 02/17/2016 08:50 AM, Anton Aylward wrote:
On 02/17/2016 02:50 AM, Marcus Meissner wrote: This http://cafbit.com/entry/reinventing_software_for_security attributes many of the problems we have with 'memory' wrt secuyrity to the use of C and C++.
Yeah. Read another interesting article on the underlying problem last night and, having done some application development in a previous life, I agree wholeheartedly with the "C is the cause for most security vulnerabilities" thread. C (and its cousins) has (had?) no function length parameters built in. You have a 1024 byte buffer area and a C function that takes data up until it gets a null (or something) with nothing to tell it that there should only be no more than 1024? Buffer overflow guaranteed, every time. Linux is created with C. Can you say potentially worse than Windows ever thought of being, security wise? IMHO, the only thing that has given Linux the perception of being so secure is the fact that with such a small installed desktop base it just hasn't been worth the effort to develop malicious code when attacking Windows is so much more lucrative. But those days are past. Android is (sorta) Linux and look at how it is attacked because it is #1 OS on the planet. But, I digress ... C is the problem. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Wouldn't stuff like this affect Windows and OS X too, since they're also written in C? https://social.microsoft.com/Forums/en-US/65a1fe05-9c1d-48bf-bd40-148e6b3da9... http://stackoverflow.com/questions/580292/what-languages-are-windows-mac-os-... I know this is specifically a glibc bug, but you'd think that those same bugs could also happen in other OS-es, so I don't really understand why the criticism against linux for being written in C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/17/2016 11:25 AM, Christopher Myers wrote:
I know this is specifically a glibc bug, but you'd think that those same bugs could also happen in other OS-es, so I don't really understand why the criticism against linux for being written in C.
Agreed. There are no shortage of pointer error and buffer overflow bugs in Windows code over the years. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/17/2016 11:12 AM, Stevens wrote:
MHO, the only thing that has given Linux the perception of being so secure is the fact that with such a small installed desktop base it just hasn't been worth the effort to develop malicious code when attacking Windows is so much more lucrative. But those days are past. Android is (sorta) Linux and look at how it is attacked because it is #1 OS on the planet. But, I digress ...
Considering that for a long time now many of the high-value machines in banking and commerce run on Linux, I think the issue of the desktop is irrelevant. If the Hackers really were following Sutton's Law[1] as Mike Danseglio[2] once said, then Linux is certainly a high profile target. [1] http://www.brainyquote.com/quotes/quotes/w/williesutt378227.html [2] From My DatabaseOfDotSigQuotes: In 2006, the attackers want to pay the rent. They don't want to write a worm that destroys your hardware. They want to assimilate your computers and use them to make money. -- Mike Danseglio, program manager in the Security Solutions group at Microsoft, April 4, 2006 -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
IIR BSD is more obsessive about bug hunting and security issues and less about features and running on the latest hardware and having the latest tweaks and innovations that Linux. Does anyone know if this bug applied to BSD? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/17/2016 08:12 AM, Stevens wrote:
On 02/17/2016 08:50 AM, Anton Aylward wrote:
On 02/17/2016 02:50 AM, Marcus Meissner wrote: This http://cafbit.com/entry/reinventing_software_for_security attributes many of the problems we have with 'memory' wrt secuyrity to the use of C and C++.
Yeah. Read another interesting article on the underlying problem last night and, having done some application development in a previous life, I agree wholeheartedly with the "C is the cause for most security vulnerabilities" thread. C (and its cousins) has (had?) no function length parameters built in. You have a 1024 byte buffer area and a C function that takes data up until it gets a null (or something) with nothing to tell it that there should only be no more than 1024? Buffer overflow guaranteed, every time. Linux is created with C. Can you say potentially worse than Windows ever thought of being, security wise? IMHO, the only thing that has given Linux the perception of being so secure is the fact that with such a small installed desktop base it just hasn't been worth the effort to develop malicious code when attacking Windows is so much more lucrative. But those days are past. Android is (sorta) Linux and look at how it is attacked because it is #1 OS on the planet. But, I digress ... C is the problem. One can introduce bugs that create minor to serious security issues in any language; Java, Rust, OCaml, C++, etc. Windows NT is written in C also. The problem here lies with the development process, not the language itself. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/17/2016 11:10 AM, sdm wrote:
One can introduce bugs that create minor to serious security issues in any language; Java, Rust, OCaml, C++, etc. Windows NT is written in C also. The problem here lies with the development process, not the language itself.
Sorta true but one has to admit that C itself makes F.U.s like this bug so easy to create. It is difficult to not have problems with C code. Other languages just do not have those issues to the degree that C does. You mentioned C++, which is only marginally better than C in that regard. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Pardon my ignorance on this, but is there any way to harden the language itself so that it's less prone to issues like this? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/17/2016 11:22 AM, Christopher Myers wrote:
Pardon my ignorance on this, but is there any way to harden the language itself so that it's less prone to issues like this?
In a word, NO! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/17/2016 10:08 AM, Stevens wrote:
On 02/17/2016 11:22 AM, Christopher Myers wrote:
Pardon my ignorance on this, but is there any way to harden the language itself so that it's less prone to issues like this?
In a word, NO!
Sure there is. The problem is, it would break just about everything, because decades of bad programing habits made deliberate use of the weakness. Maximum length is seldom a part of the definition of a string. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/17/2016 01:18 PM, John Andersen wrote:
On 02/17/2016 10:08 AM, Stevens wrote:
On 02/17/2016 11:22 AM, Christopher Myers wrote:
Pardon my ignorance on this, but is there any way to harden the language itself so that it's less prone to issues like this?
In a word, NO!
Sure there is.
The problem is, it would break just about everything, because decades of bad programing habits made deliberate use of the weakness. Maximum length is seldom a part of the definition of a string.
That's a bit of a yes-no-maybe. Some languages like Ruby, Perl and others like Pascal have proper string handling rather than low-level string handling. The strings are dynamic memory rather then static buffers. Well, OK, you CAN input to a static array in those languages, but you are doing it explicitly. If a structure has a field that is a string it is a pointer to a dynamically managed entity so that if you do hpp->url = "http://" + hpp->url ; the interpreter code allocates a new buffer, builds the new string, frees the old. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/17/2016 06:22 PM, Christopher Myers wrote:
Pardon my ignorance on this, but is there any way to harden the language itself so that it's less prone to issues like this?
Not really. C is close to assembler on steroids. It is fast and powerful because of that. If you write to a variable beyond the end of the variable, that's your sole fault as programmer. The language will not check, can not check, by design. You, the programmer, are the master and you know what you do. If you don't... disaster. I have worked with languages that did range checks at compile and at run time. Many programmers disabled the runtime checks because they made the code slower. -- Cheers / Saludos, Carlos E. R. (from openSUSE Leap 42.1 x86_64 (test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Feb 17, 2016 at 3:41 PM, Carlos E. R.
On 02/17/2016 06:22 PM, Christopher Myers wrote:
Pardon my ignorance on this, but is there any way to harden the language itself so that it's less prone to issues like this?
Not really.
C is close to assembler on steroids. It is fast and powerful because of that. If you write to a variable beyond the end of the variable, that's your sole fault as programmer. The language will not check, can not check, by design. You, the programmer, are the master and you know what you do. If you don't... disaster.
I have worked with languages that did range checks at compile and at run time. Many programmers disabled the runtime checks because they made the code slower.
I'm not the c expert I was 20 years ago, but I think you should add static code checkers to your list of potential solutions. Coverty has been scanning the linux kernel and other open source projects for years and sending out warnings/patches when they find issues. http://www.coverity.com/products/code-advisor/ http://www.coverity.com/press-releases/coverity-scan-2010-report-reveals-hig... Others can speak to the effectiveness / coverage of their solution, but I don't think it should be ignored. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/17/2016 03:52 PM, Greg Freemyer wrote:
Coverty has been scanning the linux kernel and other open source projects for years and sending out warnings/patches when they find issues.
and covertys warns are mostly BS. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/18/2016 07:48 AM, Ruben Safir wrote:
On 02/17/2016 03:52 PM, Greg Freemyer wrote:
Coverty has been scanning the linux kernel and other open source projects for years and sending out warnings/patches when they find issues.
and covertys warns are mostly BS.
It sounds like marketing. "Hey look at what we found".."buy our product"! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Feb 18, 2016 at 10:58 AM, sdm
On 02/18/2016 07:48 AM, Ruben Safir wrote:
On 02/17/2016 03:52 PM, Greg Freemyer wrote:
Coverty has been scanning the linux kernel and other open source projects for years and sending out warnings/patches when they find issues.
and covertys warns are mostly BS.
I'm curious. Coverty has been sending out linux kernel reports since 2006 (10 years). With each scan I believe they report both still existing issues and newly identified issues. Are you saying: - Most of the still unfixed Coverty identified issues are BS. - Most of the newly identified issues are BS
It sounds like marketing. "Hey look at what we found".."buy our product"!
Possibly, but Coverty Linux Kernel Scans were funded originally (in 2006) by US Homeland Security as a way to provide public knowledge about the quality of opensource projects such as the Linux kernel. I can't say how good or bad Coverty is, but DHS's original goal was to make open source projects more security risk aware. DHS only provided funding for a few years. Since 2010 or so, Coverty has been doing it for free so it could be claimed they continue to provide the service as a marketing effort. Regardless, there are tons of patches that go into the linux kernel each year just to address issues identified by the Coverty Scanner. I assume that is because at least a portion of the newly identified issues are real. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/18/2016 10:37 PM, Greg Freemyer wrote:
I'm curious. Coverty has been sending out linux kernel reports since 2006 (10 years). With each scan I believe they report both still existing issues and newly identified issues.
Are you saying:
- Most of the still unfixed Coverty identified issues are BS.
- Most of the newly identified issues are BS
I can't tell neither for the Linux kernel not for glibc; we're using Coverity in the upstream coreutils project. There are many non-issues reported (which can be marked as "triaged" and therefore would show up as such in newer scan results), but certain warnings - like array-out- of-bounds messages or about resource leaks - are quite useful. OTOH, skimming through git log| grep -iC10 coverity there are ~90% of changes avoiding a "theoretical" issue or helping the scanner to interpret a situation correctly. Like with any other tool, you have to find a balance as to how much you want to obscure/annotate your code to help static analyzers or not. That means this is about pacifying a tool to avoid false positives. The plus I'm appreciating in Coverity is to see new warnings regarding changed code compared to the previous scan. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/17/2016 12:22 PM, Christopher Myers wrote:
Pardon my ignorance on this, but is there any way to harden the language itself so that it's less prone to issues like this?
Yes, but ... I've noted that for the most part C programmers aren't concerned with anything that might slow things down. Another example might be checking return codes from calls, particularly system calls. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/17/2016 08:12 AM, Stevens wrote:
On 02/17/2016 08:50 AM, Anton Aylward wrote:
On 02/17/2016 02:50 AM, Marcus Meissner wrote: This http://cafbit.com/entry/reinventing_software_for_security attributes many of the problems we have with 'memory' wrt secuyrity to the use of C and C++.
Yeah. Read another interesting article on the underlying problem last night and, having done some application development in a previous life, I agree wholeheartedly with the "C is the cause for most security vulnerabilities" thread. C (and its cousins) has (had?) no function length parameters built in. You have a 1024 byte buffer area and a C function that takes data up until it gets a null (or something) with nothing to tell it that there should only be no more than 1024? Buffer overflow guaranteed, every time.
True, the lack of built in reference (size) checking in the normal course of code is a fundamental flaw. And one that is taken care of in other languages. In some languages if you want to reference areas beyond your defined buffer length you have to contrive to do so, the code will crash if you don't. That being said, if such range checking were suddenly added to C, the entire world would come crashing down, because programming practices of the past will take total re-writes to overcome.
Linux is created with C. Can you say potentially worse than Windows ever thought of being, security wise?
Windows is mostly written in C and C++ as well, so you can't lay that baby at Linux's door.
IMHO, the only thing that has given Linux the perception of being so secure is the fact that with such a small installed desktop base it just hasn't been worth the effort to develop malicious code when attacking Windows is so much more lucrative. But those days are past. Android is (sorta) Linux and look at how it is attacked because it is #1 OS on the planet. But, I digress ... C is the problem.
Ah, the Bill Gates argument. Windows is only attacked because its popular, not because its easy. Sorry. Not buying it. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/17/2016 11:12 AM, Stevens wrote:
Yeah. Read another interesting article on the underlying problem last night and, having done some application development in a previous life, I agree wholeheartedly with the "C is the cause for most security vulnerabilities" thread.
No. Actually, it is not so easy to overrun a buffer on a modern OS, but putting that aside, there are many times the checking for a memory size is detrimental to the softwares function, especially in video and games. You can't blame the programming language for the stupidity of the programmer. the reason C is the goto language for all things important is because it is powerful. It is. And that power is felt in the hands of the coder. Ruben -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/18/2016 07:47 AM, Ruben Safir wrote:
On 02/17/2016 11:12 AM, Stevens wrote:
Yeah. Read another interesting article on the underlying problem last night and, having done some application development in a previous life, I agree wholeheartedly with the "C is the cause for most security vulnerabilities" thread.
No. Actually, it is not so easy to overrun a buffer on a modern OS, but putting that aside, there are many times the checking for a memory size is detrimental to the softwares function, especially in video and games.
You can't blame the programming language for the stupidity of the programmer. the reason C is the goto language for all things important is because it is powerful. It is. And that power is felt in the hands of the coder.
Ruben
Very true. It's like putting a professional tennis racket in the hands of someone who played pee-wee tennis once. They're going to lose control of it and make themselves look foolish. C and C++ are running at a very low level and take advantage of the hardware better than say, Haskell or Rust or Python. Python is not as fast of a running language as C++ (and Java always was slow for me) but processors are so fast these days that the user barely notices the difference. I've also read about compiler bugs and bugs in the bytecode interpreter for those higher-level languages, so it's not like they are totally immune to security bugs just because there's a bytecode interpreter. sdm -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/18/2016 10:47 AM, Ruben Safir wrote:
On 02/17/2016 11:12 AM, Stevens wrote:
Yeah. Read another interesting article on the underlying problem last night and, having done some application development in a previous life, I agree wholeheartedly with the "C is the cause for most security vulnerabilities" thread.
No. Actually, it is not so easy to overrun a buffer on a modern OS, but putting that aside, there are many times the checking for a memory size is detrimental to the softwares function, especially in video and games.
The evidence is otherwise. SANS surveys software bugs and security problems and "buffer overrun" and "SQL injection" have been the 31 and #2 issues, changing place at the top of the list, for well over a decade. The whole issue of not checking things for the sake of speed is all to often a mis-placed excuse. In all my years of programming and auditing programming and maintaining programs, I keep finding this weak excuse to justify even things like ignoring the return values of system calls. I recall one instance with a backup program supplied by a TLA company that was quite repeatable and verified by other users, but the people at support refused to admit that it was "writing" past the end of the media. We could back up a 10G drive onto a 360K floppy disk with no errors being reported.
You can't blame the programming language for the stupidity of the programmer. the reason C is the goto language for all things important is because it is powerful. It is. And that power is felt in the hands of the coder.
Right, so lets hand out powerful weapons like thermonuclear devices willy-nilly. As I've pointed out, too many schools teach C syntax and grammar but not good programming habits, correctness, or maintainability. Being in denial over these matters does not contribute to solving the problems we are facing. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2/18/2016 10:59, Anton Aylward wrote:
On 02/17/2016 11:12 AM, Stevens wrote:
Yeah. Read another interesting article on the underlying problem last night and, having done some application development in a previous life, I agree wholeheartedly with the "C is the cause for most security vulnerabilities" thread.
No. Actually, it is not so easy to overrun a buffer on a modern OS, but putting that aside, there are many times the checking for a memory size is detrimental to the softwares function, especially in video and games. The evidence is otherwise. SANS surveys software bugs and security problems and "buffer overrun" and "SQL injection" have been the 31 and #2 issues, changing place at
On 02/18/2016 10:47 AM, Ruben Safir wrote: the top of the list, for well over a decade.
The whole issue of not checking things for the sake of speed is all to often a mis-placed excuse. In all my years of programming and auditing programming and maintaining programs, I keep finding this weak excuse to justify even things like ignoring the return values of system calls. I recall one instance with a backup program supplied by a TLA company that was quite repeatable and verified by other users, but the people at support refused to admit that it was "writing" past the end of the media. We could back up a 10G drive onto a 360K floppy disk with no errors being reported.
You can't blame the programming language for the stupidity of the programmer. the reason C is the goto language for all things important is because it is powerful. It is. And that power is felt in the hands of the coder. Right, so lets hand out powerful weapons like thermonuclear devices willy-nilly. As I've pointed out, too many schools teach C syntax and grammar but not good programming habits, correctness, or maintainability.
Being in denial over these matters does not contribute to solving the problems we are facing.
The key is programming habits. Most low level code (kernel, system libs etc) are done in C/C++, hence most juicy buffer overflow targets rely on mistakes in C/C++ code. Write the low level code in another language, and you will be bad mouthing it just as much. Key is bad programming habits, not the language. -- --Moby -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/18/2016 12:35 PM, Moby wrote:
The key is programming habits. Most low level code (kernel, system libs etc) are done in C/C++, hence most juicy buffer overflow targets rely on mistakes in C/C++ code. Write the low level code in another language, and you will be bad mouthing it just as much. Key is bad programming habits, not the language.
No, its not that simple. First, we are talking the kernel here. Bugs are more critical than elsewhere. Secondly, there are many other situations where "performance" is in demand but issues like production, maintainability and more are of greater importance. You might note that, for example, web sites tend to be written in the kind of languages, Perl, Python, Ruby, that have string handling that voids input buffer overflow such as we have been discussing. Yes there are other classes of errors, especially when the coders are let loose on the raw interface rather than using a CMS package that avoids many egregious mistakes. Again, its a issue of leverage. Productivity matter more, and productivity includes maintainability. C and especially C++ are not the most maintainable of languages, which is, in turn, part of the problem. Nothing new here. Assembler was worse as far as intelligibility goes. Its why HLLs came along. More expressive detail, hide code optimization, error handling and more in the complier and run-time packages, libraries. Compilers are really "expert systems" in code generation, embodying the skills and knowledge of many experts. and able to produce optimized code day-in, day-out, which is more than can be said for assembly code programmers. They are productivity amplifiers. The higher the HLL the greater the amplification, as packages such a RubyOnRails and its Perl and Python counterparts are showing. The thing is to differentiate between true compilers and interpreters, even bytecode interpreters. Are these HLLs impervious to errors? of course not, but they do avoid so many of the errors of C-as-structured-assembler. Even so, its not simply an issue of productivity. These HLLs are also more resilient because they are focusing on expressive power rather than the fiddly bits of implementation. Could large swaths of the kernel be implemented in a HLL? Yes. Even back in the 1980s Bill Joy of BSD fame was showing Dave Cutler[1] of VAX/VMS that a "HLL" (it *was* C) was more productive, more responsive in making changes, than assembler. Back then we didn't have the powerful compilers and code generation expertise we have now, so a LLL was needed. But it made the point: you don't need assembler to code the OS and device drivers. Taking a walk through the literature from the days before Linux became dominant you will find many vendors made use of HLLs for OS design and implementation. All Brinch Hansen's work on concurrent programming and kernel support for the same was done with Pascal. His classic work on operating system principles starts with the assertion that the needs of a OS are not radically different from other programs that require efficient and reliable design and operation. Similarly Wirth's "Algorithms + data structures = programs" from the same era made the point that reinforced his papers on multiprogramming that so much begins with good design. When you speak of bad habits, the worst is "coding first" which stems from the attitude that programming schools & courses have that teach coding, syntax and grammar, and not design. [1] https://en.wikipedia.org/wiki/Dave_Cutler#Attitude_towards_Unix -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-02-18 18:35, Moby wrote:
On 2/18/2016 10:59, Anton Aylward wrote:
Right, so lets hand out powerful weapons like thermonuclear devices willy-nilly. As I've pointed out, too many schools teach C syntax and grammar but not good programming habits, correctness, or maintainability.
Being in denial over these matters does not contribute to solving the problems we are facing.
The key is programming habits.
Habits? No, that's wrong. Don't rely on habits, or the instinct of the programmer. We have to rely on good training. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlbGfOkACgkQja8UbcUWM1wOGwD+LiLEkLcnZmD6lVXB8rHwPYB1 XVrT9VAEk3eR8bk45h0A/js0WGJc6JSrTZ+bQ1I9i0IHTbUHusQx4aDVDFubPAk3 =AZ+g -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (10)
-
Anton Aylward -
Bernhard Voelker -
Carlos E. R. -
Christopher Myers -
Greg Freemyer -
John Andersen -
Moby -
Ruben Safir -
sdm -
Stevens