Prolific Waterloo Blogger, Larry Borsato

Larry Borsato is a prolific blogger, averaging a Scoblian 6-7 posts per day by my count, writing on a wide variety of topics ranging from the Kyoto accord to note-taking; but, from what I gather, mainly Canadian politics, marketing, and technology. Judging by his resume, he also has god-like powers when it comes to marketing technology. He reads gapingvoid and Paul Graham. What’s more, he lives in Waterloo!

Blog on, Waterloo!

Electronicstalk Covers BelaSigna-Powered Device

It’s nice to see AMI Semiconductor’s DSPs getting some press. Electronicstalk has a story about Phonak’s SmartLink SX:

Through built-in microphones, audio inputs, and a Bluetooth link, the highly compact SmartLink receives and processes audio signals and transmits them to the user’s hearing aid using Phonak’s industry-leading MicroLink technology.

Are Web Apps Risky? (And Why Company Data May Not Be That Valuable)

Michael is leery of using web applications for business, writing

I don’t know if I’d want to take the risk of having my corporate data spread over several vendor’s applications and servers, but there is some appeal in handing over the technical, administrative and security tasks to someone else willing to take on that pain.

I’ve heard similar concerns about the risk of using web applications before. I suspect they are greatly exaggerated.

The arguments usually goes something like this. If my company’s data is kept on web application, there is a chance that the web application will be cracked and my valuable data will find its way into the hands of my competitors or other unscrupulous agents eager to apply it to some nefarious endeavor sure to harm me. If I spread my data across several applications the risk is multiplied because it increases the odds that one of the applications will be cracked. On the other hand, if I keep that data centralized within the company, protected by my IT people, it is safe from outside crackers because I control it.

I find some things fishy about this argument.

First, why should I expect that my IT people will be any better at securing my data than a web application sysadmin? It would stand to reason that a web applications would be more secure. As Paul Graham argues:

The argument against this approach usually hinges on security: if access is easier for employees, it will be for bad guys too. Some larger merchants were reluctant to use Viaweb because they thought customers’ credit card information would be safer on their own servers. It was not easy to make this point diplomatically, but in fact the data was almost certainly safer in our hands than theirs. Who can hire better people to manage security, a technology startup whose whole business is running servers, or a clothing retailer? Not only did we have better people worrying about security, we worried more about it. If someone broke into the clothing retailer’s servers, it would affect at most one merchant, could probably be hushed up, and in the worst case might get one person fired. If someone broke into ours, it could affect thousands of merchants, would probably end up as news on CNet, and could put us out of business.

Second, does keeping all the data centralized really reduce the risk? If a cracker gets into a central database, he’s hit the jackpot. He’s only got to crack one system. If the data is distributed across many web applications, he needs to crack into every one to do the same amount of damage.

Third, what is the danger of having the data publicized? Is the data really as valuable as you think? Consider this thought experiment: imagine that somebody cracked into Intel and managed to steal the source code for the design their latest processor, arguably their most valuable data, and posted it on the web for all to see. End of the world for Intel? I don’t think so. For the vast majority of people the code would be worthless. Unless you have access to a multi-billion dollar fabrication facility, it would be impossible to manufacture cheap knock-offs. Those that do have access to such a fab would have to invest considerable effort in learning how to build the chip, as manufacturing chips is not a straightforward process.

So for the sake of argument, let’s say along with the source code, the cracker also managed to publicize all of the process documentation, too. Then they could make the chip without a huge investment, right? I don’t think so. Though it might reduce the effort to manufacture the chip, it wouldn’t eliminate it. Somebody would still have to read all the documentation and understand it. There would be gaps in the documentation, too; information that resides in the heads of Intel employees that was never written down. Somebody would have to figure all that out, too?

But couldn’t somebody use the source code as the basis for an enhanced chip; something even better than what Intel is producing? Possibly, but Intel will be doing the same thing. Who do you think will come up with the better enhancement, the Intel engineers who developed and are intimately familiar with the code or somebody who has never seen the code before? My bet is on the Intel team.

Would it be a different story if we imagined that source code was for Microsoft Windows or the Google Internet Search routines. I don’t think so. Anybody considering competing with the creator would still have the same issues of understanding what they have stolen and building the product for themselves.

