At the other extreme you've got people writing in whatever they want whenever they come across a problem and end up re-inventing the wheel because either "I don't like Perl!" or "Numbnuts wrote this code in Object Intercal 95, which doesn't have a compiler/interpreter on the platform I need."
The problem here is not the use of multiple languages, but rather the programmer being allowed to re-implement something without a good reason.
This is not an issue of standards, but one of judgement and management.
Further, it is possible that the programmer feels the need to reimplement something not because of the language, but because the original component did not have a good API.
Put another way, the solution may be to put a thin API into the original code (which, at its simplest, could mean turning a library function into a standalone executable that talks to stdin and stdout) so that the programmer now can build on the original object without care for the language it was implemented in.
With respect to the one language standard, if the company is about producing code or monolithic software deliverables, it makes sense to have one or two core languages. But if the company is about producing data or services, it's different. These tasks tend to be modular, so the greater advantage is to be able to choose a good language for each problem.
For example, which language would be better, in general, at processing terabytes of flat text - Java or Perl? Either language can do this, but Perl's libraries are much faster for string processing.
Now, which language would you rather write a web service in -- Java or Perl? [*] Sure, you can do anything in Perl, but you're going to find more library support (and more experienced programmers) for web services in Java.
--Pat "[*] Those of you who said C, please see me after class."
What the parent poster said. Companies can get hundreds of resumes for entry-level tech positions. The first pass someone will do with this stack of resumes is triage - eliminate the obviously bogus applications.
See, of those 200 applicants, 180 are coming from people that shotgun the same resume to each opening they find. These resumes are easy to spot because: 1) there's no cover letter, and 2) the resumes are keyword soup (C++JAVAFORTRANPL/1LISPSNOBOLPOSTSCRIPTVIC-20!!!)
So, you're in the lucky 20. You wrote a cover letter saying who you are, and you wrote a resume that focuses on the strengths, interests, and experience that you have that apply to the company and the specific opening.
You're now in round 2 of triage. At this point, someone with tech experience will go through the 20 surviving resumes to pick out the best 5.
So you've made it to the top 5 - great! Now, for each of these five, an HR person (or someone filling in for this role) will either arrange for a phone interview or an in-person interview. If it's a phone interview, you should have no problem (you do have a cell phone, right? Put it on your resume so they can call you during the day).
The in-person interview will take up a great deal of the company's time. Even if you're only there for an hour, you might be interviewed by eight people. That's eight person-hours of time spent on something other than coding, QAing, or running the things. That's also eight people who have to sync up their schedules to meet you!
So the HR person goes down the list of five possible in-person, and one can't come in during the week. The other four will get interviews, and *if* none of them get an offer, you might get called back. Alternately, *if* you have a stunning resume or have demonstrated an ability to walk on water, you might get to meet with the hiring manager later in the day.
My advice is for you to take a personal half-day, even if you are an hourly employee, to do interviews. Alternately, either schedule a 1hr interview around lunchtime, and be prepared to do a second 1hr if more people need to interview you from the same company, or ask for a phone interview. Companies may prefer the phone option because they can get a sense for you without spending 8 person-hours. But if they like you, you will still have to do the in-person interview later.
One more thing. If you want your resume to be noticed, do your homework on the company. Spend an hour researching them - what they do, who they are - and think about what *you* can do for them. With that knowledge, write a 3 paragraph cover letter about why you are interested in what the company does, and how you think you can help. Also, make a customized resume for the company that emphasizes your interests as they fit with the company (this is especially true if you have a lot of experience - it helps you focus and helps the person reading the resume to fit you into their model of what they are looking for.)
In my case, it's both. I photograph in RAW mode and then convert those files to JPEG in large batches. So I've got disk IO, RAM IO, and CPU. With or without undervolting, this pegs my CPU.
In my earlier post, I forgot to mention the advantages of undervolting and underclocking. I now get about 20% more time on battery, and my machine runs cooler. The fan on my laptop is very loud, and so I go to great lenghts to keep it from spinning up.
Thanks for the clarification -- I thought the CPU was the big factor (I was dimly recalling a conversation with one of the three creators of the Rosetta software.)
The early Newton MessagePads had bad handwriting recognition, in large part because the CPUs in these machines were too wimpy.
By the MessagePad 2000 and 2100, however, handwriting recognition was excellent. I used to use one of these machines to take notes in meetings, and I could write fairly smoothly in my normal handwriting (a mix of cursive and print) and get decent performance.
I have since tried several iterations of PocketPCs and Palms and, still, eight years after the MessagePad 2000 was introduced, I haven't found a handheld that equals it in this respect.
Speaking from inside the Web 2.0 sphere (in which we get our oxygen by breathing liquid fluorocarbons, just like in The Abyss), people here are aware of (and somewhat amused by) the buzzword nature of "Web 2.0," but we also see that the technology is extremely useful and has the chance to change how people use computers and software.
Re my comment about long menus in Knoppix vs Ubuntu Live CDs, beforewisdom writes "I have noticed over the years that Gnome has shorter menus then the KDE... I am wondering if your experience is the result of Ubuntu or Gnome?"
It's possible. I would have seen the default window manager(s) for the Ubuntu and Knoppix bootable discs.
"But the only problem with rooms is that the wall tend to be hard to move, unlike cubicles."
I can't remember ever seeing cube walls moved once they were installed, in the twenty years I've spent in and out of cubeland. This includes cubes in startups and Fortune 500 companies.
Often, cubes don't get moved even when one tenant moves out of the office and another moves in.
So while open office plans plus cubes provide great flexibility in theory, in practice, it rarely works out that way.
I've only tried the bootable live CDs for Knoppix (4.0.2) and Ubuntu (5.10) and I found them both excellent in ease of configuration, detecting weird devices (a 3Ware controller with 2TB of disk an ATI Radeon graphics card on one machine, a somewhat weird laptop with Atheros wireless and an Intel video driver on another).
The big difference is the amount of stuff Knoppix puts in the menus -- it's overwhelming trying to figure out what app is where. Ubuntu instead has very clean and short menus of the apps you're likely to actually want as a desktop or typical server user.
If you're happy with Knoppix, though, I don't see a reason to switch.
I agree with your comment about electricity. I believe they are focusing on notebooks assuming the kids will charge them at school, which is more likely to have infrastructure like water and electric.
Regarding the pump story, it doesn't quite apply. No one would say "let's give them iron-age telephones so the local blacksmith can fix them." Pumps are very, very high wear items that require constant maintenance and a steady supply of spare parts. An electronic device, if designed solidly and constructed out of appropriate components, is very low maintenance.
So I think we agree that for the notebooks to be successful, one key requirement is that they be very low maintenance. If the designers cannot meet this goal, they will have a hard time keeping the notebooks in circulation in remote areas.
--Pat
One of the things that keeps me from going with the Powerbook is the lack of a very small notebook in the lineup. Apple at one point did have an ultraportable (for its time) -- the Powerbook 2400. I wish they had something like this now. I don't mean something that's the same size, I mean a notebook that fills the same spot -- just big enough to be usable, small enough that I don't mind carrying it everywhere.
I'm currently using the Fujitsu P7010D, an ultraportable with very good battery life. If Mac OS X ran on this system, I would switch.
The Show Related Links functionality in Internet Explorer is provided by Alexa. If you would like to find Web pages similar to the Web page you are currently viewing, click the Tools menu, and then click Show Related Links. When you do so, the Web address of the page you are viewing is sent to an Alexa server which returns a list of potentially similar links in the Search Companion area. This information is not sent to Microsoft. If you do not wish to send the address of the Web page you are currently viewing to Alexa, do not click Show Related Links.
In fact, design flaw #1 on this thing is that it is a piece of electronics.
While I want to agree with you, I also think that there are counter-examples that electronics are not only beneficial but the correct solution to information needs for the poor. For example, radio and telephone are electroics-based technologies, but are crucial and successful even in poor and low-tech areas.
A critical element of success is that the electronics be reliable and easy to operate. These I think are the big challenges for something like a laptop, not the fact that it's built out of electronic parts.
I will add that the Archive has particular design and performance goals, namely:
- keep the cost / GB as low as possible - keep cooling and power requirements low - use the filesystem and bundle objects into large chunks (~100MB ARC files, last I checked) - assume streaming writes affecting an edge of the system -- previously written data isn't modified - assume random reads - read latency is less important than cost / GB
I worked on the Archive ~5 years ago, and these are based on my understanding of the Archive from that period, so some of these may have changed.
But essentially, these are instantiated as: off-the-shelf SATA disks in fairly standard cases with either normal or special low-power motherboards, running a free OS (the Archive has used both Linux and FreeBSD), with off-the-shelf networking equipment.
Let's say I make a black box device that detects whether someone has recently consumed chocolate (mmm, chocolate). I demonstrate it to you by trying it on 10 people who have eaten chocolate, and 10 people who have not. The device is accurate in this trial.
Now, what you don't know is *how* it does what it does, so you do not know if perhaps there are edge conditions where it fails. Perhaps these conditions are one in a million (remember the Pentium floating point bug?) and so would not show up during testing and calibration.
If the code and hardware are open to examination, you can then say "this is how it does what it does, and I've verified that there are no error cases that could cause it to act incorrectly or unpredictably."
The parent post says "if you know how to use IE correctly [it's safe]"
That's fine, but what percent of the population "use IE correctly?" Here's my guess -- the number has no significant digits to the left of the decimal point.
Put a default install of Firefox on an ordinary user's machine, and they're unlikely to have problems. Put a default install of IE on their machine, and they face non-trivial odds of relaying Nigerian email spam from now until they buy a new computer.
At the other extreme you've got people writing in whatever they want whenever they come across a problem and end up re-inventing the wheel because either "I don't like Perl!" or "Numbnuts wrote this code in Object Intercal 95, which doesn't have a compiler/interpreter on the platform I need."
The problem here is not the use of multiple languages, but rather the programmer being allowed to re-implement something without a good reason.
This is not an issue of standards, but one of judgement and management.
Further, it is possible that the programmer feels the need to reimplement something not because of the language, but because the original component did not have a good API.
Put another way, the solution may be to put a thin API into the original code (which, at its simplest, could mean turning a library function into a standalone executable that talks to stdin and stdout) so that the programmer now can build on the original object without care for the language it was implemented in.
With respect to the one language standard, if the company is about producing code or monolithic software deliverables, it makes sense to have one or two core languages. But if the company is about producing data or services, it's different. These tasks tend to be modular, so the greater advantage is to be able to choose a good language for each problem.
For example, which language would be better, in general, at processing terabytes of flat text - Java or Perl? Either language can do this, but Perl's libraries are much faster for string processing.
Now, which language would you rather write a web service in -- Java or Perl? [*] Sure, you can do anything in Perl, but you're going to find more library support (and more experienced programmers) for web services in Java.
--Pat "[*] Those of you who said C, please see me after class."
I read the summary and wondered why a Newton mayor would back up a Brandeis librarian.
The messages were sent from a Newton public library and allegedly threatened the Heller School at Brandeis.
The librarian works for Newton, not Brandeis.
--Pat
What the parent poster said. Companies can get hundreds of resumes for entry-level tech positions. The first pass someone will do with this stack of resumes is triage - eliminate the obviously bogus applications.
See, of those 200 applicants, 180 are coming from people that shotgun the same resume to each opening they find. These resumes are easy to spot because: 1) there's no cover letter, and 2) the resumes are keyword soup (C++JAVAFORTRANPL/1LISPSNOBOLPOSTSCRIPTVIC-20!!!)
So, you're in the lucky 20. You wrote a cover letter saying who you are, and you wrote a resume that focuses on the strengths, interests, and experience that you have that apply to the company and the specific opening.
You're now in round 2 of triage. At this point, someone with tech experience will go through the 20 surviving resumes to pick out the best 5.
So you've made it to the top 5 - great! Now, for each of these five, an HR person (or someone filling in for this role) will either arrange for a phone interview or an in-person interview. If it's a phone interview, you should have no problem (you do have a cell phone, right? Put it on your resume so they can call you during the day).
The in-person interview will take up a great deal of the company's time. Even if you're only there for an hour, you might be interviewed by eight people. That's eight person-hours of time spent on something other than coding, QAing, or running the things. That's also eight people who have to sync up their schedules to meet you!
So the HR person goes down the list of five possible in-person, and one can't come in during the week. The other four will get interviews, and *if* none of them get an offer, you might get called back. Alternately, *if* you have a stunning resume or have demonstrated an ability to walk on water, you might get to meet with the hiring manager later in the day.
My advice is for you to take a personal half-day, even if you are an hourly employee, to do interviews. Alternately, either schedule a 1hr interview around lunchtime, and be prepared to do a second 1hr if more people need to interview you from the same company, or ask for a phone interview. Companies may prefer the phone option because they can get a sense for you without spending 8 person-hours. But if they like you, you will still have to do the in-person interview later.
One more thing. If you want your resume to be noticed, do your homework on the company. Spend an hour researching them - what they do, who they are - and think about what *you* can do for them. With that knowledge, write a 3 paragraph cover letter about why you are interested in what the company does, and how you think you can help. Also, make a customized resume for the company that emphasizes your interests as they fit with the company (this is especially true if you have a lot of experience - it helps you focus and helps the person reading the resume to fit you into their model of what they are looking for.)
Best of luck with your search!
--Pat
In my case, it's both. I photograph in RAW mode and then convert those files to JPEG in large batches. So I've got disk IO, RAM IO, and CPU. With or without undervolting, this pegs my CPU.
In my earlier post, I forgot to mention the advantages of undervolting and underclocking. I now get about 20% more time on battery, and my machine runs cooler. The fan on my laptop is very loud, and so I go to great lenghts to keep it from spinning up.
--Pat
I underclock and undervolt my laptop using the RightMark CPU utility.
Speedstep can only throttle my processor down to 600MHz (from a max of 1.2GHz) but underclocking reduces it to an effective 300MHz.
I do not notice the performance hit, and I do a lot of photo editing on this machine.
--Pat
Thanks for the clarification -- I thought the CPU was the big factor (I was dimly recalling a conversation with one of the three creators of the Rosetta software.)
--Pat
The early Newton MessagePads had bad handwriting recognition, in large part because the CPUs in these machines were too wimpy.
By the MessagePad 2000 and 2100, however, handwriting recognition was excellent. I used to use one of these machines to take notes in meetings, and I could write fairly smoothly in my normal handwriting (a mix of cursive and print) and get decent performance.
I have since tried several iterations of PocketPCs and Palms and, still, eight years after the MessagePad 2000 was introduced, I haven't found a handheld that equals it in this respect.
--Pat
--Pat
--Pat my blog
The responsible party attempted ritual suicide, but instead of one cut 50mm in length, they instead made 50 cuts of 1mm each.
--Pat / my blog
A lot of work on Babble was done by Appled Minds for Herman Miller. Here's a Wired article that describes the project:
t w=wn_tophead_1
1 585,a9-c407-n350,00.html
http://wired.com/news/20050621_appliedminds.html?
Here's Herman Miller's press release for the device:
http://www.hermanmiller.com/CDA/SSA/News/Story/0,
--Pat
"Can you remind me what the vt100 equivalents of eBay, Google and Skype were?"
*.forsale, WAIS, and this thing we called "the telephone."
--Pat
Re my comment about long menus in Knoppix vs Ubuntu Live CDs, beforewisdom writes "I have noticed over the years that Gnome has shorter menus then the KDE ... I am wondering if your experience is the result of Ubuntu or Gnome?"
It's possible. I would have seen the default window manager(s) for the Ubuntu and Knoppix bootable discs.
--Pat
"But the only problem with rooms is that the wall tend to be hard to move, unlike cubicles."
I can't remember ever seeing cube walls moved once they were installed, in the twenty years I've spent in and out of cubeland. This includes cubes in startups and Fortune 500 companies.
Often, cubes don't get moved even when one tenant moves out of the office and another moves in.
So while open office plans plus cubes provide great flexibility in theory, in practice, it rarely works out that way.
--Pat
I've only tried the bootable live CDs for Knoppix (4.0.2) and Ubuntu (5.10) and I found them both excellent in ease of configuration, detecting weird devices (a 3Ware controller with 2TB of disk an ATI Radeon graphics card on one machine, a somewhat weird laptop with Atheros wireless and an Intel video driver on another).
The big difference is the amount of stuff Knoppix puts in the menus -- it's overwhelming trying to figure out what app is where. Ubuntu instead has very clean and short menus of the apps you're likely to actually want as a desktop or typical server user.
If you're happy with Knoppix, though, I don't see a reason to switch.
--Pat
If you use Firefox, you can do this. Install Greasmonkey and the Secure Gmail script. It forces every Gmail access to https.
. user.js
c ific
Greasemonkey:
http://greasemonkey.mozdev.org/
Direct link to Secure Gmail script:
http://novemberborn.net/greasemonkey/secure-gmail
Other useful Gmail Greasemonkey scripts here:
http://dunck.us/collab/GreaseMonkeyUserScriptsSpe
--Pat
I agree with your comment about electricity. I believe they are focusing on notebooks assuming the kids will charge them at school, which is more likely to have infrastructure like water and electric. Regarding the pump story, it doesn't quite apply. No one would say "let's give them iron-age telephones so the local blacksmith can fix them." Pumps are very, very high wear items that require constant maintenance and a steady supply of spare parts. An electronic device, if designed solidly and constructed out of appropriate components, is very low maintenance. So I think we agree that for the notebooks to be successful, one key requirement is that they be very low maintenance. If the designers cannot meet this goal, they will have a hard time keeping the notebooks in circulation in remote areas. --Pat
One of the things that keeps me from going with the Powerbook is the lack of a very small notebook in the lineup. Apple at one point did have an ultraportable (for its time) -- the Powerbook 2400. I wish they had something like this now. I don't mean something that's the same size, I mean a notebook that fills the same spot -- just big enough to be usable, small enough that I don't mind carrying it everywhere.
I'm currently using the Fujitsu P7010D, an ultraportable with very good battery life. If Mac OS X ran on this system, I would switch.
--Pat
Here's Microsoft's description of the Alexa integration in IE 6.
--Pat "burning two mod points to write this"
In fact, design flaw #1 on this thing is that it is a piece of electronics.
While I want to agree with you, I also think that there are counter-examples that electronics are not only beneficial but the correct solution to information needs for the poor. For example, radio and telephone are electroics-based technologies, but are crucial and successful even in poor and low-tech areas.
A critical element of success is that the electronics be reliable and easy to operate. These I think are the big challenges for something like a laptop, not the fact that it's built out of electronic parts.
--Pat
You beat me to this link.
I will add that the Archive has particular design and performance goals, namely:
- keep the cost / GB as low as possible
- keep cooling and power requirements low
- use the filesystem and bundle objects into large chunks (~100MB ARC files, last I checked)
- assume streaming writes affecting an edge of the system -- previously written data isn't modified
- assume random reads
- read latency is less important than cost / GB
I worked on the Archive ~5 years ago, and these are based on my understanding of the Archive from that period, so some of these may have changed.
But essentially, these are instantiated as: off-the-shelf SATA disks in fairly standard cases with either normal or special low-power motherboards, running a free OS (the Archive has used both Linux and FreeBSD), with off-the-shelf networking equipment.
--Pat
Let's say I make a black box device that detects whether someone has recently consumed chocolate (mmm, chocolate). I demonstrate it to you by trying it on 10 people who have eaten chocolate, and 10 people who have not. The device is accurate in this trial.
Now, what you don't know is *how* it does what it does, so you do not know if perhaps there are edge conditions where it fails. Perhaps these conditions are one in a million (remember the Pentium floating point bug?) and so would not show up during testing and calibration.
If the code and hardware are open to examination, you can then say "this is how it does what it does, and I've verified that there are no error cases that could cause it to act incorrectly or unpredictably."
--Pat
The parent post says "Instead of correcting errors, the wikipedia editors indulge them."
The editors are us. Are you correcting errors or indulging them?
--Pat
The parent post says "if you know how to use IE correctly [it's safe]"
That's fine, but what percent of the population "use IE correctly?" Here's my guess -- the number has no significant digits to the left of the decimal point.
Put a default install of Firefox on an ordinary user's machine, and they're unlikely to have problems. Put a default install of IE on their machine, and they face non-trivial odds of relaying Nigerian email spam from now until they buy a new computer.
--Pat
It makes sense if the line's maximum altitude is greater than the altitude at the destination.
--Pat