Re:Prioritizing packets
on
World of Ends
·
· Score: 1
As an AC said, it is quite possible to alter software on your local machine and abuse "small packet preference". That would have the dual damages of breaking the intent of the system- but also, the smaller packets will increase the header:content ratio, bringing a greater percentage overhead onto the network.
(There are techniques one could attempt to combat such abuse. Much experimentation has gone on in this area. For example, build routers with multiple layers of queues intended for packets of different sizes or priorities, so that lower priority packets have more total space, and are less likely to be dropped. That system might allow applications to work which are either high bandwdith or low latency, but not both)
Additionally, some applications needing low-latency might still use big packets: videoconferencing, or something. (A VC protocol might tend to feel out the bandwidth available, using larger and larger packets until they start to be dropped, then stick with the large size).
Existing TCP relies on some trust between users, so that one person doesn't hurt everyone else to speed himself up. The "short packet preference" idea is even more fragile that way. I'm not sure we can continue to rely on that in the future.
Re:so, in other words....
on
World of Ends
·
· Score: 1
Minna Kirai meet the real world.
Networks have 3 states:
Empty. 0% utilization. No need for QoS.
Loaded. 10-50% util. Delays at intermediate routers cause packets to be slowed. QoS can help packets which need speed to achieve it.
Congested. 60-90% util. Overflowing routers destroy many packets. QoS could mark some packets as less likely to be dropped, but for fairness, it shouldn't. Instead, router/link throughput should be upgraded, or incoming links throttled.
Free markets are unstable.
They are stabler than any other economic system yet attempted.
We require stability in our network protocols.
We don't have it today, yet are proceding swimmingly.
Re:so, in other words....
on
World of Ends
·
· Score: 1
Not if the network is congested.
That is not the common case optimizations should be targeted for. Congested states should be rare- plan to avoid them, not discard other plans because they'd have flaws during it.
If a network gets overloaded in the face of FTP-like uses, then it needs to be upgraded, that's not disputed. (Otherwise, setting the priority flag won't help any individual once everyone starts to do it)
Networks designers should aim to leaving a portion of their bandwidth free in normal use. It's in situations with utilization of 30%-40% or so that QoS flags are really helpful. They'll insulate interactive streams from being disrupted by the occasional 3MB file download.
Simply going ahead and upgrading every single link to be high speed, high bandwidth- without an opportunity to differentiate price for different applications- will encourage users to saturate the lines. ("Leave streaming music videos on all night long? Why not?"). Then we're back to the case of the data which truely needs low-latency not getting it... and another expensive cycle of all-around upgrades begins again.
This is a "defense of the commons" problem. To allow the free market to automatically solve the problem of consumers requesting more than they need, we need a mechanism to allow some variation in price for using the service. With that capability in place, the Invisible Hand will choose an effective incremental cost.
In the future, paying internet users will be better off if they can be charged less for a 1 gigabyte music broadcast than for 1 gigabyte of videophone traffic. The latter application is more vulnerable to small changes in congestion, so it should be able to offer the network more money to protect it. Applications not needing that service shouldn't need to pay for it.
They all can benefit from a minimum guaranteed bandwidth/improved latency/improved jitter; especially audio streaming.
Audio streaming is the textbook example of a high bandwidth, high-latency application. Latency only matters if timeouts/ACKs are important, and they only matter if packets are being dropped. And if that's happening, it's a separate, major problem, which should be fixed on its own.
Re:so, in other words....
on
World of Ends
·
· Score: 1
It's not as simple as that though; otherwise I would hack my protocol stack to stick 'fast' on all my packets. My ftp downloads will fly
I guess you skipped reading my post. It was all based on the ISP charging a higher fee for faster packets!
Anyone who hacks his FTP client to request low latency will boost his usage charges, and recieve the total file in 24:36.67, instead of 24:38.12 for a normal connection (for one representative set of numerical assumptions). 1 whole second faster.
If a user feels that's an acceptable use of money, fine.
Also, when I used "fast packets" above, I was referring primarily to latency, which is different from bandwidth. You seem to be focusing on bandwidth, which is unrelated to QoS, and isn't what I was discussing. Here's a discussion about bandwidth vs latency, if you need a refresher.
If an ISP allows QoS flags to indicate that some packets need improved latency, it doesn't have to change that user's bandwidth limits at all. Regardless of the latency setting, he can still only send 150kB/s (or whatever the speed is). But, these packets will "skip over the line" at routers on his ISP (and cooperating network providers, which eventually will be most of them). They will arrive at the destination in only 25 milliseconds, insteal of 100.
That means if he's talking on the phone, or aiming a railgun at a gladiator, the response time for updates is 25% of what it had been. Yet the total data rate he can transmit remains the same.
QoS for low-latency doesn't help FTP at all. Email, IM, HTTP, and audio streaming likewise recieve no benefit. There is no incentive to request QoS for those applications. Only a few uses- voice chat, remote desktop, and gaming- can get much benefit.
For copyright, under American law, you need to enfore it as soon as you are aware of the breach
It's trademark violations that you must pursue as soon as it's discovered. Copyright and patent can wait a while.
Although, the longer you wait, the more sympathy the jury will have for the accused. In court, it's best if you can prove that you warned him early and often, before bringing suit.
The very rich are almost always going to be better off than anyone else, that's unavoidable.
If your structure resists preference, the rich will insist that it's good for everyone so it will be good for them.
Or they'll just hire someone to build a completely separate structure. That'll deprive my structure of the resources they might've contributed to improving it.
There is already a tendency for this today- large companies are transitioning their voice and videoconference systems on IP networks. But they often don't put it on the public internet, or even the same IP network their workers use for desktop applications- they actually fund separate networks just for their chat traffic.
That kind of massive oversupply of bandwidth assures them that they'll have low latency connections when they need them- but they're not using them all the time. All those mighty routers sit quietly at night, helping neither their employees, nor the general public.
If IP supported some kind of QoS tag, then these users might be able to meet the needs of real-time videoconferencing simply by spending $1000 to upgrade the routers on their LAN, rather than $10,000 to build a whole different network. And they'd reap many flexibility benefits.
It's a "big tent" philosophy. The rich will want to spend money to go faster. The Internet can either find a way to take their money, or drive them away to build a competitor, which the poor won't be able to access at all.
The fact is: not all packets need to be quick. For some applications, 3 seconds of delay is absolutely fine. For others, 3 milliseconds is unbearable.
If the internet acknowledges this fact, it becomes a little more complicated, but much more powerful. And it wouldn't be a flag day change- the upgrade can be piecemeal.
(Today, some people already abuse the bandwidth-conserving principles of TCP and HTTP to accelerate their own transmissions, at the expensive of everybody else. QoS tags would provide a legitimate way to do this, without interfering with other packets so much)
This has much less to do with ICBM (usually Nuclear)
The ABL has been mentioned as an eventual component in not just Theater Missile Defense (over a battlefield), but also the National Missile Defense system.
The intent is to keep these aircraft flying continual patrols from a base in South Korea. If sensors (on another aircraft, also continually patrolling) detect a blast like an ICBM takeoff, the laser will be fired at the rocket.
Only if a rocket evades the ABL is will interceptor "kinetic-kill vehicles" be fired at it. (This is the NMD component whose questionable testing procedures have been been all over the news)
I'd think that tabs could break many web applications- or at least increase the chance of a user giving input the app didn't expect.
For instance, if you're on page 4/5 of requesting a service, and then go back to page 2 (still open on a tab) and submit it, what's the application do then? Page 4 is already open, but it may have just been invalidated.
It won't bother all applications of course. Particularly if all inputs are single step (like a "Shopping cart"), or all but one of the tabs are used for informational purposes only.
What is more of a debate where I work is if pagination is better than scrolling.
Scrolling is better for the user for almost every reason- however, it's worse for control-freak web-publishers. Sites like Salon want to be able to tell which kinds of stories are attractive towards their readers, and they'd like to distinguish between stories that are merely downloaded, and those that actually get read. Requiring the user to make another HTTP request to see the end of a story provides them this data.
(Essentially, they wish HTTP were a stateful protocol- maintaining a live connection for as long as the reader is on the page- and pagination makes HTTP requests more frequent, bringing that goal a step closer)
Re:so, in other words....
on
World of Ends
·
· Score: 2, Interesting
Latency mostly comes from the protocols placed on top of IP, such as TCP.
It's true that TCP adds a kind of latency when it stops to wait for a retransmission. But UDP messages on their own have a lot of latency. For most users, most of that latency comes from the first mile and last mile links (especially if they're on dialup).
However, there are sources for latency deep inside the internet as well. Congestion. Actually, the most commonly damaging form of congestion is when someone else on your subnet is making a large download or streaming radio, and you want to run an interactive (VNC or SSH) session.
A non-FIFO router protocol might help alleviate this. It could recognize that the 95% of packets beloning to a big download can afford to wait until the VNC user's mouse-updates have gotten through.
I don't think there is a good way to prioritize packets.
There might be. It could be as simple as a single bitflag for "normal/fast". We'll never know unless we try. And we can't try until packets have a way to indicate desired QoS (the IPv6 "flow label", for instance), and more importantly, users enjoy some financial benefit, however small, for selecting reduced priority for their data.
Of course, there are other things which need to be fixed with the internet before it presents a fair place to test QoS. In particular, firewalls and NATs already block some of the applications which could best make use of QoS, so until they're removed, there'd be little point in doing the experiment.
I agree that widespread adoption of Microsoft-controlled.NET opens a doorway for abuse.
However, from a simplistic Internet-centric perspective, implementing.NET only involves adding new applications to hosts at the Edges. There's no plans for it to change the way routers handle packets, which is what a "change to the internet" would imply.
Yes, it is possible that someday in the future, Microsoft will decide that to optimize.NET, they'll need to transition it away from the real internet, and either create an alternative, "value-added" network, or fund the deployment of ".NET support servers" inside major IP backbones.
Re:Theorem
on
World of Ends
·
· Score: 3, Interesting
Filtering contents adds value, right?
ISP level filtering is one of those things which some people think adds value to the internet, but really damages it. Host-level filtering, however, is a voluntary, application-level process which the host can disable at any time. This is why improvements to the internet should come at the application level (where they can be easily changed and removed if they turn out to have downsides), rather than deeper in the network (where it's harder to convince the sysadmins that you need changes made to do your work).
(Host-level filtering may still be damaging in some cases, such as in a library whose users are forbidden from modifing local software. But that is a separate issue)
Music downloads adds value, right?
From the Internet's point of view, music downloads are "just another file transfer application". They are beyond the scope of section 4. They "improve" the internet by providing another use at the ends. But, as you may have noticed, DRM-based music downloads aren't very popular yet. That's because, as the authors suggested, non-open protocols lack explosive popularity.
an even more fragile piece of DRM-crap
I think that the majority of music-downloaders still manage to find non-DRM files. Not as much as when Napster was running, but it still seems that most music downloads wind up as MP3 files on multiple, redundant CDRs.
Hypothetically, the RIAA might someday propose modifying the internet to make their music transfers more secure, and that would be bad.
(If they could push DRM onto 80% of newly manufactured PC hardware, that would be very bad for other reasons)
Firstly, the phrase "destined to fail" was introduced by a poster, neither did the "World of Ends" article nor myself said anything about that. The article said that abusing the internet's founding principles would be bad, but didn't claim it would be impossible. A sufficiently wrongheaded government, backed up with public fear and acquiesence, could close down the internet and replace it with a regulated, censored information utility.
It also might be possible for Microsft, through careful leveraging of monopoly powers, to force all their users to change to closed, proprietary protocols, cutting them off from much of the internet's value.
Opinions are divided on whether they'll actually try this. Some people claim that.NET protocols are open enough to be non-dangerous. And, depending on who's in the Whitehouse in 2005, an attempt to leverage desktop software dominance into control of a new data-communication monopoly could land Microsoft in more serious legal trouble than they've ever had before.
However, in terms of the "World of Ends" article,.NET is an application at the edge of the cloud, not in the center of it, and thus falls under section 8c "Anyone can improve it", rather than section 4 "Adding value lowers value".
Re:so, in other words....
on
World of Ends
·
· Score: 4, Interesting
I do take issue with that particular writeup, although it is true in many senses.
Today, many so-called internet users have their access mediated by firewalls and NAT. This reduces the set of internet services available to them.
(I'd even say, as a slight exaggeration, that their ISPs had engaged in false advertising by calling it "Internet Access")
By the original definition of the internet, anyone with access (control of one host) could send packets to any address:port combination, and open any port to inbound connections.
This means that everyone with internet access should be able to run an HTTP, FTP, or UT server. But many people are prevented by their ISP's routing policies.
Firewalls and NATs supposedly "add value" to the internet by making it safer for some users. But it's not made a lot safer (worms get through even today), and it has "lowered value", because creating new applications is more difficult. For example, today there is a movement towards SOAP; XML-RPC. Unfortunately, one of the motivations to promote it is to allow arbitrary, application-specific traffic to travel over port 80. To work around firewalls which only permit HTTP, we're starting to see a legitimization of tunneling commands over HTTP.
(I'm not saying that was the original goal of SOAP- but sneaking around firewalls is one reason that some developers are eager to try it)
So there's an example of why "adding value to the Internet" is generally bad.
However, there are cases where it may be good. We all know that IPv6 will be a postive (someday). Multicast extensions to the internet were developed well after it was first created, and are generally accepted as a good thing, although their deployment so far is well short of universal. Multicasting is a superset of existing internet functionality (assigning a single packet to be destined to multiple recipients).
Multicasting may turn out to have downsides, depending on how it's implemented (and I haven't followed development closely enough to be sure what the direction is). If it creates an unfair environment, where large corporations (CBS, MTV, RIAA) can create multicast streams, but individual users cannot, then it will cement inequality and make internet use move closer to resembling traditional television viewing. I feel justified in hoping this won't happen, however.
And QoS (quality of service) is a debatable issue, not a flat-out bad one like the article suggests. IP, the existing internet protocol (not to be confused with Intellectual Property), makes no guarantee that packets will arrive quickly or in order. It doesn't state that packets will travel at the same speed as each other. It doesn't even state that a packet which is sent will ever arrive, only that the network make a "best effort" at getting it through someday.
Since IP makes no guarantees of transmission speed, adding an optional mechanism to request QoS efforts won't break the existing protocol definitions. Yes, it may disturb some people to consider that internet packets, which used to be fair and unbiased, may someday have preference given to them based on the sender's bank account- but look at the alternative:
Today, internet access is filtered by bank account- if your wealth is too low, you can't use the internet at all. Allowing some packets to be more expensive to send allows the rich to subsidize the poor, who might be able to afford some access instead of none.
Today, deploying applications like voice, moving video, and arcade games over the internet is difficult, because your packets have latency and jitter. That's because they are competing will all kinds of email, IM, HTTP, FTP, and NTTP protocols as they move accross the network. To make low-latency interaction work better, we can either invest a lot to make the entire internet super-fast, or invest a little to recognize which packets need high speed, and bump them ahead of the lines.
Someday, your ISP will decide to charge you by the gigabyte. Won't you want to be able to request a reduced rate, by intstructing your software to request low-priority packets, instead of rapid-response ones? (This is analogous to last-minute airline tickets)
Basically, there are only a few internet applications which really need low-latency response: speech, video, gaming, and maybe some forms of web browsing. Everything else, especially emails and big downloads over HTTP or FTP, would work absolutely fine with 10 or 100 times the per-packet latency.
As long as there is a reasonable bound on how much faster a quick, expensive packet is than a slow, cheap one- say, not more that 100 times slower- QoS won't block any people out from using the internet, and it'll make it cheaper and easier for high-speed users to get going.
Re:Theorem
on
World of Ends
·
· Score: 4, Insightful
So the Internet is destined to fail?
Yes, Doc & Dave have set themselves up to be misinterpreted with those particular headings.
It makes sense if you read the text, and see that "improve it" in item 8 doesn't mean modifing the internet in any way- only modifying protocols that use it.
"Adding value" to the internet, on the other hand, would mean changing the internet itself, which would break old applications, and make it harder to add new apps.
Untrue. That statement works as a punchline for a comic strip, nothing more.
Sure, everyone occasionally feels he could do a better job than the implementer of some library he's using. The more "Freedom" he has to see and modify that library, the greater the chance that he'll either learn he was mistaken, or incrementally improve that library, rather than rebuilding it entirely.
if you let them.
That is a more specific problem- management that is insufficiently engaged, or insufficiently informed.
Back when that guy was proposing his idea, his boss should've made him explain why it was better than each of those alternatives.
However, had he been forced to justify the cost of a reinvention, his case would've been doubly strengthened because of the prevalence of proprietary software:
A) "We can't use those things, they are owned." Whether or not that's true in a particular case, people make those assumptions, and think less about reuse than the might. Even the TCL webpage doesn't explain that it's free to use on the first 2 layers of links.
B) "We shouldn't use those things, because then we wouldn't own our changes." "Hey boss, a proprietary scripting language, all our own- won't that be an asset for the corporation?". Many organizations put too much weight on the value of restricting their code. (And even if that is beneficial for those corporations, it might not be the best for the world at large)
In the beginning, car designs were very simple, but it didn't matter, because no-one without vast amounts of capital could afford to build a factory, so the design was safe.
If IP violations were difficult back then, how come inventors needed to be issued patents?
Comparing the IP situation today and 100 years ago is basically fruitless. So many variables have changed that, depending on what you focus on, you can argue for any answer you want. Following is an argument that patents are less necessary today:
In the beginning, manufacturing anything was difficult, unless you had vast amounts of capital and could afford a factory.
So a small inventor who bolted together a new car design was at risk for a big company to mass-produce the idea before he could. Therefore patents were needed to protect him (and force Ford to license, not "steal").
To beat an established manufacturer to market, a lone inventor would need either a factory + distributors + salesmen ($1,000,000 in 1903 dollars, say), or a patent ($50 for the attorney's time). So the patent is 20,000 times cheaper, a much better bargain for the innovator, and thus better for society.
Today, especially in fields like software, the capital investment needed to start mass-producing a product is much smaller. Roughly, shareware publication of software needs $500. Commercial (pay-per-download) can start from $5000. And publishing a Free Software program costs much less than $50.
However, the price to get one patent is around $1000 of lawyer's time- and more importantly, today's IP landscape is so interconnected that you'd probably need a lot more than one. (And some of those you'd have to license from existing companies.
So now look at the modern cost ratio of patents and patent alternatives. It floats around the 0.05 - 5 range, much less than the 20,000 computed earlier. So, the value for patents as a means of protecting software inventions in 2003 is much less than what they provided to an automotive invention in 1903.
The public should reconsider if such patents are really giving them any benefit at all.
(Yes, any of my individual numbers is easily disputable. But I believe that altogether, each of them is plausible enough)
therefore everyone else must be denied the right to make money from software
It is not "everyone", but "most everyone" who should be denied this profit, because they're not adding to the sum of human knowledge. The majority of proprietary software development (80% would be a conservative estimate) is re-implementations of something that has already been done elsewhere.
If most (or all) software were Free, then redundant development would occur more rarely, and only when the programmer thought he could do a better job, not just an equivalent one.
This would raise the bar for a career as a programmer, and drive many ex-programmers into technical support (where they'd still generate the occasional patch or config file). And we'd all be better off.
I've seen lists of US top patenters, but don't know where they all are.
However, for an international perspective, you might look at the biggest patent-earners in the UK (primarily Japanese tech firms). It's on the last page of this PDF.
(And, it's a few years old...)
Quite strange that IBM doesn't show up there at all, when we know that domestically, it gets more patents than Kodak. (right?)
There is already a penalty of sorts- any corporation victimized in this way will get a big overtime bill from their IT department as it patches the holes and audits the damage. They also claim to lose revenue for the period the systems were offline.
Look at the huge dollar amounts of "damage" that companies quote when they suffer a "hacker attack". Those are big losses- it must be some kind of punishment.
Now, one might say that amount of punishment isn't a sufficient deterrent against poor security, because corporations so far haven't invested enough in prevention.
Are there approaches the government could take to increase the magnitude of that punishment? Yes, two ways:
Declare that knowingly running an insecure server is a public safety violation. Fine administrators who do this. (This requires more effort from police and lawyers. Maybe someday it will happen)
Spend less government effort pursuing "hackers", and reduce the legal repurcussions once they're caught. This would permit freelance hackers to mete out more punishment towards insecure corporations by attacking them more often. (This reduces the current government expenditures on enforcement and prosecution. But, it'll never happen)
1987 was when "everything" became copyrightable- at that time, the Berne convention made copyrights apply similarly across most of the globe. Previously, there were all sorts of loopholes where a person in one nation could ignore copyrights registered elsewhere.
But yes, from a US-centric viewpoint, the Copyright Act of 1976 was the big change.
Anyway, no characters are not copyrightable. Check out, among other things, Copyright circular 44 at the US Copyright Office. Names are not copyrightable; they belong under trademark law. A
How can names of fictional people be trademarked? The circular you reference doesn't say that characters can be trademarked. It says they "may". And by trademark law, they may, if they are used to identify goods (such as the title of a comic strip, or branded merchandise).
A trademark is a word, phrase, symbol or design... that identifies and distinguishes the source of the goods of one party from those of others.
That's all. "Characters" don't fit there at all.
Now, back to Circular 44. It never says "characters can't be copyrighted"- it says "the idea of a character can't be copyrighted". That's just to stay consistent with copyright law as a whole, which claims "Ideas cannot be protected, only their embodiments".
Rather than trying to pick apart a distinction between "character" and "idea of a character", lets just check how the legal system in the past 20 years has treated it. You can open a newspaper today and read about the upcoming movie "LXG", which features a team of "public domain characters"- except for one of them. The Invisible Man was Hawley Griffin originally, but it turns out the copyright is still in effect some places, so the movie renamed him Rodney Skinner.
Here's a TOC for a law review, with articles claiming characters can become public domain (implying they were once copyrighted).
specific description of a character may be part of a copyrighted work, BUT the character qua character is more of an idea, and thus not copyrightable either.
For any reasonable legal purpose, characters go out of copyright when the work they were first published in does.
Yes, but wouldn't confusion NATURALLY occur as a result of using MM?
No.
Well if everyone on Earth can freely copy MM, how can Disney possibly allege that they're a unique source for him?
They can't. Neither can Apple computer claim that a fruit, or pictures of a fruit, is uniquely from them. But if you use an Apple to refer to a corporation, or to a computer, then you're infringing.
If Mickey Mouse was PD, it would be just like any other PD concept which has been incorporated into a trademark.
The existince of a PD Mickey would've weakened Disney's trademark in a few places (those limited areas where confusion can occur), and that's why they made sure the copyright will never end.
That would mean that there is essentially only one software company. One organization who is the gatekeeper to writing any program.
Would it really be good if Microsoft, Apple, IBM, NeXT, Be, Gnome, and KDE all had to go through Xerox for permission to write a UI? It would be bad for everyone except Xerox stockholders.
Xerox made a business mistake when they licensed to Apple that cheaply (although prehaps they hadn't expected it to stand up in court anyway). If copyright on user interfaces had turned out to be legal, you can be sure they would've started charging much larger fees from then on.
How the hell do you make sure a company doesn't have an idea anymore?!
You can't take away the idea. You can, however, "steal" intellectual property, if you manage to take away their right to use the idea. Sneaking into an inventor's lab, photographing his notes, and then patenting them before he does is one way to accomplish this.
If Microsoft had found a way to patent or copyright any ideas they learned from Apple, that would've been theft.
(More realistically, big companies have occasionally stolen ideas from artists who were applying for jobs- copying something from his portfolio, and assiging an employee to make a new version)
but Theft of Service is a real offense
1. Notice how they had to define a new category, "Theft of Service", rather than using existing laws against theft? That's because it's not theft. It's a little like "War on Drugs", which is not war. (I don't even have to mention software piracy) 2. In the case of "stealing service", it is a little like theft. You have occupied some of the limited space on the other side of the turnstile. Fewer paying customers can enter the train or theater because of that. So some capability was removed from the victim.
Sneaking into a theater is wrong and illegal (as is entering carrying food), but by no stretch of the English language can the perpetrator be called a "thief".
That's a fun method. I don't see how it would work if things like "endl" were injected into the stream (or other functions/constants which return an ostream), but you probably just omitted that kind of detail. However
3. The compiler should optimize out the "log" variable if debugging is turned off, but leave the "side effects" (e.g., "++i" in the above example).
An interesting technique, and I see it offers protection against someone accidently changing program behavior when log outputters have side effects. But, they shouldn't be doing that.
Depending on side effects is sometimes a bad idea- especially if those side effects occur in a line that is primarily user-visible output. Suppose a someone decides the log doesn't need to show the value of "i" anymore. He's got to move the ++i somewhere else.
If the ++i is needed for the function to be correct, I really think it should be kept away from the logging message. (There remains a moderate chance that a person pursuing a bug will want to see the log output from some functions, but not all of them, and will just throw "//" in front of those messages he doesn't want. Then the side-effect is gone again)
As far as "compilers should optimize it out": many C++ compilers optimize less than it seems they should, especially if the classes are in separate object files. Keeping logger in a h++ file avoids that, and hopefully the compiler will notice when it is by inlining an identity function and remove it completely.
About the only thing it might not optimize is the 1-4 bytes of extra stack used for the play_logger in each function. (Even though the object has no members, it still needs some space, if methods will be called on it). That won't matter to anyone with a "real" computer.
the current corporate mindset seems to be `patent everything, let the courts sort it out'
Absolutely. Ever since the big Kodak v Polaroid case, that's how they've acted. Kodak learned from their expensive defeat (the $925,000,000 settlement was just a fraction of their losses), and today it patents anything it can think of, without any consideration of them ever being workable or useful. (The bottom of this page gives the top 20 patenters, Kodak is one)
The authors of ICQ had at least as good a chance of getting a patent as any silly one-click shopping `inventors'.
Not really. Getting patents effectively requires thousands of dollars for lawyers. One-Click was "invented" by Amazon.com, a major corporation that, while not profitable, had barrels of funding to burn.
Mirabilis was four 20-something guys with a good idea. Much less likely they could've afforded to push through a patent on a software idea (especially since the patent would've been flimsy anyway, with so many programs resembling prior art already well known)
Slashdot Mirror
As an AC said, it is quite possible to alter software on your local machine and abuse "small packet preference". That would have the dual damages of breaking the intent of the system- but also, the smaller packets will increase the header:content ratio, bringing a greater percentage overhead onto the network.
(There are techniques one could attempt to combat such abuse. Much experimentation has gone on in this area. For example, build routers with multiple layers of queues intended for packets of different sizes or priorities, so that lower priority packets have more total space, and are less likely to be dropped. That system might allow applications to work which are either high bandwdith or low latency, but not both)
Additionally, some applications needing low-latency might still use big packets: videoconferencing, or something. (A VC protocol might tend to feel out the bandwidth available, using larger and larger packets until they start to be dropped, then stick with the large size).
Existing TCP relies on some trust between users, so that one person doesn't hurt everyone else to speed himself up. The "short packet preference" idea is even more fragile that way. I'm not sure we can continue to rely on that in the future.
Networks have 3 states:
Free markets are unstable.
They are stabler than any other economic system yet attempted.
We require stability in our network protocols.
We don't have it today, yet are proceding swimmingly.
Not if the network is congested.
That is not the common case optimizations should be targeted for. Congested states should be rare- plan to avoid them, not discard other plans because they'd have flaws during it.
If a network gets overloaded in the face of FTP-like uses, then it needs to be upgraded, that's not disputed. (Otherwise, setting the priority flag won't help any individual once everyone starts to do it)
Networks designers should aim to leaving a portion of their bandwidth free in normal use. It's in situations with utilization of 30%-40% or so that QoS flags are really helpful. They'll insulate interactive streams from being disrupted by the occasional 3MB file download.
Simply going ahead and upgrading every single link to be high speed, high bandwidth- without an opportunity to differentiate price for different applications- will encourage users to saturate the lines. ("Leave streaming music videos on all night long? Why not?"). Then we're back to the case of the data which truely needs low-latency not getting it... and another expensive cycle of all-around upgrades begins again.
This is a "defense of the commons" problem. To allow the free market to automatically solve the problem of consumers requesting more than they need, we need a mechanism to allow some variation in price for using the service. With that capability in place, the Invisible Hand will choose an effective incremental cost.
In the future, paying internet users will be better off if they can be charged less for a 1 gigabyte music broadcast than for 1 gigabyte of videophone traffic. The latter application is more vulnerable to small changes in congestion, so it should be able to offer the network more money to protect it. Applications not needing that service shouldn't need to pay for it.
They all can benefit from a minimum guaranteed bandwidth/improved latency/improved jitter; especially audio streaming.
Audio streaming is the textbook example of a high bandwidth, high-latency application. Latency only matters if timeouts/ACKs are important, and they only matter if packets are being dropped. And if that's happening, it's a separate, major problem, which should be fixed on its own.
It's not as simple as that though; otherwise I would hack my protocol stack to stick 'fast' on all my packets. My ftp downloads will fly
I guess you skipped reading my post. It was all based on the ISP charging a higher fee for faster packets!
Anyone who hacks his FTP client to request low latency will boost his usage charges, and recieve the total file in 24:36.67, instead of 24:38.12 for a normal connection (for one representative set of numerical assumptions). 1 whole second faster.
If a user feels that's an acceptable use of money, fine.
Also, when I used "fast packets" above, I was referring primarily to latency, which is different from bandwidth. You seem to be focusing on bandwidth, which is unrelated to QoS, and isn't what I was discussing. Here's a discussion about bandwidth vs latency, if you need a refresher.
If an ISP allows QoS flags to indicate that some packets need improved latency, it doesn't have to change that user's bandwidth limits at all. Regardless of the latency setting, he can still only send 150kB/s (or whatever the speed is). But, these packets will "skip over the line" at routers on his ISP (and cooperating network providers, which eventually will be most of them). They will arrive at the destination in only 25 milliseconds, insteal of 100.
That means if he's talking on the phone, or aiming a railgun at a gladiator, the response time for updates is 25% of what it had been. Yet the total data rate he can transmit remains the same.
QoS for low-latency doesn't help FTP at all. Email, IM, HTTP, and audio streaming likewise recieve no benefit. There is no incentive to request QoS for those applications. Only a few uses- voice chat, remote desktop, and gaming- can get much benefit.
For copyright, under American law, you need to enfore it as soon as you are aware of the breach
It's trademark violations that you must pursue as soon as it's discovered. Copyright and patent can wait a while.
Although, the longer you wait, the more sympathy the jury will have for the accused. In court, it's best if you can prove that you warned him early and often, before bringing suit.
The very rich are almost always going to be better off than anyone else, that's unavoidable.
If your structure resists preference, the rich will insist that it's good for everyone so it will be good for them.
Or they'll just hire someone to build a completely separate structure. That'll deprive my structure of the resources they might've contributed to improving it.
There is already a tendency for this today- large companies are transitioning their voice and videoconference systems on IP networks. But they often don't put it on the public internet, or even the same IP network their workers use for desktop applications- they actually fund separate networks just for their chat traffic.
That kind of massive oversupply of bandwidth assures them that they'll have low latency connections when they need them- but they're not using them all the time. All those mighty routers sit quietly at night, helping neither their employees, nor the general public.
If IP supported some kind of QoS tag, then these users might be able to meet the needs of real-time videoconferencing simply by spending $1000 to upgrade the routers on their LAN, rather than $10,000 to build a whole different network. And they'd reap many flexibility benefits.
It's a "big tent" philosophy. The rich will want to spend money to go faster. The Internet can either find a way to take their money, or drive them away to build a competitor, which the poor won't be able to access at all.
The fact is: not all packets need to be quick. For some applications, 3 seconds of delay is absolutely fine. For others, 3 milliseconds is unbearable.
If the internet acknowledges this fact, it becomes a little more complicated, but much more powerful. And it wouldn't be a flag day change- the upgrade can be piecemeal.
(Today, some people already abuse the bandwidth-conserving principles of TCP and HTTP to accelerate their own transmissions, at the expensive of everybody else. QoS tags would provide a legitimate way to do this, without interfering with other packets so much)
This has much less to do with ICBM (usually Nuclear)
The ABL has been mentioned as an eventual component in not just Theater Missile Defense (over a battlefield), but also the National Missile Defense system.
The intent is to keep these aircraft flying continual patrols from a base in South Korea. If sensors (on another aircraft, also continually patrolling) detect a blast like an ICBM takeoff, the laser will be fired at the rocket.
It's called Boost Phase Intercept.
Only if a rocket evades the ABL is will interceptor "kinetic-kill vehicles" be fired at it. (This is the NMD component whose questionable testing procedures have been been all over the news)
Here's a report from when the US cancelled the treaty.
I'd think that tabs could break many web applications- or at least increase the chance of a user giving input the app didn't expect.
For instance, if you're on page 4/5 of requesting a service, and then go back to page 2 (still open on a tab) and submit it, what's the application do then? Page 4 is already open, but it may have just been invalidated.
It won't bother all applications of course. Particularly if all inputs are single step (like a "Shopping cart"), or all but one of the tabs are used for informational purposes only.
What is more of a debate where I work is if pagination is better than scrolling.
Scrolling is better for the user for almost every reason- however, it's worse for control-freak web-publishers. Sites like Salon want to be able to tell which kinds of stories are attractive towards their readers, and they'd like to distinguish between stories that are merely downloaded, and those that actually get read. Requiring the user to make another HTTP request to see the end of a story provides them this data.
(Essentially, they wish HTTP were a stateful protocol- maintaining a live connection for as long as the reader is on the page- and pagination makes HTTP requests more frequent, bringing that goal a step closer)
Latency mostly comes from the protocols placed on top of IP, such as TCP.
It's true that TCP adds a kind of latency when it stops to wait for a retransmission. But UDP messages on their own have a lot of latency. For most users, most of that latency comes from the first mile and last mile links (especially if they're on dialup).
However, there are sources for latency deep inside the internet as well. Congestion. Actually, the most commonly damaging form of congestion is when someone else on your subnet is making a large download or streaming radio, and you want to run an interactive (VNC or SSH) session.
A non-FIFO router protocol might help alleviate this. It could recognize that the 95% of packets beloning to a big download can afford to wait until the VNC user's mouse-updates have gotten through.
I don't think there is a good way to prioritize packets.
There might be. It could be as simple as a single bitflag for "normal/fast". We'll never know unless we try. And we can't try until packets have a way to indicate desired QoS (the IPv6 "flow label", for instance), and more importantly, users enjoy some financial benefit, however small, for selecting reduced priority for their data.
Of course, there are other things which need to be fixed with the internet before it presents a fair place to test QoS. In particular, firewalls and NATs already block some of the applications which could best make use of QoS, so until they're removed, there'd be little point in doing the experiment.
I agree that widespread adoption of Microsoft-controlled .NET opens a doorway for abuse.
.NET only involves adding new applications to hosts at the Edges. There's no plans for it to change the way routers handle packets, which is what a "change to the internet" would imply.
.NET, they'll need to transition it away from the real internet, and either create an alternative, "value-added" network, or fund the deployment of ".NET support servers" inside major IP backbones.
However, from a simplistic Internet-centric perspective, implementing
Yes, it is possible that someday in the future, Microsoft will decide that to optimize
Filtering contents adds value, right?
ISP level filtering is one of those things which some people think adds value to the internet, but really damages it. Host-level filtering, however, is a voluntary, application-level process which the host can disable at any time. This is why improvements to the internet should come at the application level (where they can be easily changed and removed if they turn out to have downsides), rather than deeper in the network (where it's harder to convince the sysadmins that you need changes made to do your work).
(Host-level filtering may still be damaging in some cases, such as in a library whose users are forbidden from modifing local software. But that is a separate issue)
Music downloads adds value, right?
From the Internet's point of view, music downloads are "just another file transfer application". They are beyond the scope of section 4. They "improve" the internet by providing another use at the ends. But, as you may have noticed, DRM-based music downloads aren't very popular yet. That's because, as the authors suggested, non-open protocols lack explosive popularity.
an even more fragile piece of DRM-crap
I think that the majority of music-downloaders still manage to find non-DRM files. Not as much as when Napster was running, but it still seems that most music downloads wind up as MP3 files on multiple, redundant CDRs.
Hypothetically, the RIAA might someday propose modifying the internet to make their music transfers more secure, and that would be bad.
(If they could push DRM onto 80% of newly manufactured PC hardware, that would be very bad for other reasons)
Firstly, the phrase "destined to fail" was introduced by a poster, neither did the "World of Ends" article nor myself said anything about that. The article said that abusing the internet's founding principles would be bad, but didn't claim it would be impossible. A sufficiently wrongheaded government, backed up with public fear and acquiesence, could close down the internet and replace it with a regulated, censored information utility.
.NET protocols are open enough to be non-dangerous. And, depending on who's in the Whitehouse in 2005, an attempt to leverage desktop software dominance into control of a new data-communication monopoly could land Microsoft in more serious legal trouble than they've ever had before.
.NET is an application at the edge of the cloud, not in the center of it, and thus falls under section 8c "Anyone can improve it", rather than section 4 "Adding value lowers value".
It also might be possible for Microsft, through careful leveraging of monopoly powers, to force all their users to change to closed, proprietary protocols, cutting them off from much of the internet's value.
Opinions are divided on whether they'll actually try this. Some people claim that
However, in terms of the "World of Ends" article,
Today, many so-called internet users have their access mediated by firewalls and NAT. This reduces the set of internet services available to them.
(I'd even say, as a slight exaggeration, that their ISPs had engaged in false advertising by calling it "Internet Access")
By the original definition of the internet, anyone with access (control of one host) could send packets to any address:port combination, and open any port to inbound connections.
This means that everyone with internet access should be able to run an HTTP, FTP, or UT server. But many people are prevented by their ISP's routing policies.
Firewalls and NATs supposedly "add value" to the internet by making it safer for some users. But it's not made a lot safer (worms get through even today), and it has "lowered value", because creating new applications is more difficult. For example, today there is a movement towards SOAP; XML-RPC. Unfortunately, one of the motivations to promote it is to allow arbitrary, application-specific traffic to travel over port 80. To work around firewalls which only permit HTTP, we're starting to see a legitimization of tunneling commands over HTTP.
(I'm not saying that was the original goal of SOAP- but sneaking around firewalls is one reason that some developers are eager to try it)
So there's an example of why "adding value to the Internet" is generally bad.
However, there are cases where it may be good. We all know that IPv6 will be a postive (someday). Multicast extensions to the internet were developed well after it was first created, and are generally accepted as a good thing, although their deployment so far is well short of universal. Multicasting is a superset of existing internet functionality (assigning a single packet to be destined to multiple recipients).
Multicasting may turn out to have downsides, depending on how it's implemented (and I haven't followed development closely enough to be sure what the direction is). If it creates an unfair environment, where large corporations (CBS, MTV, RIAA) can create multicast streams, but individual users cannot, then it will cement inequality and make internet use move closer to resembling traditional television viewing. I feel justified in hoping this won't happen, however.
And QoS (quality of service) is a debatable issue, not a flat-out bad one like the article suggests. IP, the existing internet protocol (not to be confused with Intellectual Property), makes no guarantee that packets will arrive quickly or in order. It doesn't state that packets will travel at the same speed as each other. It doesn't even state that a packet which is sent will ever arrive, only that the network make a "best effort" at getting it through someday.
Since IP makes no guarantees of transmission speed, adding an optional mechanism to request QoS efforts won't break the existing protocol definitions. Yes, it may disturb some people to consider that internet packets, which used to be fair and unbiased, may someday have preference given to them based on the sender's bank account- but look at the alternative:
Basically, there are only a few internet applications which really need low-latency response: speech, video, gaming, and maybe some forms of web browsing. Everything else, especially emails and big downloads over HTTP or FTP, would work absolutely fine with 10 or 100 times the per-packet latency.
As long as there is a reasonable bound on how much faster a quick, expensive packet is than a slow, cheap one- say, not more that 100 times slower- QoS won't block any people out from using the internet, and it'll make it cheaper and easier for high-speed users to get going.
So the Internet is destined to fail?
Yes, Doc & Dave have set themselves up to be misinterpreted with those particular headings.
It makes sense if you read the text, and see that "improve it" in item 8 doesn't mean modifing the internet in any way- only modifying protocols that use it.
"Adding value" to the internet, on the other hand, would mean changing the internet itself, which would break old applications, and make it harder to add new apps.
Do you work with many programmers?
Yes.
All of them think they can do a better job,
Untrue. That statement works as a punchline for a comic strip, nothing more.
Sure, everyone occasionally feels he could do a better job than the implementer of some library he's using. The more "Freedom" he has to see and modify that library, the greater the chance that he'll either learn he was mistaken, or incrementally improve that library, rather than rebuilding it entirely.
if you let them.
That is a more specific problem- management that is insufficiently engaged, or insufficiently informed.
Back when that guy was proposing his idea, his boss should've made him explain why it was better than each of those alternatives.
However, had he been forced to justify the cost of a reinvention, his case would've been doubly strengthened because of the prevalence of proprietary software:
A) "We can't use those things, they are owned." Whether or not that's true in a particular case, people make those assumptions, and think less about reuse than the might. Even the TCL webpage doesn't explain that it's free to use on the first 2 layers of links.
B) "We shouldn't use those things, because then we wouldn't own our changes." "Hey boss, a proprietary scripting language, all our own- won't that be an asset for the corporation?". Many organizations put too much weight on the value of restricting their code. (And even if that is beneficial for those corporations, it might not be the best for the world at large)
In the beginning, car designs were very simple, but it didn't matter, because no-one without vast amounts of capital could afford to build a factory, so the design was safe.
If IP violations were difficult back then, how come inventors needed to be issued patents?
Comparing the IP situation today and 100 years ago is basically fruitless. So many variables have changed that, depending on what you focus on, you can argue for any answer you want. Following is an argument that patents are less necessary today:
In the beginning, manufacturing anything was difficult, unless you had vast amounts of capital and could afford a factory.
So a small inventor who bolted together a new car design was at risk for a big company to mass-produce the idea before he could. Therefore patents were needed to protect him (and force Ford to license, not "steal").
To beat an established manufacturer to market, a lone inventor would need either a factory + distributors + salesmen ($1,000,000 in 1903 dollars, say), or a patent ($50 for the attorney's time). So the patent is 20,000 times cheaper, a much better bargain for the innovator, and thus better for society.
Today, especially in fields like software, the capital investment needed to start mass-producing a product is much smaller. Roughly, shareware publication of software needs $500. Commercial (pay-per-download) can start from $5000. And publishing a Free Software program costs much less than $50.
However, the price to get one patent is around $1000 of lawyer's time- and more importantly, today's IP landscape is so interconnected that you'd probably need a lot more than one. (And some of those you'd have to license from existing companies.
So now look at the modern cost ratio of patents and patent alternatives. It floats around the 0.05 - 5 range, much less than the 20,000 computed earlier. So, the value for patents as a means of protecting software inventions in 2003 is much less than what they provided to an automotive invention in 1903.
The public should reconsider if such patents are really giving them any benefit at all.
(Yes, any of my individual numbers is easily disputable. But I believe that altogether, each of them is plausible enough)
therefore everyone else must be denied the right to make money from software
It is not "everyone", but "most everyone" who should be denied this profit, because they're not adding to the sum of human knowledge. The majority of proprietary software development (80% would be a conservative estimate) is re-implementations of something that has already been done elsewhere.
If most (or all) software were Free, then redundant development would occur more rarely, and only when the programmer thought he could do a better job, not just an equivalent one.
This would raise the bar for a career as a programmer, and drive many ex-programmers into technical support (where they'd still generate the occasional patch or config file). And we'd all be better off.
If this is a genuine patent infringement case, then you don't need any inside knowledge to infringe.
You just read the patents from uspto.gov (or even re-invent the idea yourself), use it in Linux, and you've violated.
However, the linked news reports don't say that SCO is filing a patent claim- it looks like the Slashdot submitter inserted a bit of misinformation.
I've seen lists of US top patenters, but don't know where they all are.
However, for an international perspective, you might look at the biggest patent-earners in the UK (primarily Japanese tech firms). It's on the last page of this PDF.
(And, it's a few years old...)
Quite strange that IBM doesn't show up there at all, when we know that domestically, it gets more patents than Kodak. (right?)
There is already a penalty of sorts- any corporation victimized in this way will get a big overtime bill from their IT department as it patches the holes and audits the damage. They also claim to lose revenue for the period the systems were offline.
Look at the huge dollar amounts of "damage" that companies quote when they suffer a "hacker attack". Those are big losses- it must be some kind of punishment.
Now, one might say that amount of punishment isn't a sufficient deterrent against poor security, because corporations so far haven't invested enough in prevention.
Are there approaches the government could take to increase the magnitude of that punishment? Yes, two ways:
1987 was when "everything" became copyrightable- at that time, the Berne convention made copyrights apply similarly across most of the globe. Previously, there were all sorts of loopholes where a person in one nation could ignore copyrights registered elsewhere.
But yes, from a US-centric viewpoint, the Copyright Act of 1976 was the big change.
Anyway, no characters are not copyrightable. Check out, among other things, Copyright circular 44 at the US Copyright Office. Names are not copyrightable; they belong under trademark law. A
How can names of fictional people be trademarked?
The circular you reference doesn't say that characters can be trademarked. It says they "may". And by trademark law, they may, if they are used to identify goods (such as the title of a comic strip, or branded merchandise).
Here's the definition of trademark:
That's all. "Characters" don't fit there at all.
Now, back to Circular 44. It never says "characters can't be copyrighted"- it says "the idea of a character can't be copyrighted". That's just to stay consistent with copyright law as a whole, which claims "Ideas cannot be protected, only their embodiments".
Rather than trying to pick apart a distinction between "character" and "idea of a character", lets just check how the legal system in the past 20 years has treated it.
You can open a newspaper today and read about the upcoming movie "LXG", which features a team of "public domain characters"- except for one of them. The Invisible Man was Hawley Griffin originally, but it turns out the copyright is still in effect some places, so the movie renamed him Rodney Skinner.
Here's a TOC for a law review, with articles claiming characters can become public domain (implying they were once copyrighted).
And here's even a few slashdot articles mentioning characters that've gone in and out of copyright.
specific description of a character may be part of a copyrighted work, BUT the character qua character is more of an idea, and thus not copyrightable either.
For any reasonable legal purpose, characters go out of copyright when the work they were first published in does.
Yes, but wouldn't confusion NATURALLY occur as a result of using MM?
No.
Well if everyone on Earth can freely copy MM, how can Disney possibly allege that they're a unique source for him?
They can't. Neither can Apple computer claim that a fruit, or pictures of a fruit, is uniquely from them. But if you use an Apple to refer to a corporation, or to a computer, then you're infringing.
If Mickey Mouse was PD, it would be just like any other PD concept which has been incorporated into a trademark.
The existince of a PD Mickey would've weakened Disney's trademark in a few places (those limited areas where confusion can occur), and that's why they made sure the copyright will never end.
That would mean that there is essentially only one software company. One organization who is the gatekeeper to writing any program.
Would it really be good if Microsoft, Apple, IBM, NeXT, Be, Gnome, and KDE all had to go through Xerox for permission to write a UI? It would be bad for everyone except Xerox stockholders.
Xerox made a business mistake when they licensed to Apple that cheaply (although prehaps they hadn't expected it to stand up in court anyway). If copyright on user interfaces had turned out to be legal, you can be sure they would've started charging much larger fees from then on.
How the hell do you make sure a company doesn't have an idea anymore?!
You can't take away the idea. You can, however, "steal" intellectual property, if you manage to take away their right to use the idea. Sneaking into an inventor's lab, photographing his notes, and then patenting them before he does is one way to accomplish this.
If Microsoft had found a way to patent or copyright any ideas they learned from Apple, that would've been theft.
(More realistically, big companies have occasionally stolen ideas from artists who were applying for jobs- copying something from his portfolio, and assiging an employee to make a new version)
but Theft of Service is a real offense
1. Notice how they had to define a new category, "Theft of Service", rather than using existing laws against theft? That's because it's not theft. It's a little like "War on Drugs", which is not war. (I don't even have to mention software piracy)
2. In the case of "stealing service", it is a little like theft. You have occupied some of the limited space on the other side of the turnstile. Fewer paying customers can enter the train or theater because of that. So some capability was removed from the victim.
Sneaking into a theater is wrong and illegal (as is entering carrying food), but by no stretch of the English language can the perpetrator be called a "thief".
That's a fun method. I don't see how it would work if things like "endl" were injected into the stream (or other functions/constants which return an ostream), but you probably just omitted that kind of detail. However
3. The compiler should optimize out the "log" variable if debugging is turned off, but leave the "side effects" (e.g., "++i" in the above example).
An interesting technique, and I see it offers protection against someone accidently changing program behavior when log outputters have side effects. But, they shouldn't be doing that.
Depending on side effects is sometimes a bad idea- especially if those side effects occur in a line that is primarily user-visible output. Suppose a someone decides the log doesn't need to show the value of "i" anymore. He's got to move the ++i somewhere else.
If the ++i is needed for the function to be correct, I really think it should be kept away from the logging message. (There remains a moderate chance that a person pursuing a bug will want to see the log output from some functions, but not all of them, and will just throw "//" in front of those messages he doesn't want. Then the side-effect is gone again)
As far as "compilers should optimize it out": many C++ compilers optimize less than it seems they should, especially if the classes are in separate object files. Keeping logger in a h++ file avoids that, and hopefully the compiler will notice when it is by inlining an identity function and remove it completely.
About the only thing it might not optimize is the 1-4 bytes of extra stack used for the play_logger in each function. (Even though the object has no members, it still needs some space, if methods will be called on it). That won't matter to anyone with a "real" computer.
I forgot what we were talking about
Nothing in particular, actually.
the current corporate mindset seems to be `patent everything, let the courts sort it out'
Absolutely. Ever since the big Kodak v Polaroid case, that's how they've acted. Kodak learned from their expensive defeat (the $925,000,000 settlement was just a fraction of their losses), and today it patents anything it can think of, without any consideration of them ever being workable or useful. (The bottom of this page gives the top 20 patenters, Kodak is one)
The authors of ICQ had at least as good a chance of getting a patent as any silly one-click shopping `inventors'.
Not really. Getting patents effectively requires thousands of dollars for lawyers. One-Click was "invented" by Amazon.com, a major corporation that, while not profitable, had barrels of funding to burn.
Mirabilis was four 20-something guys with a good idea. Much less likely they could've afforded to push through a patent on a software idea (especially since the patent would've been flimsy anyway, with so many programs resembling prior art already well known)