I think that any CoC is going to need to be adapted over time. I'll cherry pick a few points based on my perspective. Note that the language in the CoC isn't mine and I'm not about to claim either expertise or agreement with it, other than to say that it largely boils down to "don't be a dick".
Overall, I think that the CoC is meant more for repeat abusers. The penalties are designed to ratchet up over time. So, if you innocently say something that hurts someone else, I don't think they are going to permban you. They would likely reach out to you first, give you a talking-to and possibly a warning, and move on from there. If you are a repeat offender, then they will likely start giving you temporary bans and more severe penalties, depending of course on the severity of the abuse. The CoC is meant to be something that people can point to when behavior is called out as unacceptable. It is the "why" and not the cudgel itself. Can it be abused? Certainly. That's why it is a code that must be judiciously enforced by community maintainers, and not a book of laws.
The "outing" rule is specifically designed to allow others to "out" known offenders. So, for instance, if that guy who makes women (or other men) feel uncomfortable due to aggressive sexual advances is going to attend BSDCon, then it's okay for community members to "out" him by providing information to event coordinators about said person. "Outing" in this context specifically means providing pertinent personal details that can help to protect others. For instance, the alleged actions of a certain hacker named after a toy whistle at certain hacker conventions were "outed" in order to ensure that boys and young men were kept safe. That convention had adopted a similar CoC used to similar effect.
I think the dead names thing really just comes down to not being a dick about someone's gender. If someone used to be known as "Tom" and is now known as "Samantha", it's a dick move to continue to refer to that person as "Tom".
The "hugs" thing is likely an issue of context and was used as an example. I've seen degrading comments made to women on mailing lists when someone indicates an action that they would like to perform to the woman, and then later plays it off as an innocent joke or misunderstanding. The reason why it's uncool is because it degrades her in front of peers. If she calls it out, then she gets labeled as "uptight". By making it part of the CoC, at least in theory, it's possible to get someone else to pull that person aside and demand a public apology.
I think that private conversation should be considered "off the record" in most contexts. When people share private conversations with others -- unless these conversations are abusive -- it is tacky. I think the CoC draws this line specifically to ensure that abuse can be forwarded, but that this doesn't open the flood gates for folks to just make all private conversations public. Sure, private and public statements are contradictory all of the time. That's politics, and any community is going to be full of politics. But, it's dirty pool to out those private communications, unless someone is harassing someone else. I'm pretty sure that is what this clause is about.
The "knowingly making harmful claims about a person" is meant as a check on the outing rule. If Bob is a sexual predator, and I out him for it, then I had better have proof. Otherwise, Bob may in fact be someone I'm just trying to smear, and that would be uncool. Likewise, let's face it, false accusations do occur. Sometimes, retaliatory accusations are made to one's accusers. There needs to be a fair balance between taking accusations at face value and ensuring that malicious parties can be dealt with. I don't think that any CoC can thread this needle, as it is highly context-sensitive, but I think the point here is to point out that this isn't a he said / she said free-for-all.
Again, I'm just an outsider looking in. I've seen similar CoCs adopted by similar communities. I
If I don't agree with the CoC of a community, I simply do not participate in that community. If a new CoC is adopted that has language with which I disagree, I'll first ask questions to clarify, following the principle of charity and keeping an open mind. If, after seeking clarification, I am still concerned, I'll move on. There is nothing to be gained by attempting to fight this stuff. This is the FreeBSD Foundation's walled garden. Either we accept their terms or we do not. But, bracketing the language, I really don't see anything in the guidelines that raises any red flags to me.
I'll turn the question back on you. Which specific clauses in the CoC do you find unreasonable? Let's not talk about language, because we can likely both agree that the language is extreme. Are there specific rules in that CoC that go too far?
Sure, this code of conduct is a bit ham-handed and written from a radical perspective that is at odds with the relatively conservative past of the project, but if we ignore the language of the conduct and focus instead on its meaning, it basically boils down to not being a dick. I think most people are likely upset because the language screams SJW, but this does not make the code wrong.
This is a sign of the times. The newer generation coming into these projects was raised with these values. Us "old timers" -- and by that I mean us who are over thirty -- were part of a different generation of OSS and Internet culture. This new culture may seem alien to us, but it's not that bad. Focus on building things and maybe try to be a bit more sensitive when critiquing others, and you'll be just fine.
I don't think this is the death knell for FreeBSD. Inclusiveness is a good thing. I'm glad they are trying to engage millennials. If enforcing a Code of Conduct that, despite the virtue signaling language, really boils down to "don't be a dick to people" ensures that this project can attract young people, then I'm glad to see it ratified.
Change can be good, but we have to be open minded to that change.
I don't disagree with your assessment. However, if your assessment is valid, then a functional language is still going to be quite foreign to someone who has only been taught object-oriented programming. I agree that we can go deep down the rabbit hole with OOP as well. The minimal interface that has been extracted from the science behind OOP and introduced to programmers in general is a mere shadow of the works of folks like Barbara Liskov.
FP has yet to have this generational winnowing. It is still fresh and academic. We can build people up to understand this, or we can pull these concepts down to their most basic versions that are still useful. I suspect that both will have to happen before the industry can meet in the middle with FP. We are seeing this happen already as mainstream languages are adopting bits and pieces of functional concepts. I think it's more likely that we will see functional applications of OOP, such as in languages like Scala, than OOP superseded by FP. That's okay. There are already plenty of examples of non-mutable objects with copy-on-write semantics. We are seeing functions treated more and more like first-class objects. There are examples of the FP-as-style movement taking off.
I believe that we should teach higher math in high school and even as a requirement for engineering or information systems disciplines. Currently, most universities top out bachelor degree seeking students specializing in these disciplines to calculus, differential equations, and linear algebra if they are lucky. It would be nice to see abstract algebra and some category theory taught as well. When I advise people genuinely interested in pursuing software development as a career, I strongly recommend that they minor in mathematics so they can have the opportunity to take these more advanced classes.
That being said, there's nothing that prevents people from studying this for self-improvement. Learning either or both OOP and FP will fundamentally change the way that one organizes software. I'd love to see high school kids exposed to these concepts and the mathematics behind them. Then again, I'd also love to see high school kids taught how to build their own CPUs from 74-series logic ICs. Understanding the theory of computation at an intuitive level will do incalculable good for most of these kids through the rest of their careers. If I were to teach a class to high school level students, it would be along this line. I can guarantee that they will never look at a computer, embedded device, or "smart" device the same way again.
Functional programming languages like Haskell, ML, and Gallina can be very beautiful. The problem is that they have a steep learning curve that has less to do with the syntax of the language and more to do with the semantics. If one is well versed in category theory or has spent a significant amount of time working with functor spaces, monoids, and monads, then it's much easier to understand a non-trivial application written in Haskell than the equivalent object hierarchy in an object-oriented language. The up-front cost is greater in terms of study and learning the semantics, but the end result is significantly more powerful.
I love functional programming. I went from C++ to Haskell and C as my go-to languages for personal projects. However, in my professional work, I tend to factor long-term language popularity into my decisions. So, I'm more inclined to use languages like Java, C#, Go, Python, and Ruby when I'm paid to write software. I have to consider the total cost of ownership in my professional work, and part of that cost is finding people to maintain it years from now.
I think that FP has an elegance that makes it a worthy model, and I hope that some day, FP becomes more popular than OOP. But, I'm old enough to understand that technical superiority rarely wins out to popularity. Popularity matters. This sort of calculus is one of the reasons why FP has not gained much traction despite all of the buzz.
Most static analysis tools look for bugs and potentially buggy behavior. They must rely on limited pattern matching and data flow analysis. They can't find all bugs. See: The Halting Problem.
So... we should re-write OpenSSL in a higher level language, yes? About how long is that going to take? How many code bases that currently use OpenSSL will not be able to use this new library, due to portability reasons? Your solution to the problem is impractical.
Should higher level languages be used when possible? Absolutely. I'm a fan of high level languages. I prefer to write software in Haskell and Scala when possible. Is suggesting the use of a higher level language at all helpful here? No.
There is idealism, and then there is pragmatism. I choose to be pragmatic. The problems in the OpenSSL code base are not impossible to solve. OpenBSD is written primarily in C, and compared to OpenSSL, it's light years beyond this library in terms of good programming style and proper use of language constructs. It's not failed advice to argue that these issues can be avoided. It's pragmatic advice, and it's more useful than throwing out a mature library and re-writing it from scratch in a higher level language.
Could a higher level language help? Sure. Is it a realistic and practical solution to OpenSSL's issues? Not really.
I've heard this argument, and I've seen blunders of vulnerabilities in Java, C#, Ruby, Python, and other higher level languages. This is not a language or platform specific problem. It's an industry wide problem. Show me typical code in any language, and I will find bugs in that code. Some of those bugs can be exploited.
The biggest difficulty I have with advocates of higher level languages is that I have a harder time convincing them that bugs in their code can be exploited. "...but, this is Java. It's supposed to be secure." Better languages can help, but they are not a panacea. It takes dedication and hard work to write hardened code.
Whether the flaw was intentional or not is irrelevant. It should not have been possible to commit such a flaw into the codebase without someone noticing.
I can agree with that. Programming style often gets confused with window dressing, which goes against the original guidelines that Kernighan and Plauger laid down in The Elements of Programming Style, many of which are still quite valid today. I refer to this tendency as "cargo cult" programming style, where people attempt to poorly mimic the style guidelines that have been passed down for generations, getting all of the trappings of this original understanding, but none of the substance.
I'm trying to take back the phrase, "programming style", to mean something in the spirit of what Brian Kernighan meant. Sometimes it means that I get a little curmudgeonly about its mis-use.:-)
Style, or the lack thereof, is absolutely related to this issue. It created the festering environment that this bug hid in for two years before it was discovered.
Style is about more than pretty print formatting. It's about avoiding the god-awful raw pointer math found in this function. It's about properly bounding values. It's about enforcing the sorts of checks that come naturally to programmers with more experience and less bravado. You may not appreciate the need for good style yet, but I bet you that the OpenSSL team is rethinking this now. To know that such a sophomoric mistake lingered for two years, even though hundreds of eyes passed over that code, is the epitome of why good programming style matters. The people who looked at this code are likely much smarter than you or I. They could not follow the logic of this code, because their eyes glossed right over this glaring bug. That's bad style. Everything else is window dressing.
I meant that the refactor would make the bug obvious. However, as is the case with any bit of refactoring, one often finds bugs, writes test cases to capture these bugs, and then comes back to eliminate them. While the pedantic would argue that refactoring keeps functionality the same, refactoring is just one step in a larger process of code stewardship that includes the isolation and elimination of bugs. When a refactor makes a bug obvious, I contend that the refactor helps to eliminate that bug.
Either way, you are correct: refactoring does not fix bugs. But, in the larger sense, it brings them to light.
There is well written C, and there is poorly written C. I've been through the bowels of OpenSSL, and there are parts of it that frighten me. Ninety percent of the issues in OpenSSL could be solved by adopting a modern coding style and using better static analysis. While static analysis tools can't find vulnerabilities, they can root out code smell that hides vulnerabilities. If, for instance, I followed the advice of two of the quality commercial static analyzers that I ran against the OpenSSL code base, I would have been forced to refactor the code in such a way that this bug would have either been obvious to anyone casually reviewing it, if the refactor did not eliminate the bug all together.
C and C++ are not necessarily the problem. It's true that higher level languages solve this particular kind of vulnerability, but they are not safe from other vulnerabilities. To solve problems like these, we need better coding style in critical open source projects.
I can explain every detail about how a bit of software I did not write works if I study it long enough. I can even do a pretty good job of explaining why I wrote the software a certain way, even if I did not write it. I can make said software look quite beautiful, and give a rather impressive presentation about how it works. I'm sorry, but there's probably no way that you can tell that I did not write this particular software, unless you happen to know the software. Just because I can describe, in detail, how a bit of software works doesn't mean that I'm capable of writing it or something like it myself.
I pass over hundreds of resumes a month, after they've been filtered by HR. I've interviewed countless people over the past fifteen years. I've seen it all. People often embellish or outright lie. Many are not nearly as good as they think they are. Board problems are objective. They can't be faked, and unless the problems are known ahead of time, they can't be rehearsed.
Actually, if the CS board problem is done correctly, then error handling, software design, and planning can be measured. There are plenty of corner cases in most of these problems. That's where the real fun begins. Even something as simple as adding and removing items in a linked list or a binary tree leads to corner cases.
Everything else comes down to Q&A. That's where we get into probing questions about design, documentation, etc.
As for code samples, I'm not a big fan of code samples. You won't believe how many times I've seen people plagiarize source code in interviews. The only exception here is the take-home test. The only problem is that take-home problems have to be rotated out pretty quickly. They hit the forums within a week.
As someone who gives CS interview problems, I have to disagree with your assessment. The problems aren't designed to prove that you can implement a bubble sort. It's meant to be representative of the sort of typical hard problem you'll be faced with writing software. The reason why we choose CS problems is because they are properly bounded, they have a finite number of correct answers, and if you get off course while working them out on the board, we can better help you to get back on course. Furthermore, there are decades of research that have gone into these problems, so a naive board implementation leads to all sorts of prompts for interesting questions.
Most of my evaluation has nothing to do with whether you get the right answer or the wrong answer. It has to do with how you arrive at the answer, and how you respond to constructive criticism, or in a pair programming environment. I couldn't care less if you can write a bubble sort coming in; if you solve the problem quickly, I'll just substitute a different one that you can't solve quickly. It's the process by which you arrive at an answer that interests me, and CS problems are, by far, the easiest way to uncover this.
A locked and loaded pistol belongs in a quick release gun safe. Most safes use thick gauge steel that the bullets cannot penetrate.
Second, for self defense you should consider using a frangible round which will not penetrate through walls or through steel. This helps to limit collateral damage. A full metal jacket or a metal jacketed hollow point bullet can go through windows and hit the neighbor's dog. In your scenario, such ammunition would be safe to the firefighters, granted that the gun is stored properly.
Riiight. Because the criminals who already have guns illegally would give these up as soon such a ban was passed?
We live in a dangerous world. It is the right of the people to arm themselves. We cannot expect the government to always be able to protect us from people who wish to do us harm. Such thinking is naieve.
Originally, the reason why this amendment was added to the Constitution was so the people could protect themselves from a corrupt government.
I'd also add 'Wizards First Rule' + sequels by Terry Goodkind.
Terry Goodkind is an excellent fantasy writer. He currently has 6 books and a few short stories out. Here is an incomplete list:
Wizard's First Rule Stone of Tears Blood of the Fold Temple of Winds Soul of the Fire Faith of the Fallen Pillars of Creation
short story Debt of Bones
I started reading WFR and could not put it down. Since then, I have been addicted. (I am currently finishing POC).
The TINI device has a serial, 1-wire, and ethernet port, and has slip, ppp, and dhcp software included. This could also be used to foreward packets from the Agenda's serial port to a 10mbit network. Add this to a little black box, and you have a portable lan monitor / admin terminal.
Slashdot Mirror
I think that any CoC is going to need to be adapted over time. I'll cherry pick a few points based on my perspective. Note that the language in the CoC isn't mine and I'm not about to claim either expertise or agreement with it, other than to say that it largely boils down to "don't be a dick".
Overall, I think that the CoC is meant more for repeat abusers. The penalties are designed to ratchet up over time. So, if you innocently say something that hurts someone else, I don't think they are going to permban you. They would likely reach out to you first, give you a talking-to and possibly a warning, and move on from there. If you are a repeat offender, then they will likely start giving you temporary bans and more severe penalties, depending of course on the severity of the abuse. The CoC is meant to be something that people can point to when behavior is called out as unacceptable. It is the "why" and not the cudgel itself. Can it be abused? Certainly. That's why it is a code that must be judiciously enforced by community maintainers, and not a book of laws.
The "outing" rule is specifically designed to allow others to "out" known offenders. So, for instance, if that guy who makes women (or other men) feel uncomfortable due to aggressive sexual advances is going to attend BSDCon, then it's okay for community members to "out" him by providing information to event coordinators about said person. "Outing" in this context specifically means providing pertinent personal details that can help to protect others. For instance, the alleged actions of a certain hacker named after a toy whistle at certain hacker conventions were "outed" in order to ensure that boys and young men were kept safe. That convention had adopted a similar CoC used to similar effect.
I think the dead names thing really just comes down to not being a dick about someone's gender. If someone used to be known as "Tom" and is now known as "Samantha", it's a dick move to continue to refer to that person as "Tom".
The "hugs" thing is likely an issue of context and was used as an example. I've seen degrading comments made to women on mailing lists when someone indicates an action that they would like to perform to the woman, and then later plays it off as an innocent joke or misunderstanding. The reason why it's uncool is because it degrades her in front of peers. If she calls it out, then she gets labeled as "uptight". By making it part of the CoC, at least in theory, it's possible to get someone else to pull that person aside and demand a public apology.
I think that private conversation should be considered "off the record" in most contexts. When people share private conversations with others -- unless these conversations are abusive -- it is tacky. I think the CoC draws this line specifically to ensure that abuse can be forwarded, but that this doesn't open the flood gates for folks to just make all private conversations public. Sure, private and public statements are contradictory all of the time. That's politics, and any community is going to be full of politics. But, it's dirty pool to out those private communications, unless someone is harassing someone else. I'm pretty sure that is what this clause is about.
The "knowingly making harmful claims about a person" is meant as a check on the outing rule. If Bob is a sexual predator, and I out him for it, then I had better have proof. Otherwise, Bob may in fact be someone I'm just trying to smear, and that would be uncool. Likewise, let's face it, false accusations do occur. Sometimes, retaliatory accusations are made to one's accusers. There needs to be a fair balance between taking accusations at face value and ensuring that malicious parties can be dealt with. I don't think that any CoC can thread this needle, as it is highly context-sensitive, but I think the point here is to point out that this isn't a he said / she said free-for-all.
Again, I'm just an outsider looking in. I've seen similar CoCs adopted by similar communities. I
If I don't agree with the CoC of a community, I simply do not participate in that community. If a new CoC is adopted that has language with which I disagree, I'll first ask questions to clarify, following the principle of charity and keeping an open mind. If, after seeking clarification, I am still concerned, I'll move on. There is nothing to be gained by attempting to fight this stuff. This is the FreeBSD Foundation's walled garden. Either we accept their terms or we do not. But, bracketing the language, I really don't see anything in the guidelines that raises any red flags to me.
I'll turn the question back on you. Which specific clauses in the CoC do you find unreasonable? Let's not talk about language, because we can likely both agree that the language is extreme. Are there specific rules in that CoC that go too far?
Sure, this code of conduct is a bit ham-handed and written from a radical perspective that is at odds with the relatively conservative past of the project, but if we ignore the language of the conduct and focus instead on its meaning, it basically boils down to not being a dick. I think most people are likely upset because the language screams SJW, but this does not make the code wrong.
This is a sign of the times. The newer generation coming into these projects was raised with these values. Us "old timers" -- and by that I mean us who are over thirty -- were part of a different generation of OSS and Internet culture. This new culture may seem alien to us, but it's not that bad. Focus on building things and maybe try to be a bit more sensitive when critiquing others, and you'll be just fine.
I don't think this is the death knell for FreeBSD. Inclusiveness is a good thing. I'm glad they are trying to engage millennials. If enforcing a Code of Conduct that, despite the virtue signaling language, really boils down to "don't be a dick to people" ensures that this project can attract young people, then I'm glad to see it ratified.
Change can be good, but we have to be open minded to that change.
I don't disagree with your assessment. However, if your assessment is valid, then a functional language is still going to be quite foreign to someone who has only been taught object-oriented programming. I agree that we can go deep down the rabbit hole with OOP as well. The minimal interface that has been extracted from the science behind OOP and introduced to programmers in general is a mere shadow of the works of folks like Barbara Liskov.
FP has yet to have this generational winnowing. It is still fresh and academic. We can build people up to understand this, or we can pull these concepts down to their most basic versions that are still useful. I suspect that both will have to happen before the industry can meet in the middle with FP. We are seeing this happen already as mainstream languages are adopting bits and pieces of functional concepts. I think it's more likely that we will see functional applications of OOP, such as in languages like Scala, than OOP superseded by FP. That's okay. There are already plenty of examples of non-mutable objects with copy-on-write semantics. We are seeing functions treated more and more like first-class objects. There are examples of the FP-as-style movement taking off.
I believe that we should teach higher math in high school and even as a requirement for engineering or information systems disciplines. Currently, most universities top out bachelor degree seeking students specializing in these disciplines to calculus, differential equations, and linear algebra if they are lucky. It would be nice to see abstract algebra and some category theory taught as well. When I advise people genuinely interested in pursuing software development as a career, I strongly recommend that they minor in mathematics so they can have the opportunity to take these more advanced classes.
That being said, there's nothing that prevents people from studying this for self-improvement. Learning either or both OOP and FP will fundamentally change the way that one organizes software. I'd love to see high school kids exposed to these concepts and the mathematics behind them. Then again, I'd also love to see high school kids taught how to build their own CPUs from 74-series logic ICs. Understanding the theory of computation at an intuitive level will do incalculable good for most of these kids through the rest of their careers. If I were to teach a class to high school level students, it would be along this line. I can guarantee that they will never look at a computer, embedded device, or "smart" device the same way again.
Functional programming languages like Haskell, ML, and Gallina can be very beautiful. The problem is that they have a steep learning curve that has less to do with the syntax of the language and more to do with the semantics. If one is well versed in category theory or has spent a significant amount of time working with functor spaces, monoids, and monads, then it's much easier to understand a non-trivial application written in Haskell than the equivalent object hierarchy in an object-oriented language. The up-front cost is greater in terms of study and learning the semantics, but the end result is significantly more powerful.
I love functional programming. I went from C++ to Haskell and C as my go-to languages for personal projects. However, in my professional work, I tend to factor long-term language popularity into my decisions. So, I'm more inclined to use languages like Java, C#, Go, Python, and Ruby when I'm paid to write software. I have to consider the total cost of ownership in my professional work, and part of that cost is finding people to maintain it years from now.
I think that FP has an elegance that makes it a worthy model, and I hope that some day, FP becomes more popular than OOP. But, I'm old enough to understand that technical superiority rarely wins out to popularity. Popularity matters. This sort of calculus is one of the reasons why FP has not gained much traction despite all of the buzz.
Most static analysis tools look for bugs and potentially buggy behavior. They must rely on limited pattern matching and data flow analysis. They can't find all bugs. See: The Halting Problem.
So... we should re-write OpenSSL in a higher level language, yes? About how long is that going to take? How many code bases that currently use OpenSSL will not be able to use this new library, due to portability reasons? Your solution to the problem is impractical.
Should higher level languages be used when possible? Absolutely. I'm a fan of high level languages. I prefer to write software in Haskell and Scala when possible. Is suggesting the use of a higher level language at all helpful here? No.
There is idealism, and then there is pragmatism. I choose to be pragmatic. The problems in the OpenSSL code base are not impossible to solve. OpenBSD is written primarily in C, and compared to OpenSSL, it's light years beyond this library in terms of good programming style and proper use of language constructs. It's not failed advice to argue that these issues can be avoided. It's pragmatic advice, and it's more useful than throwing out a mature library and re-writing it from scratch in a higher level language.
Could a higher level language help? Sure. Is it a realistic and practical solution to OpenSSL's issues? Not really.
I've heard this argument, and I've seen blunders of vulnerabilities in Java, C#, Ruby, Python, and other higher level languages. This is not a language or platform specific problem. It's an industry wide problem. Show me typical code in any language, and I will find bugs in that code. Some of those bugs can be exploited.
The biggest difficulty I have with advocates of higher level languages is that I have a harder time convincing them that bugs in their code can be exploited. "...but, this is Java. It's supposed to be secure." Better languages can help, but they are not a panacea. It takes dedication and hard work to write hardened code.
Whether the flaw was intentional or not is irrelevant. It should not have been possible to commit such a flaw into the codebase without someone noticing.
I can agree with that. Programming style often gets confused with window dressing, which goes against the original guidelines that Kernighan and Plauger laid down in The Elements of Programming Style, many of which are still quite valid today. I refer to this tendency as "cargo cult" programming style, where people attempt to poorly mimic the style guidelines that have been passed down for generations, getting all of the trappings of this original understanding, but none of the substance.
I'm trying to take back the phrase, "programming style", to mean something in the spirit of what Brian Kernighan meant. Sometimes it means that I get a little curmudgeonly about its mis-use. :-)
Style, or the lack thereof, is absolutely related to this issue. It created the festering environment that this bug hid in for two years before it was discovered.
Style is about more than pretty print formatting. It's about avoiding the god-awful raw pointer math found in this function. It's about properly bounding values. It's about enforcing the sorts of checks that come naturally to programmers with more experience and less bravado. You may not appreciate the need for good style yet, but I bet you that the OpenSSL team is rethinking this now. To know that such a sophomoric mistake lingered for two years, even though hundreds of eyes passed over that code, is the epitome of why good programming style matters. The people who looked at this code are likely much smarter than you or I. They could not follow the logic of this code, because their eyes glossed right over this glaring bug. That's bad style. Everything else is window dressing.
I meant that the refactor would make the bug obvious. However, as is the case with any bit of refactoring, one often finds bugs, writes test cases to capture these bugs, and then comes back to eliminate them. While the pedantic would argue that refactoring keeps functionality the same, refactoring is just one step in a larger process of code stewardship that includes the isolation and elimination of bugs. When a refactor makes a bug obvious, I contend that the refactor helps to eliminate that bug.
Either way, you are correct: refactoring does not fix bugs. But, in the larger sense, it brings them to light.
Theo de Raadt is correct, if not a bit abrasive in his assessment of the situation.
Two years of dedicated work: writing proper unit tests, refactoring code, and refreshing this library would do wonders for this project.
I agree. Code review with an eye towards modern programming style would have brought this bug to light years ago.
There is well written C, and there is poorly written C. I've been through the bowels of OpenSSL, and there are parts of it that frighten me. Ninety percent of the issues in OpenSSL could be solved by adopting a modern coding style and using better static analysis. While static analysis tools can't find vulnerabilities, they can root out code smell that hides vulnerabilities. If, for instance, I followed the advice of two of the quality commercial static analyzers that I ran against the OpenSSL code base, I would have been forced to refactor the code in such a way that this bug would have either been obvious to anyone casually reviewing it, if the refactor did not eliminate the bug all together.
C and C++ are not necessarily the problem. It's true that higher level languages solve this particular kind of vulnerability, but they are not safe from other vulnerabilities. To solve problems like these, we need better coding style in critical open source projects.
I can explain every detail about how a bit of software I did not write works if I study it long enough. I can even do a pretty good job of explaining why I wrote the software a certain way, even if I did not write it. I can make said software look quite beautiful, and give a rather impressive presentation about how it works. I'm sorry, but there's probably no way that you can tell that I did not write this particular software, unless you happen to know the software. Just because I can describe, in detail, how a bit of software works doesn't mean that I'm capable of writing it or something like it myself.
I pass over hundreds of resumes a month, after they've been filtered by HR. I've interviewed countless people over the past fifteen years. I've seen it all. People often embellish or outright lie. Many are not nearly as good as they think they are. Board problems are objective. They can't be faked, and unless the problems are known ahead of time, they can't be rehearsed.
Actually, if the CS board problem is done correctly, then error handling, software design, and planning can be measured. There are plenty of corner cases in most of these problems. That's where the real fun begins. Even something as simple as adding and removing items in a linked list or a binary tree leads to corner cases.
Everything else comes down to Q&A. That's where we get into probing questions about design, documentation, etc.
As for code samples, I'm not a big fan of code samples. You won't believe how many times I've seen people plagiarize source code in interviews. The only exception here is the take-home test. The only problem is that take-home problems have to be rotated out pretty quickly. They hit the forums within a week.
As someone who gives CS interview problems, I have to disagree with your assessment. The problems aren't designed to prove that you can implement a bubble sort. It's meant to be representative of the sort of typical hard problem you'll be faced with writing software. The reason why we choose CS problems is because they are properly bounded, they have a finite number of correct answers, and if you get off course while working them out on the board, we can better help you to get back on course. Furthermore, there are decades of research that have gone into these problems, so a naive board implementation leads to all sorts of prompts for interesting questions.
Most of my evaluation has nothing to do with whether you get the right answer or the wrong answer. It has to do with how you arrive at the answer, and how you respond to constructive criticism, or in a pair programming environment. I couldn't care less if you can write a bubble sort coming in; if you solve the problem quickly, I'll just substitute a different one that you can't solve quickly. It's the process by which you arrive at an answer that interests me, and CS problems are, by far, the easiest way to uncover this.
A locked and loaded pistol belongs in a quick release gun safe. Most safes use thick gauge steel that the bullets cannot penetrate.
Second, for self defense you should consider using a frangible round which will not penetrate through walls or through steel. This helps to limit collateral damage. A full metal jacket or a metal jacketed hollow point bullet can go through windows and hit the neighbor's dog. In your scenario, such ammunition would be safe to the firefighters, granted that the gun is stored properly.
Riiight. Because the criminals who already have guns illegally would give these up as soon such a ban was passed?
We live in a dangerous world. It is the right of the people to arm themselves. We cannot expect the government to always be able to protect us from people who wish to do us harm. Such thinking is naieve.
Originally, the reason why this amendment was added to the Constitution was so the people could protect themselves from a corrupt government.
On *BSD:
;-)
$ make love
make: don't know how to make love. Stop.
*BSD is Dying...
:-P
Totally untrue. *BSD rules.
The name Chronolith clearly infringes on my nick. As does Monolith, lithium, and any other /.*lith.*/
I do believe that Mr. Wilson will be getting a call from my lawyer.
Terry Goodkind is an excellent fantasy writer. He currently has 6 books and a few short stories out. Here is an incomplete list:
Wizard's First Rule
I started reading WFR and could not put it down. Since then, I have been addicted. (I am currently finishing POC).Stone of Tears
Blood of the Fold
Temple of Winds
Soul of the Fire
Faith of the Fallen
Pillars of Creation
short story Debt of Bones
Check out http://www.ibutton.com/TINI
The TINI device has a serial, 1-wire, and ethernet port, and has slip, ppp, and dhcp software included. This could also be used to foreward packets from the Agenda's serial port to a 10mbit network. Add this to a little black box, and you have a portable lan monitor / admin terminal.
Wicked!