So there you have it: three reasons web applications are not as risky as you might think. They’re probably full of holes. Poke away.

Health and Happiness

In Happiness helps people stay healthy, New Scientist reports:

People who are happier in their daily lives have healthier levels of key body chemicals than those who muster few positive feelings, a new study suggests. This means happier people may have healthier hearts and cardiovascular systems, possibly cutting their risk of diseases like diabetes.

These kinds of stories annoy me. Reporters are so eager to get people to read their stories that they extrapolate a causal relationship from a mere correlation.

Scientist have discovered that happy people are healthier than unhappy people. Are people healthier because they are happy? Are people happier because they are healthy? Is there something other unidentified cause that results in people being both happy and healthy. However it turns out, I’m glad folks are investigating.

37 days

Johnnie Moore points toward Patricia Digh’s wonderful blog, 37 Days:

In October of 2003, my stepfather was diagnosed with lung cancer. He died 37 days later.

The timeframe of 37 days made an impression on me. We act as if we have all the time in the world – that’s not a new understanding. But the definite-ness of 37 days struck me. So short a time, as if all the regrets of a life would barely have time to register before time was up.

And so, as always when awful things happen, I tried to figure out how to reconcile in my mind the fact that it was happening and the fact that the only thing I could do was try to make some good out of it. What emerged was a renewed commitment to ask myself this question every morning: ‘what would I be doing today if I only had 37 days to live?’

It’s a hard question some days.

A Startup Blog: alarm:clock

Among the many helpful links in Y Combinator’s startup resource page is alarm:clock, a blog about tech startups:

alarm:clock covers the business of technology startups. Each weekday, we add a new profile of a privately-held technology venture. We analyze the business model and tell you how the company fits in to the technology landscape. You’ll also find ongoing news and updates about the companies we cover and about the technology industry at large.

Running a Business on Web Apps

Evan Williams, former CEO of Pyra (creators of Blogger; bought out by Google), writes about running a business on web apps:

One interesting thing about starting a company today versus a few years ago: Lots of cool web apps are now available that you can more or less run you company on.

He goes on to list some of the web applications they are using at Odeo, then writes,

The improved efficiency of having these apps available, and not having to install and maintain servers for them is huge.

The Red Couch Tells a Hughtrain Story

The Red Couch tells the story of how ad man Hugh MacLeod and PR guy David Parmet helped world-class Savile Row tailor Thomas Mahon from relative obscurity to international renown through blogging:

MacLeod says he started filling Mahon’s “head with Cluetrain and blogging stuff,” and slowly Mahon got interested. “We started thinking that if Mahon could talk about tailoring on a blog about the same way that Seth Godin talks about marketing, then the people who care will see it. Mahon wouldn’t try to sell suits on the blog. Instead, he would show his knowledge and love of the craft. He would explain the labor, and materials involved and why the cost of each suit was justified.” The idea was that the people who cared either about suits or how a master craftsmen creates them would find their way to the site.

I want to believe that any world-class craftsman could reach the same success merely by keeping a blog on his work. I want to believe that, but I can’t. Too much of Thomas’s success is tied up with Hugh’s immense popularity. Thomas brought a great story, but Hugh brought the audience to hear it.

Design a DSP Chip in MATLAB

AccelChip has a family of products that allows you to synthesize a DSP from a MATLAB algorithm:

AccelChip DSP Synthesis allows algorithm developers to take designs created in MATLAB and automatically synthesize a high-quality silicon implementation. A synthesis and verification environment, the product automatically converts MATLAB design from floating-point to fixed-point, then generates synthesizable VHDL or Verilog models, providing designers the ability to verify the algorithm and its implementation sooner.

Definitely a neat idea, if it works. When I see “automatically synthesize a high-quality silicon implementation” it brings out my inner skeptic. When going from a very high-level description to a low-level one, a synthesis tool needs to make intelligent guesses about the designer’s intentions. Does it optimize for speed or power consumption or die size? Does it try to balance the competing needs? The danger is that the compiler synthesizes a correct implementation that is perfectly useless because it fails to meet some other important criteria. Lisp solves this by allowing programmers to give the compiler hints about performance. I wonder if AccelChip DSP Synthesis has a similar facility.