The whole state used the same guy to set up the machines. Here's his company's Contact Us page: LHS Associates contact page
If I was in New Hampshire or working on a campaign in any capacity for any of the candidates, I'd feel free to ask them about any discrepancies.
For those of you using screen readers, here's their phone, fax, and snail mail information since they don't even make their ELECTION RELATED web site accessible to the VOTING PUBLIC (all information is contained in images with no alternate text or titles):
phone: 888-547-8683 fax: 978-687-3670 address: LHS Associates 13 Branch St. Methuen MA 01844
The typical vote counting I've seen in the past has been two or three rows of tables, one row for each major party and maybe one for independents and small parties. They are set up in a room together, people walk around observing, and there are armed guards keeping people from tampering. It's possible to game that system, but much harder than tricking a computer.
As for which way it swung the votes... can you imagine dishonesty from the Clintons and their supporters? "I did not have fraudulent relations with that computer, Miss Diebold"? We're talking about people who see no problem swearing an oath to God to defend a country and its Constitution, then turning around and lying under an oath to God to tell the truth to that country. They think the two are completely unrelated -- a sworn oath before God and sworn oath before God administered by the same judicial branch of the same nation's government.
Yeah, because election judges by default don't care about the process and nobody ever turned down a bribe and turned over the briber to officials. What a bunch of anti-human bullshit. Bribery requires money and the dishonesty of many people. Electronic vote rigging just requires a piece of shit voting machine and one or two people who know how to game them.
By Hanlon's razor, the majority of the problem would be the gross incompetence of Diebold and officials who certify their machines with just a few truly crooked people.
When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures
The first part of that specifically says "with respect to the covered work". The part that concerns me is "you disclaim any intention to limit operation or modification of the work as a means of enforcing, against' the work's users, your or third parties' legal right to forbid circumvention of technological measures", which does not specifically mention anything about it applying to only the work in question. It's a completely separate phrase from the first part of that quote. Third parties that have legal rights about anti-circumvention are movie studios, record labels, proprietary software houses, and more. That might not be the intent, but that's how the wording reads, so that's how many people will deal with the license.
By requiring that someone distributes a trusted private key, it defeats the purpose of private key cryptography and the whole question of signing the binary becomes laughable. Better would be to force the hardware vendor to allow the user to add a public key of his own to the firmware and to allow checking against that key instead of the original with a disclaimer that the hardware manufacturer is no longer liable. Even better would be to require the vendor selling the hardware to vet and sign improved versions sent to them by third parties, but that'd be too much of a burden on the vendor.
"his is a free software license that seeks to defend the freedoms asociated with software from the impossitions ON SOFTWARE that restrictions for hardware or content entail." I could just as easily say it's a software license that imposes restrictions on hardware and content for the benefit of the software's freedom. Is that a fair way to word it?
I'm not against the GPLv3 as a new license available. It has its place. I just don't think it takes the place fully of GPLv2. I think they're both licenses worthy of consideration for people to use. I think giving people a hard time for sticking with GPLv2 instead of jumping on the v3 bandwagon is an unwise move, because mostly free is better than not free at all. The nasty attitude many have (and I'm not accusing you, this has stayed (for the most part, after that initial hump) pretty civil although heated) could sway a lot of people not toward GPLv3 but away from the GPL altogether. That seems to be the exact opposite of what FSF supporters would want.
Mine uses four spaces. How many does yours use? What about the guy sending me the next patch that's supposed to help my project? What about the guy who cleaned it up and sent it to him.
The problem with the whitespace isn't that it's enforced as a coding standard. It's that it changes the meaning of the code. You could use brackets, parentheses, some other punctuation, or keywords to denote blocks and still enforce indentation in the parser. Then you'd be able to say Python enforces good style but a program could easily reformat code to your own standard whenever the whitespace got screwed up.
Like I said, if you like Python, that's fine. I don't. It's not a bad language. It just has a quirk it picked up from ABC that I really don't care to mess with after having messed with it in ABC years ago.
Perl has odd quirks, too, as do Ruby, C, Pascal, Smalltalk, Forth, and Lisp. Some people hate Lisp for its parentheses. Other people love it for the same reason. Some people hate Perl for all the abbreviations and punctuation characters, while other think that's a great strength. It's all about trading off what you want in a language to avoid things you don't. No language is perfect, including Python, and people seem to make a lot of software work despite that.
It's news because putting new and odd genetic modifications into large mammals is a tad newish. Having them passed successfully rather than culled out of the gene pool by massive failure of the original animal, sterility, natural recoding in the sexual reproduction process, or unviable offspring is interesting.
Oh, and having a farm-fresh human liver for drunk Uncle Sal is Stuff That Matters.
The main library of functions in the core namespace along with the syntax rules for the language pretty much are the language. Having an extensible language with multiple namespaces is a much cleaner alternative to lumping so much into the core. That's the complaint.
There are people who use PHP with proper modularization, but most of what people see isn't done that way. In a language that's largely used for Open Source software, the state of the code in those OSS projects will be what the language is based on, fair or not.
I think you're entirely sidestepping at least two of my questions here.
I used the word "value" as neither economic nor moral. I used it as philosophical, as in open source has a value in preserving freedom. It's not as much freedom as you want the license to preserve, but part is better than none, yes?
I'm not talking about the freedom of Big Biz, Inc, either. I'm talking about the very real limits GPLv3 puts on the end user it's meant to protect. Many end users want to use Free Software, but might want to listen to the occasional restricted content. By making that an illegitimate activity, it's limiting the end user. The end user might want to use an OS kernel that's free, but might for security reasons need to run a signed kernel on a particular machine (I'm not talking Tivo here, but someone who needs to make sure their server isn't being tampered with). If you take the freedom from Tivo by saying you can't run the software as a signed binary, though, you're also taking it from the person who's signing it himself for his own use.
Free software licenses can protect the freedom of software. Free hardware licenses can protect the freedom of hardware. Free content licenses can protect the freedom of content. Demanding in your free software license that only certain hardware and content can be used takes real power away from real end users. Why is it so wrong to attack the problem on the three fronts you experience it rather than trying to tie it all into the software licensing?
So you rewrote a badly designed section of code to do the same work in a fraction of the space? You refactored it. That's all the word means -- to improve code and leave the same functionality in place. Just because it's a fancy jargon word somebody puffed up and because their idea of "better code" might mean something different doesn't mean you can't apply the same principles.
Most of these books on how to do software development aren't being written for you anyway. Hardware and firmware people have your own books, don't you? Most of this XP, refactoring, design patterns, and agile stuff is for people doing high-level applications where different rules apply. It's no wonder you think so little of it if you were seeing people try to apply it to stuff being embedded in a chip.
What's wrong with software licenses being for software, hardware licenses concerning hardware, and content licenses taking care of content?
If Linus is only producing software and not hardware, why should he concern himself with the freedom of the hardware?
The main difference between your point of view and the one you're attacking is that you want to tie everything up in one knot. Am I wrong about that? Is there some reason that works better than having GPL-style hardware licenses and CC or GFDL content licenses along with the GPL? Or is the whole problem that you're against mixing and matching licenses of the different parts of a complete system on principal?
Don't be satisfied with languages based on C and C++, or even all the Algol-derived languages. Learn Scheme. Learn Prolog. Learn Forth.
Take a class specifically on data structures whether you need to for your major or not. Proper data structures go from language to language much easier than syntax.
Find yourself a nice foreign literature class (most are done with texts translated into your language) or philosophy class as an elective. You'll find as a programmer or software engineer you'll interact with a lot more than just other CS majors. You'll have more in common with them knowing something outside your field. They'll be far more impressed that you know Moliere or Anaxagoras than some technical jargon about code that they don't understand for one thing.
Since you're looking as CS and Business, I can't be sure if you want to manage programmers or if you want to run a small programming shop as the owner. If you're looking at being a manager, look into psychology or sociology and learn about small-group interaction. If you're wanting to be a business owner, make sure part of your business education includes the basics of accounting, marketing, and business law. If you're wanting the third option, to write software for businesses, well, most of it is for businesses. Keep in mind that accounting software is probably the hardest business-specific software to write. If you're not sure what kind of software you want to write or in what business capacity then a good study of math, graphic design (for UIs if you want to do that), linguistics, symbolic logic, or electronics engineering could help in general.
One thing I've read lately (probably on Slashdot) that sounds like a really good idea is that instead of waiting for inspiration about what to write in other languages, pick two or three other languages and do your programming homework in those in addition to what you'll turn in. That gives you a good grasp of the other languages and might shed light on how best to implement things. It'll also get you used to evaluating projects based on which language supports the needs of the project best. That's something that'll come in handy if you have the ability to choose languages for projects later.
It does if those people actually turn out. It doesn't otherwise. They can't help fix the code if they can't see the code though. OSS is a security opportunity, and not one that's necessarily fulfilled.
There are advantages to having the code open besides security, too. Code reuse, code clarity, project longevity, and more can be helped by having more than one small team working on code.
There are two situations in which OSS helps most. One is the small team that opens their code because even a few outside helpers is a significant increase in programmers. Many projects, including the Linux kernel, start out this way.
The other is when a project becomes popular enough or gets close enough to meeting enough people's needs that large groups of programmers and major commercial and noncommercial organizations start working on the code. Here each additional programmer is statistically less significant to the overall project numbers, but the total number of people is bigger than you'd expect a development team at even a large company to contain. This is where Linux is now, with almost 2,000 developers in a fairly recent version. Sure, they're not all working on the Linux kernel full-time, but that's still a lot of eyeballs on the code.
Lots of commercial software isn't written by Microsoft, SCO, IBM, Novell, CA, Adobe, Apple, and the other big corporate software houses. Lots of it, too, is written by small teams in small companies or by in-house people supporting some other industry. Most of it is, in fact. While there are many types of software development targets, there are vanishingly few companies that have hundreds of programmers working on a single system of software. Most of the projects in the world that get hundreds of programmers involved are written, in fact, as OSS or in one of just a handful of companies.
The biggest reason OSS is so important is not necessarily because it presents a challenge to companies like Microsoft, Apple, and Adobe although OS and office suite alternatives are always nice. It's because if companies with 2 or 20 programmers who have the start of something good can have just one bug fixed by each of another 2 or 20 programmers and another company can pick up that program and develop it further without redoing the work of those 2 or 20 programmers, those things are really significant at that scale.
That mindset happens, but that's not the idea of refactoring. The right mindset is that making your code more beautiful and more elegant before your next major functionality change will help with that. If you're not going to change anything other than the code layout, that's pretty silly.
If you inherit code that's laid out badly (even from yourself when you were tired or rushed) and need to fix a bug or add a feature, the time to clean it up plus fix the bug in the cleaner version might not be much more than tracking down and fixing the bug alone. It might even be faster if the poor code layout was harboring the bug spread across too many lines. Then, the next time you need to make a change, that section of code will be more tidy.
Doing whole programs just for the sake of cleaning them up is only meaningful for two reasons. One is to practice your refactoring. The other is if you're about to do an overhaul of the whole project and are likely to touch most of those parts. Otherwise, just refactor the parts you're going to change for your bugfix or new feature anyway.
Don't forget unit testing and project testing for continuity are important, either. If you're causing regressions when refactoring, you're doing something wrong.
Even when you plan for expansion and extension, you usually plan for extension in the wrong direction. Changing business requirements, new users, and brilliant but unexpected new features often require changes to your plans for change (or extensions to your extension mechanism). Let's face it, breakthrough ideas that simply must be worked into a program aren't anticipated fully. That's what makes them breakthrough ideas.
I think more correctly you could say, "The FSF does care about freedom to see and use the source, but they also care about these other things."
The problem is the "other things" were not codified in GPLv2. In the FSF's eyes, that means they're improving upon GPLv2 with GPLv3 by codifying those other things.
That's the rub, though. Lots of other people who agreed totally with the GPLv2 don't see it the same way. They think the GPLv2 restricts enough freedoms and allows much. They think GPLv3 restricts freedoms that don't need to be restricted and that it takes away ones they actually want.
This article at Forbes is an interview with Linus, in which he says he does think what Tivo does is stupid, and that he cares. He just doesn't care enough to worry about it. Linus also says that the place to fight locked-down hardware is in hardware licenses and that the place to fight DRM is in the license for the content you produce. He also says he's worried about the freedom of the software because that's what he wrote. He thinks the freedom of hardware is up to the hardware makers and the freedom of content is up to content makers. Software licenses trying to control what you can do with hardware and content step over their bounds, so to speak.
So no, Linus is not against the goals of the FSF. He just thinks that software, hardware, and content should each take care of their own licenses.
The writer of a software program gets to license that software, but should they be able to dictate the license of content that's used with it, or that it can only be used with content of a particular license? That's what the disagreement really boils down to. The FSF is trying to promote the freedom of GNU software authors at the expense of the freedom of hardware and content developers instead of spreading out and promoting freedom from within the hardware and content realms. Their intentions are good, but many of us think the GPLv3 is bad execution of those intentions.
I'm so much of a rabid MS hater that I'm writing this post from Firefox 3b2 on Windows XP. Get real.
Where did you pull the 1% of OSS users being programmers from? Your ass? You didn't even cite your own ass? How rude!;-)
Yeah, there aren't enough world-class programmers to go around the millions of OSS projects out there, or even the most popular hundred thousand of them. Maybe not the ten thousand most popular. Yet over half the patches for the Linux kernel come from people other than the core development team.
In fact, the top submitter of changesets into Linux 2.6.20 only accounted for 4.8% of them. The top 20 contributors accounted for 28% of changesets. Similar numbers pop up by number of lines added. Linus only personally signed off on 13% of the changes in 2.6.20 so there's a good spread there, too.
The people developing the Linux kernel aren't just weekend coders in their parents' basements. Red Hat, IBM, Novell, Intel, Oracle, Google, University of Aberdeen, HP, Nokia, SGI, Astaro, MIPS Technologies, MontaVista, and Broadcom were among the top 20 sources of changesets. Stats of 7.7% for "no employer" and 25% for "unknown" appear, along with a few lesser-known companies. Add Sony to the list of employers of contributors by lines of code. Put Freescale in the list for the versions in the year in which versions from 2.6.16 to 2.6.20 were developed.
In all, 65% of the changes to the Linux kernel for version 2.6.20 was from corporate development. Over 1,900 people had patches make it into the 2.6.20 version of the kernel alone.
How many companies write and vet the code at Microsoft? Yes, I'm sure there are a bunch of dedicated people at Microsoft, and they do a pretty good job at making a usable OS. They're getting better about security. It's my opinion that Vista's kind of a mess particularly because they're having trouble designing for both usability and security from the ground up. They'll improve on that, too. I don't hate Microsoft's developers (maybe their marketing and legal departments;-), and they obviously have advantages over many smaller OSS projects.
However, the biggest OSS projects really do have a lot of people who are highly skilled professional programmers writing their code. They also have an advantage of being able to attack issues most important to their varied employers using skills and development methods different from those at other corporate contributors.
It's not a black or white issue. Microsoft's got pros and cons, and so does their software. OSS has pros and cons. I have two PCs at this desk. One's XP Pro and one's Linux. I use both every day I'm in the office. I also use Linux servers and I have a Mac at another desk. At home I have XP, Linux, Solaris, Mac, and OS/2 (the OS/2 is for fun). My wife's PC has XP on it, but she can use the Linux box when she needs to. She's not an admin level user, but she can fix some issues on Windows just from having used it so much for so long.
To bash MS when they really screw something up isn't to be a "rabid MS hater". To praise them when they do something well isn't to be an MS fan. The same's true of OSS projects. Most people want their software to meet their needs and don't root for one "team" or another. Most people who do prefer a particular project are still willing to give other projects their due respect. There are very vocal fanatics in every camp, but just because they're loud and quicker to spout doesn't mean they're actually that numerous.
You're right. I forgot to weight them based on the portion of the installation they'd each represent.
It's also unlikely that any real installation would have exactly those packages installed, BTW. Almost any installation will have packages from CPAN, PEAR, whatever Python's central repository is called, some extra stuff like syslog, logrotate, bash, and at least one text editor at the very minimum.
Let's be a little more accurate than multiplying by defects per thousand lines to make up for my previous late-night gaffe. Let's use the actual defect numbers of verified but unfixed and unverified defects.
Apache has 19 defects in 135,916 LOC. glibc has 0 defects in 588,931 LOC. Linux has 461 defects in 3,639,322 LOC. Perl has 12 defects in 496,517 LOC. PHP has 0 defects in 474,988 LOC. PostgreSQL has 37 defects in 909,148 LOC. Python has 0 defects in 282,444 LOC.
That's 6,527,266 LOC and 529 defects. That's 6527.266 TLOC. I get 0.081 defects per TLOC. That's still pretty damn good.
As I said, there's probably some other software on that server, but it starts from a pretty strong base.
It's also a performance decision and a pragmatic decision in the fact that many languages don't bootstrap on bare hardware. Let me know when you have an OS kernel running on the Core 2 Duo written in Java, Python, Erlang, Eiffel, Haskell, or Ruby.;-)
Yeah, lots of software gets written in assembly, C or C++ that probably should be in something else. No, nothing else is able to take their place for everything just yet.
Slashdot Mirror
The whole state used the same guy to set up the machines. Here's his company's Contact Us page:
LHS Associates contact page
If I was in New Hampshire or working on a campaign in any capacity for any of the candidates, I'd feel free to ask them about any discrepancies.
For those of you using screen readers, here's their phone, fax, and snail mail information since they don't even make their ELECTION RELATED web site accessible to the VOTING PUBLIC (all information is contained in images with no alternate text or titles):
phone: 888-547-8683
fax: 978-687-3670
address: LHS Associates
13 Branch St.
Methuen MA 01844
The typical vote counting I've seen in the past has been two or three rows of tables, one row for each major party and maybe one for independents and small parties. They are set up in a room together, people walk around observing, and there are armed guards keeping people from tampering. It's possible to game that system, but much harder than tricking a computer.
As for which way it swung the votes... can you imagine dishonesty from the Clintons and their supporters? "I did not have fraudulent relations with that computer, Miss Diebold"? We're talking about people who see no problem swearing an oath to God to defend a country and its Constitution, then turning around and lying under an oath to God to tell the truth to that country. They think the two are completely unrelated -- a sworn oath before God and sworn oath before God administered by the same judicial branch of the same nation's government.
Yeah, because election judges by default don't care about the process and nobody ever turned down a bribe and turned over the briber to officials. What a bunch of anti-human bullshit. Bribery requires money and the dishonesty of many people. Electronic vote rigging just requires a piece of shit voting machine and one or two people who know how to game them.
By Hanlon's razor, the majority of the problem would be the gross incompetence of Diebold and officials who certify their machines with just a few truly crooked people.
The first part of that specifically says "with respect to the covered work". The part that concerns me is "you disclaim any intention to limit operation or modification of the work as a means of enforcing, against' the work's users, your or third parties' legal right to forbid circumvention of technological measures", which does not specifically mention anything about it applying to only the work in question. It's a completely separate phrase from the first part of that quote. Third parties that have legal rights about anti-circumvention are movie studios, record labels, proprietary software houses, and more. That might not be the intent, but that's how the wording reads, so that's how many people will deal with the license.
By requiring that someone distributes a trusted private key, it defeats the purpose of private key cryptography and the whole question of signing the binary becomes laughable. Better would be to force the hardware vendor to allow the user to add a public key of his own to the firmware and to allow checking against that key instead of the original with a disclaimer that the hardware manufacturer is no longer liable. Even better would be to require the vendor selling the hardware to vet and sign improved versions sent to them by third parties, but that'd be too much of a burden on the vendor.
"his is a free software license that seeks to defend the freedoms asociated with software from the impossitions ON SOFTWARE that restrictions for hardware or content entail." I could just as easily say it's a software license that imposes restrictions on hardware and content for the benefit of the software's freedom. Is that a fair way to word it?
I'm not against the GPLv3 as a new license available. It has its place. I just don't think it takes the place fully of GPLv2. I think they're both licenses worthy of consideration for people to use. I think giving people a hard time for sticking with GPLv2 instead of jumping on the v3 bandwagon is an unwise move, because mostly free is better than not free at all. The nasty attitude many have (and I'm not accusing you, this has stayed (for the most part, after that initial hump) pretty civil although heated) could sway a lot of people not toward GPLv3 but away from the GPL altogether. That seems to be the exact opposite of what FSF supporters would want.
Sure, but not as much as 360 JCL or 360 assembly, right? How about Bliss or FORTRAN IV (if you can find them)?
Mine uses four spaces. How many does yours use? What about the guy sending me the next patch that's supposed to help my project? What about the guy who cleaned it up and sent it to him.
The problem with the whitespace isn't that it's enforced as a coding standard. It's that it changes the meaning of the code. You could use brackets, parentheses, some other punctuation, or keywords to denote blocks and still enforce indentation in the parser. Then you'd be able to say Python enforces good style but a program could easily reformat code to your own standard whenever the whitespace got screwed up.
Like I said, if you like Python, that's fine. I don't. It's not a bad language. It just has a quirk it picked up from ABC that I really don't care to mess with after having messed with it in ABC years ago.
Perl has odd quirks, too, as do Ruby, C, Pascal, Smalltalk, Forth, and Lisp. Some people hate Lisp for its parentheses. Other people love it for the same reason. Some people hate Perl for all the abbreviations and punctuation characters, while other think that's a great strength. It's all about trading off what you want in a language to avoid things you don't. No language is perfect, including Python, and people seem to make a lot of software work despite that.
Nicholas Negroponte is on line one for you. He wants to know if you work for Intel or Microsoft, and when you'll stop dissing the XO. ;-)
It's news because putting new and odd genetic modifications into large mammals is a tad newish. Having them passed successfully rather than culled out of the gene pool by massive failure of the original animal, sterility, natural recoding in the sexual reproduction process, or unviable offspring is interesting.
Oh, and having a farm-fresh human liver for drunk Uncle Sal is Stuff That Matters.
What the hell... one of these things might keep the damn moths away from the windows at least.
Damn fat fingers. I meant RPG/400. Or COBOL for that matter.
I disagree. Show me one thing RGP/400 does better than another language. ;-)
"Oh, shit! I put four spaces where I meant a tab!"
At least Perl's line noise is legible. You still have it in Python, but it's invisible. I know which I prefer. You know which you prefer.
We don't need to bash each other's choices, but your language is not objectively superior because you spout anecdotes and personal preferences.
The main library of functions in the core namespace along with the syntax rules for the language pretty much are the language. Having an extensible language with multiple namespaces is a much cleaner alternative to lumping so much into the core. That's the complaint.
There are people who use PHP with proper modularization, but most of what people see isn't done that way. In a language that's largely used for Open Source software, the state of the code in those OSS projects will be what the language is based on, fair or not.
I think you're entirely sidestepping at least two of my questions here.
I used the word "value" as neither economic nor moral. I used it as philosophical, as in open source has a value in preserving freedom. It's not as much freedom as you want the license to preserve, but part is better than none, yes?
I'm not talking about the freedom of Big Biz, Inc, either. I'm talking about the very real limits GPLv3 puts on the end user it's meant to protect. Many end users want to use Free Software, but might want to listen to the occasional restricted content. By making that an illegitimate activity, it's limiting the end user. The end user might want to use an OS kernel that's free, but might for security reasons need to run a signed kernel on a particular machine (I'm not talking Tivo here, but someone who needs to make sure their server isn't being tampered with). If you take the freedom from Tivo by saying you can't run the software as a signed binary, though, you're also taking it from the person who's signing it himself for his own use.
Free software licenses can protect the freedom of software. Free hardware licenses can protect the freedom of hardware. Free content licenses can protect the freedom of content. Demanding in your free software license that only certain hardware and content can be used takes real power away from real end users. Why is it so wrong to attack the problem on the three fronts you experience it rather than trying to tie it all into the software licensing?
So you rewrote a badly designed section of code to do the same work in a fraction of the space? You refactored it. That's all the word means -- to improve code and leave the same functionality in place. Just because it's a fancy jargon word somebody puffed up and because their idea of "better code" might mean something different doesn't mean you can't apply the same principles.
Most of these books on how to do software development aren't being written for you anyway. Hardware and firmware people have your own books, don't you? Most of this XP, refactoring, design patterns, and agile stuff is for people doing high-level applications where different rules apply. It's no wonder you think so little of it if you were seeing people try to apply it to stuff being embedded in a chip.
Open source has lots of value.
What's wrong with software licenses being for software, hardware licenses concerning hardware, and content licenses taking care of content?
If Linus is only producing software and not hardware, why should he concern himself with the freedom of the hardware?
The main difference between your point of view and the one you're attacking is that you want to tie everything up in one knot. Am I wrong about that? Is there some reason that works better than having GPL-style hardware licenses and CC or GFDL content licenses along with the GPL? Or is the whole problem that you're against mixing and matching licenses of the different parts of a complete system on principal?
Don't be satisfied with languages based on C and C++, or even all the Algol-derived languages. Learn Scheme. Learn Prolog. Learn Forth.
Take a class specifically on data structures whether you need to for your major or not. Proper data structures go from language to language much easier than syntax.
Find yourself a nice foreign literature class (most are done with texts translated into your language) or philosophy class as an elective. You'll find as a programmer or software engineer you'll interact with a lot more than just other CS majors. You'll have more in common with them knowing something outside your field. They'll be far more impressed that you know Moliere or Anaxagoras than some technical jargon about code that they don't understand for one thing.
Since you're looking as CS and Business, I can't be sure if you want to manage programmers or if you want to run a small programming shop as the owner. If you're looking at being a manager, look into psychology or sociology and learn about small-group interaction. If you're wanting to be a business owner, make sure part of your business education includes the basics of accounting, marketing, and business law. If you're wanting the third option, to write software for businesses, well, most of it is for businesses. Keep in mind that accounting software is probably the hardest business-specific software to write. If you're not sure what kind of software you want to write or in what business capacity then a good study of math, graphic design (for UIs if you want to do that), linguistics, symbolic logic, or electronics engineering could help in general.
One thing I've read lately (probably on Slashdot) that sounds like a really good idea is that instead of waiting for inspiration about what to write in other languages, pick two or three other languages and do your programming homework in those in addition to what you'll turn in. That gives you a good grasp of the other languages and might shed light on how best to implement things. It'll also get you used to evaluating projects based on which language supports the needs of the project best. That's something that'll come in handy if you have the ability to choose languages for projects later.
It does if those people actually turn out. It doesn't otherwise. They can't help fix the code if they can't see the code though. OSS is a security opportunity, and not one that's necessarily fulfilled.
There are advantages to having the code open besides security, too. Code reuse, code clarity, project longevity, and more can be helped by having more than one small team working on code.
There are two situations in which OSS helps most. One is the small team that opens their code because even a few outside helpers is a significant increase in programmers. Many projects, including the Linux kernel, start out this way.
The other is when a project becomes popular enough or gets close enough to meeting enough people's needs that large groups of programmers and major commercial and noncommercial organizations start working on the code. Here each additional programmer is statistically less significant to the overall project numbers, but the total number of people is bigger than you'd expect a development team at even a large company to contain. This is where Linux is now, with almost 2,000 developers in a fairly recent version. Sure, they're not all working on the Linux kernel full-time, but that's still a lot of eyeballs on the code.
Lots of commercial software isn't written by Microsoft, SCO, IBM, Novell, CA, Adobe, Apple, and the other big corporate software houses. Lots of it, too, is written by small teams in small companies or by in-house people supporting some other industry. Most of it is, in fact. While there are many types of software development targets, there are vanishingly few companies that have hundreds of programmers working on a single system of software. Most of the projects in the world that get hundreds of programmers involved are written, in fact, as OSS or in one of just a handful of companies.
The biggest reason OSS is so important is not necessarily because it presents a challenge to companies like Microsoft, Apple, and Adobe although OS and office suite alternatives are always nice. It's because if companies with 2 or 20 programmers who have the start of something good can have just one bug fixed by each of another 2 or 20 programmers and another company can pick up that program and develop it further without redoing the work of those 2 or 20 programmers, those things are really significant at that scale.
That mindset happens, but that's not the idea of refactoring. The right mindset is that making your code more beautiful and more elegant before your next major functionality change will help with that. If you're not going to change anything other than the code layout, that's pretty silly.
If you inherit code that's laid out badly (even from yourself when you were tired or rushed) and need to fix a bug or add a feature, the time to clean it up plus fix the bug in the cleaner version might not be much more than tracking down and fixing the bug alone. It might even be faster if the poor code layout was harboring the bug spread across too many lines. Then, the next time you need to make a change, that section of code will be more tidy.
Doing whole programs just for the sake of cleaning them up is only meaningful for two reasons. One is to practice your refactoring. The other is if you're about to do an overhaul of the whole project and are likely to touch most of those parts. Otherwise, just refactor the parts you're going to change for your bugfix or new feature anyway.
Don't forget unit testing and project testing for continuity are important, either. If you're causing regressions when refactoring, you're doing something wrong.
Even when you plan for expansion and extension, you usually plan for extension in the wrong direction. Changing business requirements, new users, and brilliant but unexpected new features often require changes to your plans for change (or extensions to your extension mechanism). Let's face it, breakthrough ideas that simply must be worked into a program aren't anticipated fully. That's what makes them breakthrough ideas.
I think more correctly you could say, "The FSF does care about freedom to see and use the source, but they also care about these other things."
The problem is the "other things" were not codified in GPLv2. In the FSF's eyes, that means they're improving upon GPLv2 with GPLv3 by codifying those other things.
That's the rub, though. Lots of other people who agreed totally with the GPLv2 don't see it the same way. They think the GPLv2 restricts enough freedoms and allows much. They think GPLv3 restricts freedoms that don't need to be restricted and that it takes away ones they actually want.
This article at Forbes is an interview with Linus, in which he says he does think what Tivo does is stupid, and that he cares. He just doesn't care enough to worry about it. Linus also says that the place to fight locked-down hardware is in hardware licenses and that the place to fight DRM is in the license for the content you produce. He also says he's worried about the freedom of the software because that's what he wrote. He thinks the freedom of hardware is up to the hardware makers and the freedom of content is up to content makers. Software licenses trying to control what you can do with hardware and content step over their bounds, so to speak.
So no, Linus is not against the goals of the FSF. He just thinks that software, hardware, and content should each take care of their own licenses.
The writer of a software program gets to license that software, but should they be able to dictate the license of content that's used with it, or that it can only be used with content of a particular license? That's what the disagreement really boils down to. The FSF is trying to promote the freedom of GNU software authors at the expense of the freedom of hardware and content developers instead of spreading out and promoting freedom from within the hardware and content realms. Their intentions are good, but many of us think the GPLv3 is bad execution of those intentions.
I'm so much of a rabid MS hater that I'm writing this post from Firefox 3b2 on Windows XP. Get real.
;-)
;-), and they obviously have advantages over many smaller OSS projects.
Where did you pull the 1% of OSS users being programmers from? Your ass? You didn't even cite your own ass? How rude!
Yeah, there aren't enough world-class programmers to go around the millions of OSS projects out there, or even the most popular hundred thousand of them. Maybe not the ten thousand most popular. Yet over half the patches for the Linux kernel come from people other than the core development team.
In fact, the top submitter of changesets into Linux 2.6.20 only accounted for 4.8% of them. The top 20 contributors accounted for 28% of changesets. Similar numbers pop up by number of lines added. Linus only personally signed off on 13% of the changes in 2.6.20 so there's a good spread there, too.
The people developing the Linux kernel aren't just weekend coders in their parents' basements. Red Hat, IBM, Novell, Intel, Oracle, Google, University of Aberdeen, HP, Nokia, SGI, Astaro, MIPS Technologies, MontaVista, and Broadcom were among the top 20 sources of changesets. Stats of 7.7% for "no employer" and 25% for "unknown" appear, along with a few lesser-known companies. Add Sony to the list of employers of contributors by lines of code. Put Freescale in the list for the versions in the year in which versions from 2.6.16 to 2.6.20 were developed.
In all, 65% of the changes to the Linux kernel for version 2.6.20 was from corporate development. Over 1,900 people had patches make it into the 2.6.20 version of the kernel alone.
All these statistics on who develops Linux can be found at LWN.net's article called "Who Wrote 2.6.20?".
How many companies write and vet the code at Microsoft? Yes, I'm sure there are a bunch of dedicated people at Microsoft, and they do a pretty good job at making a usable OS. They're getting better about security. It's my opinion that Vista's kind of a mess particularly because they're having trouble designing for both usability and security from the ground up. They'll improve on that, too. I don't hate Microsoft's developers (maybe their marketing and legal departments
However, the biggest OSS projects really do have a lot of people who are highly skilled professional programmers writing their code. They also have an advantage of being able to attack issues most important to their varied employers using skills and development methods different from those at other corporate contributors.
It's not a black or white issue. Microsoft's got pros and cons, and so does their software. OSS has pros and cons. I have two PCs at this desk. One's XP Pro and one's Linux. I use both every day I'm in the office. I also use Linux servers and I have a Mac at another desk. At home I have XP, Linux, Solaris, Mac, and OS/2 (the OS/2 is for fun). My wife's PC has XP on it, but she can use the Linux box when she needs to. She's not an admin level user, but she can fix some issues on Windows just from having used it so much for so long.
To bash MS when they really screw something up isn't to be a "rabid MS hater". To praise them when they do something well isn't to be an MS fan. The same's true of OSS projects. Most people want their software to meet their needs and don't root for one "team" or another. Most people who do prefer a particular project are still willing to give other projects their due respect. There are very vocal fanatics in every camp, but just because they're loud and quicker to spout doesn't mean they're actually that numerous.
You're right. I forgot to weight them based on the portion of the installation they'd each represent.
It's also unlikely that any real installation would have exactly those packages installed, BTW. Almost any installation will have packages from CPAN, PEAR, whatever Python's central repository is called, some extra stuff like syslog, logrotate, bash, and at least one text editor at the very minimum.
Let's be a little more accurate than multiplying by defects per thousand lines to make up for my previous late-night gaffe. Let's use the actual defect numbers of verified but unfixed and unverified defects.
Apache has 19 defects in 135,916 LOC.
glibc has 0 defects in 588,931 LOC.
Linux has 461 defects in 3,639,322 LOC.
Perl has 12 defects in 496,517 LOC.
PHP has 0 defects in 474,988 LOC.
PostgreSQL has 37 defects in 909,148 LOC.
Python has 0 defects in 282,444 LOC.
That's 6,527,266 LOC and 529 defects. That's 6527.266 TLOC. I get 0.081 defects per TLOC. That's still pretty damn good.
As I said, there's probably some other software on that server, but it starts from a pretty strong base.
Nobody can reasonably argue that having the source makes it harder to find where exploits might target.
It's also a performance decision and a pragmatic decision in the fact that many languages don't bootstrap on bare hardware. Let me know when you have an OS kernel running on the Core 2 Duo written in Java, Python, Erlang, Eiffel, Haskell, or Ruby. ;-)
Yeah, lots of software gets written in assembly, C or C++ that probably should be in something else. No, nothing else is able to take their place for everything just yet.