Personally I think one of the central issue of this conflict is Linus' claim that Tridge "just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about".
I wonder how Linus can know that. How can he make this claim without providing any supporting evidance for what he believe Tridge's intention was. To me it doesn't seem to be anything more than a wild and totally biased speculation.
Consindering Samba took years to become somewhat usable, it's fairly evident "over the wire" reverse engineering takes time, and to expect Tridge to come with a "replacement" right away is in fact pretty sureal.
Your definition of "journalist" is fuzzy at best. What's "actual research"? What's "editorial review process" and why is it required for a journalist (as opposed to a publication)? And who can decide if a source is "reputable"?
I would simply define a journalist as someone who
is willing to collect and deliver information to the general public in order to inform the latter;
has proven himself as capable of doing so;
and performs this service on a regular basis.
Whether the information being collected and deliverd is rumor or not doesn't matter (it does distinguish a good journalist from a bad one, obviously), as long as the intention of informing the public (as opposed to having some secret agenda, for example) holds true.
It still takes a long way to have those robots learn running, crawling, dodging, rolling like Indiana Jones (or Lora Croft, if you prefer your robots feminine). Until then, I won't recommend them for a mission on another planet.
Seriously, insectoid robots are obviously much more suitable for terrain expedition.
Same team who broke MD5
on
SHA-1 Broken
·
· Score: 0, Redundant
This is the same team who broken MD4, MD5, HAVAL-128 and RIPEMD six months ago, so I'd rather believe this is true that calling them liars.
This is a great sketch, we should actually organize some people to perform it and send the video recording to the EC (and to all anti-patent-law organizations, of course). An additional live performance in front of the EC would of course be a ingeniuos publicity stunt.
"Centralization" has a purpose
on
Today in P2P
·
· Score: 2, Insightful
Especially in the past few months, "decentralizing BitTorrent" has become a really hot topic where everybody wants to share his idea of getting rid of the annoyance of a tracker. It surprises me that most people - even many developers of BitTorrent compatible software whom I know and respect - seem to overlook the fact that BitTorrent's "centralized structure" is there for a reason.
The reason is called _control_.
First let me repeat what Bram uses to emphasize on every opportunity: BitTorrent is not a _filesharing_, but a file _distribution_ protocol. Considering that, the tracker is not a "single point of failure", as many suggest, but a "single point of control". With a tracker existing, access to the files being distributed can be (indirectly) controlled via access control lists (ACL) built into the tracker. For instance, one tracker may answer to authenticated users only, another tracker may postpone general access and grand exclusive "early stage access" to peers from certain IP range within a time frame of the files' release. Unfortunately, the ACL part of the (original) tracker has not been implemented until today (partly my own fault, I have to admit), but some alternative tracker implementations do have this since a long time now - often used to reward "good behaving" users (TorrentBits, anybody?).
Control is probably a bad thing for filesharing, but it is an important issue for file distribution. As for the availability of the tracker, it wouldn't be such a widespreed problem if not for legal issues, which in turn is because BitTorrent is actually "misused" for filesharing. So in other words, BitTorrent has not been decentralized not because we couldn't do it, but because we want to keep the option of control open.
Henry 'Pi' James (member of the developer team of the original BitTorrent)
PS: Since I've already explained how BitTorrent is not designed for filesharing, I also want to point out it is in fact not really suitable for filesharing. The "swarming effect" - which is what BitTorrent is all about - can only be achieved in "slashdotting scenarios", that's why BitTorrent has been adapted for filesharing by two major groups first: anime fanssubbers and tv ep captors, both releasing "hot content" whose value decreases fast, compared to movies or software, for example. For the sharing of mid and long term files, BitTorrent does not really have a significant advantage over other P2P systems.
The website has obviously been shut down to prevent terrorist attacks on it, as indicated by credible inteligence reports. Don't be surprised if the Alert Level is raised to red in the next few days!
Win32, Win32, and Win32 again
on
A Taste of Qt 4
·
· Score: 4, Interesting
So Qt 4 is "positioned directly against Java". Fantastic! Except I read just a few days ago (also here on slashdot) that Qt will keep on blockading the release of a free-of-charge and publicly available version of their Win32 library port.
Now, call me cynical, but how in the hell are you gonna compete with Java, whose foremost strength is the (alleged) platform independency if you kill yourself right away for the most commonly used platform?
As pointed out by many readers already, Mac OS X is not free or Open Source, and does not have a statistically proven larger base of FOSS developers. So offering free Qt library for OS X while categorically denying Win32 is nothing but complete BS. And this new PR crap about "positioning against Java" is simply too laughable seen in this light.
Btw, I prefer KDE over Gnome, so I'm not an "enemy" of Qt per se.
In a way, the antivirus industry always reminds me of the nobel profession of arms dealing. On the table you provide your clients weapens to "defend" themselves and to archieve and maintain peace. Off the table you know the business only flourishes when there is a war. Of course there is always a war, but your interest is in an all-out war. So what do you do if there is no such an all-out war going on? Don't panic, you simply make your clients believe there is one indeed. As soon as they believe you, you win.
If you don't know what I'm talking about, you shoudl read Vmyths more often.
To me the authors are vandals not revolutionaries, and may have ensured WMA becomes the standard.
Sure, sure. Let WMA come, since I've got enough "confidence" in Microsoft's "security". If I absolutely have to pick a DRM "technology", I absolutely would choose Microsoft (grin). "Unbreakable"? Forget Oracle, watch out for Microsoft DRM!
What if I turn this whole thing around and install fake services on a number of ports?
For example, whenever you make a connection to a port between 1025 and 2048 on my system, you're greeted with "OpenSSH...", and prompted to authenticate. But only behind one among those 1024 ports is the real SSH. On any other port, the fake service takes the username and password you've entered, wait a few seconds (just idling around), and tell you "Authentication failed". If you try too often to connect to faked services, you're put on the black list to avoid DOS, of course.
Obviously a lot of people, including Perens, are right about less choice being better in some respects. But in this specific case choice is actually not the issue. Why? Because Gnome and KDE are too different, so much that many people do not see them as "alternatives" to each other. There is actually no "choice" here.
Why isn't there a discussion about a "choice" between Mozilla and wget? Because they obviously cannot replace each other, although a lot of what they do are common. Putting softwares into "categories" is the misleading step here, since it implies one program can do roughly the same thing as another one from the same category. But "roughly" is vage, and when programs grow in their complexity, they become more and more unique, unreplacable.
Just by the amount of users defending KDE one can say that too many people don't feel Gnome is an alternative to KDE (although I'm personally not sure if KDE may indeed be an valid alternative for Gnome, if you consider the license fee for Qt to be negligible as I do). You cannot "choose" between two programs if they are not alternative to each other. It would be like choosing between vision and scent.
This is interesting. MUTE is created and coded by Jason Rohrer, the same Jason Rohrer who created and coded konspire2b. Now what is the relationship of these two programs, particularly from the view of their common author? Is he "dumping" k2b in favor of this all-new MUTE?
konspire2b came with a very intersting idea, but the implementation was less impressive. Especially the inability to deal with a "passive" Internet connection (behind NAT and/or firewall) is the reason that it hasn't gained a user base as large as it promised. It is simply a fact that many (if not most) private Internet users are using a passive Internet connection nowaday, and the procentage is even growing.
Now MUTE comes again with a very intersting idea, but as we know, problems of technical details can kill good ideas quite often. Obviously, the concept is in some points similar to Freenet. One of Freenet's biggest problem is, just like k2b, it's inability to deal with pass internet connection. I think this issue may be the corner stone for MUTE, too.
I am negatively biased against Jason, mainly because the "failure" of his k2b, and especially because of the document he published comparing his own k2b to BitTorrent, which earned quite some protests because many factual "findings" in the comparison seem wrong. To be fair, I must admit that since I am a member of the BitTorrent dev team, my opinion in this matter is biased from the start, although it has not prevent me to try out k2b, and will certainly not prevent me from trying out MUTE now.
First, I like to point out that the name of the protocol/application in question is not "Bit Torrent", but "BitTorrent".
This aside, let's differ between two kinds of possible content to be handled via BitTorrent: web content (HTML, images, Flash animations, etc.) and offline content (software, music, video, etc.).
The first kind of data is not suitable for BitTorrent because they are too small. (This is a "basic knowledge" about BitTorrent, if you don't understand why, please refer to general technical readings regarding the protocol.) The second kind of data is mostly not suitable for being embedded into a website, people normally download them and proceed with them outside of their webbrowser.
But even if any data of the second kind is indeed embedded into a website (like a video, although I never watch video embedded in my webbrowser), it's not a good idea to bind this embedding process to BitTorrent, because every "BitTorrent connection" has a lifespan which need to be specifed by the user himself. A file keeps being uploaded after its download completes within BitTorrent, until the user decides to "finish" this file. If a video embedded into a webpage is downloaded via BitTorrent, when should the upload of this same video stop? Immediately after the download completes? Or when the user leaves the website? Both are rather too soon to keep the file healthy alive.
What would make sense, however, is to write a BitTorrent download manager plugin, perhaps a sidebar, similar to the new download manager of Phoenix/Firebird. The user could handle his BitTorrent downloads within the interface of the webbrowser, and at the same time keep control over the lifespan of each of the files being transfered.
In the end, I fully agree with Olivier (Bugzilla comment #1), this is a plugin issue and WONTFIX.
No offense here, but I think the original "bug reporter" has not understood BitTorrent's field of application and mode of operation quite well (and, has not got the name "BitTorrent" right).
Henry 'Pi' James
BitTorrent dev team member
PS: My opinion here is personal and does not represent Bram (the author of BitTorrent) or any other co-developers, although I'm pretty sure they would agree with me.
Slashdot Mirror
Personally I think one of the central issue of this conflict is Linus' claim that Tridge "just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about".
I wonder how Linus can know that. How can he make this claim without providing any supporting evidance for what he believe Tridge's intention was. To me it doesn't seem to be anything more than a wild and totally biased speculation.
Consindering Samba took years to become somewhat usable, it's fairly evident "over the wire" reverse engineering takes time, and to expect Tridge to come with a "replacement" right away is in fact pretty sureal.
I do feel "DRM in any form is ridiculous". It's that simple.
Your definition of "journalist" is fuzzy at best. What's "actual research"? What's "editorial review process" and why is it required for a journalist (as opposed to a publication)? And who can decide if a source is "reputable"?
I would simply define a journalist as someone who
Whether the information being collected and deliverd is rumor or not doesn't matter (it does distinguish a good journalist from a bad one, obviously), as long as the intention of informing the public (as opposed to having some secret agenda, for example) holds true.
Maybe that's because firewalls aren't supposed to block files at all? They manage (including blocking) network connections, not files.
Yes, I know many "internet security solutions" comes with web and/or mail filter function, but that's not what you call a "firewall".
Poor Schneier has been slashdotted, here the mirrordot link to the article: http://mirrordot.org/stories/8d15245fcd484ffea6ab7 38745bfa642/index.html
It still takes a long way to have those robots learn running, crawling, dodging, rolling like Indiana Jones (or Lora Croft, if you prefer your robots feminine). Until then, I won't recommend them for a mission on another planet.
Seriously, insectoid robots are obviously much more suitable for terrain expedition.
This is the same team who broken MD4, MD5, HAVAL-128 and RIPEMD six months ago, so I'd rather believe this is true that calling them liars.
This is a great sketch, we should actually organize some people to perform it and send the video recording to the EC (and to all anti-patent-law organizations, of course). An additional live performance in front of the EC would of course be a ingeniuos publicity stunt.
Especially in the past few months, "decentralizing BitTorrent" has become a really hot topic where everybody wants to share his idea of getting rid of the annoyance of a tracker. It surprises me that most people - even many developers of BitTorrent compatible software whom I know and respect - seem to overlook the fact that BitTorrent's "centralized structure" is there for a reason.
The reason is called _control_.
First let me repeat what Bram uses to emphasize on every opportunity: BitTorrent is not a _filesharing_, but a file _distribution_ protocol. Considering that, the tracker is not a "single point of failure", as many suggest, but a "single point of control". With a tracker existing, access to the files being distributed can be (indirectly) controlled via access control lists (ACL) built into the tracker. For instance, one tracker may answer to authenticated users only, another tracker may postpone general access and grand exclusive "early stage access" to peers from certain IP range within a time frame of the files' release. Unfortunately, the ACL part of the (original) tracker has not been implemented until today (partly my own fault, I have to admit), but some alternative tracker implementations do have this since a long time now - often used to reward "good behaving" users (TorrentBits, anybody?).
Control is probably a bad thing for filesharing, but it is an important issue for file distribution. As for the availability of the tracker, it wouldn't be such a widespreed problem if not for legal issues, which in turn is because BitTorrent is actually "misused" for filesharing. So in other words, BitTorrent has not been decentralized not because we couldn't do it, but because we want to keep the option of control open.
Henry 'Pi' James (member of the developer team of the original BitTorrent)
PS: Since I've already explained how BitTorrent is not designed for filesharing, I also want to point out it is in fact not really suitable for filesharing. The "swarming effect" - which is what BitTorrent is all about - can only be achieved in "slashdotting scenarios", that's why BitTorrent has been adapted for filesharing by two major groups first: anime fanssubbers and tv ep captors, both releasing "hot content" whose value decreases fast, compared to movies or software, for example. For the sharing of mid and long term files, BitTorrent does not really have a significant advantage over other P2P systems.
The website has obviously been shut down to prevent terrorist attacks on it, as indicated by credible inteligence reports. Don't be surprised if the Alert Level is raised to red in the next few days!
So Qt 4 is "positioned directly against Java". Fantastic! Except I read just a few days ago (also here on slashdot) that Qt will keep on blockading the release of a free-of-charge and publicly available version of their Win32 library port.
Now, call me cynical, but how in the hell are you gonna compete with Java, whose foremost strength is the (alleged) platform independency if you kill yourself right away for the most commonly used platform?
As pointed out by many readers already, Mac OS X is not free or Open Source, and does not have a statistically proven larger base of FOSS developers. So offering free Qt library for OS X while categorically denying Win32 is nothing but complete BS. And this new PR crap about "positioning against Java" is simply too laughable seen in this light.
Btw, I prefer KDE over Gnome, so I'm not an "enemy" of Qt per se.
In a way, the antivirus industry always reminds me of the nobel profession of arms dealing. On the table you provide your clients weapens to "defend" themselves and to archieve and maintain peace. Off the table you know the business only flourishes when there is a war. Of course there is always a war, but your interest is in an all-out war. So what do you do if there is no such an all-out war going on? Don't panic, you simply make your clients believe there is one indeed. As soon as they believe you, you win.
If you don't know what I'm talking about, you shoudl read Vmyths more often.
There is a Reuter report on CNN online, with practically the same information as the Xinhua report.
What if I turn this whole thing around and install fake services on a number of ports?
For example, whenever you make a connection to a port between 1025 and 2048 on my system, you're greeted with "OpenSSH ...", and prompted to authenticate. But only behind one among those 1024 ports is the real SSH. On any other port, the fake service takes the username and password you've entered, wait a few seconds (just idling around), and tell you "Authentication failed". If you try too often to connect to faked services, you're put on the black list to avoid DOS, of course.
Obviously a lot of people, including Perens, are right about less choice being better in some respects. But in this specific case choice is actually not the issue. Why? Because Gnome and KDE are too different, so much that many people do not see them as "alternatives" to each other. There is actually no "choice" here.
Why isn't there a discussion about a "choice" between Mozilla and wget? Because they obviously cannot replace each other, although a lot of what they do are common. Putting softwares into "categories" is the misleading step here, since it implies one program can do roughly the same thing as another one from the same category. But "roughly" is vage, and when programs grow in their complexity, they become more and more unique, unreplacable.
Just by the amount of users defending KDE one can say that too many people don't feel Gnome is an alternative to KDE (although I'm personally not sure if KDE may indeed be an valid alternative for Gnome, if you consider the license fee for Qt to be negligible as I do). You cannot "choose" between two programs if they are not alternative to each other. It would be like choosing between vision and scent.
This is interesting. MUTE is created and coded by Jason Rohrer, the same Jason Rohrer who created and coded konspire2b. Now what is the relationship of these two programs, particularly from the view of their common author? Is he "dumping" k2b in favor of this all-new MUTE?
konspire2b came with a very intersting idea, but the implementation was less impressive. Especially the inability to deal with a "passive" Internet connection (behind NAT and/or firewall) is the reason that it hasn't gained a user base as large as it promised. It is simply a fact that many (if not most) private Internet users are using a passive Internet connection nowaday, and the procentage is even growing.
Now MUTE comes again with a very intersting idea, but as we know, problems of technical details can kill good ideas quite often. Obviously, the concept is in some points similar to Freenet. One of Freenet's biggest problem is, just like k2b, it's inability to deal with pass internet connection. I think this issue may be the corner stone for MUTE, too.
I am negatively biased against Jason, mainly because the "failure" of his k2b, and especially because of the document he published comparing his own k2b to BitTorrent, which earned quite some protests because many factual "findings" in the comparison seem wrong. To be fair, I must admit that since I am a member of the BitTorrent dev team, my opinion in this matter is biased from the start, although it has not prevent me to try out k2b, and will certainly not prevent me from trying out MUTE now.
This RFE does not make much sense.
First, I like to point out that the name of the protocol/application in question is not "Bit Torrent", but "BitTorrent".
This aside, let's differ between two kinds of possible content to be handled via BitTorrent: web content (HTML, images, Flash animations, etc.) and offline content (software, music, video, etc.).
The first kind of data is not suitable for BitTorrent because they are too small. (This is a "basic knowledge" about BitTorrent, if you don't understand why, please refer to general technical readings regarding the protocol.) The second kind of data is mostly not suitable for being embedded into a website, people normally download them and proceed with them outside of their webbrowser.
But even if any data of the second kind is indeed embedded into a website (like a video, although I never watch video embedded in my webbrowser), it's not a good idea to bind this embedding process to BitTorrent, because every "BitTorrent connection" has a lifespan which need to be specifed by the user himself. A file keeps being uploaded after its download completes within BitTorrent, until the user decides to "finish" this file. If a video embedded into a webpage is downloaded via BitTorrent, when should the upload of this same video stop? Immediately after the download completes? Or when the user leaves the website? Both are rather too soon to keep the file healthy alive.
What would make sense, however, is to write a BitTorrent download manager plugin, perhaps a sidebar, similar to the new download manager of Phoenix/Firebird. The user could handle his BitTorrent downloads within the interface of the webbrowser, and at the same time keep control over the lifespan of each of the files being transfered.
In the end, I fully agree with Olivier (Bugzilla comment #1), this is a plugin issue and WONTFIX.
No offense here, but I think the original "bug reporter" has not understood BitTorrent's field of application and mode of operation quite well (and, has not got the name "BitTorrent" right).
Henry 'Pi' James
BitTorrent dev team member
PS: My opinion here is personal and does not represent Bram (the author of BitTorrent) or any other co-developers, although I'm pretty sure they would agree with me.