Pirating software is like taking a picture of a chair, and then being able to use the picture as if it were a chair.
It's not like stealing a chair. Rather it is denying the original chair-maker a *potential* sale. This is not the same thing as denying him a sale (restraint of trade), any more than going into business as a competing chair-maker.
Clearly, it's a copyright violation. But attaching penalties above and beyond those that arise from the act of infringement itself is really hard to justify: if you take a chair, it is gone: that's stealing. If you take a picture of a chair, and the chair is still there, you haven't stolen the chair.
Violation of copyright is not theft: it is violation of copyright.
What part of "a unique email count" don't you understand?
If implemented correctly, the system could not be influenced by SPAM.
In any case, it's not going to change the Democrat/Republican voter ratio, so getting rid of one Democrat won't achieve anything except getting a different Democrat in power, if you live in a predominantly Democrat district. The converse is true for a predominantly Republican district.
Only an idiot would rotor through opposition candidates this way: "better the evil you know".
You elect someone for their judgement, not their positions on particular issues.
If you felt compelled to send your congress-person a letter, then it was because the issue was important to you, and you didn't trust their judgement on the matter enough to not explicitly voice your opinion in an attempt to sway their judgement from what you expected it to be, instead of what you wanted it to be.
Do you really want to reelect someone whose judgement you don't trust?
Do you really want to reelect someone whose judgement is so fickle that a letter-writing campaing can effect it?
No matter how you look at it, the congressperson with the most letters should probably not be reelecte.
Perhaps you can deal with galvanizing issues by having a +1 on one side and a -1 on the other, and taking the absolute value. However, if those issues are truly galvanizing, then they should result in the same level of interest, generally, meaning it's a wash: a rising tide lifts all boats, so a congressperson need not fear a galvanizing issue will lif their head up for the chop.
If everything is over IP, then you can guarantee at least transport level interoperability with everything. That lets you do things like access mapping services or locale aware restraunt guides, etc., without having to gateway the content.
It also gets around the price differential for long distance service, and further commoditizes the pipe providers as just that: pipe provider, rather than toll-booths that bill based on destination.
Back in the DNSEXT (the IETF working group on DNS), there were a lot of cell phone providers who wanted to assign an IP address to every telephone, making it directly addressable from an outside server.
Among other things, this would let them push content to your phone, based on having a phone/IP identity, so that the phone could be contacted directly.
The downside of this is that they are not really planning on forcing the use of IPv6, and the IPv4 address space actually has too little remaining space for there to be the possibility of assigning an IPv4 address to every cellular telephone in existance.
So while convergence is attractive for the cell phone vendors, and the local carriers (neither of which who could care less if the long distance providers continued to make money, other than as flat rate pipe providers), it's unlikely to avoid the issues of having to have a gateway (NAT) device, unless they go IPv6. The current 3G phones in Europe (and the "2.5G" pgones in the U.S. require gateway devices).
FWIW, both Nokia and Ericson engineers were interested in the IP-per-phone idea when the issue came up on the mailing list, so it's likely they will be the first to be pushing the idea in the future.
To paraphrase Tom Hanks as ``Forrest Gump'', "Buzzword is as buzzword does".
"At the same time, Linux, one of the flagship products of the open source/free software movement, is such a buzzword that all of these companies - and many others - want to somehow associate themselves with the community."
Yes. For marketing purposes. Not to actually *do* anything productive. And it's about time the Linux people wised up to this fact.
It's like the staunch Democrat, whi won't pass up an opportunity to get his picture taken with the President of the United States, even though that president is a Republican. Or the staunch Republican, who gets his picture taken with Teddy Kennedy, to put on his Christmas cards.
Do these people vote the way that the pictures, now on their desks, would imply that they'll be voting? No.
The entire point of endorsing something that's a darling of the trade press is to get trade press as a result of the reflected glory, that would be more expensive to buy elsewhere, under other circumstances.
Does anyone else find it incredibly ironic that Verisign is blaming Online Data for assinging weak passwords instead of strong passwords, and Online Data is blaming merchants for not changing their passwords?
Online Data, the payment processor, is a reseller of Verisign credit card gateway services.
And Verisign sells digital certificates, which provide authentication, identification, and non-repudiation of data signed with those certificates.
And yet they are relying on passwords, rather than requiring the use of an X.509 certificate for an established security association, so that no client machines other than the ones owned by the merchants themselves can be used to make credit card authorization requests.
And each of these people *has* a certificate in hand, since they have to have one to run an HTTPS (SSL based) server in the first place!
That's a bit like the U.S. Marines deciding to hire school crossing guards to provide the security for Fort Knox, isn't it?
And now they are blaming people for not hiring the right school crossing guards, or not firing olld school crossing guards, and hiring different ones "often enough"...
Or running their own mail server, yes. That's correct.
This is, though, completely orthogonal to your original argument, and I don't think it's a legitimate complaint, even if you come down to lack of choice. As a Californian, you don't have any choice about having the oxygenate MTBE in the gasoline you buy for your car, no matter which gas station you go to, even if your car was manufactured since 1981, and has an Oxygen sensor, causing the fuel to be burned more rich, and actualy causing *more* rather than *less* pollution.
Individual filtering is also not a good answer. Filtering after download multiplies the problem and the amount of computational effort required. It also has you paying message units for the transfer of the unwanted email, if you are using a commercial phone line in the U.S., if you are using a cellular phone, if you have elected that tarrif for your residential telephone connection, or, if you are a European or Japanese user who has no choice in the matter.
Filtering also has the undesirable side effect of everyone having to accumulate their own, potentially very large and expensive to accumulate, undesirable sender list.
Filtering on the server side to avoid the download has these same negatives, as well as increasing the amount of CPU cycles that have to occur at the ISP (at least at the ISP, the cycles are amortized across all users selecting a set of filtering options, instead of being a per user cost). Still, why should I have to pay more for an ISP who has to pay more for compute cycles for more flexible filtering?
The problem comes down to one of unsolicited senders costing a recipient money.
In any case, since you are running your own mail server, you have the choise of whether or not to use a black list. If you don't opt-in to one, then you aren't a member of the class that you are complaining about anyway.
I don't think you have a valid legal argument against black lists, unless you are in fact forced to utilize one as a conditon of not being black-listed (e.g. as Microsoft's Palladium permits, and will inevitably encourage as a result of non-interoperability penalties).
Unlike "sharing" of "marketing information" by credit card companies, telephone companies, and banks, blackhole lists for email ar opt-in.
You have to explicitly subscribe to someone else's judgement in order for it to have an effect on what you block.
Your argument about the putative "RIAA P2P blacklist" is flawed, in that you would have to go out of your way to elect to subscribe to RIAA's judgement.
A much more salient argument might be Palladium, which is effectively a black list of people who do not used Palladium, and which holds you hostage via the use of monopolistic power in the marketplace. A black list which forces you to use it -- which is not "opt-in" -- is much more of a threat.
PS: In your original argument, you had exactly one valid point, which was that the original probe of your email server -- before you asked them to recheck it, thereby giving them permission -- was in fact a criminal trespass on your system. On the other hand, from a legal standpoint, it's probably easy to argue "attractive nuisance" in defense of the original probe, particularly if your mail server had been reported by a third party who had received SPAM via it.
"not from what i see. IMHO, threads makes share things between two processing easier. how can u make a connection pool with many process? and you can do all cpu based work in a group of threads and let one thread do all other i/o based work. These things are impossible with multi process and damn hard with single process FSA."
The classical answer to this is "rfork" or "sfork". But there are others.
As one of the two engineers responsible for adding the ability to share the file table via opening the/proc for the process and setting a flag, so that fork(2) would behave differently in SVR4.2, I can guarantee you that there are other methods of achieving what you want, without threads. Incidently, this greatly pissed off the threads people at USL, because we didn't use their shiny happy application model: it was inappropriate for the problem we were solving.
Like descriptor table sharing, address space sharing, and SMP scalability, threads are a hammer that is applied to a lot of different problems, on the theory that if all you have is a hammer...
Userland threading and blocking calls do not mix, ever.
The way userland threading works is "call conversion", which trades a blocking system call for a non-blocking system call plus a context switch.
FWIW, I worked indirectly on the DEC MTS product on VAX/VMS back in 1992 (indirectly, in that I made patches to the Bliss code as a Novell employee on a cooperative project with DEC), and I used the undocumented "liblwp" in SunOS 4.1.2 in the late 1980's, and before that, I used the "sigsched" package in the mid 1980's. All this adds up to me having experience with implementing call conversion schedulers going on 20 years.
The problem with sendfile(2) is that it sends excessivle large blocks of data all in one go, and that those sends have to be atomic because they are not restartable.
The *obvious* workaround for the problem is to break the call up based on the size of the object being sent, so that the blocking operations don't block "too long".
Another workaround is to have "worker processes", which are used as contexts for the blocking call, to "accomodate" sendfile.
The only canonically *correct* fix is to provide asynchronous interfaces for all synchronous calls, and perform call conversion on them. For sendfile, this either means an aio_ context version, or changing the return value to be the number of bytes out of the range actually sents, and having it work as write(2) does, in terms of non-blocking file descriptors.
By the same token, I could argue that System V message queue receives "should work" -- another patent absurdity, given that such operations are, by definition, synchronous.
I understand the argument; however, it's pretty clear that the practice here has diverged significantly from the theory.
The context in which we are making these postings is an observation about the non-adoption of Apache 2.0, whse design was intended to prevent non-adoption for the reasons you state.
Still, here we are.
I'm fully willing to admit that I'm speaking in hindsight, and trying to analyze why people have failed to adopt Apache 2.0. I understand that non-adoption was not the plan; but reiterating the plan won't make the non-adoption unhappen.
With respect, the benchmarks people have posted have chown a 10-15% performance degradation in the switch from 1.x to 2.x of Apache.
I agree that your argument is valid for SMP systems... but it assumes that the application that's being used is also threaded, or rewritten to be threaded, and that the libraries it uses are also threaded. Whever they aren't, you are going to eat the performance at whatever serialization boundary you put there. It might as well be a standard one that allows legacy code to continue to function as it did before.
Basically, the promise of threads is that you will not be paying the equivalent of a full process context switch overhead, because your VM and other process-specific things will not have to change when context switching from one thread in a process and another thread in a process.
On a machine that has 1001 processes, and you are the 1 process, and you have five threads in your thread group (process), You basically have a 4 out of 1004 chance of one of your threads being picked as the next thing to get a quantum, when one of your threads makes a blocking call, so that it's no longer runnable.
What that means is that you have just reneged on the promise of lower context switch overhead, if you run thread #1, then run "cron", and then run thread #2.
So you have to play favorites, and say "I know "cron" has been waiting a long time, but I just blocked processing on thread #1, and thread #2 is runnable, so I'm going to preferrentially run thread #2, because it lets me avoid the VM switch, and the TLB shootdown, and the other overhead of a full process context switch, and therefore lets me keep my promise about threads being lower overhead than processes".
Any time you play favorites, you starve your non-favorites; just like a Robin or Sparrow with a Cuckoo's Egg in its nest.
So then you have to add all sorts of arcane accounting and other crap to avoid the starvation of other processes, and your scheduler becomes very, very complicated.
Compare this with Scheduler Activations, or an async call gate, where you give a quantum to a process -- and the quantum belongs to that process. In this case, your process runs until either there are no more threads to be run, or until its quantum is used up.
Things are actually more complicated than even this; for example, you want a threaded program to compete as multiple processes for quantum, or you are encouraging people to write programs that fork multiple children, instead of threads, in order to allocate themselves more quantum. On the other hand, you want to set some upper bound on the amount of unfair competition a single unpriviledged program can engage in, relative to other processes on the system.
If you attack thread group affinity as a scheduler problem, the amount of complexity you introduce is substantial, and there will always be corner cases.
There's actually been a huge amount of research on this; check the NEC CS search engine for "scheduling" and "load balancing" and "parallel".
Sendfile is not an operation which it's really valid to have the function return until it's complete, so that completition status will be accurate. The assumption here was that kernel threads were being used, so that one thread calling sendfile would not block execution of other threads until the sendfile was complete.
The assumption of kernel threads here, or that sendfile could call-converted into a non-blocking call plus a context switch to another threads, is what was bogus.
Though it boggles the mind that one would expect sendfile(2) to be POSIX threads safe at all, considering that it's not a system call POSIX standardizes...
I won't argue the legacy code portion of the question; all engineers prefer writing new code to maintaining old code. 8-).
The answer, at least according to me, is that SMP itself is barely a good idea for most OSs, because of scheduler-based CPU affinity implementation. Very few OSs have this right; Sequent (now IBM) and SGI got it right. Everyone else thinks that SMP scalability for Intel breaks down at 4 processors being the point of diminishing returns, but what they are really saying is that they aren't able to address the bus contention scaling issue in software without help.
Hyperthreading puts another tier of preference in there: you don't cache-bust if you move a thread between ALU's in the same CPU, but by the same token, you can't run non-ALU functions simultaneously without stalls.
Basically, this means that you need OS affinity changes, where commercial OSs, and even the free ones, like Linux and FreeBSD already have issues with affinity implementation (Linux implements affinity in the scheduler, leading to the ability of threaded processes to starvation deadlock other processes, but waves a dead chicken to try and work around it, and FreeBSD's implementation is a really rough set of patches that have yet to be integrated).
On top of the OS affinity changes, you have to have compiler help, as well, or the benefit of a Hyperthreaded processor sits at about 20-25% additional, relative to another physical CPU. With compiler help, this "jumps" to an average of 70-75%, relative to another physical CPU.
So basically, it's a relatively cheap way of incrementally increasing performance, if your OS supports the idea. If all CPUs came this way from the factory, then there's a modest win to be had, assuming a direct tie between user space threads and scheduling units. If they don't, then you will pay some penalty on non-Hyperthreaded CPUs, which probably isn't worth the trade-off, if you want to deploy on commodity hardware.
In the Linux case, the person to ask would be Ingo Molnar, who has done much of the work on the scheduler based affinity, and also on the Tux in-kernel HTTP server, and get it and the TCP stack and the minimal driver and data set to live in the confines of a single CPU cache. I don't agree with the approach he has taken in the scheduler, and have discussed it before, but there;s no arguing that it doesn't work, even if I personally think it makes things more complicated than they ought to be.
I think you will find that he will say that the benefit from Hyperthreading in a single CPU machine in that case is no better than perhaps 15-20%, relative to a non-Hyperthreaded processor, which reinforces the idea that the value of Hyperthreading is mostly in the compiler.
Actually, I've heard the Intel documentation on how to write Hyperthreaded code generating compilers described as "Don't do what GCC does", which seems pretty apt to me, all things considered. 8-).
FreeBSD's current threading is implemented in user space, although work is under way to move it into the kernel, that works is being done *ONLY* for SMP scaling and quantum utilization efficiencies.
As it stands, it is fully compliant with the POSIX threads standard.
If it is not working for Apache, it is because Apache is not a POSIX compliant threads client implementation.
From looking at the code, we can see this is the case, with the Apache code having an assumption of kernel threads, which you are not permitted by the POSIX standard to assume.
Although I have not yet verified it, an examination of the code *seems* to indicate that it has "the Netscape problem", which is an assumption about scheduling coming back to a given thread in a group of threads after involuntary preemption by the kernel when the process quantum has expired.
In older versions of Netscape, this displayed as a bug in the Java GIF rendering code, which was not thread reentrant, in that if you used a Java application as a web UI, and moved the mouse before all the pictures were loaded, the browser would crash. After I explained this, Netscape corrected their assumption, and the problem went away.
Ignorance of the requirements for writing threaded applications which will work on all POSIX compliant threads implementations is no excuse, nor is it a valid reason for blaming the host OS, unless you make it known what your requirements are, above and beyond the standard contract offered by POSIX, and that you are stricter than an application written to the POSIX interface, without such additional assumptions.
You will find that you have these same problems on MacOS 9 (NOT FreeBSD-derived), MaxOS X (uses Mach threads), Mach, Plan 9, VxWorks, OpenVMS, etc..
You will find you do NOT have these problems on systems with implied contracts above and beyond those provided by the POSIX standard: Solaris, UnixWare, Windows, and Linux. You may have *other* problems in Windows, related to implied contracts over virtual address space issues (see other posting).
[... sorry for the repost; slashdot doesn't use hidden fields, and so when you preview, the username it displays is not used for the posting, if you have cookies disabled... ]
"Furthermore there is also the fact that not everybody wants to break up their code into a state machine."
That's the "it's easier to do linear programming" camp. I told you, I would not win friends there.
"a much easier time of distributing work to a multi-processor machine"
I granted that, too, but realize that we are talking about a specific type of multiprocessor machine -- the shared memory multiprocessor. That's limited in the number of CPUs that it can scale to, and the current industry trend is toward NUMA based systems, where this type of scaling breaks down.
"I want to be able to do whatever I have to do and not have it interfere too badly with other requests pending."
This is the "I don't want to have to deal with non-blocking operations" argument. This could have been handled in Apache proper, by adding a call conversion mechanism (present a blocking interface that, underneath, converts the blocking call into a non-blocking primitive plus a context switch).
"in some operating systems the TCP stack its self does not run as a state machine but rather as a thread"
I would argue that these operating systems are inherently broken under heavy load, since they are subject to receiver livelock. Jeff Mogul (in a DEC WRL paper), Mohit Aron (in a Rice University paper), and others have examined this problem in great detail, and come to the conclusion that the correct approach is LRP (Lazy Receiver Processing). There are even versions of this code for current versions of Linux (QLinux) and FreeBSD (Rutgers University port of the Rice University code), so lack of source code for a reference implementation is no excuse.
Windows threading implicitly uses thread local storage, for all objects allocated in the context of a thread. In order to instance those objects in another thread, you have to marshall the data via CoCreateFreeThreadedMarshaller().
This isn't obvious in a lot of cases, because programmers have a tendedncy to do initialization work before they break work off to a worker thread, and the Windows VM system *happens* to leave a mapping for local instance data in the created threads for any instance data which was created prior to the thread being created.
Basically, this means that If I create some connection state objects in a pool, spawn a bunch of worker threads to wait for client requests, and then assign a state object to a client request, I'm fine... I never see the need for marshalling.
BUT... if I need to create session state objects after the threads are created, if that new object causes a new allocation, rather than using the remainder of an existing allocation, then the data space mapping ends up being private to the thread. A second request on the session object will result in a reference to a mapping that doesn't necessarily exist in all threads, on the one in which it was created, unless the object is explicitly marshalled (data copied) between the threads.
Now this is probably not a problem for the Apache programmers, who may have been aware of this, but, more likely, lucked out because of order of creation of state objecats and threads (apache works very hard to front-load state creation, and cache the results). But it IS a problem for applications modules that have to make calls into unprotected services.
Probably the most glaring one of these which is going to impact Apache on Windows modules is that the LDAP library itself is not thread-reentrant, because the connection state for the module will not be created before the threads instances are created (this is a common problem with the use of the standard LDAP libraries for programmers on Windows platforms). Because of that, you have to explicitly wrap the LDAP library with a free-threading safe interface which converts concurrent requests into serial requests -- effectively rental or apartment model threading the library, from the application's point of view (apartment model with one occupant, the worker thread allowed to talk to the library).
The standard LDAP libraries are just one example of a service commonly used in web servers used as services platform integration frameworks.
There are actually a lot of others, because the Windows threading models are not very well understood by most people: they tell you that you need to marshall data, but they don't tell you the reasoning behind it by telling you how the threading actually works; even their own programmers sometimes get it wrong, and they DO have access to the documentation. That makes it very hard to deal with secondary dependent effects automatically -- and I guarantee you that Apache 2.0 does NOT deal with these effects for third party libraries that modules will need to be able to use.
The number one problem with Apache 2 is its reliance on threads, and its assumptions about threading models.
This will certainly not win me friends in the "everything should use threads because it's easier to do linear programming than to build a session reentrant state machine" camp, but...
Threads are useful for SMP scalability, but they aren't very useful for much else (I/O interleaving is adequately handled by most network stacks, the I/O interfaces themselves, and the fact that almost all the bytes being mode are being moved from the server to the client: the protocol is very asymmetric, even if you aren't pushing multimedia files). In most cases, threads are a liability.
Under Windows, they introduce data marshalling issues that have to be accounted for in user code -- not just in the modules which implement interpreters for that user code.
Under UNIX, threads are generally a loss, unless there is specific scheduler support for thread group affinity, when threads are running on the same processor. and CPU negaffinity, when there are multiple processors, to ensure that there is maximal usage of computer resources.
If you do the first, then you have the possibility of starvation deadlock for other applications: basically, it's not possible to do it correctly in the scheduler, you have to do it by means of quantum allocation, outside the scheduler. This means a threading approach such as scheduler activations, async call gates, or a similar technique. If you do the second, then you pay a serious penalty in bus bandwidth any time locality spans multiple CPUs -- in other words, it's useless to use SMP, if you have, for example, a shopping cart session that needs to follow a client cookie around.
Overall, this means that you were much better off using session state objects to maintain session state, rather than using threads stacks to do the same job. This is actually pretty obvious for HTTP, in any case, where requests are handled independently as a single request/response pair, and connection persistance isn't generally overloaded to imply session information (you can't do that because of NAT on the clinet side, multiple client connections by a browser on the client side, and server load balancing on the server side, etc.).
Overall, this factors out into threads bringing additional pain for module writers, without any significant performance or other benefit, unless you go SMP, and have a really decent threads and scheduler implementation -- which means you are running a recent IRIX or Solaris, which is a really limited fraction of the total web server market.
Frankly, they would have been a lot better off putting the effort into the management of connection state and MTCP or a similar failover mechanism, and worried about NUMA-based scaling, rather than shared memory multiprocessor with particular threads implementation scaling. The cost for what you get out of the switch is just too high.
You have obviously never worked at IBM; only those who are annointed by the marketing fairy dare speak in public as IBM employees. All others speak only a private citizens. When one of the annointed speaks out against something, you can bet that that speech is a carefully articulated company line.
Likely, it is the same at Hewlett-Compaqard, and the issue was one of the indivisibility of his speech as a private citizen from his status as an HP employee. One of them had to go.
DVD-R does not have the same density as DVDROM, and won't, until multiple layer recording is supported by the writing hardware.
This is moderately irrlevant, in any case, since a DVD drive can detect the difference between a DVDROM and and a DVD-R (or DVD-RW) -- just use hardware in your box that's incapable of reading the recordable format, which is the same reason there is no single recordable format yet.
In the limit, it can be done by having a DVD-R or DVD-RW drive in the product itsel, and trying to write all 1's over the boot sector. If it's pirated software on writeable media, it's cooked.
These are just escalations of the situation without Palladium today, and we were talking about Microsoft hiring people to prototype Palladium in the X-Box to figure out how to make mod-chipping not work.
Nintendo and other console makers of cartridge-based console games have historically dealt with this issue in a rather straight-forward and obvious way: put a patented peice of the console hardware in the cartidge itself. Nintendo used to put the console MMU on a chip in the cartridge. This was a patented chip that you had to buy from them, and they would simply refuse to sell them to you, if you didn't pay license fees and enter into royalty contracts with them. This is the "dongle" approach.
This set the stage for the current console marketing model, where the console itself is sold as a loss-leader, and the cost of the hardware is subsidized by the royalties to the console maker from the games producer, with a fixed minimum number of games (everything past that point is profit).
This model breaks when it is very easy to copy the "cartridge" because all the "cartridge" contains is data -- as is the case with a CDROM.
The response to this is to deal with it using a CDROM with a data density that is high enough that copying is not an option for the user. That's the DVDROM.
It's pretty clear that what Microsoft is working towards here is the day when they can't rely on the data density distinction to protect the fact that their "cartridge" is only data.
Part of this strategy is to establish an umbilical back to "the mother ship", so that a cryptographic system can be hung of a peg that they have physical control over.
Part of dealing with this is to build a "dongle" into the machine itself (a unique console identifier), and to combine this with the "contact the mother ship" strategy, to endure that a given console can only run authorized software.
Indeed, this needs to be the end-goal of Palladium, as well; DVD content, if it were similarly protected, would be subject to the same controls, in terms of "authorized use".
Unfortunately, such a system permits an easy conversion from a "license purchase" system to a "subscription" or a "pay per use" system, with only a change on the server software side (specifically, you would log events, and could make a seperate "business rules" decision as to which events translated into events for the billing system).
This is actually what consumers need to be worried about; it is the thin edge of the wedge toward not being able to *own* something, rather than merely leasing it.
One has to wonder what lasting monuments, if any, are being built by modern society. The Romans built roads, and most of them, with modern repaving, are still in use today. The reniassance built ornate cathedrals.
Now compare that with, say, the "Riccochet" network, which, now that the company is out of business, has merely left so many useless artifacts clamped to municipal street lights. Motorolla has done the same thing with their satellite phone system, etc..
And now, we are on the verge of doing the same thing with books and movies.
Slashdot Mirror
Pirating software is like taking a picture of a chair, and then being able to use the picture as if it were a chair.
It's not like stealing a chair. Rather it is denying the original chair-maker a *potential* sale. This is not the same thing as denying him a sale (restraint of trade), any more than going into business as a competing chair-maker.
Clearly, it's a copyright violation. But attaching penalties above and beyond those that arise from the act of infringement itself is really hard to justify: if you take a chair, it is gone: that's stealing. If you take a picture of a chair, and the chair is still there, you haven't stolen the chair.
Violation of copyright is not theft: it is violation of copyright.
-- Terry
Actually, they opened the second door in the filming of another special already.
Here is an image of the items removed from behind the second door: new Cheops artifacts
-- Terry
What part of "a unique email count" don't you understand?
If implemented correctly, the system could not be influenced by SPAM.
In any case, it's not going to change the Democrat/Republican voter ratio, so getting rid of one Democrat won't achieve anything except getting a different Democrat in power, if you live in a predominantly Democrat district. The converse is true for a predominantly Republican district.
Only an idiot would rotor through opposition candidates this way: "better the evil you know".
-- Terry
You elect someone for their judgement, not their positions on particular issues.
If you felt compelled to send your congress-person a letter, then it was because the issue was important to you, and you didn't trust their judgement on the matter enough to not explicitly voice your opinion in an attempt to sway their judgement from what you expected it to be, instead of what you wanted it to be.
Do you really want to reelect someone whose judgement you don't trust?
Do you really want to reelect someone whose judgement is so fickle that a letter-writing campaing can effect it?
No matter how you look at it, the congressperson with the most letters should probably not be reelecte.
Perhaps you can deal with galvanizing issues by having a +1 on one side and a -1 on the other, and taking the absolute value. However, if those issues are truly galvanizing, then they should result in the same level of interest, generally, meaning it's a wash: a rising tide lifts all boats, so a congressperson need not fear a galvanizing issue will lif their head up for the chop.
It still looks like a workable approach to me...
-- Terry
What we really need is a unique email count for each congressman.
Then we need to not reelect the top 10% of these people, since they are obviously pissing off their constituents.
Email volume as more or less an inverse measure of approval...
-- Terry
The obvious answer: convergence.
If everything is over IP, then you can guarantee at least transport level interoperability with everything. That lets you do things like access mapping services or locale aware restraunt guides, etc., without having to gateway the content.
It also gets around the price differential for long distance service, and further commoditizes the pipe providers as just that: pipe provider, rather than toll-booths that bill based on destination.
Back in the DNSEXT (the IETF working group on DNS), there were a lot of cell phone providers who wanted to assign an IP address to every telephone, making it directly addressable from an outside server.
Among other things, this would let them push content to your phone, based on having a phone/IP identity, so that the phone could be contacted directly.
The downside of this is that they are not really planning on forcing the use of IPv6, and the IPv4 address space actually has too little remaining space for there to be the possibility of assigning an IPv4 address to every cellular telephone in existance.
So while convergence is attractive for the cell phone vendors, and the local carriers (neither of which who could care less if the long distance providers continued to make money, other than as flat rate pipe providers), it's unlikely to avoid the issues of having to have a gateway (NAT) device, unless they go IPv6. The current 3G phones in Europe (and the "2.5G" pgones in the U.S. require gateway devices).
FWIW, both Nokia and Ericson engineers were interested in the IP-per-phone idea when the issue came up on the mailing list, so it's likely they will be the first to be pushing the idea in the future.
-- Terry
To paraphrase Tom Hanks as ``Forrest Gump'', "Buzzword is as buzzword does".
"At the same time, Linux, one of the flagship products of the open source/free software movement, is such a buzzword that all of these companies - and many others - want to somehow associate themselves with the community."
Yes. For marketing purposes. Not to actually *do* anything productive. And it's about time the Linux people wised up to this fact.
It's like the staunch Democrat, whi won't pass up an opportunity to get his picture taken with the President of the United States, even though that president is a Republican. Or the staunch Republican, who gets his picture taken with Teddy Kennedy, to put on his Christmas cards.
Do these people vote the way that the pictures, now on their desks, would imply that they'll be voting? No.
The entire point of endorsing something that's a darling of the trade press is to get trade press as a result of the reflected glory, that would be more expensive to buy elsewhere, under other circumstances.
-- Terry
Does anyone else find it incredibly ironic that Verisign is blaming Online Data for assinging weak passwords instead of strong passwords, and Online Data is blaming merchants for not changing their passwords?
Online Data, the payment processor, is a reseller of Verisign credit card gateway services.
And Verisign sells digital certificates, which provide authentication, identification, and non-repudiation of data signed with those certificates.
And yet they are relying on passwords, rather than requiring the use of an X.509 certificate for an established security association, so that no client machines other than the ones owned by the merchants themselves can be used to make credit card authorization requests.
And each of these people *has* a certificate in hand, since they have to have one to run an HTTPS (SSL based) server in the first place!
That's a bit like the U.S. Marines deciding to hire school crossing guards to provide the security for Fort Knox, isn't it?
And now they are blaming people for not hiring the right school crossing guards, or not firing olld school crossing guards, and hiring different ones "often enough"...
-- Terry
"An end user's choice devolves to changing ISPs".
Or running their own mail server, yes. That's correct.
This is, though, completely orthogonal to your original argument, and I don't think it's a legitimate complaint, even if you come down to lack of choice. As a Californian, you don't have any choice about having the oxygenate MTBE in the gasoline you buy for your car, no matter which gas station you go to, even if your car was manufactured since 1981, and has an Oxygen sensor, causing the fuel to be burned more rich, and actualy causing *more* rather than *less* pollution.
Individual filtering is also not a good answer. Filtering after download multiplies the problem and the amount of computational effort required. It also has you paying message units for the transfer of the unwanted email, if you are using a commercial phone line in the U.S., if you are using a cellular phone, if you have elected that tarrif for your residential telephone connection, or, if you are a European or Japanese user who has no choice in the matter.
Filtering also has the undesirable side effect of everyone having to accumulate their own, potentially very large and expensive to accumulate, undesirable sender list.
Filtering on the server side to avoid the download has these same negatives, as well as increasing the amount of CPU cycles that have to occur at the ISP (at least at the ISP, the cycles are amortized across all users selecting a set of filtering options, instead of being a per user cost). Still, why should I have to pay more for an ISP who has to pay more for compute cycles for more flexible filtering?
The problem comes down to one of unsolicited senders costing a recipient money.
In any case, since you are running your own mail server, you have the choise of whether or not to use a black list. If you don't opt-in to one, then you aren't a member of the class that you are complaining about anyway.
I don't think you have a valid legal argument against black lists, unless you are in fact forced to utilize one as a conditon of not being black-listed (e.g. as Microsoft's Palladium permits, and will inevitably encourage as a result of non-interoperability penalties).
-- Terry
Unlike "sharing" of "marketing information" by credit card companies, telephone companies, and banks, blackhole lists for email ar opt-in.
You have to explicitly subscribe to someone else's judgement in order for it to have an effect on what you block.
Your argument about the putative "RIAA P2P blacklist" is flawed, in that you would have to go out of your way to elect to subscribe to RIAA's judgement.
A much more salient argument might be Palladium, which is effectively a black list of people who do not used Palladium, and which holds you hostage via the use of monopolistic power in the marketplace. A black list which forces you to use it -- which is not "opt-in" -- is much more of a threat.
PS: In your original argument, you had exactly one valid point, which was that the original probe of your email server -- before you asked them to recheck it, thereby giving them permission -- was in fact a criminal trespass on your system. On the other hand, from a legal standpoint, it's probably easy to argue "attractive nuisance" in defense of the original probe, particularly if your mail server had been reported by a third party who had received SPAM via it.
-- Terry
"not from what i see. IMHO, threads makes share things between two processing easier. how can u make a connection pool with many process? and you can do all cpu based work in a group of threads and let one thread do all other i/o based work. These things are impossible with multi process and damn hard with single process FSA."
/proc for the process and setting a flag, so that fork(2) would behave differently in SVR4.2, I can guarantee you that there are other methods of achieving what you want, without threads. Incidently, this greatly pissed off the threads people at USL, because we didn't use their shiny happy application model: it was inappropriate for the problem we were solving.
The classical answer to this is "rfork" or "sfork". But there are others.
As one of the two engineers responsible for adding the ability to share the file table via opening the
Like descriptor table sharing, address space sharing, and SMP scalability, threads are a hammer that is applied to a lot of different problems, on the theory that if all you have is a hammer...
-- Terry
Userland threading and blocking calls do not mix, ever.
The way userland threading works is "call conversion", which trades a blocking system call for a non-blocking system call plus a context switch.
FWIW, I worked indirectly on the DEC MTS product on VAX/VMS back in 1992 (indirectly, in that I made patches to the Bliss code as a Novell employee on a cooperative project with DEC), and I used the undocumented "liblwp" in SunOS 4.1.2 in the late 1980's, and before that, I used the "sigsched" package in the mid 1980's. All this adds up to me having experience with implementing call conversion schedulers going on 20 years.
The problem with sendfile(2) is that it sends excessivle large blocks of data all in one go, and that those sends have to be atomic because they are not restartable.
The *obvious* workaround for the problem is to break the call up based on the size of the object being sent, so that the blocking operations don't block "too long".
Another workaround is to have "worker processes", which are used as contexts for the blocking call, to "accomodate" sendfile.
The only canonically *correct* fix is to provide asynchronous interfaces for all synchronous calls, and perform call conversion on them. For sendfile, this either means an aio_ context version, or changing the return value to be the number of bytes out of the range actually sents, and having it work as write(2) does, in terms of non-blocking file descriptors.
By the same token, I could argue that System V message queue receives "should work" -- another patent absurdity, given that such operations are, by definition, synchronous.
-- Terry
I understand the argument; however, it's pretty clear that the practice here has diverged significantly from the theory.
The context in which we are making these postings is an observation about the non-adoption of Apache 2.0, whse design was intended to prevent non-adoption for the reasons you state.
Still, here we are.
I'm fully willing to admit that I'm speaking in hindsight, and trying to analyze why people have failed to adopt Apache 2.0. I understand that non-adoption was not the plan; but reiterating the plan won't make the non-adoption unhappen.
-- Terry
With respect, the benchmarks people have posted have chown a 10-15% performance degradation in the switch from 1.x to 2.x of Apache.
I agree that your argument is valid for SMP systems... but it assumes that the application that's being used is also threaded, or rewritten to be threaded, and that the libraries it uses are also threaded. Whever they aren't, you are going to eat the performance at whatever serialization boundary you put there. It might as well be a standard one that allows legacy code to continue to function as it did before.
-- Terry
The basic problem is thread group affinity.
Basically, the promise of threads is that you will not be paying the equivalent of a full process context switch overhead, because your VM and other process-specific things will not have to change when context switching from one thread in a process and another thread in a process.
On a machine that has 1001 processes, and you are the 1 process, and you have five threads in your thread group (process), You basically have a 4 out of 1004 chance of one of your threads being picked as the next thing to get a quantum, when one of your threads makes a blocking call, so that it's no longer runnable.
What that means is that you have just reneged on the promise of lower context switch overhead, if you run thread #1, then run "cron", and then run thread #2.
So you have to play favorites, and say "I know "cron" has been waiting a long time, but I just blocked processing on thread #1, and thread #2 is runnable, so I'm going to preferrentially run thread #2, because it lets me avoid the VM switch, and the TLB shootdown, and the other overhead of a full process context switch, and therefore lets me keep my promise about threads being lower overhead than processes".
Any time you play favorites, you starve your non-favorites; just like a Robin or Sparrow with a Cuckoo's Egg in its nest.
So then you have to add all sorts of arcane accounting and other crap to avoid the starvation of other processes, and your scheduler becomes very, very complicated.
Compare this with Scheduler Activations, or an async call gate, where you give a quantum to a process -- and the quantum belongs to that process. In this case, your process runs until either there are no more threads to be run, or until its quantum is used up.
Things are actually more complicated than even this; for example, you want a threaded program to compete as multiple processes for quantum, or you are encouraging people to write programs that fork multiple children, instead of threads, in order to allocate themselves more quantum. On the other hand, you want to set some upper bound on the amount of unfair competition a single unpriviledged program can engage in, relative to other processes on the system.
If you attack thread group affinity as a scheduler problem, the amount of complexity you introduce is substantial, and there will always be corner cases.
There's actually been a huge amount of research on this; check the NEC CS search engine for "scheduling" and "load balancing" and "parallel".
-- Terry
I'm aware of the sendfile problem and the "fix".
Sendfile is not an operation which it's really valid to have the function return until it's complete, so that completition status will be accurate. The assumption here was that kernel threads were being used, so that one thread calling sendfile would not block execution of other threads until the sendfile was complete.
The assumption of kernel threads here, or that sendfile could call-converted into a non-blocking call plus a context switch to another threads, is what was bogus.
Though it boggles the mind that one would expect sendfile(2) to be POSIX threads safe at all, considering that it's not a system call POSIX standardizes...
-- Terry
"GM Cows that dont fart so much are being developed right now."
The downside is that if you let them get more than about four years old, they explode violently.
-- Terry
That's a good question.
I won't argue the legacy code portion of the question; all engineers prefer writing new code to maintaining old code. 8-).
The answer, at least according to me, is that SMP itself is barely a good idea for most OSs, because of scheduler-based CPU affinity implementation. Very few OSs have this right; Sequent (now IBM) and SGI got it right. Everyone else thinks that SMP scalability for Intel breaks down at 4 processors being the point of diminishing returns, but what they are really saying is that they aren't able to address the bus contention scaling issue in software without help.
Hyperthreading puts another tier of preference in there: you don't cache-bust if you move a thread between ALU's in the same CPU, but by the same token, you can't run non-ALU functions simultaneously without stalls.
Basically, this means that you need OS affinity changes, where commercial OSs, and even the free ones, like Linux and FreeBSD already have issues with affinity implementation (Linux implements affinity in the scheduler, leading to the ability of threaded processes to starvation deadlock other processes, but waves a dead chicken to try and work around it, and FreeBSD's implementation is a really rough set of patches that have yet to be integrated).
On top of the OS affinity changes, you have to have compiler help, as well, or the benefit of a Hyperthreaded processor sits at about 20-25% additional, relative to another physical CPU. With compiler help, this "jumps" to an average of 70-75%, relative to another physical CPU.
So basically, it's a relatively cheap way of incrementally increasing performance, if your OS supports the idea. If all CPUs came this way from the factory, then there's a modest win to be had, assuming a direct tie between user space threads and scheduling units. If they don't, then you will pay some penalty on non-Hyperthreaded CPUs, which probably isn't worth the trade-off, if you want to deploy on commodity hardware.
In the Linux case, the person to ask would be Ingo Molnar, who has done much of the work on the scheduler based affinity, and also on the Tux in-kernel HTTP server, and get it and the TCP stack and the minimal driver and data set to live in the confines of a single CPU cache. I don't agree with the approach he has taken in the scheduler, and have discussed it before, but there;s no arguing that it doesn't work, even if I personally think it makes things more complicated than they ought to be.
I think you will find that he will say that the benefit from Hyperthreading in a single CPU machine in that case is no better than perhaps 15-20%, relative to a non-Hyperthreaded processor, which reinforces the idea that the value of Hyperthreading is mostly in the compiler.
Actually, I've heard the Intel documentation on how to write Hyperthreaded code generating compilers described as "Don't do what GCC does", which seems pretty apt to me, all things considered. 8-).
-- Terry
FreeBSD's current threading is implemented in user space, although work is under way to move it into the kernel, that works is being done *ONLY* for SMP scaling and quantum utilization efficiencies.
As it stands, it is fully compliant with the POSIX threads standard.
If it is not working for Apache, it is because Apache is not a POSIX compliant threads client implementation.
From looking at the code, we can see this is the case, with the Apache code having an assumption of kernel threads, which you are not permitted by the POSIX standard to assume.
Although I have not yet verified it, an examination of the code *seems* to indicate that it has "the Netscape problem", which is an assumption about scheduling coming back to a given thread in a group of threads after involuntary preemption by the kernel when the process quantum has expired.
In older versions of Netscape, this displayed as a bug in the Java GIF rendering code, which was not thread reentrant, in that if you used a Java application as a web UI, and moved the mouse before all the pictures were loaded, the browser would crash. After I explained this, Netscape corrected their assumption, and the problem went away.
Ignorance of the requirements for writing threaded applications which will work on all POSIX compliant threads implementations is no excuse, nor is it a valid reason for blaming the host OS, unless you make it known what your requirements are, above and beyond the standard contract offered by POSIX, and that you are stricter than an application written to the POSIX interface, without such additional assumptions.
You will find that you have these same problems on MacOS 9 (NOT FreeBSD-derived), MaxOS X (uses Mach threads), Mach, Plan 9, VxWorks, OpenVMS, etc..
You will find you do NOT have these problems on systems with implied contracts above and beyond those provided by the POSIX standard: Solaris, UnixWare, Windows, and Linux. You may have *other* problems in Windows, related to implied contracts over virtual address space issues (see other posting).
-- Terry
[ ... sorry for the repost; slashdot doesn't use hidden fields, and so when you preview, the username it displays is not used for the posting, if you have cookies disabled ... ]
"Furthermore there is also the fact that not everybody wants to break up their code into a state machine."
That's the "it's easier to do linear programming" camp. I told you, I would not win friends there.
"a much easier time of distributing work to a multi-processor machine"
I granted that, too, but realize that we are talking about a specific type of multiprocessor machine -- the shared memory multiprocessor. That's limited in the number of CPUs that it can scale to, and the current industry trend is toward NUMA based systems, where this type of scaling breaks down.
"I want to be able to do whatever I have to do and not have it interfere too badly with other requests pending."
This is the "I don't want to have to deal with non-blocking operations" argument. This could have been handled in Apache proper, by adding a call conversion mechanism (present a blocking interface that, underneath, converts the blocking call into a non-blocking primitive plus a context switch).
"in some operating systems the TCP stack its self does not run as a state machine but rather as a thread"
I would argue that these operating systems are inherently broken under heavy load, since they are subject to receiver livelock. Jeff Mogul (in a DEC WRL paper), Mohit Aron (in a Rice University paper), and others have examined this problem in great detail, and come to the conclusion that the correct approach is LRP (Lazy Receiver Processing). There are even versions of this code for current versions of Linux (QLinux) and FreeBSD (Rutgers University port of the Rice University code), so lack of source code for a reference implementation is no excuse.
-- Terry
"What you you mean[...]?"
Windows threading implicitly uses thread local storage, for all objects allocated in the context of a thread. In order to instance those objects in another thread, you have to marshall the data via CoCreateFreeThreadedMarshaller().
This isn't obvious in a lot of cases, because programmers have a tendedncy to do initialization work before they break work off to a worker thread, and the Windows VM system *happens* to leave a mapping for local instance data in the created threads for any instance data which was created prior to the thread being created.
Basically, this means that If I create some connection state objects in a pool, spawn a bunch of worker threads to wait for client requests, and then assign a state object to a client request, I'm fine... I never see the need for marshalling.
BUT... if I need to create session state objects after the threads are created, if that new object causes a new allocation, rather than using the remainder of an existing allocation, then the data space mapping ends up being private to the thread. A second request on the session object will result in a reference to a mapping that doesn't necessarily exist in all threads, on the one in which it was created, unless the object is explicitly marshalled (data copied) between the threads.
Now this is probably not a problem for the Apache programmers, who may have been aware of this, but, more likely, lucked out because of order of creation of state objecats and threads (apache works very hard to front-load state creation, and cache the results). But it IS a problem for applications modules that have to make calls into unprotected services.
Probably the most glaring one of these which is going to impact Apache on Windows modules is that the LDAP library itself is not thread-reentrant, because the connection state for the module will not be created before the threads instances are created (this is a common problem with the use of the standard LDAP libraries for programmers on Windows platforms). Because of that, you have to explicitly wrap the LDAP library with a free-threading safe interface which converts concurrent requests into serial requests -- effectively rental or apartment model threading the library, from the application's point of view (apartment model with one occupant, the worker thread allowed to talk to the library).
The standard LDAP libraries are just one example of a service commonly used in web servers used as services platform integration frameworks.
There are actually a lot of others, because the Windows threading models are not very well understood by most people: they tell you that you need to marshall data, but they don't tell you the reasoning behind it by telling you how the threading actually works; even their own programmers sometimes get it wrong, and they DO have access to the documentation. That makes it very hard to deal with secondary dependent effects automatically -- and I guarantee you that Apache 2.0 does NOT deal with these effects for third party libraries that modules will need to be able to use.
-- Terry
The number one problem with Apache 2 is its reliance on threads, and its assumptions about threading models.
This will certainly not win me friends in the "everything should use threads because it's easier to do linear programming than to build a session reentrant state machine" camp, but...
Threads are useful for SMP scalability, but they aren't very useful for much else (I/O interleaving is adequately handled by most network stacks, the I/O interfaces themselves, and the fact that almost all the bytes being mode are being moved from the server to the client: the protocol is very asymmetric, even if you aren't pushing multimedia files). In most cases, threads are a liability.
Under Windows, they introduce data marshalling issues that have to be accounted for in user code -- not just in the modules which implement interpreters for that user code.
Under UNIX, threads are generally a loss, unless there is specific scheduler support for thread group affinity, when threads are running on the same processor. and CPU negaffinity, when there are multiple processors, to ensure that there is maximal usage of computer resources.
If you do the first, then you have the possibility of starvation deadlock for other applications: basically, it's not possible to do it correctly in the scheduler, you have to do it by means of quantum allocation, outside the scheduler. This means a threading approach such as scheduler activations, async call gates, or a similar technique. If you do the second, then you pay a serious penalty in bus bandwidth any time locality spans multiple CPUs -- in other words, it's useless to use SMP, if you have, for example, a shopping cart session that needs to follow a client cookie around.
Overall, this means that you were much better off using session state objects to maintain session state, rather than using threads stacks to do the same job. This is actually pretty obvious for HTTP, in any case, where requests are handled independently as a single request/response pair, and connection persistance isn't generally overloaded to imply session information (you can't do that because of NAT on the clinet side, multiple client connections by a browser on the client side, and server load balancing on the server side, etc.).
Overall, this factors out into threads bringing additional pain for module writers, without any significant performance or other benefit, unless you go SMP, and have a really decent threads and scheduler implementation -- which means you are running a recent IRIX or Solaris, which is a really limited fraction of the total web server market.
Frankly, they would have been a lot better off putting the effort into the management of connection state and MTCP or a similar failover mechanism, and worried about NUMA-based scaling, rather than shared memory multiprocessor with particular threads implementation scaling. The cost for what you get out of the switch is just too high.
-- Terry
You have obviously never worked at IBM; only those who are annointed by the marketing fairy dare speak in public as IBM employees. All others speak only a private citizens. When one of the annointed speaks out against something, you can bet that that speech is a carefully articulated company line.
Likely, it is the same at Hewlett-Compaqard, and the issue was one of the indivisibility of his speech as a private citizen from his status as an HP employee. One of them had to go.
-- Terry
DVD-R does not have the same density as DVDROM, and won't, until multiple layer recording is supported by the writing hardware.
This is moderately irrlevant, in any case, since a DVD drive can detect the difference between a DVDROM and and a DVD-R (or DVD-RW) -- just use hardware in your box that's incapable of reading the recordable format, which is the same reason there is no single recordable format yet.
In the limit, it can be done by having a DVD-R or DVD-RW drive in the product itsel, and trying to write all 1's over the boot sector. If it's pirated software on writeable media, it's cooked.
These are just escalations of the situation without Palladium today, and we were talking about Microsoft hiring people to prototype Palladium in the X-Box to figure out how to make mod-chipping not work.
-- Terry
It's not about lock-in, it's about lock-out.
Nintendo and other console makers of cartridge-based console games have historically dealt with this issue in a rather straight-forward and obvious way: put a patented peice of the console hardware in the cartidge itself. Nintendo used to put the console MMU on a chip in the cartridge. This was a patented chip that you had to buy from them, and they would simply refuse to sell them to you, if you didn't pay license fees and enter into royalty contracts with them. This is the "dongle" approach.
This set the stage for the current console marketing model, where the console itself is sold as a loss-leader, and the cost of the hardware is subsidized by the royalties to the console maker from the games producer, with a fixed minimum number of games (everything past that point is profit).
This model breaks when it is very easy to copy the "cartridge" because all the "cartridge" contains is data -- as is the case with a CDROM.
The response to this is to deal with it using a CDROM with a data density that is high enough that copying is not an option for the user. That's the DVDROM.
It's pretty clear that what Microsoft is working towards here is the day when they can't rely on the data density distinction to protect the fact that their "cartridge" is only data.
Part of this strategy is to establish an umbilical back to "the mother ship", so that a cryptographic system can be hung of a peg that they have physical control over.
Part of dealing with this is to build a "dongle" into the machine itself (a unique console identifier), and to combine this with the "contact the mother ship" strategy, to endure that a given console can only run authorized software.
Indeed, this needs to be the end-goal of Palladium, as well; DVD content, if it were similarly protected, would be subject to the same controls, in terms of "authorized use".
Unfortunately, such a system permits an easy conversion from a "license purchase" system to a "subscription" or a "pay per use" system, with only a change on the server software side (specifically, you would log events, and could make a seperate "business rules" decision as to which events translated into events for the billing system).
This is actually what consumers need to be worried about; it is the thin edge of the wedge toward not being able to *own* something, rather than merely leasing it.
One has to wonder what lasting monuments, if any, are being built by modern society. The Romans built roads, and most of them, with modern repaving, are still in use today. The reniassance built ornate cathedrals.
Now compare that with, say, the "Riccochet" network, which, now that the company is out of business, has merely left so many useless artifacts clamped to municipal street lights. Motorolla has done the same thing with their satellite phone system, etc..
And now, we are on the verge of doing the same thing with books and movies.
-- Terry