While there is obviously some human intervention involved, I suspect that there is also some kind of automation. Four million messages a day would just be too many people.
It would be interesting to know what this automation is -- ah the irony if some OSS project was being utilized (SpamAssassin, DSPAM, etc.)
Dominic Giampaolo used to work at Google (in fact, many of the indexing approaches taken by Spotlight are based on his experiences there.)
Eric Schmidt is saying that it's a complete rewrite. Re-engineered for a completely different environment.
Google's smart enough to leverage the good bits of the OS. My money would be on them using Spotlight intelligently and hooking the local index (created by Giampaolo & Co.) with the global index (created by Schmidt & Co.)
My point is that instead of looking at different input and control mechanisms, they should be focusing on managing the huge amounts of data that we are generating.
THE does nothing for me. It's like telling me that a Dvorak keyboard is more efficient -- I'd agree with you wholeheartedly, but would never find myself using it. I've already got too much ingrained knowledge.
And there's a whole generation that has learned the current mechanisms. Good luck getting them to change.
If you gave me something "additive" that respected my preferred working environment, then I'd be much more open to the change. Give me something that makes it easy to work with the long term storage (given my propensity for working with short term memory.)
Work with reality -- don't assume that you have a blank slate on which to develop. Anything that's going to be successful will be evolutionary, not revolutionary.
Sorry Jeff, but you appear to be concerned with designing interfaces for folks that do not know how to use computers.
This is an important thing that I think Jef and many other UI researchers are missing. There aiming at an old target -- back in the 80's there were a lot of people who didn't know how to use a computer. Having a PC at home or school was rare.
These days, there are kids who have never known what it's like to live in a house without a computer. Or a school that has a computer lab. Like learning a language, it becomes second nature as you grow up. You get to the point where you don't even know that you know it.
As time passes, the proportion of the population that "gets it" becomes much larger than the part that needs a simpler UI.
Of course, there will always be people that need dead simple UI, and it's appropriate for many specialized interfaces (e.g. the iPod.) But it seems to me that research towards more complicated UIs (and how to manage the complexity) would be a better course -- that's where the "computing population" is headed.
What the Scottsdale PD should be doing is creating a program that helps the citizens setup their home network security. Give classes that teach people how to turn on WEP, how to use a firewall, etc.
A community service, for sure. And since it's offered by the local PD, it would make the average user realize how important it is...
Individuals using their email account to talk to friends don't have as much a problem as people who use their email address publically for business and publicity.
And this, my friends, is the real cost of SPAM. It's not about the bandwidth, it's about the lost business.
In my business, the cost of a losing a customer because of miscommunication far outweighs the cost of the bandwidth SPAM uses on my server. If customers/reviewers/resellers get lost in the flood of SPAM it costs me money.
And then there's the cost of having someone spend time weeding through all the crap (SPAM identification tools help, but human intervention is still needed for false positives, etc.)
It's good to see that the FTC is getting involved -- this is a business/trade problem, not a communication problem.
It appears to me that this problem exists at both the client and the server.
Updating a server to use the patched version of libpng is an obvious first step. You don't want the buffer overflow compromising security as you deliver a.png file (which would only be an issue if you read the.png from the server before delivery.)
The tricky part is what to do with the.png files that have been tampered with. You don't really want to serve those up to clients -- you'd be delivering a security risk. There will be a significant lag before client software is updated -- browsers and anything else that streams.png over a network connection will be at risk during this time.
It seems to me that there's a need for some kind of scanning tool that checks for bogus.png files. At the server side, you could scan for compromised files and get rid of them.
Back in the day, I was working on an embedded system that did automated blood gas analysis. To give you an timeframe, we were using 8-bit 8085 processors "networked" with RS-232 connections.
The controller I was working on controlled a lot of robotic mechanisms developed by the mechanical engineers. Lots of motor controls, relays and stuff with high voltage and current running through them.
So, one of the techs comes in with a new piece of hardware for the software that I'd been working on. Being the first run on the hardware, I always liked to step through the code to make sure nothing unexpected happened.
After setting a breakpoint at the point where the code started talking to the new device, I started the application up. Basically, there were a bunch of read/write registers, that told the hardware what to do.
So I get to the breakpoint and started single stepping...
BOOM!
(And capitalized text doesn't really do this justice. Scared the shit out of us...)
Turns out one of the bits in the register turned on a relay. The relay, in turn, caused 240 V to be applied directly across the inputs of a power transistor. Said power transistor didn't like that...
The transistor was one of those kinds with the metal cap and big heavy base (you still see them in power amplifiers.) The only thing left after this incident was the metal base -- never found the cap.
Afterwards, I looked at the tech and remarked, "Looks like a hardware problem..."
Apple's in the entertainment business now -- extending the reach of your service/content is what it's all about. First BMW, now Motorola -- who's next?
It also makes me think that they're just testing the waters with this -- 12 songs is nothing. I'm thinking that data services (GPRS, etc.) fit in better with their business model -- especially with regard to syncing data. Also, 12 songs isn't a limitation if you have the data channel available to replace them at will -- a GPRS connection to your iDisk is all it would take.
It's also kind of funny that this was posted today...
Both Macrovision and Sunncom seem like their on a fishing expedition -- and C|net is playing along.
Apple declined comment and MSFT only says "we don't know what they're up to".
Apple doesn't want DRM anymore than the rest of us -- the first version of the iPod had none. And I'm sure they could really give a crap about physical media when their whole business model is based on networked media.
This release was obviously pulled together for the conference -- a Herculean effort by the engineers at Apple to show what will be available in a year for now. A wonderful release for us third-party developers!
No one in their right mind is going to think that this release is fit for benchmarking. There may be some gains that are side effects of internal changes (new versions of gcc, etc.), but anyone with a clue will realize that minimal optimization has been done.
Machine learning at the client level doesn't seem real useful. As a user, I'm perfectly capable of aggregating my own information within the browser environment.
The real win is aggregate information at a higher level. Imagine a server that has access to billions of pages of information and can aggregate and learn from that huge base of data.
Normally, I'd agree with this sentiment. But, on page 2 of the article, there were a couple of good ideas.
One of the barriers for switchers is financial: they have peripherals, software and other things that they won't be able to bring from Wintel to the Mac.
Adding a financial incentive to switch is, IMHO, much better than the current "it makes your life easier" approach (look at the switcher ads and they all have this common theme.)
Also, the "test drive" suggestion is really good -- spending some quality time with a Mac is the best way to fall in love with it. The Apple Stores are a great environment to try the product out, but it pales in comparison to the comfort of your living room.
Such a promotion would also drive foot traffic into the Apple Stores -- always a good thing from a retail point-of-view.
I also find it interesting that the typical car analogy fits in with this thought. Apple is like a BMW -- it comes from the factory configured with good components that you don't NEED to mess with it. I own a 1995 M3 and have never wanted to add or change anything -- it's the best damn car I've ever had.
A 1995 Chevy/Ford/Chrysler, on the other hand, has been (or will soon be) modified.
Nothing wrong with either approach -- just like the parent post says: it's a different concept.
The best feature of DSPAM, in my opinion, is that the SPAM never leaves the mail server.
The bad messages go into a quarantine on the server and can be reviewed by the end user using a web-based interface (looking for false positives.) In the press of a button, that quarantine can be emptied, freeing up disk resources on the server.
Other SPAM solutions (like SpamAssassin) mark the message and continue with delivery. What's the point in downloading the SPAM to your mail client just to throw them away?
I was lucky to have Paul Mockapetris as a professor in the early 80's before the widespread use of networks (UUCP was hot stuff at that point in time.)
One of the things I remember most, was his acronym for the OSI model: "All Professors Should Teach Networking Like Paul" so your could remember this. Of course, a lot has changed since then, but I was lucky to get a head start on it all -- thanks Paul!
Another cool thing about this class was that Marshall Rose was a fellow student. He's written a few RFCs since then.
Slashdot Mirror
You gotta wonder if that robot is going to hold up a HUSKIES sign.
It would be a great way to even the score.
-ch
I'm going to need more than one mouse button!
-ch
So any of you marketing geniuses want to explain why Apple would release this product after the Christmas season?
(I would love to buy one for my nephew's present, but January is too late.)
-ch
While there is obviously some human intervention involved, I suspect that there is also some kind of automation. Four million messages a day would just be too many people.
It would be interesting to know what this automation is -- ah the irony if some OSS project was being utilized (SpamAssassin, DSPAM, etc.)
-ch
After reading the headline, I thought the Slashdot editors were going to own up to posting a dupe.
Well, at least we can look forward to "Atlantis Found. Again. Again."
-ch
... looks like Steve Gedikian finally shut off the lights:
I Haven't Forgotten, And We Will Never Forget.
An insider's view of the end of Nullsoft...
-ch
Why does it have to compete?
Dominic Giampaolo used to work at Google (in fact, many of the indexing approaches taken by Spotlight are based on his experiences there.)
Eric Schmidt is saying that it's a complete rewrite. Re-engineered for a completely different environment.
Google's smart enough to leverage the good bits of the OS. My money would be on them using Spotlight intelligently and hooking the local index (created by Giampaolo & Co.) with the global index (created by Schmidt & Co.)
For some good background on Spotlight, check this out
-ch
Your point is?
My point is that instead of looking at different input and control mechanisms, they should be focusing on managing the huge amounts of data that we are generating.
THE does nothing for me. It's like telling me that a Dvorak keyboard is more efficient -- I'd agree with you wholeheartedly, but would never find myself using it. I've already got too much ingrained knowledge.
And there's a whole generation that has learned the current mechanisms. Good luck getting them to change.
If you gave me something "additive" that respected my preferred working environment, then I'd be much more open to the change. Give me something that makes it easy to work with the long term storage (given my propensity for working with short term memory.)
Work with reality -- don't assume that you have a blank slate on which to develop. Anything that's going to be successful will be evolutionary, not revolutionary.
-ch
Sorry Jeff, but you appear to be concerned with designing interfaces for folks that do not know how to use computers.
This is an important thing that I think Jef and many other UI researchers are missing. There aiming at an old target -- back in the 80's there were a lot of people who didn't know how to use a computer. Having a PC at home or school was rare.
These days, there are kids who have never known what it's like to live in a house without a computer. Or a school that has a computer lab. Like learning a language, it becomes second nature as you grow up. You get to the point where you don't even know that you know it.
As time passes, the proportion of the population that "gets it" becomes much larger than the part that needs a simpler UI.
Of course, there will always be people that need dead simple UI, and it's appropriate for many specialized interfaces (e.g. the iPod.) But it seems to me that research towards more complicated UIs (and how to manage the complexity) would be a better course -- that's where the "computing population" is headed.
-ch
TCP = Takin' Care of Packets
-ch
Let's see -- do I want to trade an innovative and secure OS that never crashes for one that is derivative, insecure and buggy?
I'll get back to you on that...
-ch
If you take a look at the GUI you'll see that it's going to be challenging. Just like your typical VCR or digital camera...
The thing that makes the iPod so unique (and popular) is the simplicity. It's about having less, not more.
-ch
What the Scottsdale PD should be doing is creating a program that helps the citizens setup their home network security. Give classes that teach people how to turn on WEP, how to use a firewall, etc.
A community service, for sure. And since it's offered by the local PD, it would make the average user realize how important it is...
-ch
So how long will it take before a Mac rumor site predicts that this CPU will be in the next PowerBook?
-ch
Individuals using their email account to talk to friends don't have as much a problem as people who use their email address publically for business and publicity.
And this, my friends, is the real cost of SPAM. It's not about the bandwidth, it's about the lost business.
In my business, the cost of a losing a customer because of miscommunication far outweighs the cost of the bandwidth SPAM uses on my server. If customers/reviewers/resellers get lost in the flood of SPAM it costs me money.
And then there's the cost of having someone spend time weeding through all the crap (SPAM identification tools help, but human intervention is still needed for false positives, etc.)
It's good to see that the FTC is getting involved -- this is a business/trade problem, not a communication problem.
-ch
It appears to me that this problem exists at both the client and the server.
.png file (which would only be an issue if you read the .png from the server before delivery.)
.png files that have been tampered with. You don't really want to serve those up to clients -- you'd be delivering a security risk. There will be a significant lag before client software is updated -- browsers and anything else that streams .png over a network connection will be at risk during this time.
.png files. At the server side, you could scan for compromised files and get rid of them.
Updating a server to use the patched version of libpng is an obvious first step. You don't want the buffer overflow compromising security as you deliver a
The tricky part is what to do with the
It seems to me that there's a need for some kind of scanning tool that checks for bogus
Does such a tool exist?
-ch
Back in the day, I was working on an embedded system that did automated blood gas analysis. To give you an timeframe, we were using 8-bit 8085 processors "networked" with RS-232 connections.
The controller I was working on controlled a lot of robotic mechanisms developed by the mechanical engineers. Lots of motor controls, relays and stuff with high voltage and current running through them.
So, one of the techs comes in with a new piece of hardware for the software that I'd been working on. Being the first run on the hardware, I always liked to step through the code to make sure nothing unexpected happened.
After setting a breakpoint at the point where the code started talking to the new device, I started the application up. Basically, there were a bunch of read/write registers, that told the hardware what to do.
So I get to the breakpoint and started single stepping...
BOOM!
(And capitalized text doesn't really do this justice. Scared the shit out of us...)
Turns out one of the bits in the register turned on a relay. The relay, in turn, caused 240 V to be applied directly across the inputs of a power transistor. Said power transistor didn't like that...
The transistor was one of those kinds with the metal cap and big heavy base (you still see them in power amplifiers.) The only thing left after this incident was the metal base -- never found the cap.
Afterwards, I looked at the tech and remarked, "Looks like a hardware problem..."
-ch
Apple's in the entertainment business now -- extending the reach of your service/content is what it's all about. First BMW, now Motorola -- who's next?
It also makes me think that they're just testing the waters with this -- 12 songs is nothing. I'm thinking that data services (GPRS, etc.) fit in better with their business model -- especially with regard to syncing data. Also, 12 songs isn't a limitation if you have the data channel available to replace them at will -- a GPRS connection to your iDisk is all it would take.
It's also kind of funny that this was posted today...
-ch
Both Macrovision and Sunncom seem like their on a fishing expedition -- and C|net is playing along.
Apple declined comment and MSFT only says "we don't know what they're up to".
Apple doesn't want DRM anymore than the rest of us -- the first version of the iPod had none. And I'm sure they could really give a crap about physical media when their whole business model is based on networked media.
-ch
This release was obviously pulled together for the conference -- a Herculean effort by the engineers at Apple to show what will be available in a year for now. A wonderful release for us third-party developers!
No one in their right mind is going to think that this release is fit for benchmarking. There may be some gains that are side effects of internal changes (new versions of gcc, etc.), but anyone with a clue will realize that minimal optimization has been done.
When they say DEVELOPER PREVIEW they mean it...
-ch
Machine learning at the client level doesn't seem real useful. As a user, I'm perfectly capable of aggregating my own information within the browser environment.
The real win is aggregate information at a higher level. Imagine a server that has access to billions of pages of information and can aggregate and learn from that huge base of data.
Imagine Google.
-ch
Normally, I'd agree with this sentiment. But, on page 2 of the article, there were a couple of good ideas.
One of the barriers for switchers is financial: they have peripherals, software and other things that they won't be able to bring from Wintel to the Mac.
Adding a financial incentive to switch is, IMHO, much better than the current "it makes your life easier" approach (look at the switcher ads and they all have this common theme.)
Also, the "test drive" suggestion is really good -- spending some quality time with a Mac is the best way to fall in love with it. The Apple Stores are a great environment to try the product out, but it pales in comparison to the comfort of your living room.
Such a promotion would also drive foot traffic into the Apple Stores -- always a good thing from a retail point-of-view.
-ch
This is so true.
I also find it interesting that the typical car analogy fits in with this thought. Apple is like a BMW -- it comes from the factory configured with good components that you don't NEED to mess with it. I own a 1995 M3 and have never wanted to add or change anything -- it's the best damn car I've ever had.
A 1995 Chevy/Ford/Chrysler, on the other hand, has been (or will soon be) modified.
Nothing wrong with either approach -- just like the parent post says: it's a different concept.
-ch
The best feature of DSPAM, in my opinion, is that the SPAM never leaves the mail server.
The bad messages go into a quarantine on the server and can be reviewed by the end user using a web-based interface (looking for false positives.) In the press of a button, that quarantine can be emptied, freeing up disk resources on the server.
Other SPAM solutions (like SpamAssassin) mark the message and continue with delivery. What's the point in downloading the SPAM to your mail client just to throw them away?
-ch
I was lucky to have Paul Mockapetris as a professor in the early 80's before the widespread use of networks (UUCP was hot stuff at that point in time.)
One of the things I remember most, was his acronym for the OSI model: "All Professors Should Teach Networking Like Paul" so your could remember this. Of course, a lot has changed since then, but I was lucky to get a head start on it all -- thanks Paul!
Another cool thing about this class was that Marshall Rose was a fellow student. He's written a few RFCs since then.
-ch