Another path would be to open the protocol. Currently, Apple provides dotmac libraries to Mac developers, so that third-party apps running in MacOSX can benefit from dotmac.
But this doesn't allow customers to use their apps with a different dotmac provider.
Imagine that Apple discloses the.Mac protocol. Anybody could build a.Mac clone, and charge whatever they want for it... More money, less money, nothing, nothing with ads, usage-based, etc. This could include enterprise versions, you know, that run within a protected intranet.
Apple would likely loose some.Mac subscriptions, but they'd get more customers to actually use Tiger and iLife software to the fullest. And that's still the best method to make happy customers.
Interestingly, there seem to be few or no post-OCR filters. Search for "vesterday" for example, and look at the excerpts. Also, some of these books have handwritten pages that went through OCR like the rest. Look for the "Ducky" result of the "vesterday" search and check the page 14. The excerpt is basically garbled OCR results. So, what's the idea for the QA plan ?
Talking about the/. effect, I think it would be amusing to have the/. clickthrough data displayed as a graph (e.g. clickthrough/min over time) for each link in a story (at least for the links in the initial story). One usage of these graphs would be a popularity measure of the stories over time.
> This tends to confuse people, because RH's > current 0.9.6b isn't vulnerable even though > stock 0.9.6b is.
Yeah. Confusing it is. I don't see anything in the RedHat RPM indicating that it is different from stock 0.9.6b. The only indicator is that the package release number is currently 28... 28 releases for the same package, no track of what the releases are about. Call me a whiner, but I say it's sloppy.
According to various reports, updating to 0.9.6e or 0.9.6g will prevent the exploit. The exploit has been reported on Bugtraq Friday (9/13). RedHat still hasn't released updated RPMs. Have they stopped working on weekends ? I'm beginning to wonder why I'm paying the RHN subscription.
Would you be kind enough to write a small HOWTO or recipe on how to do this ? I've been meaning to try something similar, but I'm too lazy too read all the docs.
Clients which connect to our peer-to-peer clients, and then afterwards attempt to illegally access the network will be immediately blacklisted
Well now, how easy is it to circumvent this ? You just need two IPs apparently unconnected, which is cheap to obtain... The "and then afterwards" is terminally flawed
Another path would be to open the protocol. Currently, Apple provides dotmac libraries to Mac developers, so that third-party apps running in MacOSX can benefit from dotmac.
.Mac protocol. Anybody could build a .Mac clone, and charge whatever they want for it... More money, less money, nothing, nothing with ads, usage-based, etc. This could include enterprise versions, you know, that run within a protected intranet.
.Mac subscriptions, but they'd get more customers to actually use Tiger and iLife software to the fullest. And that's still the best method to make happy customers.
But this doesn't allow customers to use their apps with a different dotmac provider.
Imagine that Apple discloses the
Apple would likely loose some
Interestingly, there seem to be few or no post-OCR filters. Search for "vesterday" for example, and look at the excerpts. Also, some of these books have handwritten pages that went through OCR like the rest.
Look for the "Ducky" result of the "vesterday" search and check the page 14. The excerpt is basically garbled OCR results.
So, what's the idea for the QA plan ?
Talking about the /. effect, I think it would be amusing to have the /. clickthrough data displayed as a graph (e.g. clickthrough/min over time) for each link in a story (at least for the links in the initial story).
One usage of these graphs would be a popularity measure of the stories over time.
> This tends to confuse people, because RH's
> current 0.9.6b isn't vulnerable even though
> stock 0.9.6b is.
Yeah. Confusing it is. I don't see anything in the RedHat RPM indicating that it is different from stock 0.9.6b.
The only indicator is that the package release number is currently 28... 28 releases for the same package, no track of what the releases are about.
Call me a whiner, but I say it's sloppy.
According to various reports, updating to 0.9.6e or 0.9.6g will prevent the exploit. The exploit has been reported on Bugtraq Friday (9/13).
RedHat still hasn't released updated RPMs.
Have they stopped working on weekends ?
I'm beginning to wonder why I'm paying the RHN subscription.
Would you be kind enough to write a small HOWTO or recipe on how to do this ? I've been meaning to try something similar, but I'm too lazy too read all the docs.
Well now, how easy is it to circumvent this ? You just need two IPs apparently unconnected, which is cheap to obtain...
The "and then afterwards" is terminally flawed