> The only thing that matters to the provider is the volume. Doesn't matter if it's 10 big messages or 15 slightly smaller ones.
yEnc will allow me to download a given binary in 10 small messages, using your analogy. This is a reduction in volume, and a good thing for those of us with metered connections.
yEnc is not perfect, but it *IS* an improvement (even yEnc detractors admit this) over uuencode. I find it hard to dismiss yEnc simply because it is an incremental, rather than complete, solution.
>More, smaller messages -- what difference do you think that would possibly make?
Correct me if I am wrong, but I believe you are speaking in regards to the NNTP server. I was speaking in regards the end user.
An end user will download FEWER posts of a given size, if those posts are yEnc encoded, as compared to posts that are uuencoded for the same binary.
If you are referring to the fact that users will simply post more files, well, that will happen in any event, regardless of encoding scheme. If you or any "group of people who know what they're doing" can devise an encoding scheme that will reduce both post size and number of messages, for a given binary, I shall switch to it immediately. Provided, of course, that it is implemented in my lifetime...
As I said in my previous post, yEnc certainly has lit a fire under the binary posting issue.
It *WIILL* decrease the amount of data downloaded on a per message basis. Of course, this means the customer will simply download more messages... good for the customer, bad for the service provider.
Jeremy, where is YOUR answer to yEnc? I admit I'm not up on the history of your involvement in Usenet encoding, save for the info on your web page, but I'm curious as to why you didn't follow through and persue the new format.
The whole yEnc brouhaha reminds me of the GIF vs JPG Usenet debates of the late80s/early 90s. Each side claimed their format was "obviously" better and produced "data" that supported their arguments.
Time will tell, of course, whether yEnc emerges as the predominant standard or not; just as it did with GIF and JPG.
FWLIW, I support yEnc. No, its not a formal standard and its not perfect. It does, however, force the issue of encoding for Usenet. If left to the powers that be, Usenet encoding would never change as there is no incentive to do so.
If you don't like yEnc: create a better format, formalize it, issue an RFC, wait, make changes, discuss the issue some more, wait, hope that end users accept your format, wait. etc., ad nausium.
In the meantime, I (and many, many others) will happily make use of yEnc. Whether you like it or not, you have to deal with it, as a user or as an admin.
...just like those ancient GIF proponents had to deal with JPG.
Slashdot Mirror
You can go to your local car mega-stereo shop for alternator upgrades, so electricity shouldn't be a problem.
I'd worry more about improving the car's cooling system to handle the heat...
> The only thing that matters to the provider is the volume. Doesn't matter if it's 10 big messages or 15 slightly smaller ones.
yEnc will allow me to download a given binary in 10 small messages, using your analogy. This is a reduction in volume, and a good thing for those of us with metered connections.
yEnc is not perfect, but it *IS* an improvement (even yEnc detractors admit this) over uuencode. I find it hard to dismiss yEnc simply because it is an incremental, rather than complete, solution.
Try parchive.sourceforge.net.
Also, SmartPAR works (for me, anyway) under WINE.
>More, smaller messages -- what difference do you think that would possibly make?
Correct me if I am wrong, but I believe you are speaking in regards to the NNTP server. I was speaking in regards the end user.
An end user will download FEWER posts of a given size, if those posts are yEnc encoded, as compared to posts that are uuencoded for the same binary.
If you are referring to the fact that users will simply post more files, well, that will happen in any event, regardless of encoding scheme. If you or any "group of people who know what they're doing" can devise an encoding scheme that will reduce both post size and number of messages, for a given binary, I shall switch to it immediately. Provided, of course, that it is implemented in my lifetime...
As I said in my previous post, yEnc certainly has lit a fire under the binary posting issue.
It *WIILL* decrease the amount of data downloaded on a per message basis. Of course, this means the customer will simply download more messages... good for the customer, bad for the service provider.
Jeremy, where is YOUR answer to yEnc? I admit I'm not up on the history of your involvement in Usenet encoding, save for the info on your web page, but I'm curious as to why you didn't follow through and persue the new format.
The whole yEnc brouhaha reminds me of the GIF vs JPG Usenet debates of the late80s/early 90s. Each side claimed their format was "obviously" better and produced "data" that supported their arguments.
...just like those ancient GIF proponents had to deal with JPG.
Time will tell, of course, whether yEnc emerges as the predominant standard or not; just as it did with GIF and JPG.
FWLIW, I support yEnc. No, its not a formal standard and its not perfect. It does, however, force the issue of encoding for Usenet. If left to the powers that be, Usenet encoding would never change as there is no incentive to do so.
If you don't like yEnc: create a better format, formalize it, issue an RFC, wait, make changes, discuss the issue some more, wait, hope that end users accept your format, wait. etc., ad nausium.
In the meantime, I (and many, many others) will happily make use of yEnc. Whether you like it or not, you have to deal with it, as a user or as an admin.