If you want a bit more leisurely time (and a more sophisticated task), you might try out the ICFP Programming Contest. It runs 72 hours, and you can participate from the comfort of your living room. I've been on a team four or five times and have always had a good time. This year we're organizing it, so I know it's gonna be good!
Twin Galaxies is really bad about making videos available.. this isn't the first time! Fortunately there's plenty of great stuff at Speed Demos Archive, the "other" official record keepers.
Standards compliance is pointless unless the standards are supported. Give me a guarantee that valid documents will be rendered correctly and I'll be glad to stop using the guess-and-check method. It rather makes me feel like a C++ programmer anyway.
First, comments are useful even if you are hiding your code forever. I can't tell you how often I've come back to an old piece of code, intended only for my own use, and been confounded by its obscurity or pleased to see an explanation in a comment. It makes a difference. It's also a good way to force you to think about what you're doing before you do it. (Even better are languages that allow you to express some of these things in the language itself, so that they are additionally checked by the compiler!)
Two: I'm surprised the article didn't explicitly mention pre- and post-conditions, since this has been known for years. When documenting a function, it's critical to state precisely the conditions under which it will work, what it does, and what state of the world it guarantees after being executed. Being specific here helps for the person who wants to call your function, but is even more important for blame assignment: when the program goes wrong, it's important to be able to figure out WHY. Is it the caller or callee? Being able to see that a function is called without its preconditions, for instance, would blame the caller. Seeing that the function doesn't meet its stated specification in a corner case would blame the function itself.
I would recommend exercise instead of starving yourself. I've found that running for 20 minutes every morning increases my alertness and mood through the day. If you're programming all day, then exercise is advisable for more than just weight loss!
The other thing to consider is that different foods make you feel more or less full, and this is not necessarily related to their calorie content. If you feel like you need to eat throughout the day, take a look at one of the various lists on the internet, and choose wisely.
Otherwise, well, what can I say--not everything is easy.
I would say that your direct superior has the responsibility to make the case to upper management that code quality matters (I would agree with his priorities, in fact!). This is, after all, the supposed point of a management hierarchy.
First, I am happy to see these stackguard-like systems be integrated into C compilers and runtimes. I think they can go a long way towards solving common security problems, and I am dumbfounded that distributions aren't clamoring to have these installed by default. The only explanation I can think of is this bizarre obsession with performance in the Linux world, as if a few percentage points of performance are worth living in constant fear of being hacked. However, it's not really fair to say that C "has" these security features, since hardly any of the C programs that are out there are running with them enabled. (On the other hand, basically every Java program runs with array bounds checks!) The day that my linux system comes pre-installed with OpenSSH running with heap and stack protection, I will happily change my tune. Unfortunately I think that day is sadly a lot further off then the author seems to suggest.
I expected to be really angered by this article, but I actually thought it was pretty reasonable. Basically his argument comes down to this: given two systems with indistinguishable security features, the one with the smaller trusted computing base is more trustworthy. I totally agree, and it's clear that the Java+javac+JVM+OS TCB is larger than C+GCC+CRT+Proguard+PaX+OS. What I don't agree with is that these languages provide equivalent security features. For one thing, unless I am mistaken, C running with these protections does not provide array bounds checking, unless the out-of-bounds writes happen to hit certain places identified as dangerous. Although this unarguably closes a lot of common attack vectors, it is not the same kind of automatic and absolute protection that a safe language whose semantics includes array bounds checking offers. Any time an attacker can compromise your data structures in an unexpected way, he is going to have more access than you intended. Language-based memory protection is a security feature that C does not offer, even extended with these systems.
The point I really want to make, though, is that the author presents a false dichotomy: Choose either the lean dangerous language C with some OS-style protections, or choose the bloated safe language Java with a lot of stuff you have to trust. Fortunately, there is a middle ground that I think provides better security than both; any of the compiled safe languages. A great example is Standard ML; its performance is somewhere between C and C++, it compiles to native code (plus a modest runtime, implementing for instance garbage collection; surely smaller than PaX and Proguard), and has none of the "undefined behavior" that causes security problems in C. Since it's also a higher-level language, programmers get the benefit of writing shorter and more concise code, which gives them more time to both look for high-level security problems that can never be caught by a program, and to optimize the algorithms in their code for better performance. (For a data point: my FTP server written in SML is 2200 lines; wu_ftpd is just under 20,000!) There is no reason why safe languages need a "platform" like the JVM or Mono or.NET. SML compilers simply compile in the runtime checks as regular old machine instructions, and this code is so simple that it's pretty unlikely that they would get it wrong. (About as likely as a particular aspect of your C compiler having a bug, basically.)
So, it's great to make C more secure by adding features to its runtime. I really hope this happens soon so that I don't need to patch my linux box so often. But the Java methodology is not the only alternative. Lightweight compiled languages with built in language security mechanisms do better than both.
I can generally agree with Linus that English-language specifications are hardly ever good enough to build software around. I can think of at least one notable example that is both large, useful, and accurate: The Definition of Standard ML defines the programming language SML in a way that is very accurate and thorough, to the point that the specification is almost machine-executable. (Indeed, a project is currently underway at CMU to formalize an alternate version of the definition in Twelf, and mechanically prove it correct, which would really make it machine executable.) Because of this spec, SML has several compilers that are impressively compatible, and where they differ, it's almost always clear who's right and who's wrong. (To be fair, there are some known mistakes and ambiguities in the published version, which is one of the reasons for the machine-verifiable version in development.)
The real problem is that specs are hard, I mean, way harder than writing software that more-or-less works, like linux does. If you believe "worse is better", then maybe specs aren't necessary. If you believe that it's worth the time to make sure you're really doing something right, it is possible to write specs that are accurate and useful, and that can be helpful to collect your thoughts outside the warzone of source code, and reason abstractly about the program that you intend to write.
emacs, whose shell mode and keyboard macros have totally replaced the crude shell-or-worse scripts that one writes and debugs to perform repetitive daily tasks.
I doubt I'm the only one saying this, but let me reiterate:
* A Computer Science degree is not primarily about getting a job * Understanding theory does in fact make you a better, and more employable, programmer
Now, his code can already take advantage of any amount of GPL'ed code that he would like. It's only a legal issue when his company goes to sell the code. So I would refrain from using point #3.
Well, not just sell, but distribute. If this program isn't just for internal use--like if they are installing it at customer's sites as part of some service contract, perhaps, then they need to abide by the terms of the GPL if there is GPL code in there. He wasn't really clear about how they're using it.
But yes, I am unable to speak the IT-speak indeed.
builds goodwill of a community (that may be your customers (?))
can result in free development work by hobbyists that use your code
allows you to legally make use of the vast library of other GPL code out there
a free alternative may supplant proprietary solutions of your competitors (see IBM's various contributions..); best if you have no commercial plans for your product
open source is a cool buzzword to have attached to your product and company at little cost
Of course, if you can sell him on FSF dogma, then there are loads of philosophical advantages, too.
Slashdot Mirror
Here are some high-res pictures of a non-working Bombe rebuild from Bletchley last year:
2 2/1/2 3/1/4 91/1/
http://gallery.spacebar.org/f/a/photo/viewpic/1/5
http://gallery.spacebar.org/f/a/photo/viewpic/1/5
http://pictures.spacebar.org/f/a/photo/viewpic/2/
If you want a bit more leisurely time (and a more sophisticated task), you might try out the ICFP Programming Contest. It runs 72 hours, and you can participate from the comfort of your living room. I've been on a team four or five times and have always had a good time. This year we're organizing it, so I know it's gonna be good!
Twin Galaxies is really bad about making videos available.. this isn't the first time! Fortunately there's plenty of great stuff at Speed Demos Archive, the "other" official record keepers.
Yeah, I hope the "market" "sorts out" this Infoworld business too.
Standards compliance is pointless unless the standards are supported. Give me a guarantee that valid documents will be rendered correctly and I'll be glad to stop using the guess-and-check method. It rather makes me feel like a C++ programmer anyway.
Two M-audio delta-44s or delta-66s.
Neither side is rational. It seems to be from a Gardner hoax.
equidistant from each other?
First, comments are useful even if you are hiding your code forever. I can't tell you how often I've come back to an old piece of code, intended only for my own use, and been confounded by its obscurity or pleased to see an explanation in a comment. It makes a difference. It's also a good way to force you to think about what you're doing before you do it. (Even better are languages that allow you to express some of these things in the language itself, so that they are additionally checked by the compiler!)
Two: I'm surprised the article didn't explicitly mention pre- and post-conditions, since this has been known for years. When documenting a function, it's critical to state precisely the conditions under which it will work, what it does, and what state of the world it guarantees after being executed. Being specific here helps for the person who wants to call your function, but is even more important for blame assignment: when the program goes wrong, it's important to be able to figure out WHY. Is it the caller or callee? Being able to see that a function is called without its preconditions, for instance, would blame the caller. Seeing that the function doesn't meet its stated specification in a corner case would blame the function itself.
Even sweatshop workers can work miracles under the threat of being shot.
I would recommend exercise instead of starving yourself. I've found that running for 20 minutes every morning increases my alertness and mood through the day. If you're programming all day, then exercise is advisable for more than just weight loss!
The other thing to consider is that different foods make you feel more or less full, and this is not necessarily related to their calorie content. If you feel like you need to eat throughout the day, take a look at one of the various lists on the internet, and choose wisely.
Otherwise, well, what can I say--not everything is easy.
Zombies and Wi-Fi. What more could you want?
Cheese?
I would say that your direct superior has the responsibility to make the case to upper management that code quality matters (I would agree with his priorities, in fact!). This is, after all, the supposed point of a management hierarchy.
First, I am happy to see these stackguard-like systems be integrated into C compilers and runtimes. I think they can go a long way towards solving common security problems, and I am dumbfounded that distributions aren't clamoring to have these installed by default. The only explanation I can think of is this bizarre obsession with performance in the Linux world, as if a few percentage points of performance are worth living in constant fear of being hacked. However, it's not really fair to say that C "has" these security features, since hardly any of the C programs that are out there are running with them enabled. (On the other hand, basically every Java program runs with array bounds checks!) The day that my linux system comes pre-installed with OpenSSH running with heap and stack protection, I will happily change my tune. Unfortunately I think that day is sadly a lot further off then the author seems to suggest.
.NET. SML compilers simply compile in the runtime checks as regular old machine instructions, and this code is so simple that it's pretty unlikely that they would get it wrong. (About as likely as a particular aspect of your C compiler having a bug, basically.)
I expected to be really angered by this article, but I actually thought it was pretty reasonable. Basically his argument comes down to this: given two systems with indistinguishable security features, the one with the smaller trusted computing base is more trustworthy. I totally agree, and it's clear that the Java+javac+JVM+OS TCB is larger than C+GCC+CRT+Proguard+PaX+OS. What I don't agree with is that these languages provide equivalent security features. For one thing, unless I am mistaken, C running with these protections does not provide array bounds checking, unless the out-of-bounds writes happen to hit certain places identified as dangerous. Although this unarguably closes a lot of common attack vectors, it is not the same kind of automatic and absolute protection that a safe language whose semantics includes array bounds checking offers. Any time an attacker can compromise your data structures in an unexpected way, he is going to have more access than you intended. Language-based memory protection is a security feature that C does not offer, even extended with these systems.
The point I really want to make, though, is that the author presents a false dichotomy: Choose either the lean dangerous language C with some OS-style protections, or choose the bloated safe language Java with a lot of stuff you have to trust. Fortunately, there is a middle ground that I think provides better security than both; any of the compiled safe languages. A great example is Standard ML; its performance is somewhere between C and C++, it compiles to native code (plus a modest runtime, implementing for instance garbage collection; surely smaller than PaX and Proguard), and has none of the "undefined behavior" that causes security problems in C. Since it's also a higher-level language, programmers get the benefit of writing shorter and more concise code, which gives them more time to both look for high-level security problems that can never be caught by a program, and to optimize the algorithms in their code for better performance. (For a data point: my FTP server written in SML is 2200 lines; wu_ftpd is just under 20,000!) There is no reason why safe languages need a "platform" like the JVM or Mono or
So, it's great to make C more secure by adding features to its runtime. I really hope this happens soon so that I don't need to patch my linux box so often. But the Java methodology is not the only alternative. Lightweight compiled languages with built in language security mechanisms do better than both.
I can generally agree with Linus that English-language specifications are hardly ever good enough to build software around. I can think of at least one notable example that is both large, useful, and accurate: The Definition of Standard ML defines the programming language SML in a way that is very accurate and thorough, to the point that the specification is almost machine-executable. (Indeed, a project is currently underway at CMU to formalize an alternate version of the definition in Twelf, and mechanically prove it correct, which would really make it machine executable.) Because of this spec, SML has several compilers that are impressively compatible, and where they differ, it's almost always clear who's right and who's wrong. (To be fair, there are some known mistakes and ambiguities in the published version, which is one of the reasons for the machine-verifiable version in development.)
The real problem is that specs are hard, I mean, way harder than writing software that more-or-less works, like linux does. If you believe "worse is better", then maybe specs aren't necessary. If you believe that it's worth the time to make sure you're really doing something right, it is possible to write specs that are accurate and useful, and that can be helpful to collect your thoughts outside the warzone of source code, and reason abstractly about the program that you intend to write.
emacs, whose shell mode and keyboard macros have totally replaced the crude shell-or-worse scripts that one writes and debugs to perform repetitive daily tasks.
I doubt I'm the only one saying this, but let me reiterate:
* A Computer Science degree is not primarily about getting a job
* Understanding theory does in fact make you a better, and more employable, programmer
Not that surprising, since for one thing it's solid state and so won't be subject to as much EM interference.
Wind Waker was easily among the best-looking video games I've ever played. It impressed me more than DOOM III, that's for sure.
You guys do realize that not everything that is against the law is crime, right?
Next they need to invent quad damage.
SKATEBOARDING is not a CRIME
Now, his code can already take advantage of any amount of GPL'ed code that he would like. It's only a legal issue when his company goes to sell the code. So I would refrain from using point #3.
Well, not just sell, but distribute. If this program isn't just for internal use--like if they are installing it at customer's sites as part of some service contract, perhaps, then they need to abide by the terms of the GPL if there is GPL code in there. He wasn't really clear about how they're using it.
But yes, I am unable to speak the IT-speak indeed.
builds goodwill of a community (that may be your customers (?))
can result in free development work by hobbyists that use your code
allows you to legally make use of the vast library of other GPL code out there
a free alternative may supplant proprietary solutions of your competitors (see IBM's various contributions..); best if you have no commercial plans for your product
open source is a cool buzzword to have attached to your product and company at little cost
Of course, if you can sell him on FSF dogma, then there are loads of philosophical advantages, too.
The breakthrough promises a cheap and disposable power source for home health tests. ... that you pee on.