Okay, let me be a little more patient with you, because you're going to a tremendous effort to write such long (and dorky) notes back:
1. I never said PDF sucks because Linux has poor support for it. I said exactly the other way around: Linux has poor support for PDF because PDF sucks. BIG difference, and it's too bad you missed it.
2. There are front-ends that don't "suck" other than xpdf. If you want the pretty graphics, and the cutesy hotkeys, and so on, then don't use xpdf. Personally I like the tiny footprint of xpdf. You obviously want something that looks like a Mac. Yay you.
3. Did you not just say that you had to buy a new sound card because your previous one wasn't performing up to your standards in Linux? And who's the fucking dolt? You're the one bitching about Linux drivers like some kind of petulant child. Are you aware of the kind of CPU wastage that happens when disparate samples are mixed in software? Perhaps the reason there is no software fallback is that there's no clean way to ensure that the impact of such mixing doesn't kill the system? Hm? Software mixing doesn't belong in the driver, and you're the dolt for thinking it does.
4. YOU were fucking whining about the lack of support for your older card: "I did, in fact, run out and purchas a SB Live just so that I could get multi-channel sound on Linux. Had I been using Windows, I could have made do with my older sound card and had exactly what I was looking for." So your older sound card didn't have enough channels for you? Jesus you're picky for someone using a free OS. And maybe there's a good reason why ALSA developers don't want to waste their time on software mixing?
5. The original post I was replying to was PDF support. I notice you've conveniently cut this out of your own notes. Does that mean I was right about PDF support under Linux? That xpdf does search through text after all? Hm? Perhaps YOU are the one misleading yourself, here: After all, xpdf *DOES* have text-searching capabilities, and you don't appear to be capable of clicking the little binoculars button at the bottom of the screen...
6. I love how you characterize the free software that you're enjoying that supports your multi-channel hardware as: "completely suck[s]". Oh, did you forget what you said? Here's a refresher: (Linux will not take off) "until the Linux sound architecture doesn't completely suck." What gratitude. What gratefulness. What willingness to volunteer to help.
What fucking bullshit.
You're just making an ass of yourself--give it up now before it's too late for redemption.
Try using a document that has actual text instead of images, and stop whining about not being able to search through the text IN AN IMAGE. What, do you want the system to do a little OCR for you? Highlight the image where it thinks the words you're looking for are? Get your head out of the clouds.
xpdf does have the ability to search through text, and if you can't find it or make effective use of it, that's really your problem then, isn't it?
PDF support sucks because PDF sucks.
Why do you expect others to write drivers for your existing hardware? And why do you whine when you didn't check to see whether your hardware was supported in the fashion you wanted before taking the Linux plunge?
Sounds like someone convinced you to use Linux, you ran out and bought a copy (or invested a pile of time in it,) without doing some rudimentary research first. Your friend is at fault for being a zealot without considering his actions, and you are at fault for not looking into the matter a little more carefully.
I apologize on behalf of the rest of us for your friend's over-enthusiasm.:-)
Also, there already exist drivers that can mix sound together--but where do you want this to happen? In software? In hardware? Software solutions don't work so well because the streams may not match and may need to be resampled (a costly affair.) If you want support in the drivers you're using for the multi-channel hardware you might have (can SB Live play two completely different sample types at the same time?) then why not donate some hardware to someone who can do it or find some specs and write it yourself?
But check the ALSA project:
http://www.alsa-project.org... where they list right on the front page they have support for multi-channel professional sound getups.
I read your question just fine--you apparently have forgotten there's this thing called Google.
You're missing a whole level of functionality then. xpdf searches for text, too. How is it you've missed this? Probably because you're impatient and callously toss something away instead of appreciating it for what it is.
Also, esd makes mixing sound simple, and there already are drivers for mixing two streams of sound all over the drivers.
How is it you've missed this functionality? Beats me. Maybe you were too busy whining about it on Slashdot.
You never mentioned anything about a compatible CGI library in your original post. If you had, I wouldn't be sitting here (apparently wasting my time.)
You can't change your argument after the fact, turkey.:-) In this case, just state that you wrote a compatible library to the CGI library, and that your software modifies your own library, and that your own library wasn't based off the "real" CGI library, and you're off the hook. If I were the author of the CGI library I wouldn't pursue it. The fact that it's compatible with "my" CGI library is a bonus for your users.
Piece of cake. If your program doesn't modify the CGI library then you don't have to worry about the GPL.
The courts will eb loathe to support such "activism"? Now what are you on about I wonder. RMS has the perfect right to dictate to others how they use his software. Makes sense to me. You don't think the courts will agree? I wonder...
I think you'll be wrong about the use of GPL'd code unmodified. Else, we could embed huge chunks of Windows in our own software: Why would anyone want that kind of freedom for users? You'd effectively destroy a huge software industry.
Precedent is not another way of saying that laws are usually interpreted to mean what people think they mean. You've got the word wrong: precedent means that cases are decided using preceding judgements wherever possible: Judges follow previous decisions by other judges as much as possible. Often that has nothing to do with "what people think [the laws] mean.":-)
No, it doesn't matter. Linking to the LGPL'd library and then subsequently redistributing that work makes your software fall under the terms of the LGPL. It's safer to assume it's valid than it is to flout the terms of the license, and that's partly why companies haven't challenged it yet.
We can argue all we want here whether those LGPL terms are "allowed" or not under copyright law--and Rosen can say all he wants that linking to an LGPL library doesn't make thats oftware also fall under som eof the terms of the LGPL, but until it's challenged and defeated in court (pray that day never comes) it's safer to just abide by the terms of the LGPL, don't you think?
You *are* distributing a portion of the library when you distribute a piece of software that's been dynamically linked to it--the binary interfaces, definitions from the header files of the library, and so on. And you're DEFINITELY distributing whole chunks of the library when you link statically.:-)
You are causing to be modified the CGI library--regardless of the actual mechanism that does it, you're the one that's causing it to actually be done. So that part of your thesis needs a little work.
So I think the answer is no, it is not reasonable to write that code and claim it as your own unless you are also the author of the CGI library.
And an artist can't require royalties each time someome looks at his painting--he can just restrict access to the original. Also, many museums don't allow photographs. But the act of looking itself?
Doesn't matter--redistributing the software afterwards implies acceptance of the GPL terms: why do you think no company has actually tried to challenge the GPL yet? If they did, then many of the clauses in their own licenses would also be void--and they don't want that.
So we win both ways: if the companies claim that the GPL is unenforcable for simple linking, then much of the commercial EULA and licensing that is similar is also invalid. If they claim otherwise, then the GPL is totally enforceable and we also win.
Pure genius.
However, it is meaningful, and you aren't quite informed as to what the courts will or won't allow.
That's just as much a derivative work as if you had added another function that relied on other portions of the CGI library to work.
Either that, or the GPL and LGPL are unenforceable. If they were unenforceable, then why aren't more companies challenging the GPL? Or any companies for that matter? Answer: they don't want to invlidate their own licenses that make similar end-user restrictions.
By validating the GPL's ability to enforce such restrictions, they are affirming their own ability to enforce their own restrictions.
So it seems to me that the companies disagree with our man Rosen here.
..with the clauses of the LGPL, wherein it guarantees the right to reverse engineer the software linked to it--proprietary or no--and that any proprietary license that tries to revoke that right is in violation of the LGPL.
This means, of course, that the glibc library (which is under the LGPL) is the enabler for any reverse engineering that happens on pretty much any Linux system, anywhere.
Cool, IMHO. No so cool if this fellow is right and that simply linking to an LGPL'd library does not constitute a derivative work.
Basically, if Rosen's right, then the LGPL is invalidated at its core, and the GPL and the LGPL aren't allowed to dictate--in any fashion whatsoever--how end users are allowed to make use of software provided they make no modifications.
So where was it again that my monthly cable bill goes?
Bring it to the Supreme Court so we can get on with the civil disobedience part.
And I challenge you to find a way to charge me $0.01 per commercial skipped that won't piss every current VCR and computer owner off in the whole continent.
1. Make sure that the user has complete control over the system and isn't just a subverted single process.
2. Ensure that there's some modicum of proficiency on the part of the user: stupid people need not apply.
3. They're forcing people on multi-user machines to have some measure of self-accountability.
Fine by me: whiners are the ones who find it inconvenient. One minute of setup, and I never have to worry about it again. Why are you people whining about it?
I have a question about wink-in: How does ClearCase deal with languages it hasn't been specifically taught about? And, how precisely does it deal with C/C++ dependencies to decide whether something should be "winked-in" in another developer's workspace?
What I'm asking is whether clearmake actually builds a correct parse tree to calculate dependencies, or whether it has to be taught what depends on what by the fallible developers?
If the answers are no and no, then really, clearmake is useless except in specialized, tightly-controlled situations. Making the decision that another developer would benefit from an object compiled in someone else's tree is extremely touchy--what about makefiles? What about compiler switches? What about system libraries? What about subtle problems like an include that spans more than one line?
Sure I know nothing about ClearMake--but what's the benefit of downloading object files over just compiling them--especially when you're operating, say, over a dialup or remotely over a saturated T1? And what if it's all triggered just by a single modified dependency? Isn't it better, network abd bandwidth-wise, to just download that one file and let the workstation build from there? Seems like a big waste of bandwidth if you're going to download masses of object files just because of a single line of change in someone else's tree.
For the thousandth time, identd is NOT for the IRC network admin. It's for the remote admin who requests it in order to help track down *which* of their users was being neughty.
You ever thought of untrusted users on a multi-user system such as.. say.. a University's? In a multi-user system you can't spoof your ident unless you've got access to bind to port 113. Otherwise, it's a very helpful tool for the admin of those systems: you're just a goof if you think otherwise.
"No serious systems administrator."
Give me a break! SFU's system admins were some of the best UNIX-heads I've ever met!
Slashdot Mirror
How the heck will this help Crusoe sales?
Wow..
Come on, SCO. I *dare* you to try to collect royalties from people who run Linux. I frickin dare ya!
A loss? Are you on crack? It's software. How much do you really think they had to pay to develop it in the first place?
Yeesh.
Sigh.
Okay, let me be a little more patient with you, because you're going to a tremendous effort to write such long (and dorky) notes back:
1. I never said PDF sucks because Linux has poor support for it. I said exactly the other way around: Linux has poor support for PDF because PDF sucks. BIG difference, and it's too bad you missed it.
2. There are front-ends that don't "suck" other than xpdf. If you want the pretty graphics, and the cutesy hotkeys, and so on, then don't use xpdf. Personally I like the tiny footprint of xpdf. You obviously want something that looks like a Mac. Yay you.
3. Did you not just say that you had to buy a new sound card because your previous one wasn't performing up to your standards in Linux? And who's the fucking dolt? You're the one bitching about Linux drivers like some kind of petulant child. Are you aware of the kind of CPU wastage that happens when disparate samples are mixed in software? Perhaps the reason there is no software fallback is that there's no clean way to ensure that the impact of such mixing doesn't kill the system? Hm? Software mixing doesn't belong in the driver, and you're the dolt for thinking it does.
4. YOU were fucking whining about the lack of support for your older card: "I did, in fact, run out and purchas a SB Live just so that I could get multi-channel sound on Linux. Had I been using Windows, I could have made do with my older sound card and had exactly what I was looking for." So your older sound card didn't have enough channels for you? Jesus you're picky for someone using a free OS. And maybe there's a good reason why ALSA developers don't want to waste their time on software mixing?
5. The original post I was replying to was PDF support. I notice you've conveniently cut this out of your own notes. Does that mean I was right about PDF support under Linux? That xpdf does search through text after all? Hm? Perhaps YOU are the one misleading yourself, here: After all, xpdf *DOES* have text-searching capabilities, and you don't appear to be capable of clicking the little binoculars button at the bottom of the screen...
6. I love how you characterize the free software that you're enjoying that supports your multi-channel hardware as: "completely suck[s]". Oh, did you forget what you said? Here's a refresher: (Linux will not take off) "until the Linux sound architecture doesn't completely suck." What gratitude. What gratefulness. What willingness to volunteer to help.
What fucking bullshit.
You're just making an ass of yourself--give it up now before it's too late for redemption.
Try using a document that has actual text instead of images, and stop whining about not being able to search through the text IN AN IMAGE. What, do you want the system to do a little OCR for you? Highlight the image where it thinks the words you're looking for are? Get your head out of the clouds.
:-)
... where they list right on the front page they have support for multi-channel professional sound getups.
xpdf does have the ability to search through text, and if you can't find it or make effective use of it, that's really your problem then, isn't it?
PDF support sucks because PDF sucks.
Why do you expect others to write drivers for your existing hardware? And why do you whine when you didn't check to see whether your hardware was supported in the fashion you wanted before taking the Linux plunge?
Sounds like someone convinced you to use Linux, you ran out and bought a copy (or invested a pile of time in it,) without doing some rudimentary research first. Your friend is at fault for being a zealot without considering his actions, and you are at fault for not looking into the matter a little more carefully.
I apologize on behalf of the rest of us for your friend's over-enthusiasm.
Also, there already exist drivers that can mix sound together--but where do you want this to happen? In software? In hardware? Software solutions don't work so well because the streams may not match and may need to be resampled (a costly affair.) If you want support in the drivers you're using for the multi-channel hardware you might have (can SB Live play two completely different sample types at the same time?) then why not donate some hardware to someone who can do it or find some specs and write it yourself?
But check the ALSA project:
http://www.alsa-project.org
I read your question just fine--you apparently have forgotten there's this thing called Google.
You're missing a whole level of functionality then. xpdf searches for text, too. How is it you've missed this? Probably because you're impatient and callously toss something away instead of appreciating it for what it is.
Also, esd makes mixing sound simple, and there already are drivers for mixing two streams of sound all over the drivers.
How is it you've missed this functionality? Beats me. Maybe you were too busy whining about it on Slashdot.
You never mentioned anything about a compatible CGI library in your original post. If you had, I wouldn't be sitting here (apparently wasting my time.)
:-) In this case, just state that you wrote a compatible library to the CGI library, and that your software modifies your own library, and that your own library wasn't based off the "real" CGI library, and you're off the hook. If I were the author of the CGI library I wouldn't pursue it. The fact that it's compatible with "my" CGI library is a bonus for your users.
You can't change your argument after the fact, turkey.
Piece of cake. If your program doesn't modify the CGI library then you don't have to worry about the GPL.
(And is the CGI library even under the GPL...?)
The courts will eb loathe to support such "activism"? Now what are you on about I wonder. RMS has the perfect right to dictate to others how they use his software. Makes sense to me. You don't think the courts will agree? I wonder...
:-)
I think you'll be wrong about the use of GPL'd code unmodified. Else, we could embed huge chunks of Windows in our own software: Why would anyone want that kind of freedom for users? You'd effectively destroy a huge software industry.
Precedent is not another way of saying that laws are usually interpreted to mean what people think they mean. You've got the word wrong: precedent means that cases are decided using preceding judgements wherever possible: Judges follow previous decisions by other judges as much as possible. Often that has nothing to do with "what people think [the laws] mean."
No, it doesn't matter. Linking to the LGPL'd library and then subsequently redistributing that work makes your software fall under the terms of the LGPL. It's safer to assume it's valid than it is to flout the terms of the license, and that's partly why companies haven't challenged it yet.
:-)
We can argue all we want here whether those LGPL terms are "allowed" or not under copyright law--and Rosen can say all he wants that linking to an LGPL library doesn't make thats oftware also fall under som eof the terms of the LGPL, but until it's challenged and defeated in court (pray that day never comes) it's safer to just abide by the terms of the LGPL, don't you think?
You *are* distributing a portion of the library when you distribute a piece of software that's been dynamically linked to it--the binary interfaces, definitions from the header files of the library, and so on. And you're DEFINITELY distributing whole chunks of the library when you link statically.
You are causing to be modified the CGI library--regardless of the actual mechanism that does it, you're the one that's causing it to actually be done. So that part of your thesis needs a little work.
So I think the answer is no, it is not reasonable to write that code and claim it as your own unless you are also the author of the CGI library.
And an artist can't require royalties each time someome looks at his painting--he can just restrict access to the original. Also, many museums don't allow photographs. But the act of looking itself?
Doesn't matter--redistributing the software afterwards implies acceptance of the GPL terms: why do you think no company has actually tried to challenge the GPL yet? If they did, then many of the clauses in their own licenses would also be void--and they don't want that.
So we win both ways: if the companies claim that the GPL is unenforcable for simple linking, then much of the commercial EULA and licensing that is similar is also invalid. If they claim otherwise, then the GPL is totally enforceable and we also win.
Pure genius.
However, it is meaningful, and you aren't quite informed as to what the courts will or won't allow.
That's just as much a derivative work as if you had added another function that relied on other portions of the CGI library to work.
Either that, or the GPL and LGPL are unenforceable. If they were unenforceable, then why aren't more companies challenging the GPL? Or any companies for that matter? Answer: they don't want to invlidate their own licenses that make similar end-user restrictions.
By validating the GPL's ability to enforce such restrictions, they are affirming their own ability to enforce their own restrictions.
So it seems to me that the companies disagree with our man Rosen here.
Don't be obtuse. What about compatible but entirely separate .NET platforms like Mono or DotGNU or whatever it's called now?
The LGPL/GPL don't just "assume" the meaning of derivative work. They quite explicitly define it.
..with the clauses of the LGPL, wherein it guarantees the right to reverse engineer the software linked to it--proprietary or no--and that any proprietary license that tries to revoke that right is in violation of the LGPL.
This means, of course, that the glibc library (which is under the LGPL) is the enabler for any reverse engineering that happens on pretty much any Linux system, anywhere.
Cool, IMHO. No so cool if this fellow is right and that simply linking to an LGPL'd library does not constitute a derivative work.
Basically, if Rosen's right, then the LGPL is invalidated at its core, and the GPL and the LGPL aren't allowed to dictate--in any fashion whatsoever--how end users are allowed to make use of software provided they make no modifications.
That would seriously SUCK.
.. you could just get behind Debian and push that a little harder. Debian is cool. .. uh.. I've never used Debian but I like their package system. :-)
Don't hurt me.
I've broken the following CDs in various 40x-52x CD drives:
...and then I trashed the drive with a sledgehammer.
Unreal Tournament Disk 1
Quake 3 Arena
4 critical backups on CDRW media,
Why did I keep them so long? Because I wanted to burn CDs faster, much like whoever thought this story was a good post.
No longer.
Well it seems simple enough to me: Show him what it would take to write an event queue and then call him a pussy when he blanches!
Event queues dammit! select(), poll(), or signal-driven event queues are the way to go for anyone who wants to do something Really Impressive.
One fork() per second (especially in Linux where threads are "emulated" with clone()) has similar impact under Linux to using threads.
But why bother with threads? Use one process per CPU (if needed) and accept computational tasks using either shared memory or message-passing.
Event-queues! There's the ticket! Single-process event queues..! Ha ha! Be a masochist with me and join the event-queue fanclub!
So where was it again that my monthly cable bill goes?
Bring it to the Supreme Court so we can get on with the civil disobedience part.
And I challenge you to find a way to charge me $0.01 per commercial skipped that won't piss every current VCR and computer owner off in the whole continent.
No.. It was a hello world output, that was the whole point.
The requirements are simple:
1. Make sure that the user has complete control over the system and isn't just a subverted single process.
2. Ensure that there's some modicum of proficiency on the part of the user: stupid people need not apply.
3. They're forcing people on multi-user machines to have some measure of self-accountability.
Fine by me: whiners are the ones who find it inconvenient. One minute of setup, and I never have to worry about it again. Why are you people whining about it?
I have a question about wink-in: How does ClearCase deal with languages it hasn't been specifically taught about? And, how precisely does it deal with C/C++ dependencies to decide whether something should be "winked-in" in another developer's workspace?
What I'm asking is whether clearmake actually builds a correct parse tree to calculate dependencies, or whether it has to be taught what depends on what by the fallible developers?
If the answers are no and no, then really, clearmake is useless except in specialized, tightly-controlled situations. Making the decision that another developer would benefit from an object compiled in someone else's tree is extremely touchy--what about makefiles? What about compiler switches? What about system libraries? What about subtle problems like an include that spans more than one line?
Sure I know nothing about ClearMake--but what's the benefit of downloading object files over just compiling them--especially when you're operating, say, over a dialup or remotely over a saturated T1? And what if it's all triggered just by a single modified dependency? Isn't it better, network abd bandwidth-wise, to just download that one file and let the workstation build from there? Seems like a big waste of bandwidth if you're going to download masses of object files just because of a single line of change in someone else's tree.
Yeesh.
For the thousandth time, identd is NOT for the IRC network admin. It's for the remote admin who requests it in order to help track down *which* of their users was being neughty.
Get it? Jesus you people, get a fuckin clue!
You ever thought of untrusted users on a multi-user system such as.. say.. a University's? In a multi-user system you can't spoof your ident unless you've got access to bind to port 113. Otherwise, it's a very helpful tool for the admin of those systems: you're just a goof if you think otherwise.
"No serious systems administrator."
Give me a break! SFU's system admins were some of the best UNIX-heads I've ever met!