(Hi Matt!) In the Clearway days before Mirror-Image, we went as far as starting to register "slashdotted.com" for just such a service. Got lost in the CW/MII shuffle, I believe.
The difference here is that the customers can be identified a few hours or days before the deluge of traffic hits. And by the time./ subscribers start clicking on the site, the Webmaster will already be seeing a good-sized surge of traffic; it's much easier to sell traffic surge protection when the customer sees a surge actually starting, and they know that they have only a few days or a few hours (or minutes!) to make a decision.
The two biggest problems in the CDN business are (1) finding high quality new customer leads, and (2) convincing people that they'll actually need the service and that they'll see real benefit. This scheme addresses both, head-on. And the cost of this marketing program? Just a basic./ subscription, and having a specialized sales rep make a couple of phone calls a day.
Of course, if MII doesn't want this business, I'm sure there are others who do. And besides, they always say if you want something done right, you have to do it yourself... *gr{i|oa}n*
Here's a great marketing opportunity for someone entrepeneurially-minded:
1. Subscribe to the Mysterious Future via./ 2. Contact Web site owners and warn them politely of impending future slashdotting 3. Offer to sell them (short-term?) service on a Content Delivery Network 4.... Profit!
Commercial sites would love this. Academic/government ones probably wouldn't care as much. You could sell them a contract with an existing CDN (Akamai, Mirror-Image, etc.) or build out your own special purpose service, just to handle slashdot-like effects.
-Mark, founder of Clearway Technologies (now owned by Mirror-Image Internet)
Having implemented several RAM-based, multithreaded data storehouses, I've got to say that this really hit the bullseye for me:
If there is only one object in memory for each record, then you'll be writing a tremendous amount of custom thread-safety code and even then, either A) writers block readers and readers block writers or B) read consistacny isn't guaranteed. Either is usually unacceptable. One alternative is to clone objects at every write (sounds slow and horribly inefficient). Of course, this too has to be serialized, or you don't have ACIDity.
You didn't explicitly mention many-readers-one-writer locks; they greatly improve the multiprocessing of the system, but nevertheless getting it all right and using everything consistently is still a huge task.
The only task that seems more daunting to me that that, having implemented these things several times, is trying to force all the developers to never read data from the managed objects without taking out (at least) a read lock first. There's this whole "well, it's only a memory read, so why bother with a transaction?" mindset, and it's just plain wrong.
Thanks for the clarifying reply. I think my two fundamental concerns are (1) that it's not a great idea to rely on every single developer to observe the "don't touch the business objects directly" rule every single time without some way of making sure they're all "being good", and (2) single-threading all of the transactions seems like a guaranteed performance bottleneck, for some kinds of applications, anyway.
I'll take a look at the other articles once their server is juggling fewer threads itself.
I completely understand. I've been in your position before, and, I'm sheepish to admit, the Primadonna's position as well. I once wrote a (really, really, really fast!) RAM-based indexed database for C++ objects. At least I had enough smarts to disclaim any and all ACID functionality -- basically all I said was that it was really fast for read queries, and that everything else was up to the individual user/developer. But even so, there were only about two people who were able to use it "correctly"; everyone else assumed that the database engine itself was dealing with things like locking, transaction commit/rollback, etc.. We eventually replaced it with a system that did all that itself, and myriad odd application bugs suddenly disappeared.
More interestingly, I once oversaw the development of a RAM-based object/caching layer implemented on top of a disk-based relational database that DID support ACID (c-tree plus from Faircom). Our RAM-based caching layer was truly blindingly and screamingly fast... until we had to add all the interlocks necessary to guarantee that the RAM cache stayed in atomically in sync with the underlying disk database. (Then it was only just plain screamingly fast, not blindingly screamingly fast.)
But it took a lot of work to get it right. And, unfortunately, we learned a huge amount about databases in the process.
If I read the IBM article (the one written by the person they describe as "a 19-year old Java and Python enthusiast") correctly, then: 1. Atomicity is implemented at the method-call level; there's no notion of a transaction (even a read transaction) that can be open while others are open too. The exception to that, of course, is if you write methods that read values from the business objects WITHOUT using doing it inside a Serializable subclass, in which case you've lost your atomicity anyway. 2. It appears that there is no declarative data consistency checking; that's left up to the individual programmer accessing the Java objects directly. 3. It appears that there is no transaction isolation; any code can read from the business objects directly. 4. There is a journaling mechanism that does provide durability.
One of the most annoying lessons to learn the hard way when trying to implement a RAM-based (disk-backed) data store that provides ACID functionality is that every set of READ operations against the memory objects have to be wrapped in a transaction of some sort, as well as the WRITE operations. It's so, so tempting to just read from the objects directly "just this once"... but in doing so, you usually violate the "isolation" restriction.
It looks to me like prevalayer data store transactions are Durable, but are not Atomic, Consistent, or Isolated. If I've mis-read, please let me know, because I'm basically a big fan of RAM-based databases; this one just seems like a (really fast) non-ACID toy.
Things I want in a persistent datastore: - Atomicity of transactions (commit/rollback), - Consistency in the enforcement of my data integrity rules, - Isolation of each transaction from other competing transactions (locking) - Durable storage that can survive a crash without losing transactions (e.g., journaling)
My experience with RAM-centeric disk-backed object storage is that you, the developer, often have to implement the ACID fetures yourself, from scratch. And from-scratch implementations of complex data-integrity mechanisms tend to be time-consuming to develop and test and often take much, much longer than you think to "get right".
Call me old-fashioned, but I really like using data storage (database) engines that pass the ACID test and have already been debugged and debugged and debugged and debugged and debugged.
Heh. I guess that goes with the "there no such thing as bad PR" theory.
But trust me, it was a royal pain in the reverse proxy. We'd developed this software for both Windows and MacOS, and we'd seeded it to a dozen test sites -- including a bunch of K12 schools were THRILLED with it.
As a small (tiny) software company, we depended on various Web sites to carry our new product announcements and get the word out about our offerings. When we released AdScreen, most of those very same Web sites not only refused to carry the announcement, but many also sent us three-dimensional nastygrams saying that they weren't going to cover ANY of our products ever again.
We had some very heated discussions with many of the Web site owners and editors that morning, and came to the conclusion that they were "holding our head under water", and that unless we recanted, they'd collectively cut off our (free) PR channel to the marketplace. Since we depended on that for our marketing and sales, we backed down.
Our software did not remove ads. Instead, it removed the graphical parts of the ads, replacing them with text-only versions (mostly from the ALT text) that were still visible and clickable, just not as bandwidth-hogging or visually intrusive.
It's interesting to note that several of the most vocal Web sites that were complaining about how AdScreen was going to ruin their business have now switched from running graphical banner ads to inline text-box ads -- exactly what AdScreen would have done to their site anyway four years ago.
Canning the software LOUDLY was a good PR move, given the rest of the situation. But it in no way made up for the extended multiplatform development effort that went into developing AdScreen.
Strictly from a PR point of view, I can't imagine that kicking users off your Web site for any reason is all that good for business.
But all this talk about ad blocking reminds me of PrivNet's IFF. In 1996, PrivNet launched the Web's first ad-blocking software, "Internet Fast Forward", saying "if it's out there, we can filter it". When PrivNet was threatened with various legal nastiness, they responded with "The Scissors Defense".
The Scissors Defense argues that if you pick up a copy of a newspaper (even a free one), you're full entitled to cut out the ads out with a scissor and throw them away, and the newspaper has no standing to sue the scissors manufacturer. Hence, they argued, just because someone uses PrivNet's software to do something undesirable doesn't make PrivNet liable for the outcome.
If "enough" people snip the ads, the newspaper may ultimately have to raise their newsstand price, but that's capitalism for you.
Q8: What about OS X? Chimera is the top gecko-based browser for OS X. We do not intend to compete on that platform.
Chimera is here. It might be nice to see Chimera and Phoenix share ideas, programmers, resources, and code, but both projects seem to be doing OK so far as separate entities.
Besides, if they merged the projects, they'd have a very confusing animal for a logo: flaming bird with the head of a male lion, the body of a goat, and the tail of a snake: a 'phimera'.
Since the new project would also be Mac OS X -native, they really should also crossbreed this new 'phimera' with Hexley (the Darwin mascot), a duck-billed platypus with horns. The result would be a horny duck-faced lion with a goatee that lays flaming serpent eggs midair.
I think you can see now the grave importance of keeping these two projects separate.
NOLO Press ("Please Don't Feed The Lawyers") needs to be mentioned here. Not only to they publish some really great legal books for non-lawyes, but they also have several "Plain English Law Centers", including a legal encyclopedia, dictionary, FAQ, and so on.
I'm not affiliated with NOLO, except for the fact that I'm a very satisfied customer. I've started and run a couple of small technology businesses, and dealt with a fair amount of IP (both patent and trademark) and contract law issues, and NOLO books are great for educating yourself about what the real legal issues are, and when you really need to get an attorney involved.
-Mark (IANAL, but my wife is -- and she approves of NOLO:)
Don't forget the porn angle, too...
on
Why VHS Was Better
·
· Score: 3, Interesting
I've read several times now that because VHS tapes themselves were cheaper than Beta tapes, the suddenly-revitalized (due to VCRs in general) porn industry had a preference for publishing on VHS tapes. With more porn titles available on VHS, VHS quickly became the format of choice for home VCRs.
(Check out the book "Obscene Profits" by Frederick Lane.)
A 10BaseT line runs at ten million bits per second. A 320kbps MP3 datastream requires (only) 320 thousand bits per second. You could stream roughly thirty concurrent different music streams at 320kbps each over a 10baseT ethernet line.
There may be a bitrate limitation in the SliMP3 device itself, but the ethernet wire, even if it's "only" ten megabit line, connecting the SliMP3 to the server is not the bit-rate bottleneck.
Here's what they've gotten right: average folks are starting to embrace the put-all-my-CDs-on-a-hard-drive and listen-to-them-from-there model. And $399 is a much better price -- not just cheaper, but better: it's more in line with what other stereo components cost.
But for me, there is one big thing missing from this setup: if you want music in the living room, and in the study, and in the bedroom, you have to buy three of these things, and rip your CDs three times each. If one of these boxes could feed a Rio Receiver or a SliMPEG over ethernet (wireless perferred, of course), I'd be much more interested. Central storage, distributed independent playback.
It seems to me that the Tradegy of the Commons kicks in when the 'leeches' hit a certain density within the general population, and when their 'leeching' begins to have a measurable effect on the average non-leeching individual.
And, in fact, we have seen exactly this kind of thing kicking in in certain parts of the Internet, like broadband service and pricing. AT&T has started separating out the 'leeches' ("heavy users") from average users, and applying negative feedback (higher prices) to their leeching behavior. Again, you can see how it takes a centralized administration (AT&T) to bring the system back into balance.
So you can either (1) hope that your system never becomes popular, or (2) hope that the denisty of leeches in your population never exceeds a certain 'thermal runaway' threshold, or (3) hope that the very worst leeching behavior doesn't substantially degrade service for everyone else, or you can (4) design the system so that at least one of those is true. Since popularity is desirable in a p2p system, and there are always some leeches, you need to design in limits to how much leeching one user can do -- an interesting problem in an open-source, p2p network.
This problem was first identified and analized in 1833 by Willian Lloyd. It went something like this:
The tragedy of the commons develops in this way. Picture a pasture open to all. It is to be expected that each herdsman will try to keep as many cattle as possible on the commons. Such an arrangement may work reasonably satisfactorily for centuries because tribal wars, poaching, and disease keep the numbers of both man and beast well below the carrying capacity of the land. Finally, however, comes the day of reckoning, that is, the day when the long-desired goal of social stability becomes a reality. At this point, the inherent logic of the commons remorselessly generates tragedy.
As a rational being, each herdsman seeks to maximize his gain. Explicitly or implicitly, more or less consciously, he asks, "What is the utility to me of adding one more animal to my herd?" This utility has one negative and one positive component.
1. The positive component is a function of the increment of one animal. Since the herdsman receives all the proceeds from the sale of the additional animal, the positive utility is nearly + 1.
2. The negative component is a function of the additional overgrazing created by one more animal. Since, however, the effects of overgrazing are shared by all the herdsmen, the negative utility for any particular decisionmaking herdsman is only a fraction of - 1.
Adding together the component partial utilities, the rational herdsman concludes that the only sensible course for him to pursue is to add another animal to his herd. And another.... But this is the conclusion reached by each and every rational herdsman sharing a commons. Therein is the tragedy. Each man is locked into a system that compels him to increase his herd without limit -- in a world that is limited. Ruin is the destination toward which all men rush, each pursuing his own best interest in a society that believes in the freedom of the commons. Freedom in a commons brings ruin to all.
The problem in general arises when you've set up a situation where if each user acted in both a rational and self-interested way, the system overall would collapse for all the users.
When designing any kind of multi-user system, it's critical to plan for the "what if all the users (or half of them) suddenly got very selfish." What results are things like disk quotas: central-system-enforced limits on individual behavior.
In a system like the gnutella network, where there is no 'central system' to enforce 'community-minded' behavior, the eventual collapse of the system can be predicted as a function of overall population, presuming that there are always a few people who are more selfish than the rest.
Centralized systems like Napster actually had an advantage in that the centralized servers could establish and enforce 'fairness' policies that kept selfish users from triggeringa 'Tragedy of The Commons'.
This has the potential to be a real win for journalists, students, bloggers, e-mail jockeys, and anyone else who's make use of computer is to read, enter, and edit text.
The big problem that I see is that it needs a hard lid that closes over the keyboard and screen to protect them so you can just toss this into your backpack without filling the keyboard with Doritos crumbs.
The eMate design handled this nicely, but any hard lid would be great.
Actually, the eMate was a huge hit with the people (mostly in the education market) who actually got to use one. Not only did students and teachers like them, but journalists went nuts for them - just the thing for traveling and writing. The big downside was that the eMate wasn't nearly as quick or powerful as the Newton 2000/2100.
There was rampant speculation for a while that Apple was going to put the more-powerful (167Mhz ARM) Newton 2000/2100 guts into an eMate case and retarget it towards business users: a "bMate".
The AlphaSmart Dana reminds me a lot of the "bMate" concept. I bet it quickly develops a cult following, especially if the Internet functionality (wireless, e-mail, Web, and blogging, anyone?) is up to speed.
Even though slashdotting brings in a metric buttload of legitimate traffic, a Web site designed for high traffic scalability can include some kind of "surge protection", such as that provided by 'Content Deli ve ry Networks' such as Akamai, Mirror Image, etc.
Today's CDNs respond in realtime to traffic surges. If there's a sudden upswing in client-side demand, the CDN responds by distributing the content and the server-side load more widely across a larger number of servers, topologically selected to minimize network delays, etc.
Today the bottleneck with highly intereactive Web sites, even those that use CDNs, comes from the back-end databases that manage the content and drive the site. There's still lo ts of smart work to be done there with intelligent caching and content distribution.
-Mark Kriegsman
Founder, Clearway Technologies (which was subsequently purchased by Mirror Image),el
Your Company is a member of the Borealis Family of Companies, and is incorporated in Gibraltar.
Is it just me, or does this look like a template document where someone missed one of the 'search and replace' terms? E.g. Perhaps Borealis provides this boilerplate text to all of the companies they try this with.
Clerical errors are by no means an indication of anything more sinister. But clerical errors in the stock trading information that a company provides don't really make me feel especially warm and fuzzy.
The list: lawyers who work for the ACLU fighting for civil rights, lawyers who work for NRDC trying to protect the environment, lawywers who work for the EFF, or PFAW, or any other public interest organization. Or all the lawers who work for the state, federal, and local government who try to keep corporations for running amuck. My wife works for the Massachusetts Office of Child Care Services trying to keep kids safe, and help parents find child care they can count on.
And for the record, the attorneys in her office make a lot closer to $20/hour. Care to figure out how long it takes to repay $60,000 in law school student loans at that rate (after you take out rent and food)?
There are thousands of lawyers who choose to work for the public good instead of their own greed. There are tens of thousands who go for the greed, but don't let that make you ignore the ones who Do The Right Thing.
Don't forget that there are lots and lots of lawers who only work on public interest cases (and who get paid diddley-squat to do it). Lawyers who go into public interest (as my wife did) seem make only about a quarter of the salary as their corporate counterparts.
Giving up 75% of your income to work excusively on projects you believe in for the public good? I'd say that's called putting your money where your mouth is.
Public interest lawers -- those working for civil rights, the environment, public policy agencies, etc -- are generally paid very little compared to (evil) corporate lawers. I know one public interest attorney (my wife) who makes approximately one quarter of what her law school classmates who went to work for large corporate law firms are making these days.
Public interest lawers have a lot more in common with your average Open Source programmer than you might think. It takes a pretty strong sense of values to give up 75% of your earning potential to work on the things that you think are "important to all of us", but there are lots of lawers who do just that.
Way back in 1995 when we got married, we put up wedding pictures online and it was so rare and unusual that People Magazine, Cosmopolitan Magazine and NetGuide Magazine all ran printed-on-paper stories about it! Now there are zillions of great wedding web pages, and no one bats an eyelash.
On the other hand, Rob's proposal is probably one of those "great Internet moments" that'll become part of the lore now.
*raises a glass* Congratulations and have a great adventure together!
Slashdot Mirror
(Hi Matt!) In the Clearway days before Mirror-Image, we went as far as starting to register "slashdotted.com" for just such a service. Got lost in the CW/MII shuffle, I believe.
./ subscribers start clicking on the site, the Webmaster will already be seeing a good-sized surge of traffic; it's much easier to sell traffic surge protection when the customer sees a surge actually starting, and they know that they have only a few days or a few hours (or minutes!) to make a decision.
./ subscription, and having a specialized sales rep make a couple of phone calls a day.
The difference here is that the customers can be identified a few hours or days before the deluge of traffic hits. And by the time
The two biggest problems in the CDN business are (1) finding high quality new customer leads, and (2) convincing people that they'll actually need the service and that they'll see real benefit. This scheme addresses both, head-on. And the cost of this marketing program? Just a basic
Of course, if MII doesn't want this business, I'm sure there are others who do. And besides, they always say if you want something done right, you have to do it yourself... *gr{i|oa}n*
-Mark
Here's a great marketing opportunity for someone entrepeneurially-minded:
./ ... Profit!
1. Subscribe to the Mysterious Future via
2. Contact Web site owners and warn them politely of impending future slashdotting
3. Offer to sell them (short-term?) service on a Content Delivery Network
4.
Commercial sites would love this. Academic/government ones probably wouldn't care as much. You could sell them a contract with an existing CDN (Akamai, Mirror-Image, etc.) or build out your own special purpose service, just to handle slashdot-like effects.
-Mark, founder of Clearway Technologies (now owned by Mirror-Image Internet)
The only task that seems more daunting to me that that, having implemented these things several times, is trying to force all the developers to never read data from the managed objects without taking out (at least) a read lock first. There's this whole "well, it's only a memory read, so why bother with a transaction?" mindset, and it's just plain wrong.
Thanks for the clarifying reply. I think my two fundamental concerns are (1) that it's not a great idea to rely on every single developer to observe the "don't touch the business objects directly" rule every single time without some way of making sure they're all "being good", and (2) single-threading all of the transactions seems like a guaranteed performance bottleneck, for some kinds of applications, anyway.
I'll take a look at the other articles once their server is juggling fewer threads itself.
I completely understand. I've been in your position before, and, I'm sheepish to admit, the Primadonna's position as well. I once wrote a (really, really, really fast!) RAM-based indexed database for C++ objects. At least I had enough smarts to disclaim any and all ACID functionality -- basically all I said was that it was really fast for read queries, and that everything else was up to the individual user/developer. But even so, there were only about two people who were able to use it "correctly"; everyone else assumed that the database engine itself was dealing with things like locking, transaction commit/rollback, etc.. We eventually replaced it with a system that did all that itself, and myriad odd application bugs suddenly disappeared.
... until we had to add all the interlocks necessary to guarantee that the RAM cache stayed in atomically in sync with the underlying disk database. (Then it was only just plain screamingly fast, not blindingly screamingly fast.)
More interestingly, I once oversaw the development of a RAM-based object/caching layer implemented on top of a disk-based relational database that DID support ACID (c-tree plus from Faircom). Our RAM-based caching layer was truly blindingly and screamingly fast
But it took a lot of work to get it right. And, unfortunately, we learned a huge amount about databases in the process.
-Mark
If I read the IBM article (the one written by the person they describe as "a 19-year old Java and Python enthusiast") correctly, then:
1. Atomicity is implemented at the method-call level; there's no notion of a transaction (even a read transaction) that can be open while others are open too. The exception to that, of course, is if you write methods that read values from the business objects WITHOUT using doing it inside a Serializable subclass, in which case you've lost your atomicity anyway.
2. It appears that there is no declarative data consistency checking; that's left up to the individual programmer accessing the Java objects directly.
3. It appears that there is no transaction isolation; any code can read from the business objects directly.
4. There is a journaling mechanism that does provide durability.
One of the most annoying lessons to learn the hard way when trying to implement a RAM-based (disk-backed) data store that provides ACID functionality is that every set of READ operations against the memory objects have to be wrapped in a transaction of some sort, as well as the WRITE operations. It's so, so tempting to just read from the objects directly "just this once"... but in doing so, you usually violate the "isolation" restriction.
It looks to me like prevalayer data store transactions are Durable, but are not Atomic, Consistent, or Isolated. If I've mis-read, please let me know, because I'm basically a big fan of RAM-based databases; this one just seems like a (really fast) non-ACID toy.
-Mark
Things I want in a persistent datastore:
- Atomicity of transactions (commit/rollback),
- Consistency in the enforcement of my data integrity rules,
- Isolation of each transaction from other competing transactions (locking)
- Durable storage that can survive a crash without losing transactions (e.g., journaling)
My experience with RAM-centeric disk-backed object storage is that you, the developer, often have to implement the ACID fetures yourself, from scratch. And from-scratch implementations of complex data-integrity mechanisms tend to be time-consuming to develop and test and often take much, much longer than you think to "get right".
Call me old-fashioned, but I really like using data storage (database) engines that pass the ACID test and have already been debugged and debugged and debugged and debugged and debugged.
-Mark
Heh. I guess that goes with the "there no such thing as bad PR" theory.
But trust me, it was a royal pain in the reverse proxy. We'd developed this software for both Windows and MacOS, and we'd seeded it to a dozen test sites -- including a bunch of K12 schools were THRILLED with it.
As a small (tiny) software company, we depended on various Web sites to carry our new product announcements and get the word out about our offerings. When we released AdScreen, most of those very same Web sites not only refused to carry the announcement, but many also sent us three-dimensional nastygrams saying that they weren't going to cover ANY of our products ever again.
We had some very heated discussions with many of the Web site owners and editors that morning, and came to the conclusion that they were "holding our head under water", and that unless we recanted, they'd collectively cut off our (free) PR channel to the marketplace. Since we depended on that for our marketing and sales, we backed down.
Our software did not remove ads. Instead, it removed the graphical parts of the ads, replacing them with text-only versions (mostly from the ALT text) that were still visible and clickable, just not as bandwidth-hogging or visually intrusive.
It's interesting to note that several of the most vocal Web sites that were complaining about how AdScreen was going to ruin their business have now switched from running graphical banner ads to inline text-box ads -- exactly what AdScreen would have done to their site anyway four years ago.
Canning the software LOUDLY was a good PR move, given the rest of the situation. But it in no way made up for the extended multiplatform development effort that went into developing AdScreen.
-Mark
Strictly from a PR point of view, I can't imagine that kicking users off your Web site for any reason is all that good for business.
But all this talk about ad blocking reminds me of PrivNet's IFF. In 1996, PrivNet launched the Web's first ad-blocking software, "Internet Fast Forward", saying "if it's out there, we can filter it". When PrivNet was threatened with various legal nastiness, they responded with "The Scissors Defense".
The Scissors Defense argues that if you pick up a copy of a newspaper (even a free one), you're full entitled to cut out the ads out with a scissor and throw them away, and the newspaper has no standing to sue the scissors manufacturer. Hence, they argued, just because someone uses PrivNet's software to do something undesirable doesn't make PrivNet liable for the outcome.
If "enough" people snip the ads, the newspaper may ultimately have to raise their newsstand price, but that's capitalism for you.
-Mark, who has some experience in this area
Chimera is here. It might be nice to see Chimera and Phoenix share ideas, programmers, resources, and code, but both projects seem to be doing OK so far as separate entities.
Besides, if they merged the projects, they'd have a very confusing animal for a logo: flaming bird with the head of a male lion, the body of a goat, and the tail of a snake: a 'phimera'.
Since the new project would also be Mac OS X -native, they really should also crossbreed this new 'phimera' with Hexley (the Darwin mascot), a duck-billed platypus with horns. The result would be a horny duck-faced lion with a goatee that lays flaming serpent eggs midair.
I think you can see now the grave importance of keeping these two projects separate.
-Mark
NOLO Press ("Please Don't Feed The Lawyers") needs to be mentioned here. Not only to they publish some really great legal books for non-lawyes, but they also have several "Plain English Law Centers", including a legal encyclopedia, dictionary, FAQ, and so on.
:)
I'm not affiliated with NOLO, except for the fact that I'm a very satisfied customer. I've started and run a couple of small technology businesses, and dealt with a fair amount of IP (both patent and trademark) and contract law issues, and NOLO books are great for educating yourself about what the real legal issues are, and when you really need to get an attorney involved.
-Mark
(IANAL, but my wife is -- and she approves of NOLO
I've read several times now that because VHS tapes themselves were cheaper than Beta tapes, the suddenly-revitalized (due to VCRs in general) porn industry had a preference for publishing on VHS tapes. With more porn titles available on VHS, VHS quickly became the format of choice for home VCRs.
(Check out the book "Obscene Profits" by Frederick Lane.)
-Mark
A 10BaseT line runs at ten million bits per second.
A 320kbps MP3 datastream requires (only) 320 thousand bits per second.
You could stream roughly thirty concurrent different music streams at 320kbps each over a 10baseT ethernet line.
There may be a bitrate limitation in the SliMP3 device itself, but the ethernet wire, even if it's "only" ten megabit line, connecting the SliMP3 to the server is not the bit-rate bottleneck.
-Mark, a 192Kbps kind of guy
Here's what they've gotten right: average folks are starting to embrace the put-all-my-CDs-on-a-hard-drive and listen-to-them-from-there model. And $399 is a much better price -- not just cheaper, but better: it's more in line with what other stereo components cost.
But for me, there is one big thing missing from this setup: if you want music in the living room, and in the study, and in the bedroom, you have to buy three of these things, and rip your CDs three times each. If one of these boxes could feed a Rio Receiver or a SliMPEG over ethernet (wireless perferred, of course), I'd be much more interested. Central storage, distributed independent playback.
-Mark
It seems to me that the Tradegy of the Commons kicks in when the 'leeches' hit a certain density within the general population, and when their 'leeching' begins to have a measurable effect on the average non-leeching individual.
And, in fact, we have seen exactly this kind of thing kicking in in certain parts of the Internet, like broadband service and pricing. AT&T has started separating out the 'leeches' ("heavy users") from average users, and applying negative feedback (higher prices) to their leeching behavior. Again, you can see how it takes a centralized administration (AT&T) to bring the system back into balance.
So you can either (1) hope that your system never becomes popular, or (2) hope that the denisty of leeches in your population never exceeds a certain 'thermal runaway' threshold, or (3) hope that the very worst leeching behavior doesn't substantially degrade service for everyone else, or you can (4) design the system so that at least one of those is true. Since popularity is desirable in a p2p system, and there are always some leeches, you need to design in limits to how much leeching one user can do -- an interesting problem in an open-source, p2p network.
-Mark
The problem in general arises when you've set up a situation where if each user acted in both a rational and self-interested way, the system overall would collapse for all the users.
When designing any kind of multi-user system, it's critical to plan for the "what if all the users (or half of them) suddenly got very selfish." What results are things like disk quotas: central-system-enforced limits on individual behavior.
In a system like the gnutella network, where there is no 'central system' to enforce 'community-minded' behavior, the eventual collapse of the system can be predicted as a function of overall population, presuming that there are always a few people who are more selfish than the rest.
Centralized systems like Napster actually had an advantage in that the centralized servers could establish and enforce 'fairness' policies that kept selfish users from triggeringa 'Tragedy of The Commons'.
-Mark
Snow Crash here we come.
-Mark
This has the potential to be a real win for journalists, students, bloggers, e-mail jockeys, and anyone else who's make use of computer is to read, enter, and edit text.
The big problem that I see is that it needs a hard lid that closes over the keyboard and screen to protect them so you can just toss this into your backpack without filling the keyboard with Doritos crumbs.
The eMate design handled this nicely, but any hard lid would be great.
-Mark
Actually, the eMate was a huge hit with the people (mostly in the education market) who actually got to use one. Not only did students and teachers like them, but journalists went nuts for them - just the thing for traveling and writing. The big downside was that the eMate wasn't nearly as quick or powerful as the Newton 2000/2100.
There was rampant speculation for a while that Apple was going to put the more-powerful (167Mhz ARM) Newton 2000/2100 guts into an eMate case and retarget it towards business users: a "bMate".
The AlphaSmart Dana reminds me a lot of the "bMate" concept. I bet it quickly develops a cult following, especially if the Internet functionality (wireless, e-mail, Web, and blogging, anyone?) is up to speed.
-Mark
Actually, I think the answer is yes.
Even though slashdotting brings in a metric buttload of legitimate traffic, a Web site designed for high traffic scalability can include some kind of "surge protection", such as that provided by 'Content Deli ve ry Networks' such as Akamai, Mirror Image, etc.
Today's CDNs respond in realtime to traffic surges. If there's a sudden upswing in client-side demand, the CDN responds by distributing the content and the server-side load more widely across a larger number of servers, topologically selected to minimize network delays, etc.
Today the bottleneck with highly intereactive Web sites, even those that use CDNs, comes from the back-end databases that manage the content and drive the site. There's still lo ts of smart work to be done there with intelligent caching and content distribution.
-Mark Kriegsman
Founder, Clearway Technologies (which was subsequently purchased by Mirror Image),el
Is it just me, or does this look like a template document where someone missed one of the 'search and replace' terms? E.g. Perhaps Borealis provides this boilerplate text to all of the companies they try this with.
Clerical errors are by no means an indication of anything more sinister. But clerical errors in the stock trading information that a company provides don't really make me feel especially warm and fuzzy.
-Mark
The list: lawyers who work for the ACLU fighting for civil rights, lawyers who work for NRDC trying to protect the environment, lawywers who work for the EFF, or PFAW, or any other public interest organization. Or all the lawers who work for the state, federal, and local government who try to keep corporations for running amuck. My wife works for the Massachusetts Office of Child Care Services trying to keep kids safe, and help parents find child care they can count on.
And for the record, the attorneys in her office make a lot closer to $20/hour. Care to figure out how long it takes to repay $60,000 in law school student loans at that rate (after you take out rent and food)?
There are thousands of lawyers who choose to work for the public good instead of their own greed. There are tens of thousands who go for the greed, but don't let that make you ignore the ones who Do The Right Thing.
Giving up 75% of your income to work excusively on projects you believe in for the public good? I'd say that's called putting your money where your mouth is.
-Mark
Public interest lawers have a lot more in common with your average Open Source programmer than you might think. It takes a pretty strong sense of values to give up 75% of your earning potential to work on the things that you think are "important to all of us", but there are lots of lawers who do just that.
-Mark
Way back in 1995 when we got married, we put up wedding pictures online and it was so rare and unusual that People Magazine, Cosmopolitan Magazine and NetGuide Magazine all ran printed-on-paper stories about it! Now there are zillions of great wedding web pages, and no one bats an eyelash.
On the other hand, Rob's proposal is probably one of those "great Internet moments" that'll become part of the lore now.
*raises a glass* Congratulations and have a great adventure together!
-Mark