Links: May 13th

I have some mostly techy links today.

Technology and Programming

There’s a fascinating discussion regarding different types of malloc()s–and how they all effectively promise the same thing!

Also in this same thread is Google’s very own TCMalloc.

Hacker News has a discussion on the “most easy to learn framework”. Be warned: Although there is some discussion about Python and Ruby frameworks, most of this is PHP-oriented. My memory compels me to recall a rather tongue-in-cheek post related to stupid PHP design practices, decisions, and general mediocrity in the language. There’s a reason I’ve started shifting away from PHP toward Python-based web application frameworks!

Microsoft has a new language in the works for parallel computing. It’s called Axum.

Simon Segal has issued a plea to all developers: Pleae don’t write unnecessarily long methods or functions. I know how he feels! I’m guilty of writing code like this, of course, but I find that my brain explodes if I have to content with stuff that is FAR TOO LONG to be useful. Please take his advice. If you’re not sure what I’m talking about, click the link and read. Then weep.

Iqbal M. Khan has an interesting piece on why you should use an ORM.

Somewhat-but-not-completely-tech-oriented

The 75% answer: For when you just don’t know enough to know what to ask. This article makes for a humorous read and raises several good points, too!

Sociology
If you feel tempted to take what you can now don’t. Or why delaying gratification may be good for you.

No comments.
***

Windows 7 Disk Thrashing Quickie

When I left my computer on for a while before I went to grab lunch today, I came back and–expectedly–the monitor was powered off. So, I moved the mouse and…

Nothing.

Instead, the disk was thrashing like crazy. I figured it was possible something had gotten swapped out to disk. Unlikely, sure, but stranger things have happened. Long story short, it took nearly a minute after pressing ctrl+alt+delete before anything appeared. I’ve never had this happen under XP, and it turns out that nothing had been swapped to disk. Most applications were responsive but that disk thrashing had to stop.

I poked around with the process and service list for some time before I finally settled on the culprit. In Windows Vista, it is fairly well known that the Windows Search service will actively index accessible files. Windows Search appears to be more well-behaved in Win 7 and disabling it didn’t have any effect. It turns out that the misbehaving process (which had read more than 2GiB of data by the time I got to the system) was a surprisingly well hidden one. It’s launched from the Task Scheduler and is called “WinSAT.” It’s purpose is to “[m]easure a system’s performance and capabilities.” Here’s what it looks like from the scheduler (click for a slightly bigger version):

Honestly, I don’t like it when a service runs, eats process time, and more importantly hampers my ability to do useful work. This is especially true for a service that simply measures a system’s performance. Why is this needed? In particular, why is this enabled by default to run automatically, without user input, and why is this a redundant feature to the system performance index accessible from the system information dialog (winkey+pause/break)? If I wanted it to run, I’d do it myself.

I’m assuming it’s only run once even though the scheduler is set to “whenever the computer is idle.” In either case, I don’t trust it. It stays off.

Update:

Be sure to go through the task scheduler. I found a few additional tasks that were set to run automatically which could affect performance, including automatic defragmentation. Now I understand why there were so many complaints about Vista!

2 comments.
***

Links: May 6th

I’ve got a few things from government, health, history, and technology for you this week. Enjoy. Read more…

No comments.
***