LimeWire's FOSS too. It's also a popular program, and other viruses out there have been known to piggyback on it. LimeWire certainly doesn't download anything without the user's permission. If you're concerned, just build it from the source (available at limewire.org).
The article didn't mention it, but LW5 doesn't let the user share or download programs unless he/she explicitly allows it (by changing some scary looking settings). So virus complaints with LimeWire should go way down.
Whichever way it is -- some conspiracy theories do have hints of truth. Sure, the depths that the rumours tend to evolve to are essentially false, but they started somewhere.
About a year ago I submitted a story on "P2P through Firewalls" -- I wrote up the article and explicitly included "(link to Dijjer omitted at author's request)". I found that when it was posted on Slashdot, Michael had changed the article to make the word Dijjer link through to their page. This, despite flashing blinking red text on the Dijjer page that said "DO NOT LINK TO US". Stuff like that breeds conspiracy theories.
I'm just curious... what makes you think folks that edit commercials out now will proceed to wipe away product placement? Commercials disappear because they interrupt the flow of the show. If people liked watching commercials, then DVDs would include them also. The studio knows people don't like commercials, they're just a necessary evil with classic business models.
Product placement is different though. You can't edit out product placement without changing the story, and if you can, what's the point?
I find analogies with books work best for almost every sort of comparison. The best analogy, of course, is when people say, "Isn't the program finished? What do you do all day?" That easily translates to, "No, it isn't. It's a book that needs constant revisions, edits and changes. People send in typos and grammatical errors and plot suggestions and new characters, etc..." (Well, that's more of a metaphor.)
As far as "what is source code", that's somewhat comparable to a book review versus the actual book. You can't read the book review and honestly say it's a great book -- you have to go to the book itself. A better comparison, though, is translations into different languages. If you want to critique the book in the form the author intended, you need the original -- not a copy that has lost some of its meaning in the translation.
There'll be no exact comparison, simply because there's so few things that have the same relaionship. What you need is to figure out what the source code actually gives you that a proprietary product wouldn't. Many times, there's not much. For instance, if an "open document format" was required, it wouldn't much matter if the code itself was proprietary, because the goal of keeping the format open can be met.
Actually, thinking about it a bit -- a very good analogy is DNA testing. If someone mysteriously shows up and claims to be person X, you can verify that by testing DNA. If a program claims to be doing one thing, you can verify it by reading the source code.
There's tons of different analogies for each angle of "source code", none of them will always be spot-on, but depending on the situation, there's one that'll meet your needs.
Indeed. A class on OSS is a business, legal or philosophy class, not a programming class. That doesn't mean CS students shouldn't have an OSS class, but if they do it certainly wouldn't be a programming one.
If you want to do a programming class, use whatever code makes sense in teaching kids how to program. If you want to teach about how to use existing libraries while programming, make that an assignment -- ie, have an assignment that requires building a servlet, or making an http connection, or using various collection utilities.
One problem with many college CS classes is that they ignore existing libraries. Yes, students need to learn how to do a bubble sort and build a linked list and prevent collisions in hash maps... but, students should realize and understand that it is often counter-productive to build these utilities themselves, especially when the existing ones are so widely used (meaning they're heavily documented and debugged).
Most AJAX webapps do have the ability to have a permalink to a particular portion of the page, you just have to click an extra button.
What's needed to make everything behave like it used to is the ability to change the visible URL & history without actually changing the page. This way, when you click to do something in the webapp, it can update the global state immediately & the user can get all the benefits (of bookmarks & whatnot) without the drawbacks of reloading pages.
I could understand concern if there was some subjectivity in the review. However, the review is 100% objective -- it gathers facts and reports them. He doesn't give his recommendation, nor does he draw conclusions based on an opinion. That said, Ben did disclose who funded the study, which should remove any concern.
If you use any decent software, such as AdAware or Spybot or Microsoft Anti-Spyware, you'll see that LimeWire indeed has absolutely no bundled software. If you use software whose only claim to fame is that it can find spyware where no spyware exists, well... good luck keeping your computer working.
Is it wrong for a company to commission an article that highlights good points about their software? Is it wrong for FireFox to point out why it's better than Internet Explorer?
LimeWire has no bundled software, so it commissioned an article from a well-known & reputable source in order to prove it.
You're probably the only one. At least if you downloaded LimeWire any time after last August. LimeWire hasn't had bundled software for close to a year.
Him and the other 30 million people that have download LimeWire since last August. And 1 million more each week. LimeWire has absolutely no bundled software.
The data length need not use any of the existing bits. It could be sent separately, and tools matching signatures would also match the size.
That said, I do understand that you could use the same storage where the size is stored in order to store more signature bits, raising uniqueness. But consider the size as a measure intended for future-proofing, in case the algorithm is broken.
I have barely any cryptography knowledge, but would the SHA series be any safer if the size of the data was part of the signature? From glancing over Bruce's post (and remembering how MD5 and others were broken), data has to be padded. You can't just change arbitrary bits and produce the same signature. So, couldn't you just add the size of the file to the signature? Does that decrease security, because the size is now known?
It's a tough question. Many of the built-in Java classes work wonders, and by building them in, it lets other built-in classes make use of them instead of having to build their own versions. One example is the Collections API. Sure, there could be things added/removed/changed with the API and things like ArrayList, LinkedList, HashMap, TreeSet, etc... but by including them, other necessary stuff can be simpler because they don't have to worry about a simple list or queue.
The remaining object-oriented problem with most OO languages is that object construction is not easily object-oriented. Java's gotten around this by using service providers (for things like crypto and other places), but most SPI interfaces are bulky and difficult to use. Unless all classes use the SPI for object creation, the largest benefit is lost. A way of having 'new ArrayList()' return my ArrayList instead of Java's ArrayList would allow pre-existing classes to make use of later optimizations in different libraries.
What I've found with many of the Java classes is that they're good for the designed scenario. HttpUrlConnection, for example, breaks if the server accepts the connection and disco's without sending any data (the connection just hangs in this instance) -- but in the vast majority of Java apps, this is never going to happen. Any robust implementation, though, needs to handle this scenario. Things like StringTokenizer are also great for simple & quick manipulation of string tokens, but are terribly inefficient.
IMHO, Java's done an excellent job of providing an API that gets the job done 90% of the time. For that other 10%, you need external libraries.
This rationale makes sense, but ignores the plight of client apps (as opposed to server apps). When writing a client app, you want as low an overhead and as much compatability as possible. Commons Logging lets the developer have zero runtime or compile-time dependencies on heavy-weight logging systems (like log4j) or newer Java versions (like 1.4's logging system). The developers can instruct the logging to use log4j or 1.4's logger while developing, and set the layer to use a NoOpLog for shipping. Total logging overhead: 28KB (which would have been required anyway from using a library that used commons logging) and zero extra dependencies.
It's not just a political problem. If you're using different libraries, the libraries are going to use different loggers. log4j is too large to bundle with client apps and not necessary for many apps. Commons Logging is a simple layer that libraries can use and leaves the actual implementation decision to the developer using the library.
Sure, it's not a logging system -- but it's a damned fine logging layer.
Commons Logging. Yeah, you said you wanted to avoid extra libraries, but the overhead of commons logging is so incredibly small, and the extra libraries you'll want to otherwise use are going to require it anyway. It's a measly 28KB last I checked, and well worth it.
HttpClient If you want to do any form of HTTP transfers, avoid HttpUrlConnection (built in to Java) at all costs. The HttpUrlConnection code is broken in many ways (too many to list), so you'll need another library. HttpClient does a good job of hiding the HTTP transfer behind the scenes, and has easy ways of letting you extend/change what you need.
JGoodies Looks Swing is getting better every day, but for that extra polish, you'll want to use the JGoodies Looks library. It does a great job of making Metal look just that much better, and also helps out the Windows L&F in some places.
Xerces I'm not sure if the bulk of this is included in the latter versions of Java, but Xerces is definitely a must-have for any XML parsing.
Other goodies...
For rendevous (multicast DNS) support, use jmDNS. It just works.
If you need i18n handling (normalization, etc..), IBM's icu4j does a great job.
It's still peer to peer. Or more appropriately, peer to peer using another peer (P2PUAP). The flow is like this:
- Someone sends a request that gets routed through the network. - Someone sends a reply that gets routed back through the network. The reply contains the address of a few [directly connectable] people the replier is connected to. - The requestor sends a message to the directly connectable folks telling them to tell the replier to start sending UDP packets. - Requestor & Replier both start sending UDP packets to each other. The NATs open, the transfer begins.
Slashdot Mirror
LimeWire's FOSS too. It's also a popular program, and other viruses out there have been known to piggyback on it. LimeWire certainly doesn't download anything without the user's permission. If you're concerned, just build it from the source (available at limewire.org).
The article didn't mention it, but LW5 doesn't let the user share or download programs unless he/she explicitly allows it (by changing some scary looking settings). So virus complaints with LimeWire should go way down.
Uh, no. And it never did.
Why? FrostWire _is_ LimeWire. They take LimeWire's open-source GPL code and repackage and rename it.
Didja know LimeWire is open source, GPL'd?
See http://limewire.org/ .
Whichever way it is -- some conspiracy theories do have hints of truth. Sure, the depths that the rumours tend to evolve to are essentially false, but they started somewhere.
About a year ago I submitted a story on "P2P through Firewalls" -- I wrote up the article and explicitly included "(link to Dijjer omitted at author's request)". I found that when it was posted on Slashdot, Michael had changed the article to make the word Dijjer link through to their page. This, despite flashing blinking red text on the Dijjer page that said "DO NOT LINK TO US". Stuff like that breeds conspiracy theories.
I'm just curious... what makes you think folks that edit commercials out now will proceed to wipe away product placement? Commercials disappear because they interrupt the flow of the show. If people liked watching commercials, then DVDs would include them also. The studio knows people don't like commercials, they're just a necessary evil with classic business models.
Product placement is different though. You can't edit out product placement without changing the story, and if you can, what's the point?
I find analogies with books work best for almost every sort of comparison. The best analogy, of course, is when people say, "Isn't the program finished? What do you do all day?" That easily translates to, "No, it isn't. It's a book that needs constant revisions, edits and changes. People send in typos and grammatical errors and plot suggestions and new characters, etc..." (Well, that's more of a metaphor.)
As far as "what is source code", that's somewhat comparable to a book review versus the actual book. You can't read the book review and honestly say it's a great book -- you have to go to the book itself. A better comparison, though, is translations into different languages. If you want to critique the book in the form the author intended, you need the original -- not a copy that has lost some of its meaning in the translation.
There'll be no exact comparison, simply because there's so few things that have the same relaionship. What you need is to figure out what the source code actually gives you that a proprietary product wouldn't. Many times, there's not much. For instance, if an "open document format" was required, it wouldn't much matter if the code itself was proprietary, because the goal of keeping the format open can be met.
Actually, thinking about it a bit -- a very good analogy is DNA testing. If someone mysteriously shows up and claims to be person X, you can verify that by testing DNA. If a program claims to be doing one thing, you can verify it by reading the source code.
There's tons of different analogies for each angle of "source code", none of them will always be spot-on, but depending on the situation, there's one that'll meet your needs.
Indeed. A class on OSS is a business, legal or philosophy class, not a programming class. That doesn't mean CS students shouldn't have an OSS class, but if they do it certainly wouldn't be a programming one.
If you want to do a programming class, use whatever code makes sense in teaching kids how to program. If you want to teach about how to use existing libraries while programming, make that an assignment -- ie, have an assignment that requires building a servlet, or making an http connection, or using various collection utilities.
One problem with many college CS classes is that they ignore existing libraries. Yes, students need to learn how to do a bubble sort and build a linked list and prevent collisions in hash maps... but, students should realize and understand that it is often counter-productive to build these utilities themselves, especially when the existing ones are so widely used (meaning they're heavily documented and debugged).
Do TV studios get a cut of TV sales?
Do software developers get a cut of computer sales?
Do game developers get a cut of console sales?
[Insert countless other examples]
Ummm... No.
But it'd make sense if all history of it was wiped away 'cause of the ban on using the words. ;)
(not that i really believe the story)
Most AJAX webapps do have the ability to have a permalink to a particular portion of the page, you just have to click an extra button.
What's needed to make everything behave like it used to is the ability to change the visible URL & history without actually changing the page. This way, when you click to do something in the webapp, it can update the global state immediately & the user can get all the benefits (of bookmarks & whatnot) without the drawbacks of reloading pages.
I could understand concern if there was some subjectivity in the review. However, the review is 100% objective -- it gathers facts and reports them. He doesn't give his recommendation, nor does he draw conclusions based on an opinion. That said, Ben did disclose who funded the study, which should remove any concern.
If you use any decent software, such as AdAware or Spybot or Microsoft Anti-Spyware, you'll see that LimeWire indeed has absolutely no bundled software. If you use software whose only claim to fame is that it can find spyware where no spyware exists, well... good luck keeping your computer working.
Is it wrong for a company to commission an article that highlights good points about their software? Is it wrong for FireFox to point out why it's better than Internet Explorer?
LimeWire has no bundled software, so it commissioned an article from a well-known & reputable source in order to prove it.
You're probably the only one. At least if you downloaded LimeWire any time after last August. LimeWire hasn't had bundled software for close to a year.
Him and the other 30 million people that have download LimeWire since last August. And 1 million more each week. LimeWire has absolutely no bundled software.
I just pulled out Cat's Cradle from the top of my desk to illustrate this exact point. :)
So that I do have something to add, though, chapter 20 of Cat's Cradle is indeed titled, "Ice-Nine".
The data length need not use any of the existing bits. It could be sent separately, and tools matching signatures would also match the size.
That said, I do understand that you could use the same storage where the size is stored in order to store more signature bits, raising uniqueness. But consider the size as a measure intended for future-proofing, in case the algorithm is broken.
I have barely any cryptography knowledge, but would the SHA series be any safer if the size of the data was part of the signature? From glancing over Bruce's post (and remembering how MD5 and others were broken), data has to be padded. You can't just change arbitrary bits and produce the same signature. So, couldn't you just add the size of the file to the signature? Does that decrease security, because the size is now known?
It's a tough question. Many of the built-in Java classes work wonders, and by building them in, it lets other built-in classes make use of them instead of having to build their own versions. One example is the Collections API. Sure, there could be things added/removed/changed with the API and things like ArrayList, LinkedList, HashMap, TreeSet, etc... but by including them, other necessary stuff can be simpler because they don't have to worry about a simple list or queue.
The remaining object-oriented problem with most OO languages is that object construction is not easily object-oriented. Java's gotten around this by using service providers (for things like crypto and other places), but most SPI interfaces are bulky and difficult to use. Unless all classes use the SPI for object creation, the largest benefit is lost. A way of having 'new ArrayList()' return my ArrayList instead of Java's ArrayList would allow pre-existing classes to make use of later optimizations in different libraries.
What I've found with many of the Java classes is that they're good for the designed scenario. HttpUrlConnection, for example, breaks if the server accepts the connection and disco's without sending any data (the connection just hangs in this instance) -- but in the vast majority of Java apps, this is never going to happen. Any robust implementation, though, needs to handle this scenario. Things like StringTokenizer are also great for simple & quick manipulation of string tokens, but are terribly inefficient.
IMHO, Java's done an excellent job of providing an API that gets the job done 90% of the time. For that other 10%, you need external libraries.
This rationale makes sense, but ignores the plight of client apps (as opposed to server apps). When writing a client app, you want as low an overhead and as much compatability as possible. Commons Logging lets the developer have zero runtime or compile-time dependencies on heavy-weight logging systems (like log4j) or newer Java versions (like 1.4's logging system). The developers can instruct the logging to use log4j or 1.4's logger while developing, and set the layer to use a NoOpLog for shipping. Total logging overhead: 28KB (which would have been required anyway from using a library that used commons logging) and zero extra dependencies.
It's not just a political problem. If you're using different libraries, the libraries are going to use different loggers. log4j is too large to bundle with client apps and not necessary for many apps. Commons Logging is a simple layer that libraries can use and leaves the actual implementation decision to the developer using the library.
Sure, it's not a logging system -- but it's a damned fine logging layer.
In no particular order...
Commons Logging. Yeah, you said you wanted to avoid extra libraries, but the overhead of commons logging is so incredibly small, and the extra libraries you'll want to otherwise use are going to require it anyway. It's a measly 28KB last I checked, and well worth it.
HttpClient If you want to do any form of HTTP transfers, avoid HttpUrlConnection (built in to Java) at all costs. The HttpUrlConnection code is broken in many ways (too many to list), so you'll need another library. HttpClient does a good job of hiding the HTTP transfer behind the scenes, and has easy ways of letting you extend/change what you need.
JGoodies Looks Swing is getting better every day, but for that extra polish, you'll want to use the JGoodies Looks library. It does a great job of making Metal look just that much better, and also helps out the Windows L&F in some places.
Xerces I'm not sure if the bulk of this is included in the latter versions of Java, but Xerces is definitely a must-have for any XML parsing.
Other goodies...
For rendevous (multicast DNS) support, use jmDNS. It just works.
If you need i18n handling (normalization, etc..), IBM's icu4j does a great job.
It's still peer to peer. Or more appropriately, peer to peer using another peer (P2PUAP). The flow is like this:
- Someone sends a request that gets routed through the network.
- Someone sends a reply that gets routed back through the network. The reply contains the address of a few [directly connectable] people the replier is connected to.
- The requestor sends a message to the directly connectable folks telling them to tell the replier to start sending UDP packets.
- Requestor & Replier both start sending UDP packets to each other. The NATs open, the transfer begins.