marcus

The point to remember is that a security system is only as strong as its weakest link, in the comic the human storing the password.

But there are many other weak spots available to people who want to decode an encrypted system, keyloggers, social engineering etc.

Not necessarily, the question is do you procrastinate on parts of it significantly more than the rest, if you do that part probably does stink.

Actually that is what separates the professional from the hobbyist (I've seen both bad professional programmers aka 9-5ers and amazing hobbyists), and when I work professionally both in my startup and in a previous life as an employee I put on my waders and jump right into the thick smelly bog. But especially when you take a couple of years of vacation and work for fun on projects that interest you, you find out that sense of ickiness is probably the best indicator of code rot.

My number one symptom of rotting design is a lot simpler, I keep postponing touching the code... If I do this for more than a couple of days it must be really rotten.

The weird thing is that they only did a web version considering the fact that your income distribution is so heavily desktop biased.

The problem is that in any large company, accurate evaluation of an individuals ability/contribution is nearly impossible. Deciding which half of the staff to axe would be better performed by coin toss than by any method a company is likely to employ.

I prefer this one "Imagine a school with children that can read and write, but with teachers who cannot, and you have a metaphor of the Information Age in which we live."

I always thought of natural language as a lossy compression algorithm for ideas, and as always in every lossy compression, you sacrifice some accuracy for the sake of brevity.

Don't ever contact them first!!! you'll be admitting that you are knowingly infringing on their patent, which will put you in an awful position if they decide to pursue litigation. consult a lawyer before you do anything, and have him/her review everything you write to them.

Sorry about the exclamation marks but this is a really dangerous suggestion.

You want to make a company an attractive IPO target, make it profitable!!!

Actually it didn't http://klausler.com/cray2.txt it had a command for a square root approximation and a command to iteratively get closer to the real square root.

But even if a certain computer did compute a square root (or even an approximation) in a single cycle, that would mean CPU speed was reduced by slowing down the clock to enable a more complex action to complete within the timeframe of a single cycle, and other simpler actions like adding/subtracting/moving memory we're sacrificed in its favor.

Sorry, you're right. Changed the original comment.

Yep, but we'll have Y2K38 bug before that because of the original Unix time rep as signed 32bit int

http://en.wikipedia.org/wiki/Year_2038_problem

Not exactly its a bit more difficult, leap years occur once every four years unless the year is divisible by 100 and not by 400

so 1900 wasn't a leap year 2000 was one 2100 won't be.

Although in most places I saw the code just ignored it as something that's valid between 1901-2099 is considered good enough in most places.

Edit: sorry shouldn't post this early in the morning, its 400 not 1000

The process the author describes is almost identical to the one I've experienced, despite the fact my area of research is different than his (machine learning), but his analysis of the results drastically differs from mine

Its true, 90% of the stuff doesn't work/isn't applicable and I have spent more money on buying papers than on rent in the past year, and I spend many days working on stuff that often has little or no positive effect. But its still the most cost effective research you can do, after you factor in the value of your time.

Every new idea I develop on my own takes far longer to develop and test, and trying to get better results than everyone else is a lot easier when you're basing your progress on the cutting edge instead of something that is a decade old.

PG wrote an article a while back called "The Power of the Marginal" http://www.paulgraham.com/marginal.html the effect of the current crisis will create a multitude of people with marginal time whether because they'll be between jobs or because the jobs they have will be changed to part-time jobs to save costs, and the things we do with free time are nothing short of spectacular.

The point is that at a certain point writing the code gets easier than writing a spec.

Lets say you outsource this site, and you send a spec to the developer the spec looks something like this: 1) These 27 actions should only be used by an administrator. 2) All users must register with a valid looking email and choose a username.

Every one of those would still take one line, wouldn't it be simpler to just code the damn thing yourself???

If I had a dime for every time a co-worker said it was a problem with the compiler, I would have retired years ago...

If you set the time line filter correctly you'll see it is getting deader by the year.

http://www.google.com/views?q=java+dead+view%3Atimeline&...

Installing an app on Vista/XP almost always requires administrative privileges even if the only need stems from writing into the C:\program files\ directory.

And frankly once you give an application Admin privileges once, it doesn't matter anymore it can do whatever the hell it wants. Sandboxing is a much better mechanism from a security perspective

Plus uninstalling a program is always problematic under the existing Windows mechanisms, basically it is every programmers duty to write an uninstaller for his own software, many of which are buggy, leave trash on the computer and so on. Sandboxing an installation makes the uninstall automatically easy & fool proof.

Hmm, combine BaseShield with DropBox and you might have a winner...

You should also add a way for developers to bundle their software directly with the BaseShield so they can distribute the bundle as a single package on their website. This will save small developers a ton of effort in writing an automatic software updater, they'll be able to simply rely on your mechanism.

Yes that is what PG always says.

The last time I saw that sentiment in a book review it was on a Dilbert book.

Tell me who your friends are and I'll tell you who you are...

True, you still need the headers, what you don't need is a new connection every key stroke. Establishing a new TCP connection is a relatively high cost network item (between all the Acks and Syns you need 3 messages have to go back and forth for it to establish), keep the connection alive, the stuff will run a lot faster.

No that's based on a different acquisition, 2Web Technologies

Well that's a stupid way to handle it... keep the socket open... read about Comet. http://en.wikipedia.org/wiki/Comet_(programming)

You're forgetting Google didn't develop Google Docs in-house they purchased Writely back in 2006 and that's the codebase Google Docs is built on. Depending on how it was built originally the change might require a massive rewrite...

There is a python philosophy that says there should be one and preferably only one obvious way to do things.

You can do things in a million different ways, monkey patch everything under the sun but in the end, having just one way to do things makes code more reliable and readable.

If you don't like the way the framework is built, and its one preferred way of doing things, select a different framework or write your own. Trying to undermine the assumptions of an existing framework has a tendency to cause subtle hard to detect bugs. And trying to support all approaches tend to create stuff that is bloated, ugly and slow.

There is a concept I've come to appreciate called "Code Debt", its the technical liabilities you've accumulated through using shortcuts and bad practices, things you've chosen to patch so they work in the short term but will bite your ass in the long term and require much more effort to fix than was originally saved.

Always remember the interest on Code Debt is brutal so the wise entrepreneur strives to avoid it.