30 Nov 06 Using SCons in a large project
I work on large projects for my job, and we currently use Make, just like everyone else. Our project layout is complicated, which means that the Makefiles are practically voodoo at this point. What makes it even worse is that we try to re-use code, which means we have a directory structure just for common code. Inevitably though, as any engineer finds out when trying to re-use code like this (especially if being shared among too many projects), the code isn’t really always common, and in some cases, diverges significantly. This leads to the use of ever-more confusing variable uses, included Makefiles (ostensibly to make things more modular), and other trickery to make targets build and link in the correct order.
A few years ago, I discovered a project called SCons. It promised to do a lot of neat things, but it was still new at that point, and brand-new open source projects typically aren’t usable. I tried it out, but it seemed flaky and unnatural. Some of that can be attributed to my lack of experience with Python and build tools other than Make, but it was also just flaky.
Fast-forward to 2006. (more…)
20 Nov 06 Engineers don’t get capitalization
They also don’t get a number of other things, like punctuation and grammar.
When I was in 1st grade, my teacher gave us an assignment to write something – you know, on those tables with the huge writing lines with the dashed line in the middle so you’d know how big to make your lower-case letters.
Anyway, I asked the teacher if we should use capital letters or not. She said something to the effect of “Either one is fine.” As a 7-year-old, I interpreted her a little too literally, and I wrote things like “I WenT tO ThE paRk.” My grade on that assignment was really low, and the teacher explained that she meant for us to use capital letters all throughout or not at all.
Engineers aren’t much better. What’s even more surprising is that these documents that I’ve read were written by senior engineers who have written numerous documents like these and are very highly paid. The documents I’m talking about have phrases like “Signal Sample Rate” and “Tuned Signal Bandwidth” where they should be “Signal sample rate” and “Tuned signal bandwidth.” These are pretty benign examples – there are far worse ones, but I’m not permitted to reproduce many of them here.
It’s baffling to me; I have no idea why it seems to some engineers that words like “signal” need to be capitalized when they aren’t proper nouns or part of a title or any other category of words or phrases that need to be capitalized. It’s very distracting to read documents like this because instead of focusing on the subject matter, I think about how badly the document was written.
Update: I just realized that I previously wrote a post very much like this one. I’ll leave this as is, but add that the duplication illustrates that I see poorly-written documents on a regular basis. I’d be embarrased if I wrote such a document.
Tags: software_engineering, writing_skills
17 Nov 06 Ballmer on Novell, Linux and patents
Ballmer on Novell, Linux and patents
This smells like “SCO v IBM vol. II” to me. One commentor on the Post-Intelligencer website seems to elucidate clearly what’s going on:
#16666
Posted by unregistered user at 11/17/06 7:15 a.m.
So if Linux violates Microsoft’s patents, why doesn’t Microsoft say which patents are being violated and sue over them? Anybody?
I think we all know the answer. If it was to their advantage to sue, they would. Sure, they wouldn’t have much luck suing just the Linux developers, but they could easily sue Red Hat, Ubuntu, Linspire, Xandros, etc.
But they haven’t. That could only mean that they believe they get more benefit from keeping the “violations” secret.
This suggests several things:
1) They think it would be hard to win the lawsuits
2) They’re afraid some of the patents might be invalidated if examined closely (prior art, perhaps?)
3) They’re afraid it might be too easy to rewrite the code to avoid the violations
4) They either have no violations, or the violations are not exactly many or majorSome combination of the above means that it makes more sense to claim “secret” violations and make corporations nervous about unspecified liability.
If they can’t identify the violations, they don’t have much of a case.
Tags: GNU, intellectual-property, linux, microsoft
16 Nov 06 GPL More Trouble Than It’s Worth
This is a great example of the hypocrisy of the GNU GPL and the associated ideology that is so much baggage.
From the GNU website:
“Free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech”, not as in “free beer”.
Free software is a matter of the users’ freedom to run, copy, distribute, study, change and improve the software. More precisely, it refers to four kinds of freedom, for the users of the software:
- The freedom to run the program, for any purpose (freedom 0).
- The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
- The freedom to redistribute copies so you can help your neighbor (freedom 2).
- The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
This all sounds great. I’m not a subscriber to the “software wants to be free” ideology that Richard Stallman advocates (which is simple socialism with communist fantasies – it’s not even disguised, it’s blatant). What bothers me most about GNU is their inconsistency with their own goals.
Users of software get the 4 enumerated freedoms; that is, unless the user is Microsoft or anyone that wants to work with Microsoft. You’re free to redistribute copies, and run the program for any purpose, unless it’s under the protected of patents and used for the purpose of generating a profit for a company that doesn’t write “liberated” software. “Freedom” #3 (the last one) is the worst one: you’re free to make improvements to this “free” software, so long as you give your work away for free and impose the same restrictions on users of your derivative work.
It basically boils down to GNU insisting that restrictions on software are bad, unless they’re the restrictions GNU says are good. This is why I prefer BSD/MIT-compatible licensing, and the OpenBSD operating system in particular. BSD licensed software is truly “free”, as GNU claims they want, but BSD doesn’t force any license restrictions on the user – it doesn’t have the GPL “viral effect”. Many people who write BSD-licensed software believe “software should be free”, but at least they actually practice what they preach instead of brow-beating people into submission like GNU does.
I know this is all old news, and the merits and/or problems with the GPL have been debated ad nauseum across many sites on the internet, but this particular article describing how GNU is coming up with new and creative ways to put more licensing restrictions into the GPL v3 really rubbed me the wrong way.
Tags: free-software, GNU, OpenBSD
