But isn't that the first guys point. Sure it would compress better, "better" here meaning smaller. But the compressed audio would sound even more shitty than the original. Theoretically a single high pitch or low pitch note.
So by mastering the CD the way they did maybe they were hoping it would still sound "good enough" from CD but so shitty as an MP3 as to make it worthless in that format. Unfortunately it seems it's worthless in any format.
I wouldn't think so. I'd think that by throwing the info away in advance, it'd compress better and sound closer to the "original" than if they'd put the right mix there in the first place.
I admit I'm not totally hip on audio compression to that level of detail, but when they're essentially throwing away sound by clipping it, then it's seems it'd be a heck of a lot easier to compress because there's less actual data there to compress.
Nope. If you were to try to compress some of those harsh clipped signals, you'd get much better compression than trying to compress a signal with good headroom to it. Go read the article and look at those signals. The peaks and troughs are just way the hell off the scale. When you clip a peak or trough like that, you're essentially throwing away all signal information that was in there. It's really easy to compress something when it's made up of all zero's.
Back in my senior year of high school, we had some sort of tracking system that was based primarily on attendance. It flagged me as a student that was going to fail out, never mind my 3.9 GPA and my acceptance to Stanford based upon the entrance exams (untimately did not go to Stanford because I could not afford the $25k/year). I had a meeting with our vice principal telling me I was in serious trouble with my attendance. What a joke.
Heh. I never had this sort of problem in college until my junior year, when my Physics prof called me into his office. He told me that I had been to something like 25% of the classes, and he was going to drop me because that was the "rules" of the university. Then he realized that I had the second highest grade in the class, so he called me in. My general response was "yeah, doesn't the rule seem stupid?"
Him and one other teacher were the only ones who had ever given me trouble with that rule. I attended much less than 50% of my classes the entire time I was in college and got quite good grades indeed. I just didn't attend the time wasting classes, and did attend the ones where I needed to know the information being presented.
All college rules based solely upon attendance are stupid and worthless. However, in high school, there's legal issues to be resolved, I think, in that you have to attend school until such and such age, and the school is responsible for you during those hours and so on. But other than that, I agree with you.
Some of the other lovely competitions that UMR competes in every year include the concrete canoe races (people actually build canoes out of concrete and race them) and mucking (old time mining).
I think you left out competitive drinking. In a place where kegs can be bought for $25, it's almost a given, really.;)
As a matter of fact, if I understand this correctly, it's just a more efficient and faster way to search for something. So if you have any database, you could implement this search alg. for any plaintext data, or, depending on the implementation, any data at all. Not sure if it would be realistically feasible for some real-world app, but it's an idea.
Well, not really, I think. Basically, the method is to generate keys from other key's hashes, and thus form chains of keys. Then you only have to store the first and last endpoints of those keys.
Think of it like this: For every possible password, I can generate a hash, or ciphertext. So what you do is to create a "reduction function" that will generate a password (any password) from that hash. Then you apply the hash to it again, and so on. This creates a chain of alternating keys and hashes.
So I make a whole lot of these chains, and then only store the beginning and ending points on that chain.
Now, when I want to decode a hash, I start by creating a key from it using my function. Then I hash it. Then I search the big list of endpoints. If I don't find it, I repeat the process. Eventually I will find the hash I have now matches one of my endpoints. So I start the chain again from the starting point for that endpoint, and calculate until I find my hash, at which point I know what the password was to get that hash (because I just calculated it).
This has the effect of reducing the size of the hashes I have to search through, because if my chains are say, 10 hashes long, then the number of hashes is reduced by a factor of ten.
This has a problem whereby you can create loops and/or merged chains, where you end up with two different chains that have different start points but come together into the same endpoints. That has to be accounted for.
Their new method in the paper is to include the position in the chain as part of the reduction function. They go on to show how this eliminates loops completely, makes merged chains improbable and easily detectable when they do occur, and even can reduce the number of hash calculations that are needed to be done by half, on average.
So it doesn't really apply itself well to more normal types of searching, unless you're searching in a set of data that can be wholly precalcuated.
If you read their paper, then they actually did do something kinda nifty.
Short version is that they precalculated a hell of a lot of hashes to passwords.
This is possible on Windows because it uses no salt for the password (no machine specific number to create the hash). So one password generates the same hash on all Windows boxes.
Where they actually did something nifty is devised a way to do an extremely fast lookup through those hashes. You input the hash and it can find it in that 1.4 gig of data within 13.6 seconds, as opposed to 101 seconds using the older fastest way available.
I disagree that the definition of linking we use is different from everyone else's. And I disagree that proprietary software vendors will avoid LGPL software -- given the amount of high-quality LGPL libraries available, they will make the rational decision: it's better to not have unenforcable clauses in their license than to reinvent the wheel. Ten years of history shows that the LGPL is popular and effective.
I think you're failing to understand something here. Ten years of history shows it to be effective because everyone knew what "linking" meant, and you've just turned that on it's ear.
I know for an absolute *fact* that by your terms, I've violated the LGPL license. So has probably anyone who's ever used an LGPL library in an closed source project. Not intentionally, mind you, but just because they don't use your unusual definition there.
Proprietary vendors may not have avoided LGPL in the past, but if they ever find out about your definition, they sure as heck will avoid it now. Why? Because they've gotten burned here, without even knowing it.
...reverse engineering happens whether or not licenses allow it. While that's true, it's also irrelevant. What license have you seen for any major product that doesn't have "you agree not to blah, blah, reverse engineer, blah.." in it?
Such a strange definition being used for linking forces companies into Section 6, and therefore they won't be adopting open source libraries, and won't be contributing back to those libraries.
Look, guy, you can argue this all you want, but in the end, your definition of "linking" is still contrary to everybody else's in the whole bloody world, and that unusual definition makes the LGPL suck big time.
To put it another way that hopefully illustrates how stupid that definition is:
Say I make code that calls upon an LGPL library:
- If I distribute the library and the closed code in separate installers, I don't fall under section 6, but only under section 5.
- If I create a single installer for both, then I now fall under section 6.
See the ridiculousness of this? Nothing actually changed in any code anywhere, but because I'm now packaging in one zip file instead of two, I now have to leave myself open to reverse engineering and modification of my program by anybody. How dumb is that?
It's not true that code linked to and distributed with an LGPL library needs to be licensed under the LGPL.
No, but by your definition, it does need to allow reverse engineering and modification for personal use.
That's not acceptable to a closed source project, and is a very big reason not to use the LGPL. It's also non-sensical, non-intuitive, and not the way that any normal person would read the document and understand it because of your wacky way to define "linking".
This is simply not true! The LGPL's section 6 (the section in question) allows you to link proprietary software to a LGPL library.
Not realistically, it doesn't. Not if you define "linking" as "putting two items in the distribution package".
Whoa, what "stigma"? Do you mean that the calling code must be LGPL? That's not correct. But the calling code must obey the small restrictions in section 6 of the LGPL. The goal of these restrictions are to make sure you can link in new versions of the LGPL library.
But they don't do that. The requirement for "reverse engineering" and "ability to modify" simply make it impossible for any realistic closed source application to use any LGPL'd library. Those are impossible restrictions to place upon the developer of closed source code, and no closed source developer in his right mind would agree to them.
What the restrictions of section 6 do, if you define "linking" with such a broad brush, is ensure that LGPL'd libraries never get used by anybody other than open source projects. Period.
I, for one, sure as hell won't be using any LGPL'd code after this, because the requirement to allow people to reverse engineer and modify my code is unacceptable. If I wanted to allow them to do that, then I would have made the project open source in the first freakin' place.
Your wacky definition of "linking" in the LGPL fails to accomplish the goals of the LGPL, which is to make libraries which will be used by both open and closed source developers and which will allow closed source developers to contribute to the open source community without compromising their own closed source code. It is *viral* because it now FORCES developers to open up their code, even if it's just a little bit.
That's wholly unacceptable, and it's also not what any normal person would read the LGPL document and think, because you're defining "linking" differently than every programmer on the face of the earth has done since the beginning of time.
In other words, by your definition, it's utterly impossible for anyone making code that uses any LGPL library of any type to create one distribution file that includes both the code and the LGPL'd library, without getting the most definitely undesirable stigma of section 6 attached to the code.
The whole point of the LGPL is to create libraries that are open source but which can be used by closed source programs, requiring only that any modifications to the *library* be distributed back into open source. Your definition requires more than that, and thus the LGPL doesn't do what everybody has thought it did for the past X years.
Distributing a jar, along with some code which will end up calling code from that jar, is linking to that jar. The actual bindings are resolved at runtime (although as I understand it, the jar needs to be present at compile time too), but it's still linking.
That's the most wacked out crazy way to look at linking I have ever heard, and if that is in fact the case, then the LGPL is severely broken and should never be used in any circumstances whatsoever, by anybody.
Furthermore, if that's the case, nobody should ever use LGPL'd libraries, as it definitely *is* viral in nature. Your definition is contrary to the popular view of the LGPL.
By your definition, if I distribute a DLL in the same installer as code that calls upon that DLL, and the DLL is open sourced and LGPL'd, then the code calling that DLL now has stigma attached to it that, most likely, the maker of the DLL didn't intend to attach to it and that the creator of the code had no idea that was there.
In other words, by your definition, it's utterly impossible for anyone making code that uses any LGPL library of any type to create one distribution file that includes both the code and the LGPL'd library, period.
Okay, if I make a piece of java code, like a class, and provide methods to use that class, and wrap this up in a jar file and say it's now under LGPL, then here's what somebody should be able to do (IMO):
1. Create java code which uses my library (jar file) with the library as a separate jar file (ie., none of my code is in their code, they're just calling methods and classes from my code).
2. Not have any requirements placed upon their code at all in any way.
As I see it, this is exactly what the LGPL does. Section 6 never comes into play whatsoever, because their code falls into section 5. They haven't actually combined my code into theirs, it's totally separate, sitting right in that jar file (aka library).
Granted, if they modify my code and distribute the modified version, then they must distribute the modifications they made to my code as well. That's what the LGPL is for in the first place.
But I fail to see how section 6 applies in any way whatsoever. None of my LGPL'd code is included in their code in any way. It's separated because it's in a separate jar file.
Lookie here: 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
To me, this exactly describes someone calling classes or other code that resides in my jar file. They're not copying the code into their own jar, they're linking to it. But let's look at section 6:
6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library...
This never happens if done properly. My jar is sitting alone, their jar is sitting alone. At runtime, their jar loads, says to the java interpreter "hey, make a class from that other jar", then my jar loads and a class gets created.
So, am I wrong here? I see no normal situation in which section 6 would ever apply to Java libraries, unless someone was straight up ripping my classes off and including them in their own jar file along with their own code.
Re:the slashdot story is mis-interpreting the post
on
LGPL is Viral for Java
·
· Score: 1
No. According to this interpretation, any app at all that uses any LGPL library must be GPL or LGPL itself. The LGPL has a clause that says that you must provide the code to your app in a form that can be linked with a future version of the LGPLed library; this is apparently difficult with Java.
Now, I'll be the first to admit that I don't know a hell of a lot of Java, but I'm notunderstanding this at all. Linking is done at run-time. If I have a "library" in Java, then all it really is is a separate jar file with some classes in it. Those classes have public methods, which I'm importing and calling upon.
If I want to use a more up to date version of that library, then I simply replace the libraries jar file with the more up to date version and restart the program.
So I fail to see how why I have to make my app LGPL or any damn license at all, really. If someone wants to use a newer library, they can just drop the new jar in place. There's no "recompiling" that needs to be done.
Holy crap. Okay, fair enough, but frankly, you need virtual desktops in a bad way. I can't even conceive of trying to manage 80 items, tabbed or not.
Forget tabs, start organizing by tasks. Put similar tasks on different desktops. Then have a work desktop (or 2), a personal desktop, etc, etc. It's a lot easier to manage what you're doing that way.
When you are running lots of programs at once, a row of browser tabs at the top of the screen is vastly more efficient than twenty browser tabs mixed in the taskbar interspersed with other unrelated applications.
I grant you that, however, I cannot see a need to have more than, say, three, perhaps four, foreground windowed applications running at once, ever. And in most cases I'd switch to a virtual desktop and run them there.
The first is that you can group related sites into one window. For instance, when I am simultaneously browsing through slashdot and nytimes and TV listings and weather reports, I can open one window for each group of pages and use tabs in each window to get multiple pages within each group. This two-level organization is impossible with a single taskbar.
Now this is the first actually useful reason for tabbing that I've seen. Okay, I'm with you on that one. However, there's very few cases where I'd need that type of browsing organization.
- 3 or 4 mIRC entries - 2 to 10 IE entries (average say about 6) - 1 Outlook Express entry - 1 Explorer (file, not web) entry - 1 binary newsgroup leecher - 1 Winamp
Holy crap, man. SIMPLIFY. -Run Winamp as a taskbar icon, there's no need to have it taking space when you're not switching to it and it's just playing background music. -Stop running your full email client all the time, get a small client to check your every x minutes for you and pop up a message or flash an icon or something. There's plenty of better ways out there. -So many mIRC's: Get a life?;-) Seriously, look into virtual desktops, or just run one instance of mIRC connected to all those servers. You don't need 4 mIRC windows open. -Binary Newsgroup Leecher: Stop pirating crappy games? Lay off the porn? I dunno, man.:-D
In any case, if you have anything running *all the time* then why the hell are you running it as an application? Set it up as a background process, or a service, or scheduled task. I see *no* reason to leave a windowed application running 24/7. That's just inefficent.
In Opera, disable the Page bar and use Ctrl+Tab to switch between tabs (or 1 and 2).
Or just use windows and hit Alt-Tab to switch between them.
But anyway, tabbed browsing is great, especially if you open a lot of browser windows, because it doesn't clutter up your main task bar. How much crap do you have in your main task bar? Do people really run like 15 applications at once? If I have much more than three, I can't keep up. It's one thing to surf 10 pages at the same time, it's a whole other to have email, irc, a word processor, etc, etc.
You might want to consider using multiple virtal window spaces. If I have more than about 3 apps I need to run, I shift to another desktop and run it there.
And the tabs don't take up much space anyway. Methinks you are kind of grasping for straws, unless you are running in 640x480 or something.
No, I usually run at 1400x1050, for preference. But the tabs take up at least the same space as the height of the address bar, more if you have enough browsers going that it's trying to display multiple rows of tabs. And if you don't display multiple rows, then you have to scroll left/right using those damned small arrows at the sides, which frankly annoys me to no end.
I always had a problem with IE in that it would *never* remember windows positions for multiple browsers.
I never have that problem, as my IE window is always maximized. On the rare occasion that I need to see something else on the screen, I can reposition it.
the ability to have mutiple tabs as your startup pages
My startup page is about:blank, so I doubt this applies to me. I have no desire to waste my time loading a startup page or pages when I'm loading the browser to go somewhere else anyway (usually a google search which I can simply type into the address bar). about:blank is fast and efficent.
if the browser does crash, you can do a quick restore and start surfing again right where you left off
If the browser crashed, I'd get a new browser. I've never had IE crash unless I've gone to demonstration pages showing off IE specific bugs, or gone to "most annoying javascript" type pages. I haven't found these sorts of bugs "in the wild", yet.
As for cleaner, I fail to see how having more screen space taken by crap that ain't what you're looking at is any less cluttered. The tabs take up extra space. This is a given. The windows on the taskbar *don't* take any extra space. If they weren't there, there'd just be, hah, a blank taskbar.
I agree with "to each his own", but everyone seems to love tabs and for the life of me, I cannot understand why.
Nothing seems to happen? Hello, what of all these features:
Tabbed browsing
Why in the hell is everyone so big on tabbed browsing? I tried it, and frankly it pissed me off. Why? Because it did the same thing that multiple window browsing does, but it did it while adding an extra line for the tabs at the top of my page, further reducing my screen real estate that can use for the actual web page I'm trying to read.
I multi window surf all the time. I frequently have 10+ browser windows open. But I detested tabbed browsing when I tried it, and removed Mozilla yet again (since it's still slow and bloated and the only reason I installed it again was to see what the tabbed fuss was all about).
I mean, how, exactly, is giving me a clickable list of browser pages at the top of the screen any better than giving me a clickable list of browser pages at the bottom of the screen (in the toolbar, where my windows are listed)? Be detailed, mind you. It's still one process either way, I'm not loading multiple copies of the browser into memory (check the task manager). It's just as fast to switch windows as it is to switch tabs. And the window bar takes up space on the screen already, giving it that slight edge over tabbed browsing, in my view.
I just fail to see the benefits, but there's a very good downside. I use my browser maximized, with most menus and toolbars off. Why? So I can see what I'm reading. Anything that reduces my screen space is an instant loser.
Until the day I die, I will pronounce it with a hard G because it makes more sense, and isn't easily confused with.JIF files, another image file format, albeit not one commonly used.
The inventor of the format can correct me all day long. He's still wrong.
But you can't stop them (__AA) using a real client behind a network device that can sniff the traffic and find out who / where / what you are sharing even with encryption.
True, but with something like the FreeNet protocols, how do you even know you're sharing it? And encrypted links can be made secure against man in the middle attacks if you care to put in the effort. And even so, they'd have to actually DOWNLOAD something from you in order to prove you have it. And once their reputation drops, and they get revoked by a few people, they suddenly find they can't download anything, because that client or even IP block is no longer trusted.
We're not talking a P2P with a million users here. But even a P2P among people I personally know with MP3's comes to one hell of a large collection of sound, for example.
Excuse me, but doesn't Nullsoft's W.A.S.T.E. (see/. a couple days ago) already accomplish this without special handware -- and without Microsoft?
Yes, but you could do it in a somewhat more robust fashion than WASTE does. And you still can't trust the hardware with waste, nor the software for that matter.
Slashdot Mirror
But isn't that the first guys point. Sure it would compress better, "better" here meaning smaller. But the compressed audio would sound even more shitty than the original. Theoretically a single high pitch or low pitch note.
So by mastering the CD the way they did maybe they were hoping it would still sound "good enough" from CD but so shitty as an MP3 as to make it worthless in that format. Unfortunately it seems it's worthless in any format.
I wouldn't think so. I'd think that by throwing the info away in advance, it'd compress better and sound closer to the "original" than if they'd put the right mix there in the first place.
I admit I'm not totally hip on audio compression to that level of detail, but when they're essentially throwing away sound by clipping it, then it's seems it'd be a heck of a lot easier to compress because there's less actual data there to compress.
Nope. If you were to try to compress some of those harsh clipped signals, you'd get much better compression than trying to compress a signal with good headroom to it. Go read the article and look at those signals. The peaks and troughs are just way the hell off the scale. When you clip a peak or trough like that, you're essentially throwing away all signal information that was in there. It's really easy to compress something when it's made up of all zero's.
Back in my senior year of high school, we had some sort of tracking system that was based primarily on attendance. It flagged me as a student that was going to fail out, never mind my 3.9 GPA and my acceptance to Stanford based upon the entrance exams (untimately did not go to Stanford because I could not afford the $25k/year). I had a meeting with our vice principal telling me I was in serious trouble with my attendance. What a joke.
Heh. I never had this sort of problem in college until my junior year, when my Physics prof called me into his office. He told me that I had been to something like 25% of the classes, and he was going to drop me because that was the "rules" of the university. Then he realized that I had the second highest grade in the class, so he called me in. My general response was "yeah, doesn't the rule seem stupid?"
Him and one other teacher were the only ones who had ever given me trouble with that rule. I attended much less than 50% of my classes the entire time I was in college and got quite good grades indeed. I just didn't attend the time wasting classes, and did attend the ones where I needed to know the information being presented.
All college rules based solely upon attendance are stupid and worthless. However, in high school, there's legal issues to be resolved, I think, in that you have to attend school until such and such age, and the school is responsible for you during those hours and so on. But other than that, I agree with you.
Some of the other lovely competitions that UMR competes in every year include the concrete canoe races (people actually build canoes out of concrete and race them) and mucking (old time mining).
;)
I think you left out competitive drinking. In a place where kegs can be bought for $25, it's almost a given, really.
As a matter of fact, if I understand this correctly, it's just a more efficient and faster way to search for something. So if you have any database, you could implement this search alg. for any plaintext data, or, depending on the implementation, any data at all. Not sure if it would be realistically feasible for some real-world app, but it's an idea.
Well, not really, I think. Basically, the method is to generate keys from other key's hashes, and thus form chains of keys. Then you only have to store the first and last endpoints of those keys.
Think of it like this:
For every possible password, I can generate a hash, or ciphertext. So what you do is to create a "reduction function" that will generate a password (any password) from that hash. Then you apply the hash to it again, and so on. This creates a chain of alternating keys and hashes.
So I make a whole lot of these chains, and then only store the beginning and ending points on that chain.
Now, when I want to decode a hash, I start by creating a key from it using my function. Then I hash it. Then I search the big list of endpoints. If I don't find it, I repeat the process. Eventually I will find the hash I have now matches one of my endpoints. So I start the chain again from the starting point for that endpoint, and calculate until I find my hash, at which point I know what the password was to get that hash (because I just calculated it).
This has the effect of reducing the size of the hashes I have to search through, because if my chains are say, 10 hashes long, then the number of hashes is reduced by a factor of ten.
This has a problem whereby you can create loops and/or merged chains, where you end up with two different chains that have different start points but come together into the same endpoints. That has to be accounted for.
Their new method in the paper is to include the position in the chain as part of the reduction function. They go on to show how this eliminates loops completely, makes merged chains improbable and easily detectable when they do occur, and even can reduce the number of hash calculations that are needed to be done by half, on average.
So it doesn't really apply itself well to more normal types of searching, unless you're searching in a set of data that can be wholly precalcuated.
If you read their paper, then they actually did do something kinda nifty.
r ch.php?ref=Oech03
Short version is that they precalculated a hell of a lot of hashes to passwords.
This is possible on Windows because it uses no salt for the password (no machine specific number to create the hash). So one password generates the same hash on all Windows boxes.
Where they actually did something nifty is devised a way to do an extremely fast lookup through those hashes. You input the hash and it can find it in that 1.4 gig of data within 13.6 seconds, as opposed to 101 seconds using the older fastest way available.
So it's news worthy not in that they cracked M$ crappy passwords, but in that they developed a better search method to do it fast. Read the paper here: http://lasecwww.epfl.ch/php_code/publications/sea
I disagree that the definition of linking we use is different from everyone else's. And I disagree that proprietary software vendors will avoid LGPL software -- given the amount of high-quality LGPL libraries available, they will make the rational decision: it's better to not have unenforcable clauses in their license than to reinvent the wheel. Ten years of history shows that the LGPL is popular and effective.
I think you're failing to understand something here. Ten years of history shows it to be effective because everyone knew what "linking" meant, and you've just turned that on it's ear.
I know for an absolute *fact* that by your terms, I've violated the LGPL license. So has probably anyone who's ever used an LGPL library in an closed source project. Not intentionally, mind you, but just because they don't use your unusual definition there.
Proprietary vendors may not have avoided LGPL in the past, but if they ever find out about your definition, they sure as heck will avoid it now. Why? Because they've gotten burned here, without even knowing it.
...reverse engineering happens whether or not licenses allow it.
While that's true, it's also irrelevant. What license have you seen for any major product that doesn't have "you agree not to blah, blah, reverse engineer, blah.." in it?
Such a strange definition being used for linking forces companies into Section 6, and therefore they won't be adopting open source libraries, and won't be contributing back to those libraries.
Look, guy, you can argue this all you want, but in the end, your definition of "linking" is still contrary to everybody else's in the whole bloody world, and that unusual definition makes the LGPL suck big time.
Them's just the facts.
To put it another way that hopefully illustrates how stupid that definition is:
Say I make code that calls upon an LGPL library:
- If I distribute the library and the closed code in separate installers, I don't fall under section 6, but only under section 5.
- If I create a single installer for both, then I now fall under section 6.
See the ridiculousness of this? Nothing actually changed in any code anywhere, but because I'm now packaging in one zip file instead of two, I now have to leave myself open to reverse engineering and modification of my program by anybody. How dumb is that?
It's not true that code linked to and distributed with an LGPL library needs to be licensed under the LGPL.
No, but by your definition, it does need to allow reverse engineering and modification for personal use.
That's not acceptable to a closed source project, and is a very big reason not to use the LGPL. It's also non-sensical, non-intuitive, and not the way that any normal person would read the document and understand it because of your wacky way to define "linking".
This is simply not true! The LGPL's section 6 (the section in question) allows you to link proprietary software to a LGPL library.
Not realistically, it doesn't. Not if you define "linking" as "putting two items in the distribution package".
Whoa, what "stigma"? Do you mean that the calling code must be LGPL? That's not correct. But the calling code must obey the small restrictions in section 6 of the LGPL. The goal of these restrictions are to make sure you can link in new versions of the LGPL library.
But they don't do that. The requirement for "reverse engineering" and "ability to modify" simply make it impossible for any realistic closed source application to use any LGPL'd library. Those are impossible restrictions to place upon the developer of closed source code, and no closed source developer in his right mind would agree to them.
What the restrictions of section 6 do, if you define "linking" with such a broad brush, is ensure that LGPL'd libraries never get used by anybody other than open source projects. Period.
I, for one, sure as hell won't be using any LGPL'd code after this, because the requirement to allow people to reverse engineer and modify my code is unacceptable. If I wanted to allow them to do that, then I would have made the project open source in the first freakin' place.
Your wacky definition of "linking" in the LGPL fails to accomplish the goals of the LGPL, which is to make libraries which will be used by both open and closed source developers and which will allow closed source developers to contribute to the open source community without compromising their own closed source code. It is *viral* because it now FORCES developers to open up their code, even if it's just a little bit.
That's wholly unacceptable, and it's also not what any normal person would read the LGPL document and think, because you're defining "linking" differently than every programmer on the face of the earth has done since the beginning of time.
Let me rephrase that last statement:
In other words, by your definition, it's utterly impossible for anyone making code that uses any LGPL library of any type to create one distribution file that includes both the code and the LGPL'd library, without getting the most definitely undesirable stigma of section 6 attached to the code.
The whole point of the LGPL is to create libraries that are open source but which can be used by closed source programs, requiring only that any modifications to the *library* be distributed back into open source. Your definition requires more than that, and thus the LGPL doesn't do what everybody has thought it did for the past X years.
Distributing a jar, along with some code which will end up calling code from that jar, is linking to that jar. The actual bindings are resolved at runtime (although as I understand it, the jar needs to be present at compile time too), but it's still linking.
That's the most wacked out crazy way to look at linking I have ever heard, and if that is in fact the case, then the LGPL is severely broken and should never be used in any circumstances whatsoever, by anybody.
Furthermore, if that's the case, nobody should ever use LGPL'd libraries, as it definitely *is* viral in nature. Your definition is contrary to the popular view of the LGPL.
By your definition, if I distribute a DLL in the same installer as code that calls upon that DLL, and the DLL is open sourced and LGPL'd, then the code calling that DLL now has stigma attached to it that, most likely, the maker of the DLL didn't intend to attach to it and that the creator of the code had no idea that was there.
In other words, by your definition, it's utterly impossible for anyone making code that uses any LGPL library of any type to create one distribution file that includes both the code and the LGPL'd library, period.
That's freakin' insane.
Okay, if I make a piece of java code, like a class, and provide methods to use that class, and wrap this up in a jar file and say it's now under LGPL, then here's what somebody should be able to do (IMO):
1. Create java code which uses my library (jar file) with the library as a separate jar file (ie., none of my code is in their code, they're just calling methods and classes from my code).
2. Not have any requirements placed upon their code at all in any way.
As I see it, this is exactly what the LGPL does. Section 6 never comes into play whatsoever, because their code falls into section 5. They haven't actually combined my code into theirs, it's totally separate, sitting right in that jar file (aka library).
Granted, if they modify my code and distribute the modified version, then they must distribute the modifications they made to my code as well. That's what the LGPL is for in the first place.
But I fail to see how section 6 applies in any way whatsoever. None of my LGPL'd code is included in their code in any way. It's separated because it's in a separate jar file.
Lookie here:
5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
To me, this exactly describes someone calling classes or other code that resides in my jar file. They're not copying the code into their own jar, they're linking to it. But let's look at section 6:
6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library...
This never happens if done properly. My jar is sitting alone, their jar is sitting alone. At runtime, their jar loads, says to the java interpreter "hey, make a class from that other jar", then my jar loads and a class gets created.
So, am I wrong here? I see no normal situation in which section 6 would ever apply to Java libraries, unless someone was straight up ripping my classes off and including them in their own jar file along with their own code.
No. According to this interpretation, any app at all that uses any LGPL library must be GPL or LGPL itself. The LGPL has a clause that says that you must provide the code to your app in a form that can be linked with a future version of the LGPLed library; this is apparently difficult with Java.
Now, I'll be the first to admit that I don't know a hell of a lot of Java, but I'm notunderstanding this at all. Linking is done at run-time. If I have a "library" in Java, then all it really is is a separate jar file with some classes in it. Those classes have public methods, which I'm importing and calling upon.
If I want to use a more up to date version of that library, then I simply replace the libraries jar file with the more up to date version and restart the program.
So I fail to see how why I have to make my app LGPL or any damn license at all, really. If someone wants to use a newer library, they can just drop the new jar in place. There's no "recompiling" that needs to be done.
Or am I misunderstanding the issue here?
Holy crap. Okay, fair enough, but frankly, you need virtual desktops in a bad way. I can't even conceive of trying to manage 80 items, tabbed or not.
Forget tabs, start organizing by tasks. Put similar tasks on different desktops. Then have a work desktop (or 2), a personal desktop, etc, etc. It's a lot easier to manage what you're doing that way.
When you are running lots of programs at once, a row of browser tabs at the top of the screen is vastly more efficient than twenty browser tabs mixed in the taskbar interspersed with other unrelated applications.
I grant you that, however, I cannot see a need to have more than, say, three, perhaps four, foreground windowed applications running at once, ever. And in most cases I'd switch to a virtual desktop and run them there.
The first is that you can group related sites into one window. For instance, when I am simultaneously browsing through slashdot and nytimes and TV listings and weather reports, I can open one window for each group of pages and use tabs in each window to get multiple pages within each group. This two-level organization is impossible with a single taskbar.
Now this is the first actually useful reason for tabbing that I've seen. Okay, I'm with you on that one. However, there's very few cases where I'd need that type of browsing organization.
- 3 or 4 mIRC entries
;-) Seriously, look into virtual desktops, or just run one instance of mIRC connected to all those servers. You don't need 4 mIRC windows open. :-D
- 2 to 10 IE entries (average say about 6)
- 1 Outlook Express entry
- 1 Explorer (file, not web) entry
- 1 binary newsgroup leecher
- 1 Winamp
Holy crap, man. SIMPLIFY.
-Run Winamp as a taskbar icon, there's no need to have it taking space when you're not switching to it and it's just playing background music.
-Stop running your full email client all the time, get a small client to check your every x minutes for you and pop up a message or flash an icon or something. There's plenty of better ways out there.
-So many mIRC's: Get a life?
-Binary Newsgroup Leecher: Stop pirating crappy games? Lay off the porn? I dunno, man.
In any case, if you have anything running *all the time* then why the hell are you running it as an application? Set it up as a background process, or a service, or scheduled task. I see *no* reason to leave a windowed application running 24/7. That's just inefficent.
In Opera, disable the Page bar and use Ctrl+Tab to switch between tabs (or 1 and 2).
Or just use windows and hit Alt-Tab to switch between them.
But anyway, tabbed browsing is great, especially if you open a lot of browser windows, because it doesn't clutter up your main task bar.
How much crap do you have in your main task bar? Do people really run like 15 applications at once? If I have much more than three, I can't keep up. It's one thing to surf 10 pages at the same time, it's a whole other to have email, irc, a word processor, etc, etc.
You might want to consider using multiple virtal window spaces. If I have more than about 3 apps I need to run, I shift to another desktop and run it there.
And the tabs don't take up much space anyway. Methinks you are kind of grasping for straws, unless you are running in 640x480 or something.
No, I usually run at 1400x1050, for preference. But the tabs take up at least the same space as the height of the address bar, more if you have enough browsers going that it's trying to display multiple rows of tabs. And if you don't display multiple rows, then you have to scroll left/right using those damned small arrows at the sides, which frankly annoys me to no end.
I always had a problem with IE in that it would *never* remember windows positions for multiple browsers.
I never have that problem, as my IE window is always maximized. On the rare occasion that I need to see something else on the screen, I can reposition it.
the ability to have mutiple tabs as your startup pages
My startup page is about:blank, so I doubt this applies to me. I have no desire to waste my time loading a startup page or pages when I'm loading the browser to go somewhere else anyway (usually a google search which I can simply type into the address bar). about:blank is fast and efficent.
if the browser does crash, you can do a quick restore and start surfing again right where you left off
If the browser crashed, I'd get a new browser. I've never had IE crash unless I've gone to demonstration pages showing off IE specific bugs, or gone to "most annoying javascript" type pages. I haven't found these sorts of bugs "in the wild", yet.
As for cleaner, I fail to see how having more screen space taken by crap that ain't what you're looking at is any less cluttered. The tabs take up extra space. This is a given. The windows on the taskbar *don't* take any extra space. If they weren't there, there'd just be, hah, a blank taskbar.
I agree with "to each his own", but everyone seems to love tabs and for the life of me, I cannot understand why.
Nothing seems to happen? Hello, what of all these features:
Tabbed browsing
Why in the hell is everyone so big on tabbed browsing? I tried it, and frankly it pissed me off. Why? Because it did the same thing that multiple window browsing does, but it did it while adding an extra line for the tabs at the top of my page, further reducing my screen real estate that can use for the actual web page I'm trying to read.
I multi window surf all the time. I frequently have 10+ browser windows open. But I detested tabbed browsing when I tried it, and removed Mozilla yet again (since it's still slow and bloated and the only reason I installed it again was to see what the tabbed fuss was all about).
I mean, how, exactly, is giving me a clickable list of browser pages at the top of the screen any better than giving me a clickable list of browser pages at the bottom of the screen (in the toolbar, where my windows are listed)? Be detailed, mind you. It's still one process either way, I'm not loading multiple copies of the browser into memory (check the task manager). It's just as fast to switch windows as it is to switch tabs. And the window bar takes up space on the screen already, giving it that slight edge over tabbed browsing, in my view.
I just fail to see the benefits, but there's a very good downside. I use my browser maximized, with most menus and toolbars off. Why? So I can see what I'm reading. Anything that reduces my screen space is an instant loser.
While the Tivo demo is slanted towards the young person with money to burn, their percentage of older people is rapidly growing.
And in any case, as other people point out, young people with money is who the advertisers target 90% of the ads at.
Until the day I die, I will pronounce it with a hard G because it makes more sense, and isn't easily confused with .JIF files, another image file format, albeit not one commonly used.
The inventor of the format can correct me all day long. He's still wrong.
But you can't stop them (__AA) using a real client behind a network device that can sniff the traffic and find out who / where / what you are sharing even with encryption.
True, but with something like the FreeNet protocols, how do you even know you're sharing it?
And encrypted links can be made secure against man in the middle attacks if you care to put in the effort. And even so, they'd have to actually DOWNLOAD something from you in order to prove you have it. And once their reputation drops, and they get revoked by a few people, they suddenly find they can't download anything, because that client or even IP block is no longer trusted.
We're not talking a P2P with a million users here. But even a P2P among people I personally know with MP3's comes to one hell of a large collection of sound, for example.
Excuse me, but doesn't Nullsoft's W.A.S.T.E. (see /. a couple days ago) already accomplish this without special handware -- and without Microsoft?
Yes, but you could do it in a somewhat more robust fashion than WASTE does. And you still can't trust the hardware with waste, nor the software for that matter.