The server is called Kolab, and the client is KMail, Korganizer, KAddressbook and KPilot. In KDE 3.2 these will come together in one bunch under the name Kontact. We are now porting the features to KDE cvs HEAD.
I'm sorry, but that is still a ridiculously amusing mish-mash of K-prefix names. I actually laughed as I read that paragraph. My boss would too. "Kmail, Korganizer, Kaddressbook, all under the name Kontact."
I really don't see how KMail (when pronounced K-Mail) is any worse, as for example, "MS Word". Would your boss laugh the first time he hears any new of such brand names from Microsoft?
I agree that names like "Kontact" are problematic, but I simply started pronouncing them as "K-contact". Or you could simply stick with "contact". People neither have a problem when talking about "word", "windows", "office", "exchange" and so on.
Sure, what I am doing here is comparing an unknown brand with an one known world-wide. But then, your argument shouldn't be that the name is bad (which you do seem to by calling it "ridiculous"), but that such a name is not good for a product that is not marketed appropriately.
DB2 and Oracle are very close feature wise. MSSQL lags in terms of engine features but it is far closer to Oracle and DB2 than it is to MySQL. MySQL's SQL can't handle many of the structues in Access. It doesn't offer live backups.
I was with you (although one could argue about the one or other point), until this...
It still has borrible problems with table corruption.....
Huh? In which world do you live? Making such a claim without any reference is ridiculous. MySQL in known for not having any software-inflicted data losses.
In fact, it's so reliable, that at the first sign of a corruption, I would start looking for hardware problems causing it:
The two times I had corruptions (on databases, which got billions of queries in the meantime), it were, in fact, hardware problems: the one time it was a faulty memory bit, several month after the machine was into production, which only showed with memtest after running it for a day (i.e. it was not completely random, but only sometimes lost its state).
And the other time, the manufactorer put a terminator on the SCSI bus, where none belonged, which caused spurious errors. Luckily we detected the this one during running stress tests for a week before going into production.
So in order to get back to the point: Mind giving any references to those "borrible problems with table corruption"?
So, while you are right that today everyone who plays games dual boots, it is certainly not true for me that I will be for a whole lot longer, and I imagine that a lot of other people are in the same position I am.
I absolutely second that. There are only two games left, that I boot MS Windows 98 for. I did not have the itch and time to get WineX running with them (there are reports that they run), yet, but when I will, Win98 will be gone.
And I will not buy any game that won't run on Win98, because I am not willing to upgrade. I'd rather buy a game console (equally closed, but at least it's just plug-and-play).
I am convinced that games on Linux will become a market, and anyone starting with it now will have an advantage (and bigger share of the cake) then.
* You agree to have sex with me unless you say no.
* You agree to drink this soda, unless you set the cup down.
* You agree to bend over and let me anally violate you unless you have objections.
That's quite correct (at least as good as such analogies can be). I am surprised that you came up with those correctly, but did not notice the point.
E.g. the second: If you agree to the EULA, I just forced you to set down the cup down, if you don't want to drink it, you may not hold a cup of soda for any other purpose anymore.
Or in more general terms, the EULA changes an agreement from an active to a passive one. There are a lot of cases where legal systems assume that lack of explicit consent equals no consent. (Of course, there are usually as much cases, where explicit consent is not required.)
The EULA changes that lack of explicit consent, means consent, anyhow, and you need to say no explicitly. This may be a big change in liability, depending on the issue.
That said, I cannot tell whether it is a big change for the issue at hand, because I am not familiar with US law (and what 'defaults' there are for the cases the EULA covers).
High intelligence would be realizing that spending an avg of 7 hours a day on the computer playing video games is probably why your computer repair/building/card swapping business is bust and you're broke.
And if you cared to read the article, instead of simply quoting half of it, you would have noticed the part that mentioned, that the business was bust and he was broke, before he started playing AO.
Of course, playing excessively won't make it better, but you ignored cause and effect just to make your point.
Besides, I wonder why everyone thinks that 7 hours a day doesn't leave time for something else. On times, when I played a game extensively, that was more like 12-14 hours a day. So he does something with the rest of the time. Why do all those that pick on this point presume that he wouldn't reduce his gaming time, if he found some work?
I don't mean to say that he isn't possibly an addict or that don't spend that time on gaming wouldn't increase his chance to find other work. But nothing in the whole article suggests that gaming was the reason for the state of his business.
That's a great idea...... for a/. poll. It would by no means be the scientific evidence you're looking for, but it would certainly be interesting thought fodder.
Although I like the idea for the poll, I strongly doubt that it would give an indication of hacker politcs. I don't mean to offend anyone, but considering that the majority of Slashdot readers are wannabees, the votes of the real hackers would be lost in the noise.
"Hacker" politics range widely, from left to right, from intensely political to completely uninterested in political issues.
You "definition" simply avoids to make any statement at all, except for the small fact, that not all hackers have the same views.
Read the original again. ESR shows some details, and unless you argue that he is wrong about (some of) them, leaving them out, is simply avoiding the difficulty of explaining them.
[...] But think about it: are the two *programs* really exchanging complex *internal* data structures? How is my complex database structure *internal* to MySQL? It's not. MySQL runs just fine without my table files. [...] It is hard to imagine a more arms-length method of communication than SQL, especially if it's sent across the planet to a remote MySQL server. [...]
You seem to focus on the client/server part or whatever. But the client library, which you do link into your program, is also GPL'ed - since version 4.0.x, which is the current stable version, so this would be what the web site is about.
PS: They do mention at several places that older version have different licensing.
PPS: Yes, I know about the idea that maybe using ODBC can work around that linking-the-library-limitation. But I wouldn't bet my money on it.
Oh, and including GPL libraries in your code doesn't make your code GPL - it just makes it illegal if your code isn't (or GPL compatible). That's not quite the same thing.
I can't believe you said that with a straight face.
Well, I am not the one who originally said that, but it could have been from me. And I really don't get what you imply with your answer. You don't really believe that judges would commonly rule the source code to be GPL'ed? They would simply assure that the offense stops and that an appropriate retribution is made.
The GPL does not have the might to make any other source GPL. It can only say something about the work it covers. All it can say is that you violate copyright if you don't comply with it.
The word completely and the fact that you left out most of my posting (and concentrate on a minor part of it) don't go well together. Yes, my example was wrong (mixed up who was waiting). The other statements still stand.
Do you know anything about X11? The client is a seperate process.
Man, of course. Or else, talking about priority inversion, which is defined to happen between at least two tasks wouldn't make much sense. Opposite question: Did you read the lkml thread the article refers to?
It waits on the X server to do its drawing and get its input. There's the problem - the X server is not keeping up with the client. Nicing up a process to make it more responsive is a classic symptom of this.
Correct. But this has nothing to do with priority inversion, yet. This can happen just as well when both tasks have the same priority and there is just not enough free CPU power. And guess what? That is the discussed case.
Here, you can increase responsiveness (that is, decrease latency) by changing how big the slices are (i.e. whether to give 10x0.01 secs or 1x0.1 secs). While changing priority effectively changes how much time slices you get (2x0.1 or 5x0.1)
Priority inversion applies perfectly.
Only if you define priority to include everything what could influence the time until a task is executed (including interrupt mask and so on). Then, yes, time slice layout would be part of the priority and you'd call it that.
The classic understanding is more about which task is scheduled to come first and for preemptive kernels, also which task may preempt another.
Btw, due to the reference to QNX in the original post I understood that the classic sense was meant, because QNX only knows about explicit priorities (what Linux calls niceness) and does simply round-robin or FIFO for tasks of the same priority, depending on system settings. No other magic involved (at least according to the white papers).
The article is about tasks at the same priority[1]. The task scheduler distinguishes between interactive and non-interactive tasks in order to improve latency where the user cares.
When you treat tasks differently, you're prioritizing them. All the priority information isn't necessarily encoded into the UNIX-type priority number. This is a nomenclature distinction between "priority" in the formal sense of "who gets the (a) CPU", vs. the classical UNIX representation of priority numbers.
You are correct. This difference was, why I used "niceness" vs. "priority". Niceness being the priority the user chooses, while priority being the one the system calculates.
That said, the article is still talking about tasks at the same priority (in your sense). Is is not about how much time of a minute a task gets (which is priority), but in how much slices the tasks gets it (which influences latency).
It may be that the "interactive points", which were tweaked, also influence the priority, but the part worth an article was that getting the latency right was much improved.
What's being described here is called a priority inversion, where a high-priority task makes a request of some service running at a lower priority and gets hung up behind it.
Which is wrong. Did you read the article?
Priority inversion is, as you explained yourself, about a high priority task effectively getting a low priority by being dependend and therefore waiting on a low priority task.
The article is about tasks at the same priority[1]. The task scheduler distinguishes between interactive and non-interactive tasks in order to improve latency where the user cares.
Beforehand, the behaviour failed on a slow, loaded system to recognize the X server as interactive, because then X looks like a CPU-hog[2]. That resulted in freezes of several seconds[3]. Simply speaking, the patch solves this by passing some interactivity points between processes.
You could have easily seen that this is not about priority inversion as one of the suggested work-arounds was to simply increase the niceness of the X process (which wouldn't help, if priority inversion had been the problem).
Regarding QNX: As good as it is as a RTOS, as bad it fails to do something sensible when you have too much processes at the same priority. Having a reasonably working system presumes that each task is assigned an appropriate priority. Of course, the people at QNX did a decent job on the default priorities.
[1] It may have an impact on tasks of different priority. I did not care to investigate that aspect, because that is of minor importance to what the patch is about.
[2] And for the scheduler, interactivity is determined by a process going to sleep often (by waiting for interaction).
[3] For non-interactive processes it is beneficial to do them in larger hunks, i.e. let 5 seconds other processes do their work, then work 5 seconds, instead of having 0.01 second slices and do the switching all the time.
Reread the original proposal. The original proposal states because the tickets are so insanely expensive to calculate, the sender keeps a constant pool of precomputed tickets, on standby.
That automatically precludes including any recipient-specific information, because it would involve expensive computation in order to send each message, which is precisely the intended means for blocking mass-mailings.
Now, who's clueless?
Hm. Let me think... You? As you like to refer to the original post, let's cite it:
In normal circumstances, you almost never have to create new tickets. If you have 10 in your pool, and you are mostly emailing co-workers and friends, you never run out of tickets, and everything acts just like it does today.
So where is the problem that the pool contains tickets with the recipient-specific information?
Yes, when you mail a new recepient you have to create a new ticket, and the mail is delayed for 5 minutes (suggestion of original post). Big deal. Happens so often (for 08/15 users).
Aside from that, you picked the example (which I admit was not that great), instead of considering the general idea, i.e. there are ways to prevent simple cloning of tickets.
That said, there are flaws in that scheme (mainly legitimate mass mail), but that was not the point.
Wouldn't it be easier to just have the smtp server delay the response to the TO field by 5 seconds per recipient?
No. A spammer would simply keep is computer busy by sending in parallel to other hosts. The only resource that could run out is related to the number of open connections.
Well, we can stop the discussion here by agreeing to disagree:
I do not think that you could get away with your argument ("but I have only obfuscated code") when you are facing a judge. You may have a chance when the source code can be edited with reasonable effort.
But IMHO there is no chance if you have obfuscated code, which this discussion is all about. And regarding object code... I want to see you convince the judge how you are used to editing this. Ridiculous.
The fact that no company has dared to test this in court yet should be convincing enough that lawyers don't see it this way.
Ah, what I forget... when your main point is that there are ways to circumvent the GPL, you are right. There are (but they are complicated and inconvenient). And we can stop that argument.
But that cannot be done by simply putting a third party in-between or by obfuscating code. It's not that easy. And that was my main point. And the only one I am going to discuss here, because I leave discussing the whole GPL to the lawyers - I only wanted to prevent a misconception one could get by reading your original post.
Putting "the preferred form for making changes" in the GPL was a very smart move and it will need more than a bit effort for bypassing that.
And, of course, this is where you are wrong. You just explained that in Step2, you are creating a secondary form. Well, then the primary form, the one you created the obfuscated assembly from, is the source, defined by the GPL as the "preferred form for making modifications to the work".
Thing is, that interpretation is counter to copyright law. According to the law, the derivative work is an entirely new work. It inherits restrictions from the original based on any license (or lack of license) received by whoever makes the changes, but the reverse is not true. For the GPL to apply to the predecessor work, the GPL would have to explicitly state that it applies to the predecessor work.
More correctly, the GPL would have to state that in order to accept the license the distributor would have to offer the linked works and all portions of all predecessor works that the linked work was derived from under the GPL. It doesn't.
That's not my point. This has nothing to do with what parts are considered derivative work.
I could write a license that allows you distributing my software only if you put the source code of software you own and all code you ever wrote with it. It is irrelevant whether any of your work is related to mine or not, or whether you have the source of the proprietary software, not to mention whether you are allowed to give it away. It is simply the condition of the license. Accept it or not. But if you do not, you may not redistribute my stuff.
The same way works the GPL. It says, in order to be allowed to redistribute anything based on my work, you have to put the source code[1] with it, whether you have it or not.
What it does do is talk about the "preferred" source form. The intent is seemingly straightforward, but that's a nastily vague way of saying it.
I consider it quite clear. If I can show reasonably or even prove that you are using something else than the obfuscated assembler code for making changes...
So, if you want to be doubly sure, you add one layer to my example. Create a corporate entity B whose sole purpose is to receive derivative work A (but not the original work!) from the owner of the original work, compile and link it to the GPL code, and then release it.
Derivative work A is the preferred source because: 1) It is in fact a generally accepted form of source code. 2) Its the only source code available to corporate entity B when they combined it with the GPL part.
And with 2) you are wrong, IMHO. It is not my problem whether you have access to the source[1] or not. If entity B need a new feature, do they change the source of Derivative work A, or do they tell order the other company to change A? In your example, they will do the latter (because the reason of the example is to make the source[1] of Derivative work A unusable). Therefore the source[1] of A is also the source[1] of Derivative work A.
... One media contains the proprietary work and the other contains the GPL work. Since they're never actually distributed in a combined form, license is granted under the GPL for the GPL part without impacting the stuff on the non-GPL media.
Depends, that is only true, if the proprietary stuff is not a derivative work of the GPL stuff. Simply distributing them seperately does not make a derived work not derived any more. But yes, that scheme works, if you have a sufficiently seperate program that can simply make use of the GPL'ed work.
[1] meaning the preferred form for making changes.
Well, this is going to have several questions, but they are all variants of the same.
Does the "or any later version" clause imply, I am free to take a GPLv2 source and make it a GPLv6 release (not being the copyright holder, of course)? Or must it stay to say "GPLv2 or later". If allowed, I am able to protect new releases against a loophole in an earlier GPL version. If so, the next item is redundant, I think.
If not, I thought about using the phrase "or (at your option) the latest version" instead, this way you may only use GPLv2 or GPLv4 (or whatever is current by then), but not GPLv3. The idea is, that if GPLv3 is found to have a loophole, there is problably a GPLv4 soon. Would the GPL support such a copyright clause (the "or any later version" is directly referenced in the GPL)? And if so, do you see any disadvantages in doing so?
Assume the worst, that the FSF goes bad in 30 years and publishes GPLv7, which is, say, BSD-style (*eg*). Is there a way that I can use this clause and being safe from such a change by the FSF?
Well, in short I think the real question is: what do you see as the risks and benefits of using this clause - under the requirement, that I want my source stay licensed under the same meaning, but be safe against loopholes in the current and in future versions of the GPL (even if I died meanwhile)?
What's your problem? I am interested in the answer, how is pro-bono (and pro-GPL) work affects his other work. Maybe that can be found by googling, but I hope that a direct answer will contain some insight not found elsewhere.
There is an obvious way around this in the build process. Obvious to me anyway.
Step 1: Segregate the sources. GPL part not allowed to contaminate the non-GPL part.
Step 2: Build the non-GPL part to a secondary source form (e.g. uncommented assembly with generic variable names). Be especially nasty by renaming the files to "a, b, c," etc and collapsing the source tree to a single directory. Or, hey, just lump it all into one big file.
Label this new work, "Derivative work A." License this new source code under the GPL.
Step 3: Combine "Derivative work A" with the GPL part and compile to object code.
Is "Derivative Work A" licensed under the GPL? Absolutely. If it wasn't, it wouldn't be legal to distribute it linked with other GPL code. The original? No!
Wrong. See below.
(More precisely: Right, there is nothing "forcing" it under GPL, but if it is not GPL'ed, you violate the copyright).
The original work is not distributed in any form, and is not contaminated by the GPL's requirements. But what about this "preferred source code" stuff? Derivative work A is the preferred source code because its the only source code.
And, of course, this is where you are wrong. You just explained that in Step2, you are creating a secondary form. Well, then the primary form, the one you created the obfuscated assembly from, is the source, defined by the GPL as the "preferred form for making modifications to the work".
The predecessor work was not combined with any GPL materials or distributed in object form with GPL materials.
That does not matter. The GPL simply says, you have to give me the files which you use for making modifications, or you violate it. And I am sure you aren't using the assembly to do so. If you have 20 steps in-between before you get the end result is irrelevant. If you do not give me the what you use to make changes, you may not distribute it with GPL stuff. Full stop.
As long as Derivative work A is actually source code of some form (not object code) you're golden.
Also wrong. The GPL does not talk about "some source code", but the source code aka the preferred... (you know this by know).
For example, if you use docbook to generate HTML, the HTML is a kind of source (in the sense of being able to modify it easily), but the source in the sense of the GPL is of course the docbook format.
If you're still not sure, make one or two by-hand changes to Derivative work A before compiling.
Also irrelevant. The question is, what do use to write the next major feature, the preferred form.
No one has had the proper combination of balls and stupidity yet
Heh, I know someone who has the proper combination. Problem is, he's not a programmer. In any case, he has to find it himself. If I give it to him, he'll just say I gave it to him, and then I'll have to prove I abode the GPL (which shouldn't be that hard, really, since I would of course fulfill my obligation:) )
I am not sure what you are referring to, you don't have to prove you abode the GPL:
You don't have to abide to the GPL for him to be bound. He has no right outside of copyright law without the GPL. And the GPL explicitly states that he may use it under GPL, no matter whether you complied or not.
The only one who can reasonable sue you is the copyright holder, not him. If you mean he will claim you are the culprit, well, if he distributes the software, he has to prove why he has the right to do so. Simply saying "but he gave it to me" is not enough. He has to show some legal papers, and the only thing he can show is the GPL, isn't it?
The only thing that remains is that he could sue you claiming you gave it to him with different copyright headers (e.g. public domain). But well, then again, he could sue you for giving it to him, even if you were never involved.;-)
Well, I am not really active in Open Source development, but I follow some software packages close enough to know how it usually works.
It's mostly point 3) of yours, full disclosure. The original poster is right that only a "somebody" finds the bug and posts a fix. And a release is prepared and so on. And yes, it happens that a bugfix is broken.
But the big difference is that there are quite some people who all peer-review the bugfix (other core developers, the respective security guys of distributions like RedHat, Mandrake, Debian, etc... and some interested users/developers like me). If there is some problem with the bugfix, most often it is found within less than an hour, long before the release with it is ready to be published.
Another point that is missing above is simple pride. Not all, but most of Open Source developers take pride in what they do (a lot of them do it mainly for the self-esteem) and publishing a broken security-bugfix is not something to be proud of. You cannot beat such a highly motivated OS developer by a paid one, no matter the salary.;-)
Well you could, by openly publishing the author (email included) in commercial patches. *evilgrin*
I thought the whole reason worm writers release their creations in the weekend is so they have the best chance to spread before systadmins wake up and realise what is happening.
Actually, the worm "armed" it's attack before it "struck". It infected a large number of machines silently, without much noise, and at the given time, it opened up the fire hoses on the Net..
The conclusion is wrong, although the facts (you presented below) are right. The source code analysis shows that the worm had no such code. The fast infection rate came from the simple fact that it needed only one small UDP packet per host to do its work. See e.g. this slashdot comment citing bugtraq (or better, read the original bugtraq post).
Theoretically a different worm or method (trojan, whatever), which has a more sophisticated payload, could be used to silently infect a certain base of machine and then let them "go" on command (it could even replace itself by its simpler child). But there is no evidence to support that claim and the known evidence is already enough to explain the fast spreading.
I haven't heard much mention about this anywhere, but if you graph the attacks (if you had properly configured Snort, for example) you can see the attack curve rise to it's maximum in just under 20 minutes.
Well, see above. Given that the payload was less then half a kilobyte, you get about 20.000 attacks over a 10MBit line per second. That explains very well, how it could reach its maximum peak so fast (3 minutes, not 20, IIRC).
I actually like some tv-cleaned versions of movies better because they remove excessive use of language. I'd be mad if they only offered the edited version to me but if the DVD offered 'cleaned' English language version I'd sometimes use it. No new technology required.:)
I'd like to see support for some of these features in Xine, MPlayer,
Oh, you mean like this:
2.5 Edit Decision Lists (EDL)
The edit decision list (EDL) system allows you to automatically skip or mute sections of videos during playback, based on a movie specific EDL configuration file.
This is useful for those who may want to watch a film in "family-friendly" mode. You can cut out any violence, profanity, Jar-Jar Binks.. from a movie according to your own personal preferences. Aside from this, there are other uses, like automatically skipping over commercials in video files you watch.
That is taken straight from the mplayer docs. It is still a bit rough currently, but what matters: the basics are already there!
Slashdot Mirror
I really don't see how KMail (when pronounced K-Mail) is any worse, as for example, "MS Word". Would your boss laugh the first time he hears any new of such brand names from Microsoft?
I agree that names like "Kontact" are problematic, but I simply started pronouncing them as "K-contact". Or you could simply stick with "contact". People neither have a problem when talking about "word", "windows", "office", "exchange" and so on.
Sure, what I am doing here is comparing an unknown brand with an one known world-wide. But then, your argument shouldn't be that the name is bad (which you do seem to by calling it "ridiculous"), but that such a name is not good for a product that is not marketed appropriately.
DB2 and Oracle are very close feature wise.
MSSQL lags in terms of engine features but it is far closer to Oracle and DB2 than it is to MySQL. MySQL's SQL can't handle many of the structues in Access. It doesn't offer live backups.
I was with you (although one could argue about the one or other point), until this...
It still has borrible problems with table corruption.....
Huh? In which world do you live? Making such a claim without any reference is ridiculous. MySQL in known for not having any software-inflicted data losses.
In fact, it's so reliable, that at the first sign of a corruption, I would start looking for hardware problems causing it:
The two times I had corruptions (on databases, which got billions of queries in the meantime), it were, in fact, hardware problems: the one time it was a faulty memory bit, several month after the machine was into production, which only showed with memtest after running it for a day (i.e. it was not completely random, but only sometimes lost its state).
And the other time, the manufactorer put a terminator on the SCSI bus, where none belonged, which caused spurious errors. Luckily we detected the this one during running stress tests for a week before going into production.
So in order to get back to the point: Mind giving any references to those "borrible problems with table corruption"?
So, while you are right that today everyone who plays games dual boots, it is certainly not true for me that I will be for a whole lot longer, and I imagine that a lot of other people are in the same position I am.
I absolutely second that. There are only two games left, that I boot MS Windows 98 for. I did not have the itch and time to get WineX running with them (there are reports that they run), yet, but when I will, Win98 will be gone.
And I will not buy any game that won't run on Win98, because I am not willing to upgrade. I'd rather buy a game console (equally closed, but at least it's just plug-and-play).
I am convinced that games on Linux will become a market, and anyone starting with it now will have an advantage (and bigger share of the cake) then.
That's about as effective as saying:
* You agree to have sex with me unless you say no.
* You agree to drink this soda, unless you set the cup down.
* You agree to bend over and let me anally violate you unless you have objections.
That's quite correct (at least as good as such analogies can be). I am surprised that you came up with those correctly, but did not notice the point.
E.g. the second: If you agree to the EULA, I just forced you to set down the cup down, if you don't want to drink it, you may not hold a cup of soda for any other purpose anymore.
Or in more general terms, the EULA changes an agreement from an active to a passive one. There are a lot of cases where legal systems assume that lack of explicit consent equals no consent. (Of course, there are usually as much cases, where explicit consent is not required.)
The EULA changes that lack of explicit consent, means consent, anyhow, and you need to say no explicitly. This may be a big change in liability, depending on the issue.
That said, I cannot tell whether it is a big change for the issue at hand, because I am not familiar with US law (and what 'defaults' there are for the cases the EULA covers).
Projects? High intelligence? WTF?
High intelligence would be realizing that spending an avg of 7 hours a day on the computer playing video games is probably why your computer repair/building/card swapping business is bust and you're broke.
And if you cared to read the article, instead of simply quoting half of it, you would have noticed the part that mentioned, that the business was bust and he was broke, before he started playing AO.
Of course, playing excessively won't make it better, but you ignored cause and effect just to make your point.
Besides, I wonder why everyone thinks that 7 hours a day doesn't leave time for something else. On times, when I played a game extensively, that was more like 12-14 hours a day. So he does something with the rest of the time. Why do all those that pick on this point presume that he wouldn't reduce his gaming time, if he found some work?
I don't mean to say that he isn't possibly an addict or that don't spend that time on gaming wouldn't increase his chance to find other work. But nothing in the whole article suggests that gaming was the reason for the state of his business.
That's a great idea... ... for a /. poll. It would by no means be the scientific evidence you're looking for, but it would certainly be interesting thought fodder.
Although I like the idea for the poll, I strongly doubt that it would give an indication of hacker politcs. I don't mean to offend anyone, but considering that the majority of Slashdot readers are wannabees, the votes of the real hackers would be lost in the noise.
"Hacker" politics range widely, from left to right, from intensely political to completely uninterested in political issues.
You "definition" simply avoids to make any statement at all, except for the small fact, that not all hackers have the same views.
Read the original again. ESR shows some details, and unless you argue that he is wrong about (some of) them, leaving them out, is simply avoiding the difficulty of explaining them.
IMHO, you are missing the point. E.g.:
[...] But think about it: are the two *programs* really exchanging complex *internal* data structures? How is my complex database structure *internal* to MySQL? It's not. MySQL runs just fine without my table files.
[...]
It is hard to imagine a more arms-length method of communication than SQL, especially if it's sent across the planet to a remote MySQL server. [...]
You seem to focus on the client/server part or whatever. But the client library, which you do link into your program, is also GPL'ed - since version 4.0.x, which is the current stable version, so this would be what the web site is about.
PS: They do mention at several places that older version have different licensing.
PPS: Yes, I know about the idea that maybe using ODBC can work around that linking-the-library-limitation. But I wouldn't bet my money on it.
Well, I am not the one who originally said that, but it could have been from me. And I really don't get what you imply with your answer. You don't really believe that judges would commonly rule the source code to be GPL'ed? They would simply assure that the offense stops and that an appropriate retribution is made.
The GPL does not have the might to make any other source GPL. It can only say something about the work it covers. All it can say is that you violate copyright if you don't comply with it.
You're completely wrong.
The word completely and the fact that you left out most of my posting (and concentrate on a minor part of it) don't go well together. Yes, my example was wrong (mixed up who was waiting). The other statements still stand.
Do you know anything about X11? The client is a seperate process.
Man, of course. Or else, talking about priority inversion, which is defined to happen between at least two tasks wouldn't make much sense. Opposite question: Did you read the lkml thread the article refers to?
It waits on the X server to do its drawing and get its input. There's the problem - the X server is not keeping up with the client. Nicing up a process to make it more responsive is a classic symptom of this.
Correct. But this has nothing to do with priority inversion, yet. This can happen just as well when both tasks have the same priority and there is just not enough free CPU power. And guess what? That is the discussed case.
Here, you can increase responsiveness (that is, decrease latency) by changing how big the slices are (i.e. whether to give 10x0.01 secs or 1x0.1 secs). While changing priority effectively changes how much time slices you get (2x0.1 or 5x0.1)
Priority inversion applies perfectly.
Only if you define priority to include everything what could influence the time until a task is executed (including interrupt mask and so on). Then, yes, time slice layout would be part of the priority and you'd call it that.
The classic understanding is more about which task is scheduled to come first and for preemptive kernels, also which task may preempt another.
Btw, due to the reference to QNX in the original post I understood that the classic sense was meant, because QNX only knows about explicit priorities (what Linux calls niceness) and does simply round-robin or FIFO for tasks of the same priority, depending on system settings. No other magic involved (at least according to the white papers).
You are correct. This difference was, why I used "niceness" vs. "priority". Niceness being the priority the user chooses, while priority being the one the system calculates.
That said, the article is still talking about tasks at the same priority (in your sense). Is is not about how much time of a minute a task gets (which is priority), but in how much slices the tasks gets it (which influences latency).
It may be that the "interactive points", which were tweaked, also influence the priority, but the part worth an article was that getting the latency right was much improved.
What's being described here is called a priority inversion, where a high-priority task makes a request of some service running at a lower priority and gets hung up behind it.
Which is wrong. Did you read the article?
Priority inversion is, as you explained yourself, about a high priority task effectively getting a low priority by being dependend and therefore waiting on a low priority task.
The article is about tasks at the same priority[1]. The task scheduler distinguishes between interactive and non-interactive tasks in order to improve latency where the user cares.
Beforehand, the behaviour failed on a slow, loaded system to recognize the X server as interactive, because then X looks like a CPU-hog[2]. That resulted in freezes of several seconds[3]. Simply speaking, the patch solves this by passing some interactivity points between processes.
You could have easily seen that this is not about priority inversion as one of the suggested work-arounds was to simply increase the niceness of the X process (which wouldn't help, if priority inversion had been the problem).
Regarding QNX: As good as it is as a RTOS, as bad it fails to do something sensible when you have too much processes at the same priority. Having a reasonably working system presumes that each task is assigned an appropriate priority. Of course, the people at QNX did a decent job on the default priorities.
[1] It may have an impact on tasks of different priority. I did not care to investigate that aspect, because that is of minor importance to what the patch is about.
[2] And for the scheduler, interactivity is determined by a process going to sleep often (by waiting for interaction).
[3] For non-interactive processes it is beneficial to do them in larger hunks, i.e. let 5 seconds other processes do their work, then work 5 seconds, instead of having 0.01 second slices and do the switching all the time.
Reread the original proposal. The original proposal states because the tickets are so insanely expensive to calculate, the sender keeps a constant pool of precomputed tickets, on standby.
That automatically precludes including any recipient-specific information, because it would involve expensive computation in order to send each message, which is precisely the intended means for blocking mass-mailings.
Now, who's clueless?
Hm. Let me think... You? As you like to refer to the original post, let's cite it:
In normal circumstances, you almost never have to create new tickets. If you have 10 in your pool, and you are mostly emailing co-workers and friends, you never run out of tickets, and everything acts just like it does today.
So where is the problem that the pool contains tickets with the recipient-specific information?
Yes, when you mail a new recepient you have to create a new ticket, and the mail is delayed for 5 minutes (suggestion of original post). Big deal. Happens so often (for 08/15 users).
Aside from that, you picked the example (which I admit was not that great), instead of considering the general idea, i.e. there are ways to prevent simple cloning of tickets.
That said, there are flaws in that scheme (mainly legitimate mass mail), but that was not the point.
Wouldn't it be easier to just have the smtp server delay the response to the TO field by 5 seconds per recipient?
No. A spammer would simply keep is computer busy by sending in parallel to other hosts. The only resource that could run out is related to the number of open connections.
... you'll just use a million copies of the same ticket.
There are ways to prevent that and it is obvious that the ticket system was meant this way. (e.g. make the recepeints address part of the calculation)
So, what? Trolling? Or clueless?
Well, we can stop the discussion here by agreeing to disagree:
I do not think that you could get away with your argument ("but I have only obfuscated code") when you are facing a judge. You may have a chance when the source code can be edited with reasonable effort.
But IMHO there is no chance if you have obfuscated code, which this discussion is all about. And regarding object code... I want to see you convince the judge how you are used to editing this. Ridiculous.
The fact that no company has dared to test this in court yet should be convincing enough that lawyers don't see it this way.
Ah, what I forget... when your main point is that there are ways to circumvent the GPL, you are right. There are (but they are complicated and inconvenient). And we can stop that argument.
But that cannot be done by simply putting a third party in-between or by obfuscating code. It's not that easy. And that was my main point. And the only one I am going to discuss here, because I leave discussing the whole GPL to the lawyers - I only wanted to prevent a misconception one could get by reading your original post.
Putting "the preferred form for making changes" in the GPL was a very smart move and it will need more than a bit effort for bypassing that.
More correctly, the GPL would have to state that in order to accept the license the distributor would have to offer the linked works and all portions of all predecessor works that the linked work was derived from under the GPL. It doesn't.
That's not my point. This has nothing to do with what parts are considered derivative work.
I could write a license that allows you distributing my software only if you put the source code of software you own and all code you ever wrote with it. It is irrelevant whether any of your work is related to mine or not, or whether you have the source of the proprietary software, not to mention whether you are allowed to give it away. It is simply the condition of the license. Accept it or not. But if you do not, you may not redistribute my stuff.
The same way works the GPL. It says, in order to be allowed to redistribute anything based on my work, you have to put the source code[1] with it, whether you have it or not.
What it does do is talk about the "preferred" source form. The intent is seemingly straightforward, but that's a nastily vague way of saying it.
I consider it quite clear. If I can show reasonably or even prove that you are using something else than the obfuscated assembler code for making changes...
So, if you want to be doubly sure, you add one layer to my example. Create a corporate entity B whose sole purpose is to receive derivative work A (but not the original work!) from the owner of the original work, compile and link it to the GPL code, and then release it.
Derivative work A is the preferred source because:
1) It is in fact a generally accepted form of source code.
2) Its the only source code available to corporate entity B when they combined it with the GPL part.
And with 2) you are wrong, IMHO. It is not my problem whether you have access to the source[1] or not. If entity B need a new feature, do they change the source of Derivative work A, or do they tell order the other company to change A? In your example, they will do the latter (because the reason of the example is to make the source[1] of Derivative work A unusable). Therefore the source[1] of A is also the source[1] of Derivative work A.
Depends, that is only true, if the proprietary stuff is not a derivative work of the GPL stuff. Simply distributing them seperately does not make a derived work not derived any more. But yes, that scheme works, if you have a sufficiently seperate program that can simply make use of the GPL'ed work.
[1] meaning the preferred form for making changes.
- Does the "or any later version" clause imply, I am free to take a GPLv2 source and make it a GPLv6 release (not being the copyright holder, of course)? Or must it stay to say "GPLv2 or later". If allowed, I am able to protect new releases against a loophole in an earlier GPL version. If so, the next item is redundant, I think.
- If not, I thought about using the phrase "or (at your option) the latest version" instead, this way you may only use GPLv2 or GPLv4 (or whatever is current by then), but not GPLv3. The idea is, that if GPLv3 is found to have a loophole, there is problably a GPLv4 soon. Would the GPL support such a copyright clause (the "or any later version" is directly referenced in the GPL)? And if so, do you see any disadvantages in doing so?
- Assume the worst, that the FSF goes bad in 30 years and publishes GPLv7, which is, say, BSD-style (*eg*). Is there a way that I can use this clause and being safe from such a change by the FSF?
Well, in short I think the real question is: what do you see as the risks and benefits of using this clause - under the requirement, that I want my source stay licensed under the same meaning, but be safe against loopholes in the current and in future versions of the GPL (even if I died meanwhile)?What's your problem? I am interested in the answer, how is pro-bono (and pro-GPL) work affects his other work. Maybe that can be found by googling, but I hope that a direct answer will contain some insight not found elsewhere.
There is an obvious way around this in the build process. Obvious to me anyway.
... (you know this by know).
Step 1: Segregate the sources. GPL part not allowed to contaminate the non-GPL part.
Step 2: Build the non-GPL part to a secondary source form (e.g. uncommented assembly with generic variable names). Be especially nasty by renaming the files to "a, b, c," etc and collapsing the source tree to a single directory. Or, hey, just lump it all into one big file.
Label this new work, "Derivative work A." License this new source code under the GPL.
Step 3: Combine "Derivative work A" with the GPL part and compile to object code.
Is "Derivative Work A" licensed under the GPL? Absolutely. If it wasn't, it wouldn't be legal to distribute it linked with other GPL code. The original? No!
Wrong. See below.
(More precisely: Right, there is nothing "forcing" it under GPL, but if it is not GPL'ed, you violate the copyright).
The original work is not distributed in any form, and is not contaminated by the GPL's requirements. But what about this "preferred source code" stuff? Derivative work A is the preferred source code because its the only source code.
And, of course, this is where you are wrong. You just explained that in Step2, you are creating a secondary form. Well, then the primary form, the one you created the obfuscated assembly from, is the source, defined by the GPL as the "preferred form for making modifications to the work".
The predecessor work was not combined with any GPL materials or distributed in object form with GPL materials.
That does not matter. The GPL simply says, you have to give me the files which you use for making modifications, or you violate it. And I am sure you aren't using the assembly to do so. If you have 20 steps in-between before you get the end result is irrelevant. If you do not give me the what you use to make changes, you may not distribute it with GPL stuff. Full stop.
As long as Derivative work A is actually source code of some form (not object code) you're golden.
Also wrong. The GPL does not talk about "some source code", but the source code aka the preferred
For example, if you use docbook to generate HTML, the HTML is a kind of source (in the sense of being able to modify it easily), but the source in the sense of the GPL is of course the docbook format.
If you're still not sure, make one or two by-hand changes to Derivative work A before compiling.
Also irrelevant. The question is, what do use to write the next major feature, the preferred form.
I am not sure what you are referring to, you don't have to prove you abode the GPL:
- You don't have to abide to the GPL for him to be bound. He has no right outside of copyright law without the GPL. And the GPL explicitly states that he may use it under GPL, no matter whether you complied or not.
- The only one who can reasonable sue you is the copyright holder, not him. If you mean he will claim you are the culprit, well, if he distributes the software, he has to prove why he has the right to do so. Simply saying "but he gave it to me" is not enough. He has to show some legal papers, and the only thing he can show is the GPL, isn't it?
The only thing that remains is that he could sue you claiming you gave it to him with different copyright headers (e.g. public domain). But well, then again, he could sue you for giving it to him, even if you were never involved.Well, I am not really active in Open Source development, but I follow some software packages close enough to know how it usually works.
;-)
:)
It's mostly point 3) of yours, full disclosure. The original poster is right that only a "somebody" finds the bug and posts a fix. And a release is prepared and so on. And yes, it happens that a bugfix is broken.
But the big difference is that there are quite some people who all peer-review the bugfix (other core developers, the respective security guys of distributions like RedHat, Mandrake, Debian, etc... and some interested users/developers like me). If there is some problem with the bugfix, most often it is found within less than an hour, long before the release with it is ready to be published.
Another point that is missing above is simple pride. Not all, but most of Open Source developers take pride in what they do (a lot of them do it mainly for the self-esteem) and publishing a broken security-bugfix is not something to be proud of. You cannot beat such a highly motivated OS developer by a paid one, no matter the salary.
Well you could, by openly publishing the author (email included) in commercial patches. *evilgrin*
Oh well, unfortunately not really.
The conclusion is wrong, although the facts (you presented below) are right. The source code analysis shows that the worm had no such code. The fast infection rate came from the simple fact that it needed only one small UDP packet per host to do its work. See e.g. this slashdot comment citing bugtraq (or better, read the original bugtraq post).
Theoretically a different worm or method (trojan, whatever), which has a more sophisticated payload, could be used to silently infect a certain base of machine and then let them "go" on command (it could even replace itself by its simpler child). But there is no evidence to support that claim and the known evidence is already enough to explain the fast spreading.
I haven't heard much mention about this anywhere, but if you graph the attacks (if you had properly configured Snort, for example) you can see the attack curve rise to it's maximum in just under 20 minutes.
Well, see above. Given that the payload was less then half a kilobyte, you get about 20.000 attacks over a 10MBit line per second. That explains very well, how it could reach its maximum peak so fast (3 minutes, not 20, IIRC).
I'd like to see support for some of these features in Xine, MPlayer,
Oh, you mean like this:That is taken straight from the mplayer docs. It is still a bit rough currently, but what matters: the basics are already there!