I don't think you realize how ungodly complex such a thing would need to be to actually replace common configuration files. Just look at how the absolutely most trivial example of configuration ballooned into 20 lines of XML. Configuration gets a lot more complex than that. If you don't believe me, just look at the enormous complexity and verbosity of XML Schema, which is trying to solve a problem of similar complexity.
All I have to say is that Slashdotters come up with the most bizarre theories.
Fronting a bunch of cash to launch a product, planning all the while to eventually shut it down, going through the hassle of refunding all the purchases, all to... teach the public a lesson? I'd love to see the meeting of middle management where that gets suggested.
If we're talking about what ought to be, believe me when I say that I have no love for EULAs.
But even more than I hate EULAs, I hate sweeping and incorrect legal analysis by armchair lawyers.
"Software EULAs have no legal weight" is demonstrably false: there are cases where they have been upheld. The question is more complex than that. That's the only statement I was trying to make.
As an aside, I see several other cases described on this page that apparently have also upheld the enforceability of EULAs. I can't find the texts of the rulings online or more information about the exact circumstances, but a world where EULAs have no teeth seems to be getting more remote.:(
Software EULAs have been upheld in court: see ProCD v. Zeidenberg. The judge's analysis rested mostly on the Uniform Commercial Code (or UCC), not copyright law.
"Work for hire" is a concept that only applies to copyright law; it makes no sense to talk about it in the context of a service.
These basic errors lead me to question the rest of your analysis as well.
I am pretty sure that this license (or at least some software under the license) will not be accepted by Debian, which is slightly stricter than the FSF and the OSI. If the software includes a trademark, it must be included when distributed in either modified or unmodified form.
No, a trademark notice.
A trademark notice would be something like "Windows is a trademark of Microsoft."
Which is totally different than actually using the trademark itself.
How can a person be "orders of magnitude a better programmer" if they repeatedly make significant errors of judgement?
Ingo wrote the bad scheduler that Con dramatically improved! Con only had work to do because Ingo dug Linux into this poor scheduler design to begin with.
Maybe you could argue that Ingo writes cleaner code or something, but to me good judgement is what makes a programmer good.
You're missing the point. I'm a site owner. I want to embed content from another site dynamically. Given strict browsers, this means that I have to totally and unconditionally trust said site to serve perfect HTML every time. The consequences of their screwup is that my site won't display at all.
No remotely important site could afford to take the risk of embedding third-party content in such a world.
Please see my comment here. It's senseless to make a website owner put their entire site on the line when they choose to embed content from comment authors, Google Analytics, Google Adwords, etc.
Imagine if C++ compilers could take the same liberties that web browsers could with the input!
Imagine if web browsers were anal retentive and refused to display anything with the slightest syntax error. Imagine if your blog suddenly became undisplayable because commenter number 32 input some broken HTML, and your not-quite-perfect blog software didn't quite know how to launder it. Imagine that the slightest syntax error from Google Analytics, Google AdWords, or anything else you embed into your site could make your site completely unavailable.
I know it's not satisfying, but being permissive on the web really is the best policy, as long as the results of the permissiveness are well-defined (which is what HTML5 does).
Multithreading is important to GUI performance, but not for the reason people think.
For ordinary computer users, CPUs aren't the bottleneck, and they haven't been for a while. It's all about I/O.
Experiencing GUI slowness? Chances are it's one of the following:
- your application stupidly lets its GUI threads block on I/O. your application won't redraw or respond until it gets what it wants from the disk or network.
- your OS is stupidly letting the VM system thrash, madly swapping applications in and out of memory (the sound of this phenomenon is your hard disk churning)
- (least likely) you are truly doing something CPU intensive, like using Google Maps in Safari (which, for whatever reason, is horribly slow. Safari must have a slow JS interpreter or something).
Sadly, I don't see things getting better anytime soon.
...[involving] numerous strange computations involving a number of magic constants; it is difficult to understand, much less improve. --Linux Weekly News
Well, yeah. If the documentation says, "This method expects a bit-packed value in ARGB format" you had better pass it a value in ARGB format.
Bit-packed, huh? You must really like bitwise operations. A sane language would let you express it as a struct with four members. But keep working around Java's quirks; it's no skin off my back.
Killer isn't it? Adding that extra > sign.
The amount of work has absolutely nothing to do with it. It's not much work to walk around the mines in a mine field.
Um, okaaaay. Would you like to explain to the class which overflow-detection scheme you can use in C/C++ that you can't use in Java?
#include <stdio.h>
int main() {
unsigned char a = 100, b, c;
printf("Enter an integer to add to 100: ");
scanf("%hhu", &b);
c = a + b;
if(c < a)
printf("Sorry, the result overflowed!\n");
else
printf("The result is %hhu\n", c); }
This doesn't work for Java, because the faux-unsigned byte you would be storing in c will wrap around in "normal" circumstances. You will have to do two checks instead of one in this case. Again, not a huge amount of work, but a minefield.
First off, you're a very bad boy for using the decimal value 65535 when your real intent is obviously to fill all 16 bits with 1's.
On the contrary, my intent was to mimic a situation like this:
As in, the rules you read when you learn how to program the language. Unsurprisingly, casts are signed. So if you don't want to cast a number (which you should never, ever, ever be doing with a bit-packed number anyway) you should be doing bitwise casts on them:
Oh right. You're bit-packing again to deal with shortcomings of your language. As you were.
Wow, you Java apologists are hard-core. Your contention is that the lack of unsigned types is no problem at all because you can:
infer from context/documentation that *some* signed values are actually unsigned values in disguise
for such values, use bit shift instead of arithmetic shift
for such values, manually translate them if they are printed incorrectly on the console or in a debugger
Not only that, you're not even right. You miss the following problems:
you will have to devise your own strange and complicated ways to detect overflow
you will not be able to assign literal values outside the signed range of the data type (short x = 65535 does not compile)
Types will be converted incorrectly, as demonstrated in the following program:
public class Test {
public static void main(String args[])
{
short y = -32768;// 65535 in disguise!
int x = y;// "incorrectly" converted to (int)-32768
System.out.println(x);
} }
I don't see how this improves the situation for realtime applications. A realtime application's need can be summarized thus: "I need X amount of resources (CPU time, I/O bandwidth) by timestamp Y." As I understand it, CFS distributes CPU time completely equally among runnable processes, so if the realtime application needs more than an equal share in order to maintain its realtime processing, it's sorry out of luck.
If I run 50 processes that are spinning, each one of them will get just as much CPU time as the realtime process. How is CFS going to protect that realtime process from starvation?
Promises that it's much better than the last scheduler? Check.
What, you're trying to tell me that complex heuristics to try to determine the "interactiveness" of processes wasn't the peak of scheduler technology?
I eagerly await the next grand rewrite when something else comes up that they didn't think through. My bets are that it will be the interdependency of I/O scheduling and CPU scheduling: what good is giving a process the CPU if it's swapped out? The VM system is going to immediately try to swap it back in, and switch to another task when this happens, and if memory is short to begin with this will just thrash, thrash, thrash (I'm sure everyone has experienced this at one time or another).
Can't wait for the "Completely Awesome Knows-About-I/O Scheduler."
See ProCD v. Zeidenberg, in which the enforceability of a EULA (presented only after the sale) was upheld.
The court held that Zeidenberg did accept the offer by clicking through. The court noted, "He had no choice, because the software splashed the license on the screen and would not let him proceed without indicating acceptance." The court stated that Zeidenberg could have rejected the terms of the contract and returned the software.
That's exactly why it's totally ridiculous that it is contained in a single source repository!
Need a newer version of the USB subsystem, or a fix to a driver? Have fun downloading a new version of Linux, which has an ungodly number of changes across the entire kernel.
People tend to think of monolithic/micro kernel only in terms of run-time technical advantages/disadvantages. But equally important IMO is the impact on development processes. With a good microkernel architecture, it would be totally reasonable to think that you could upgrade an entire subsystem (like USB) without touching the rest of the OS. Each subsystem could be run as an independent project with its own releases, and there could be competition for who can make the best subsystem.
On one hand I sympathize with your position, because I tend to favor MIT/BSD as well.
But the GPL isn't just about visions and causes. It's about defenses against predatory behavior. The only reason that Microsoft hasn't gone after Red Hat demanding royalties for patent violations is because GPLv2 prohibits it:
Now that Microsoft had identified the infringements, it could try to seek royalties. But from whom? [...] One possibility was to approach the big commercial Linux distributors like Red Hat and Novell that give away the software but sell subscription support services. However, distributors were prohibited from paying patent royalties by something whose very existence may surprise many readers: FOSS's own licensing terms.
[...]
"Any free program is threatened constantly by software patents," Stallman wrote in a 1991 revision to the GPL. "We have made it clear that any patent must be licensed for everyone's free use or not licensed at all." This restriction became known as the "liberty or death" clause.
If Linux and the GNU project had taken your attitude of "hey, I'm just a guy putting up my code," then the community would be in a very different position today wrt. Microsoft's patent aggression.
I agree that SQLite is brilliant, but I want to add a word of warning: don't use it for anything that needs to support any kind of concurrency (ESPECIALLY writes concurrent with anything else).
SQLite holds up like a champ (I used it for a database that ultimately grew to 20GB, 150M rows), and it will never corrupt your data, but due to the nature of its file-based implementation (there is no server process to mediate concurrent access), the locking is quite coarse.
As a developer who tends toward BSD, I'm more likely to use GPLv3 specifically because of its patent protections (still not sure if I ultimately will, but...)
Now that Microsoft has made its strategy of patent bullying clear, why on earth would you specifically oppose erecting defenses against it? Remember, the existing patent defenses in GPLv2 are the only thing that is keeping Microsoft from going after RedHat and other Linux distributors right now. Microsoft has said as much!
Two bytes is not enough for all Unicode characters. UTF-16, which stores characters under U+FFFF using two bytes, is still a variable-length encoding for characters higher than U+FFFF. If you want a fixed-length encoding, use UTF-32.
So, perhaps if data was all stored and represented in UTF-8, for example, this wouldn't be a problem?
You can't impose this on the whole world; a lot of the protocols and file formats that we use every day explicitly allow for multiple encodings. Correct software simply has to buck it up and transcode when necessary.
Nice article. Here is an invoice for the Intellectual Property fees you owe to the descendents of the many works of art you appropriated.
- The descendents of James Madison, for your quotation of the Constitution - The descendents of Thomas Jefferson, for the quotation attributed to him. - The descendents of William Shakespeare, for using the title of his play "Winter's Tale" - The descendents of Moses, for the phrase "Does not then the government's giveth support its taketh," which is clearly alluding to the book of Job in the bible ("the Lord gave, and the Lord hath taken away", Job 1:21). - The Chicago University Press, which has appropriated the rights to the ellipsis, a glyph that has remained in Copyright since it was first introduced in 200BC.
We hope you will be able to secure agreeable licensing terms for all these works. In the case that you cannot, you will naturally need to remove the reference. We look forward to seeing more of your work, and thank you for helping to support a thriving intellectual property market.
Slashdot Mirror
I don't think you realize how ungodly complex such a thing would need to be to actually replace common configuration files. Just look at how the absolutely most trivial example of configuration ballooned into 20 lines of XML. Configuration gets a lot more complex than that. If you don't believe me, just look at the enormous complexity and verbosity of XML Schema, which is trying to solve a problem of similar complexity.
All I have to say is that Slashdotters come up with the most bizarre theories.
Fronting a bunch of cash to launch a product, planning all the while to eventually shut it down, going through the hassle of refunding all the purchases, all to... teach the public a lesson? I'd love to see the meeting of middle management where that gets suggested.
If we're talking about what ought to be, believe me when I say that I have no love for EULAs.
:(
But even more than I hate EULAs, I hate sweeping and incorrect legal analysis by armchair lawyers.
"Software EULAs have no legal weight" is demonstrably false: there are cases where they have been upheld. The question is more complex than that. That's the only statement I was trying to make.
As an aside, I see several other cases described on this page that apparently have also upheld the enforceability of EULAs. I can't find the texts of the rulings online or more information about the exact circumstances, but a world where EULAs have no teeth seems to be getting more remote.
Software EULAs have been upheld in court: see ProCD v. Zeidenberg. The judge's analysis rested mostly on the Uniform Commercial Code (or UCC), not copyright law.
"Work for hire" is a concept that only applies to copyright law; it makes no sense to talk about it in the context of a service.
These basic errors lead me to question the rest of your analysis as well.
I am pretty sure that this license (or at least some software under the license) will not be accepted by Debian, which is slightly stricter than the FSF and the OSI. If the software includes a trademark, it must be included when distributed in either modified or unmodified form.
No, a trademark notice.
A trademark notice would be something like "Windows is a trademark of Microsoft."
Which is totally different than actually using the trademark itself.
How can a person be "orders of magnitude a better programmer" if they repeatedly make significant errors of judgement?
Ingo wrote the bad scheduler that Con dramatically improved! Con only had work to do because Ingo dug Linux into this poor scheduler design to begin with.
Maybe you could argue that Ingo writes cleaner code or something, but to me good judgement is what makes a programmer good.
You're missing the point. I'm a site owner. I want to embed content from another site dynamically. Given strict browsers, this means that I have to totally and unconditionally trust said site to serve perfect HTML every time. The consequences of their screwup is that my site won't display at all.
No remotely important site could afford to take the risk of embedding third-party content in such a world.
Please see my comment here. It's senseless to make a website owner put their entire site on the line when they choose to embed content from comment authors, Google Analytics, Google Adwords, etc.
Imagine if C++ compilers could take the same liberties that web browsers could with the input!
Imagine if web browsers were anal retentive and refused to display anything with the slightest syntax error. Imagine if your blog suddenly became undisplayable because commenter number 32 input some broken HTML, and your not-quite-perfect blog software didn't quite know how to launder it. Imagine that the slightest syntax error from Google Analytics, Google AdWords, or anything else you embed into your site could make your site completely unavailable.
I know it's not satisfying, but being permissive on the web really is the best policy, as long as the results of the permissiveness are well-defined (which is what HTML5 does).
Multithreading is important to GUI performance, but not for the reason people think.
For ordinary computer users, CPUs aren't the bottleneck, and they haven't been for a while. It's all about I/O.
Experiencing GUI slowness? Chances are it's one of the following:
- your application stupidly lets its GUI threads block on I/O. your application won't redraw or respond until it gets what it wants from the disk or network.
- your OS is stupidly letting the VM system thrash, madly swapping applications in and out of memory (the sound of this phenomenon is your hard disk churning)
- (least likely) you are truly doing something CPU intensive, like using Google Maps in Safari (which, for whatever reason, is horribly slow. Safari must have a slow JS interpreter or something).
Sadly, I don't see things getting better anytime soon.
When you speak about "mature" scheduling in Linux, are you referring to the scheduler that was written completely from scratch in 62 hours three months ago, or the one that was written completely from scratch five years ago and described asJust wondering.
However, your attempt to add more points is pathetic. For instance, "short a = (short)65535;" works just like "byte c = (byte)255;"
Which can be read as "some of the weird and obnoxious problem you'll run into have non-obvious workarounds."
Furthermore, Java actually *does* have an unsigned 16-bit type. It is called "char"
Whatever, repeat the same criticism for "byte."
Bit-packed, huh? You must really like bitwise operations. A sane language would let you express it as a struct with four members. But keep working around Java's quirks; it's no skin off my back.
Killer isn't it? Adding that extra > sign.
The amount of work has absolutely nothing to do with it. It's not much work to walk around the mines in a mine field.
Um, okaaaay. Would you like to explain to the class which overflow-detection scheme you can use in C/C++ that you can't use in Java? This doesn't work for Java, because the faux-unsigned byte you would be storing in c will wrap around in "normal" circumstances. You will have to do two checks instead of one in this case. Again, not a huge amount of work, but a minefield.
First off, you're a very bad boy for using the decimal value 65535 when your real intent is obviously to fill all 16 bits with 1's.
On the contrary, my intent was to mimic a situation like this:
struct ARGB
{
char a, r, g, b;
}color = {255, 255, 255, 255};
I really did mean 65535.
As in, the rules you read when you learn how to program the language. Unsurprisingly, casts are signed. So if you don't want to cast a number (which you should never, ever, ever be doing with a bit-packed number anyway) you should be doing bitwise casts on them:
Oh right. You're bit-packing again to deal with shortcomings of your language. As you were.
Oops, got my twos complement wrong in the example -- it's been a while. But the point is still valid.
- infer from context/documentation that *some* signed values are actually unsigned values in disguise
- for such values, use bit shift instead of arithmetic shift
- for such values, manually translate them if they are printed incorrectly on the console or in a debugger
Not only that, you're not even right. You miss the following problems:I don't see how this improves the situation for realtime applications. A realtime application's need can be summarized thus: "I need X amount of resources (CPU time, I/O bandwidth) by timestamp Y." As I understand it, CFS distributes CPU time completely equally among runnable processes, so if the realtime application needs more than an equal share in order to maintain its realtime processing, it's sorry out of luck.
If I run 50 processes that are spinning, each one of them will get just as much CPU time as the realtime process. How is CFS going to protect that realtime process from starvation?
Complete rewrite of scheduler, again? Check.
Catchy new name? Check.
Promises that it's much better than the last scheduler? Check.
What, you're trying to tell me that complex heuristics to try to determine the "interactiveness" of processes wasn't the peak of scheduler technology?
I eagerly await the next grand rewrite when something else comes up that they didn't think through. My bets are that it will be the interdependency of I/O scheduling and CPU scheduling: what good is giving a process the CPU if it's swapped out? The VM system is going to immediately try to swap it back in, and switch to another task when this happens, and if memory is short to begin with this will just thrash, thrash, thrash (I'm sure everyone has experienced this at one time or another).
Can't wait for the "Completely Awesome Knows-About-I/O Scheduler."
That's exactly why it's totally ridiculous that it is contained in a single source repository!
Need a newer version of the USB subsystem, or a fix to a driver? Have fun downloading a new version of Linux, which has an ungodly number of changes across the entire kernel.
People tend to think of monolithic/micro kernel only in terms of run-time technical advantages/disadvantages. But equally important IMO is the impact on development processes. With a good microkernel architecture, it would be totally reasonable to think that you could upgrade an entire subsystem (like USB) without touching the rest of the OS. Each subsystem could be run as an independent project with its own releases, and there could be competition for who can make the best subsystem.
Now, as an extention to this power thing. Why in 2007 are we still talkinga about EULAs? As far as I know, they are complete BS.
Unfortunately the enforceability of EULAs has been upheld in court; see ProCD v. Zeidenberg.
But the GPL isn't just about visions and causes. It's about defenses against predatory behavior. The only reason that Microsoft hasn't gone after Red Hat demanding royalties for patent violations is because GPLv2 prohibits it:If Linux and the GNU project had taken your attitude of "hey, I'm just a guy putting up my code," then the community would be in a very different position today wrt. Microsoft's patent aggression.
I agree that SQLite is brilliant, but I want to add a word of warning: don't use it for anything that needs to support any kind of concurrency (ESPECIALLY writes concurrent with anything else).
SQLite holds up like a champ (I used it for a database that ultimately grew to 20GB, 150M rows), and it will never corrupt your data, but due to the nature of its file-based implementation (there is no server process to mediate concurrent access), the locking is quite coarse.
As a developer who tends toward BSD, I'm more likely to use GPLv3 specifically because of its patent protections (still not sure if I ultimately will, but...)
Now that Microsoft has made its strategy of patent bullying clear, why on earth would you specifically oppose erecting defenses against it? Remember, the existing patent defenses in GPLv2 are the only thing that is keeping Microsoft from going after RedHat and other Linux distributors right now. Microsoft has said as much!
Two bytes is not enough for all Unicode characters. UTF-16, which stores characters under U+FFFF using two bytes, is still a variable-length encoding for characters higher than U+FFFF. If you want a fixed-length encoding, use UTF-32.
I recommend checking out the Wikipedia article Comparison of Unicode encodings.
So, perhaps if data was all stored and represented in UTF-8, for example, this wouldn't be a problem?
You can't impose this on the whole world; a lot of the protocols and file formats that we use every day explicitly allow for multiple encodings. Correct software simply has to buck it up and transcode when necessary.
Dear Mark,
Nice article. Here is an invoice for the Intellectual Property fees you owe to the descendents of the many works of art you appropriated.
- The descendents of James Madison, for your quotation of the Constitution
- The descendents of Thomas Jefferson, for the quotation attributed to him.
- The descendents of William Shakespeare, for using the title of his play "Winter's Tale"
- The descendents of Moses, for the phrase "Does not then the government's giveth support its taketh," which is clearly alluding to the book of Job in the bible ("the Lord gave, and the Lord hath taken away", Job 1:21).
- The Chicago University Press, which has appropriated the rights to the ellipsis, a glyph that has remained in Copyright since it was first introduced in 200BC.
We hope you will be able to secure agreeable licensing terms for all these works. In the case that you cannot, you will naturally need to remove the reference. We look forward to seeing more of your work, and thank you for helping to support a thriving intellectual property market.
--Intellectual Property Association, Inc.