Basically the broad early claims do have force (unless deemed unenforceable or whatever by a judge.) Certainly infringing on claim 1 in the MS patent in question is enough to bring a lawsuit, and then you'd need a few $m in the bank just to fight off the patent (which is enough to intimidate, even if the patent does not hold up in court.)
I agree with many here that the current patent systems are rather ridiculous (basically those doing the checking cannot possibly have enough expertise in the relevant area to evaluate the 'obviousness' or novely of a given claim, yet their approval puts the burden of proof on others to prove that they have not infringed: it is this shift in the burden of proof, and how easily it can be obtained that is a large part of the problem.)
That, and autocopy means that you can't copy something, do a little editing (involving selecting) and then paste. Basically, you select far more than you copy, so autocopy is a bad feature of X, not a good one.
Furthermore, it is too easy in the current system to use distribution schedules to stab competitors in the back (by making it hard for company Co to get electricity from A to B since most of the capacity in a few critical places is deliberately used by company X.)
I always wrap cells up in paper when carrying the around. First, you can roll it round in such a way as the paper separates a couple of cells, and the rest insulates them from anything around. (I usually wrap them in pairs, since I've got nothing that requires an odd number of them.)
(For AA: Take A5 sheet; put AA cell in middle of one of the short edges; roll it round the cell once; put the second cell next to it, roll it up and fold the ends over, sticking one inside the other to keep the whole thing from unrolling.)
As for shorting: this is the problem with cells that have a low internal resistance. For a more extreme example, take a typical lead-acid cell that you'd get in your car. This can quite happily explode (in the real explosion sense) when shorted (the heat boils the liquid (H2SO4 IIRC) blows the cell open spraying the acid all over the place.) That said, I've only heard this (not stupid enough to actually try it.)
p.s. people can cause the above problem if they use jump-leads incorrectly, wiring + to -, - to + rather than + to +, - to -.
You can't do that without contradicting the clause that states that 'no further restrictions to distribution may be applied'. Your program would be covered by a GPL-like GPL-incompatible license.
It should be a 'consumer right' to ask how many bytes on a given hard disk. If this is not already a right, it should be. Basically, those who care (for e.g. use in RAID devices), they can ask for the number of bytes and compare/calculate themselves. Further, there should be some rule of consistency/transparency, so that a company marketing hard drives must stick with one convention across their adverts, and write in small print in the advert what their GB is. The reader who's getting ready to buy can then grab their calculator. (The difference is irrelevant to the user who cannot use a calculator: software settings will usually eclipse the difference between 1Gigabyte and 1Gibabyte.) If shopping quickly and casually, the difference doesn't really matter, and before you buy, you can check to make sure everythings ok (it only takes as much time as checking what you can pay with.)
You get the picture. So long as you can find out easily, that is enough.
p.s. Quake users will now have an added ambiguity: the word 'gib'! (Talking about having 120 gibs will bring up pictures of gratuitous violence...)
It's ok to use CAPITAL LETTERS. The CAPS LOCK key provides this functionality, so users have no need to the SHIFT KEY, which is clearly intended to bypass copy-protection devices11 9Legitimate CAPS LOCK users have nothing to fear, but shifty SHIFT users clearly have something to hide...0
in a further development, the windows device manager is also a DMCA-outlawed circumvention device.
BREAKING NEWS... people with normal keyboard layouts may no longer type in people's email address. THIS feature will be useful for preventing unwanted emails from being sent. ALSO, patches are being released so that emails of the form me'here.com are acceptable.
This has similarities to the modern marketing ideas regarding brands. The 'brand' is what is being 'sold', with the product to back it up. Getting the brand identity spreading around the consumer mindset is all important when generating sales.
Naomi Klein's No Logo is a good introduction to the various antics of brand-marketing corporations.
That said, I agree that blaming people for their human psychology is stupid and pointless. How to reduce susceptibility given our psychological weaknesses is the problem at hand.
It's true in general. * will not expand hidden files (e.g..emacs), so rm -rf * will remove all files and directories that are not hidden, whereas rm -rf . will remove everything.
Not only that, but the browser or even the ISP knows far more about the context of the DNS request failure. It can give a far more intelligent reply. (This is a major reason why browser related features of the internet should be implemented in the browser.)
Furthermore, StieFinder or something else should be implemented in a way that a DNS query still produces something that is an authoratative 'domian name not registered' so that software that wants to deal with this can do so.
What is bonkers with COM and NET is, for example, if I type www.bonjourdefrance.com, I get a French only website. If I type www.bonjoudefrance.com, I'd get SiteFinder, in English, not French, which is clearly the language of the person doing the search. (And that person may not speak English.) Similar points are valid for other languages. Here, VeriSign have failed to ask: who uses.com and.net. And blindly assumed it's the americans or English speakers only.
Dealing with DNS failures should be dealt with nearer to the user doing the DNS request (where more information is available about what they want, e.g. their probable languages, etc.)
This is a silly though: but the ability to refer from one domain to another could well be abused. (I suspect that there should simply be a limit on the amount of recursion required, or at least a minimum.)
Suppose I send from a domain a.b.hello.com, where I control the DNS on b.hello.com. I modify my DNS server so that there are, say, 10 referrals to: b.b.hello.com, c.b.hello.com,... j.b.hello.com. Then, b.b.hello.com refers to something else, etc. etc. With all the SPF referral entries being generated on the fly.
Now, this isn't so much of a problem, because tying up a mail server would entail tying up the DNS server doing the referring. But a large number of small DNS servers distributed around the place could start causing problems.
I'm not sure where thinking this through leads to... any thoughts?
Abolish all laws against violence, fraud, theft, etc.
It is up to individuals to ensure that they are secured properly against all kinds of theft, and it is up to individuals to ensure that they protect themselves.
Let's think.
It is clear that the result of the above would be lawless anarchy and rule of the gun.
What next? People would eventually work together, gradually bringing about despotic rule in various forms. Better forms of government would then come about, allowing members of the various 'protection groups' to have to worry less about their security and more about getting stuff done. Industry and stuff will come about, and inter 'protection group' trade will do likewise. Each 'protection group' will negotiate conventions with each other in order to further it's own constituents interests. Etc. Etc. Etc. (been here before?...)
The US government, for economic reasons, will back up what it perceives to be MS's property rights. In this sense, MS is certainly state sponsored. (Just as a nation with a hard line fundamentalist government may back up what it sees as fundamental rights of people that e.g. the US calls terrorists.) State sponsorship of various things is heavily engrained in our country, far more than it may seem at first.
Essentially, all property rights are things that are enforced by the government of a given country, and as such are determined by the laws of that country (possibly influenced by treaties.) In this way, any internaitonal trade by companies in country X can give rise to the perception that companies in country X are sponsored by country X.
A licensed MTA operator may only send mail to other licensed MTAs So how does the MTA legally send the email to the target inbox? I think you mean '... or to their own network.'
There are also considerations about how the email system should work (for example, to get the burden to be more on the sender than on the receiver.)
The current system is suboptimal in many ways, and enshrining the current system in law could be counter productive. (Essentially, the international treaties underlying such laws would need to be very well thought out and worded so as to avoid various different implementation details appearing in different states/countries' ratifications. Such good thinking is usually disrupted by the kind of horse trading that goes on with international agreements.)
It's true that adding Y adds flexibility in the sense that you've another graphical environment to choose from.
The main gist of my comment (as I intended it) was to point out that constraining flexibility and choice of the application developer can be a useful thing. But, the constraints should be put in place so that it is easy to get a given job done, yet hard to fall into various traps. Things such as consistency are easier to achieve with a little less flexability.
That said, choosing the right constriants correctly generally requires a huge research project. The experience up til now with X serves as that research into 'how X should have been done'.
When was anything last done on that? Note the web page: Last modified: Tue Mar 3 19:21:27 PST 1998. To all intents and purposes, it does not exist today.
Still, selecting text so as to copy it somewhere else is less common than simply selecting text for some other purpose. Maybe one should be using shift-middle-click for copy. In any case, autocopy with a stack still adds complexity to the act of pasting (which is slightly more common than copying on a Windows or Mac system that doesn't copy automatically.)
And many consider the act of building upon X to add too much unnecessary complexity. What is needed is a simpler, network transparent GUI, without many of the mistakes, workarounds, etc. that are present in X in one form or another.
Poor decisions early on (or at least, that are poor with respect to what X needs to do today,) together with workarounds and extensions added here and there have added far too much complexity. The solution to the problems that X helps to solve should be far simpler than any solution that can be managed using X.
Something like XWT would be a good idea. Essentially, the standard toolkit should allow for abstract descriptions of UI's to be sent up to the server. But designing it properly is one problem, allowing the parse/unparse time to be got rid of is another. My view:
Abstract stuff such as this should be available, esp. for small simple apps. Basic logic can be implemented in some scripting language, e.g. Javascript2. BUT, this should only be implemented as a layer above the underlying UI system. Furthermore, things such as menubars etc. should be marked out so that the UI can deal with toolbar/menu/etc. policy rather than being told by the application. To only be able to do UI stuff with HTTP friendly protocols would be suicide. But to allow for abstract constructions of application UI's on the server side could be advantagous. (The problem is when details are sent to the server. Probably sending the minimum first, starting the application and then sending commonly used stuff in the background is good policy here.)
XML is fast evolving. Trying to target it with something such as a window system is futile. It will have been changed by the time the UI system cathes on, if it ever does.
What is important is being able to do this stuff easily, and not being forced to add too much unnecessary complexity when doing it.
Your point of view arises from the question of 'what is X designed to do, and does it do it well?'. The answer to that is, indeed, a qualified yes.
There is, however, some difference between what X is designed to do, and the user experience demanded by modern users.
Point by point...
(I shall rever to the X server as the display, and an X client as 'an application')
X has too much latency: See Packard's paper in Freenix 2003: high latency is not an inherent X attribute, even over high-latency connections.
Recently, articles talked about NX, something that greatly improved performance across slow links. One thing it did was to eliminate a great deal of round-trip communications between the application (i.e. X client) and display (i.e. X server).
These round trips are part of the problem. Eliminating them by, e.g. consolidating common communications across multiple applications, should be considered important.
One should ask why this is such a common problem: why is so easy to write applications that use far too many round trip communications to the server, and why is there no standardised solution. (Basically, it should be easy to make an efficient application with respect to this.)
I've usually favoured something like an app server centric way of doing things as a way of getting this done. Basically, your applications (almost) always talk to a local application server which, in turn, handles communication with a remote application server, possibly also directly with the display where necessary. Basically, application logic runs through the app server, multimedia graphics goes straight to the display, and the app servers keep themselves up to date about the relevant details of the display server's innards so as to prevent each application interrogating stuff like that over the network.
(Think of this as refactoring the user experience.)
X requires a toolkit for ease of programming:
Duh. As opposed to what, exactly?
X cannot be considered a GUI in itself (as we all know.) X+standard_toolkit does not exist, and this guy can be though of as looking at the possiblity of having a standard toolkit.
X needs standardized UI semantics: This is moot. You may use X+Gnome or X+KDE if this is what you desire. Either is a fairly good and fairly complete system with standard UI semantics.
The existence of two such systems is no more troublesome than the simultaneous coexistence of Windows and MacOS.
Agreed here, but factoring the complete X+KDE+related_network_stuff differently at a (hypothetical) early design stage could remove a lot of the complexity present in either of these desktop systems.
X is "an incoherent mess": When making this argument, it is always useful to confuse the protocol with the implementation. The existence of Kdrive is a nice example of how much the latter can be cleaned up. The protocol hasn't changed in 20 years except for extensions: the argument that the extensions don't work together is supremely unconvincing, supported by one lame example. freedesktop.org has made a lot of progress in a short time in refactoring and standardizing X.
X itself may not be. X always appears an incoherent mess, especially to users. This is part of the problem. But also, X taken together with the various workarounds and applications required to do things that are considered out of the scope of X, in order to produce the user experience, becomes a huge mess. Suppose, (my usual example,) you are sitting at a slowish PC with floppy drive, zip, cdrom, sound card. The user expects to be able to use the removable drives, and hear sound. How this is done is outside the scope of X. Adding the necessary workarounds to complete the 'user experience' makes things into a large mess. It is here that things need to be looked at, and from this point of view that the shortcomings of X become more apparent. It does too many unnecessary things and misses out a fe
You cannot unplug one toolkit and plug in another one. Modern toolkit designs play a large part in how you design the application.
As to sticking 'pluggable' things into the server, the idea of making it pluggable in the way that binary compatible libraries are should not be the aim. Basic UI logic (such as how UI elements respond to each other) etc. probably should reside in the server.
The right kind of abstract understanding is a thing we techies take for granted. It is hard not to see things the way we do, and not to think of things as obvious, even though they may seem so to us.
You make the point that if someone lacked the brain power for concepts required to use an application then they will have problems in real life, and then list some analogous examples. The thing that the user-having-trouble needs is the abstract understanding that ties these concepts together.
The idea of thing-on-thing-doesn't-mean-thing-is-gone is a very generally well known principle that most children pick up automatically at about the same age. In fact, your average magician relies on things such as this.
The idea that you can't stuff 1000 apples into a single rucksack is, again, an intuitive one that most people know instinctively. But to know that the same principle means that data compression can't keep making things smaller indefinately, even though it may appear so, requires a kind of abstract reasoning that many people may not be able to grasp (even though the basic principle is so simple, so intuitive and so easily understood.)
Slashdot Mirror
Take a look at
http://www.lawnotes.com/patent/claims.html for some details. I obviously cannot vouch for the accuracy, but I'd guess it's pretty good.
Basically the broad early claims do have force (unless deemed unenforceable or whatever by a judge.) Certainly infringing on claim 1 in the MS patent in question is enough to bring a lawsuit, and then you'd need a few $m in the bank just to fight off the patent (which is enough to intimidate, even if the patent does not hold up in court.)
I agree with many here that the current patent systems are rather ridiculous (basically those doing the checking cannot possibly have enough expertise in the relevant area to evaluate the 'obviousness' or novely of a given claim, yet their approval puts the burden of proof on others to prove that they have not infringed: it is this shift in the burden of proof, and how easily it can be obtained that is a large part of the problem.)
That, and autocopy means that you can't copy something, do a little editing (involving selecting) and then paste. Basically, you select far more than you copy, so autocopy is a bad feature of X, not a good one.
Furthermore, it is too easy in the current system to use distribution schedules to stab competitors in the back (by making it hard for company Co to get electricity from A to B since most of the capacity in a few critical places is deliberately used by company X.)
I always wrap cells up in paper when carrying the around. First, you can roll it round in such a way as the paper separates a couple of cells, and the rest insulates them from anything around. (I usually wrap them in pairs, since I've got nothing that requires an odd number of them.)
(For AA: Take A5 sheet; put AA cell in middle of one of the short edges; roll it round the cell once; put the second cell next to it, roll it up and fold the ends over, sticking one inside the other to keep the whole thing from unrolling.)
As for shorting: this is the problem with cells that have a low internal resistance. For a more extreme example, take a typical lead-acid cell that you'd get in your car. This can quite happily explode (in the real explosion sense) when shorted (the heat boils the liquid (H2SO4 IIRC) blows the cell open spraying the acid all over the place.) That said, I've only heard this (not stupid enough to actually try it.)
p.s. people can cause the above problem if they use jump-leads incorrectly, wiring + to -, - to + rather than + to +, - to -.
You can't do that without contradicting the clause that states that 'no further restrictions to distribution may be applied'. Your program would be covered by a GPL-like GPL-incompatible license.
It should be a 'consumer right' to ask how many bytes on a given hard disk. If this is not already a right, it should be. Basically, those who care (for e.g. use in RAID devices), they can ask for the number of bytes and compare/calculate themselves. Further, there should be some rule of consistency/transparency, so that a company marketing hard drives must stick with one convention across their adverts, and write in small print in the advert what their GB is. The reader who's getting ready to buy can then grab their calculator. (The difference is irrelevant to the user who cannot use a calculator: software settings will usually eclipse the difference between 1Gigabyte and 1Gibabyte.) If shopping quickly and casually, the difference doesn't really matter, and before you buy, you can check to make sure everythings ok (it only takes as much time as checking what you can pay with.)
You get the picture. So long as you can find out easily, that is enough.
p.s. Quake users will now have an added ambiguity: the word 'gib'! (Talking about having 120 gibs will bring up pictures of gratuitous violence...)
It's ok to use CAPITAL LETTERS. The CAPS LOCK key provides this functionality, so users have no need to the SHIFT KEY, which is clearly intended to bypass copy-protection devices11 9Legitimate CAPS LOCK users have nothing to fear, but shifty SHIFT users clearly have something to hide...0
in a further development, the windows device manager is also a DMCA-outlawed circumvention device.
BREAKING NEWS... people with normal keyboard layouts may no longer type in people's email address. THIS feature will be useful for preventing unwanted emails from being sent. ALSO, patches are being released so that emails of the form me'here.com are acceptable.
HAVE A NICE DAY111
This has similarities to the modern marketing ideas regarding brands. The 'brand' is what is being 'sold', with the product to back it up. Getting the brand identity spreading around the consumer mindset is all important when generating sales.
Naomi Klein's No Logo is a good introduction to the various antics of brand-marketing corporations.
That said, I agree that blaming people for their human psychology is stupid and pointless. How to reduce susceptibility given our psychological weaknesses is the problem at hand.
It's true in general. * will not expand hidden files (e.g. .emacs), so rm -rf * will remove all files and directories that are not hidden, whereas rm -rf . will remove everything.
Not only that, but the browser or even the ISP knows far more about the context of the DNS request failure. It can give a far more intelligent reply. (This is a major reason why browser related features of the internet should be implemented in the browser.)
Furthermore, StieFinder or something else should be implemented in a way that a DNS query still produces something that is an authoratative 'domian name not registered' so that software that wants to deal with this can do so.
.com and .net. And blindly assumed it's the americans or English speakers only.
What is bonkers with COM and NET is, for example, if I type www.bonjourdefrance.com, I get a French only website. If I type www.bonjoudefrance.com, I'd get SiteFinder, in English, not French, which is clearly the language of the person doing the search. (And that person may not speak English.)
Similar points are valid for other languages.
Here, VeriSign have failed to ask: who uses
Dealing with DNS failures should be dealt with nearer to the user doing the DNS request (where more information is available about what they want, e.g. their probable languages, etc.)
This is a silly though: but the ability to refer
... j.b.hello.com.
from one domain to another could well be abused. (I suspect that there should simply be a limit on the amount of recursion required, or at least a minimum.)
Suppose I send from a domain a.b.hello.com, where I control the DNS on b.hello.com. I modify my DNS server so that there are, say, 10 referrals to:
b.b.hello.com, c.b.hello.com,
Then, b.b.hello.com refers to something else, etc. etc. With all the SPF referral entries being generated on the fly.
Now, this isn't so much of a problem, because tying up a mail server would entail tying up the DNS server doing the referring. But a large number of small DNS servers distributed around the place could start causing problems.
I'm not sure where thinking this through leads to... any thoughts?
To paraphrase:
Abolish all laws against violence, fraud, theft, etc.
It is up to individuals to ensure that they are secured properly against all kinds of theft, and it is up to individuals to ensure that they protect themselves.
Let's think.
It is clear that the result of the above would be lawless anarchy and rule of the gun.
What next? People would eventually work together, gradually bringing about despotic rule in various forms. Better forms of government would then come about, allowing members of the various 'protection groups' to have to worry less about their security and more about getting stuff done. Industry and stuff will come about, and inter 'protection group' trade will do likewise. Each 'protection group' will negotiate conventions with each other in order to further it's own constituents interests. Etc. Etc. Etc. (been here before?...)
The US government, for economic reasons, will back up what it perceives to be MS's property rights. In this sense, MS is certainly state sponsored.
(Just as a nation with a hard line fundamentalist government may back up what it sees as fundamental rights of people that e.g. the US calls terrorists.) State sponsorship of various things is heavily engrained in our country, far more than it may seem at first.
Essentially, all property rights are things that are enforced by the government of a given country, and as such are determined by the laws of that country (possibly influenced by treaties.) In this way, any internaitonal trade by companies in country X can give rise to the perception that companies in country X are sponsored by country X.
Quick thoughts:
A licensed MTA operator may only send mail to other licensed MTAs
So how does the MTA legally send the email to the target inbox? I think you mean '... or to their own network.'
There are also considerations about how the email system should work (for example, to get the burden to be more on the sender than on the receiver.)
The current system is suboptimal in many ways, and enshrining the current system in law could be counter productive. (Essentially, the international treaties underlying such laws would need to be very well thought out and worded so as to avoid various different implementation details appearing in different states/countries' ratifications. Such good thinking is usually disrupted by the kind of horse trading that goes on with international agreements.)
It's true that adding Y adds flexibility in the sense that you've another graphical environment to choose from.
The main gist of my comment (as I intended it) was to point out that constraining flexibility and choice of the application developer can be a useful thing. But, the constraints should be put in place so that it is easy to get a given job done, yet hard to fall into various traps. Things such as consistency are easier to achieve with a little less flexability.
That said, choosing the right constriants correctly generally requires a huge research project. The experience up til now with X serves as that research into 'how X should have been done'.
When was anything last done on that? Note the web page: Last modified: Tue Mar 3 19:21:27 PST 1998.
To all intents and purposes, it does not exist today.
Still, selecting text so as to copy it somewhere else is less common than simply selecting text for some other purpose. Maybe one should be using shift-middle-click for copy. In any case, autocopy with a stack still adds complexity to the act of pasting (which is slightly more common than copying on a Windows or Mac system that doesn't copy automatically.)
I doubt he could review RISC OS properly (access being the problem), and sticking in hearsay from other's descriptions would be bad.
And many consider the act of building upon X to add too much unnecessary complexity. What is needed is a simpler, network transparent GUI, without many of the mistakes, workarounds, etc. that are present in X in one form or another.
Poor decisions early on (or at least, that are poor with respect to what X needs to do today,) together with workarounds and extensions added here and there have added far too much complexity.
The solution to the problems that X helps to solve should be far simpler than any solution that can be managed using X.
My view:
Your point of view arises from the question of 'what is X designed to do, and does it do it well?'. The answer to that is, indeed, a qualified yes.
There is, however, some difference between what X is designed to do, and the user experience demanded by modern users. Point by point...
(I shall rever to the X server as the display, and an X client as 'an application')
Recently, articles talked about NX, something that greatly improved performance across slow links. One thing it did was to eliminate a great deal of round-trip communications between the application (i.e. X client) and display (i.e. X server). These round trips are part of the problem. Eliminating them by, e.g. consolidating common communications across multiple applications, should be considered important.
One should ask why this is such a common problem: why is so easy to write applications that use far too many round trip communications to the server, and why is there no standardised solution. (Basically, it should be easy to make an efficient application with respect to this.)
I've usually favoured something like an app server centric way of doing things as a way of getting this done. Basically, your applications (almost) always talk to a local application server which, in turn, handles communication with a remote application server, possibly also directly with the display where necessary. Basically, application logic runs through the app server, multimedia graphics goes straight to the display, and the app servers keep themselves up to date about the relevant details of the display server's innards so as to prevent each application interrogating stuff like that over the network. (Think of this as refactoring the user experience.)
X cannot be considered a GUI in itself (as we all know.) X+standard_toolkit does not exist, and this guy can be though of as looking at the possiblity of having a standard toolkit.
Agreed here, but factoring the complete X+KDE+related_network_stuff differently at a (hypothetical) early design stage could remove a lot of the complexity present in either of these desktop systems.
X itself may not be. X always appears an incoherent mess, especially to users. This is part of the problem. But also, X taken together with the various workarounds and applications required to do things that are considered out of the scope of X, in order to produce the user experience, becomes a huge mess. Suppose, (my usual example,) you are sitting at a slowish PC with floppy drive, zip, cdrom, sound card. The user expects to be able to use the removable drives, and hear sound. How this is done is outside the scope of X. Adding the necessary workarounds to complete the 'user experience' makes things into a large mess. It is here that things need to be looked at, and from this point of view that the shortcomings of X become more apparent. It does too many unnecessary things and misses out a fe
You cannot unplug one toolkit and plug in another one. Modern toolkit designs play a large part in how you design the application.
As to sticking 'pluggable' things into the server, the idea of making it pluggable in the way that binary compatible libraries are should not be the aim. Basic UI logic (such as how UI elements respond to each other) etc. probably should reside in the server.
The right kind of abstract understanding is a thing we techies take for granted. It is hard not to see things the way we do, and not to think of things as obvious, even though they may seem so to us.
You make the point that if someone lacked the brain power for concepts required to use an application then they will have problems in real life, and then list some analogous examples. The thing that the user-having-trouble needs is the abstract understanding that ties these concepts together.
The idea of thing-on-thing-doesn't-mean-thing-is-gone is a very generally well known principle that most children pick up automatically at about the same age. In fact, your average magician relies on things such as this.
The idea that you can't stuff 1000 apples into a single rucksack is, again, an intuitive one that most people know instinctively. But to know that the same principle means that data compression can't keep making things smaller indefinately, even though it may appear so, requires a kind of abstract reasoning that many people may not be able to grasp (even though the basic principle is so simple, so intuitive and so easily understood.)