Slashdot Mirror

If an NNTP server fails to actively *request* the password in the prescribed fashion, Netscape will report a failed login due to "bad password". The Wildcat 5.x NNTP server has that bug, so it doesn't work with NS3.x. I suppose it's possible that your ISP's new POP server is either misconfigured or has a similar bug. Anyway, it's worth asking 'em to check it, assuming they give a flip.

I still sometimes use NS3 for news -- the way around the evil yEnc problem, or multipart files in general, is to select all the body parts, then "save as" to a file on disk, at which point NS will proceed to download them all to a single file. Then use UUDeview to decode it. UUDeview is smart enough to deal with headers and multiple files, and now knows about yEnc. Also, if UUDeview says the file is bad, it is definitely bad, no matter what else may claim to have successfully decoded it.

I use NewsXpress for most news now (very text and keyboard friendly, and far less annoying than Agent, which I loathe), but NX never heard of yEnc. So I use a variant of the above method: archive all desired posts to a folder, then use UUDeview to decode them all (or selected files) at once, yEnc or not.

1) yENC is not even an IETF draft, let alone an RFC, let alone an internet standard.
2) yENC is shit, stop using it.

Hopefully the Thunderbird developers are smart enough never to support that peice of crap.

I read what the guy said and it's mostly FUD and sour grapes. Bottom line, yEnc is here to stay until it gets replaced, and moaning about it and trying to convince users not to use it is a futile exercise.

Now when the new "standard" comes (whenever that happens, it's been coming for a while now which is why yEnc filled the void in the first place) developers will be able to actively promote that standard within their programs with little effort. Setting it as the default, explaining why it is the default when they go to change it, etc. And a true standard will be implemented much more thoroughly than yEnc has been, so people should be able to upgrade their newsreaders without switching software (as I had to do for yEnc, and thankfully so because XNews is way better than Agent was anyway). But they will still bitch and moan as they always have, because the majority of binary NG non-posters are total babies about everything.

Then again, it will probably just end up being Usenet with pretty Outlook stationery.

If this catches on, it will be worse than the yEnc problem.

Its problems are listed here.

Its got all the problems that show up when someone tries to invent something without doing the research 1st.

So why was UUENCODE and UUDECODE, then later MIME created?

No, UUencode was created for UUCP, the Unix-to-Unix copy system that predates the spread of the Internet. UUCP was a store-and-forward system for the delivery of files; usually, it operated over serial lines (read: mostly long-distance dialup!) at odd hours. Netnews was built to run on UUCP. (Some argue that news runs better over UUCP than its current protocol NNTP, though this may be nostalgia run amok.)

UUencode was necessary to move arbitrary binary data (as opposed to ASCII text) because many serial interfaces had limits on the bytes they could transfer. Many connections were only seven-bit-safe, meaning that they might strip or misinterpret a 1 on the high bit. Also, IIRC, many serial connections used characters 0-31 for signaling (with XON and XOFF being only the best-known) -- sending a file containing these characters might hang or abort your connection.

Your newsfeed is almost definitely pre-filtered, probably by your ISP, using (mostly) Cleanfeed. Lurk in nanau for a couple weeks, and you'll get a pretty solid picture of everything. (You'll also get lots of flames, trolls, floodbots, cancelbots, sporgeries, and everything else that makes Usenet fun.)

I'm also a Comcast customer and have chosen to go with Giganews as a commercial news service. Their retention is nice and long (about 2 weeks on average) and the completeness I've seen it perfect. Its not cheap, but they provide a great news feed. Here is a page with useful reviews of premium usenet providers if you want to do a little homework before you decide.

Jeremy Nixon used to work (maybe still does) at a major premium news service so he knows what he's talking about.

He has a comprehensive and reasonably up-to-date list of providers .

Also, use your current NNTP server to read as much of alt.binaries.news-server-comparison as you can tolerate.

Jeremy Nixon used to work (maybe still does) at a major premium news service so he knows what he's talking about.

He has a comprehensive and reasonably up-to-date list of providers .

Also, use your current NNTP server to read as much of alt.binaries.news-server-comparison as you can tolerate.

yEnc isn't all that great. See http://www.exit109.com/~jeremy/news/yenc.html.

I am posting this on Slashdot under the yEnc Article, news.software.nntp, and also will CC it to both Jeremy Nixon and also Jürgen Helbing

I like the idea of bringing down the overhead of binary messages. With probably over 100GB? per day of binaries on all the newsgroups, this probably means a drastic 40GB reduction (albeit probably temporary as Jeremy Nixon mentioned) which means a lot of saved bandwidth on servers and also faster downloads for end users our favorite digital media (whatever that may be ;-). I feel this is a good start - though maybe a little rushed. I have to thank Jürgen for bringing the inefficiencies of MIME to the forefront of discussion even though he might have created a little extra work for developers. I also agree with Jeremy that yEnc should be stamped out in place of moving this into MIME.

I would first like to say: From the involvement I have seen from Jeremy with Usenet (especially news.software.nntp) and nntp software, I would be insane to say that I know more than or even close to what he knows. In fact, I work on the browser portion of Mozilla (as a volunteer) and know little about the underlying code of the Mail-News portion (nor do I even use it because its still very beta, and doesn't do what I need from a Usenet client). I am also not very knowledgeable on the deep-down guts of Usenet. I am a regular user of Usenet though, and have a little knowledge about how the news system works, so I feel that gives me a right to talk about yEnc from a more general standpoint than one possible from someone with Jeremy's experience. But I've decided to start expanding my experience into Mail-News and I'm thinking about implementing yEnc for Mozilla (even though I have a million other projects I'm working on).

From Jeremy's article:

>Unfortunately, with the discussions being fragmented in many newsgroups, the people
>who will ultimately determine the acceptance (or non-acceptance) of yEnc -- the end-
>users -- are largely unaware of the issues and problems raised by this situation.

I respectfully disagree that it is the end-user's decision.It is developers' decisions whether or not it becomes popular. Otherwise, we will have people continue to "spam" the groups with yEnc messages supported by only a couple clients. The people that have those clients will be happy and continue to post in that format, leaving out the people using other clients from those postings. This will never end, and the only solution is that everyone switch to the same client, ignore the postings as much as possible, or quality clients (which hopefully will one day include Mozilla Mail-News) support yEnc (at least on a read basis) so that no one will be left out of yEnc. It almost seems like developers have no choice now if they want to stay competitive in the Usenet arena. Good or bad? I think good in the long run, although it is currently a headache for developers.

>My objection to yEnc is because it was done poorly, not because it was done by
>Jürgen, and I certainly have nothing against him. Had he done it right, I would be
>thanking him right now.

I agree that yEnc seems like a wimp compared to MIME. Of course, this isn't the end of the world and I think it might be a good impetus to whip some people into action. I imagine that Jeremy, with his experience, Jürgen, and others can get together and majorly revamp the MIME standard, throwing out 7-bit encoding, including every new technology that has been thought of since its inception, making it easily identifiable as something separate from the old standard, and renaming it.

> And the bandwidth savings? That's an illusion. A smaller encoding scheme gives
> us exactly one benefit: faster downloads and uploads for the users. It is not going
> to make Usenet smaller. It is not going to allow servers to increase retention. Do
> you really think people aren't going to post more, if they can do it faster? Of
> course they are. They're always going to post more, with or without yEnc. And,
> with yEnc, they are even more likely to post more, because posting the same
> amount of material will take a shorter time, and because people who can't use
> yEnc will ask for reposts in uuencode. [I actually see this happening]

> The growth of Usenet volume is more or less exponential, and has been for quite some
> time. So let's just say I'm wrong > about people and they really will post less. Let's say
> that, overnight, all of the binaries on Usenet start getting posted in yEnc, and people
> post exactly the same amount they would have posted with uuencode, resulting in less
> total volume. All you have done, in that far-fetched scenario, is create a one-time
> volume savings. Usenet will continue to grow at the same rate it has been growing, and
> after a few months, it will be just as large as it was before. And it will get bigger from
> there. So all you have done is moved the graph back by a few months. Big deal.

Personally, I think that Usenet has gotten way too large to have all the newsgroups (or a large portion of them) on every server and needs to be redesigned (possibly with a more distributed system). That's another issue though.

> Programmers of Usenet software now have to implement yEnc in their code.
> Not just once, either. The specification is, as I write this, up to version 1.3, and
> there will be future revisions. So everyone has to go back and update their code
> every time the spec is updated. And they don't just have to change it, they have to
> continue to support the older spec as well, because updates to a new version won't
> happen overnight. And because the spec is imprecise, programmers are forced to create
> and maintain even more ugly [ Pretty :-) ] code in their software, when they could be
> spending time making more worthwhile improvements. There is a good reason for
> new standards to be discussed at length and incorporate feedback from experts - so
> that you don't have to keep going back and fixing it. And, even when something better
> comes along, all that yEnc code can't just go away; it will still be there, and still have to
> be maintained. People won't stop using yEnc overnight. It would take years to become
> uncommon.

I'm willing to waste a little of my time implementing it if it will stir some people into action. We need some kind of standard out there that can warrant the throwing away of every other encoding standard out there.
Anyone willing to undertake such a project? If there is a standard that replaces all the current standards, I imagine that yEnc, UUEncode, Base64 would phase out over time. A more naive wish is there could be an industry-wide
agreement to rip out all the other standards from their code, but I know the chances of that happening are slim.

Anyway, I say for Jeremy the old adage, "If you want something done right, you have to do it yourself". Jeremy, why don't you organize a group to oversee the development of a new all-inclusive MIME
standard? Is there any point to leaving the 7 bit aspects of MIME in there? Why aren't they ripped out (A question from someone who hasn't looked at the mime standard :)?

> Now, he seems to be planning to update the spec to include a means of using yEnc
> with MIME, which is the way everyone has told him it should be done. But he says
> he's going to do it within a few weeks! You can't add something to MIME in a few
> weeks, and there are good reasons for that. So, in reality, what he may be planning to
> do is bypass the standards process and simply publish a specification.

> There are two small problems (two that I have found, at least) with the MIME spec
> which would need to be addressed before the creation of a yEnc transfer-encoding.
> Why was MIME ignored for yEnc in the first place? Jürgen has said that MIME is
> not suitable because not all newsreaders support it, or support it fully. Does this
> make sense? You can't use MIME because it's not universally supported, so instead
> you create something new which isn't supported by a single newsreader in existence?

It appears that things are moving too slowly for his liking. This makes me think of huge multinational corporations that just lumber along and don't get anything accomplished but arguing and fighting. This (along with squelching
all competition) causes a slowdown in the growth of technology. I have no clue if that is the case with the MIME group, but it appears that Jürgen would like things to go a little faster. I definately agree with him on this, since I am
getting sick of all the messed up multipart postings I see on Usenet, and if the new changes being proposed to MIME can fix that (MD5 checksums, etc), then I would like to see that implemented as soon as possible. Since I don't have
the experience to do that and would rather not throw myself into yet another project, I hope people with experience can get the ball rolling. From my look at Google Groups, it seems that these things have been talked about for ages.
Why can't we have a little less talk and a little more action? From my experience on the Mozilla project, I see that people can sit discussing something for years. Sometimes, it's better to take the bull by the horns and try to - even
if it doesn't satisfy everybody - actually do something. For me, this means implementing something that has been talked about and discussed about forever because no one wants to (or has the time to) sit down and come up with a detailed proposal on how it should be accomplished.

> If you agree with me, what can you do to help? If you are the author of a
> Usenet newsreader, you probably have to implement yEnc at least for decoding

Sounds like a very good idea. I will propose this for Mail-News.

yEnc bug on bugzilla.mozilla.org

I have been looking through the binary newsgroups (as I am a regular lurker on many groups) and have been seeing all the people moaning about yEnc, and I can't say I blame them, as I have been moaning silently, also. That's the main reason I am planning on implemting this for Mozilla. That would leave one other thing before I was willing to switch from Outlook Express: Multipart message decoding (Hopefully better than OE's wimpy support), for which I have written a lengthy preliminary spec but don't have time to implement myself - Multipart messages bug.

Being a Mozilla developer, I would like nothing more than to use Mozilla's own software for news, and I will be caught between a rock and a hard place if Mozilla supports yEnc and not multipart decoding, and Outlook Express
supports multipart decoding and not yEnc (at least until people stop posting yEnc messages).

I am posting this on Slashdot under the yEnc Article, news.software.nntp, and also will CC it to both Jeremy Nixon and also Jürgen Helbing

I like the idea of bringing down the overhead of binary messages. With probably over 100GB? per day of binaries on all the newsgroups, this probably means a drastic 40GB reduction (albeit probably temporary as Jeremy Nixon mentioned) which means a lot of saved bandwidth on servers and also faster downloads for end users our favorite digital media (whatever that may be ;-). I feel this is a good start - though maybe a little rushed. I have to thank Jürgen for bringing the inefficiencies of MIME to the forefront of discussion even though he might have created a little extra work for developers. I also agree with Jeremy that yEnc should be stamped out in place of moving this into MIME.

I would first like to say: From the involvement I have seen from Jeremy with Usenet (especially news.software.nntp) and nntp software, I would be insane to say that I know more than or even close to what he knows. In fact, I work on the browser portion of Mozilla (as a volunteer) and know little about the underlying code of the Mail-News portion (nor do I even use it because its still very beta, and doesn't do what I need from a Usenet client). I am also not very knowledgeable on the deep-down guts of Usenet. I am a regular user of Usenet though, and have a little knowledge about how the news system works, so I feel that gives me a right to talk about yEnc from a more general standpoint than one possible from someone with Jeremy's experience. But I've decided to start expanding my experience into Mail-News and I'm thinking about implementing yEnc for Mozilla (even though I have a million other projects I'm working on).

From Jeremy's article:

>Unfortunately, with the discussions being fragmented in many newsgroups, the people
>who will ultimately determine the acceptance (or non-acceptance) of yEnc -- the end-
>users -- are largely unaware of the issues and problems raised by this situation.

I respectfully disagree that it is the end-user's decision.It is developers' decisions whether or not it becomes popular. Otherwise, we will have people continue to "spam" the groups with yEnc messages supported by only a couple clients. The people that have those clients will be happy and continue to post in that format, leaving out the people using other clients from those postings. This will never end, and the only solution is that everyone switch to the same client, ignore the postings as much as possible, or quality clients (which hopefully will one day include Mozilla Mail-News) support yEnc (at least on a read basis) so that no one will be left out of yEnc. It almost seems like developers have no choice now if they want to stay competitive in the Usenet arena. Good or bad? I think good in the long run, although it is currently a headache for developers.

>My objection to yEnc is because it was done poorly, not because it was done by
>Jürgen, and I certainly have nothing against him. Had he done it right, I would be
>thanking him right now.

I agree that yEnc seems like a wimp compared to MIME. Of course, this isn't the end of the world and I think it might be a good impetus to whip some people into action. I imagine that Jeremy, with his experience, Jürgen, and others can get together and majorly revamp the MIME standard, throwing out 7-bit encoding, including every new technology that has been thought of since its inception, making it easily identifiable as something separate from the old standard, and renaming it.

> And the bandwidth savings? That's an illusion. A smaller encoding scheme gives
> us exactly one benefit: faster downloads and uploads for the users. It is not going
> to make Usenet smaller. It is not going to allow servers to increase retention. Do
> you really think people aren't going to post more, if they can do it faster? Of
> course they are. They're always going to post more, with or without yEnc. And,
> with yEnc, they are even more likely to post more, because posting the same
> amount of material will take a shorter time, and because people who can't use
> yEnc will ask for reposts in uuencode. [I actually see this happening]

> The growth of Usenet volume is more or less exponential, and has been for quite some
> time. So let's just say I'm wrong > about people and they really will post less. Let's say
> that, overnight, all of the binaries on Usenet start getting posted in yEnc, and people
> post exactly the same amount they would have posted with uuencode, resulting in less
> total volume. All you have done, in that far-fetched scenario, is create a one-time
> volume savings. Usenet will continue to grow at the same rate it has been growing, and
> after a few months, it will be just as large as it was before. And it will get bigger from
> there. So all you have done is moved the graph back by a few months. Big deal.

Personally, I think that Usenet has gotten way too large to have all the newsgroups (or a large portion of them) on every server and needs to be redesigned (possibly with a more distributed system). That's another issue though.

> Programmers of Usenet software now have to implement yEnc in their code.
> Not just once, either. The specification is, as I write this, up to version 1.3, and
> there will be future revisions. So everyone has to go back and update their code
> every time the spec is updated. And they don't just have to change it, they have to
> continue to support the older spec as well, because updates to a new version won't
> happen overnight. And because the spec is imprecise, programmers are forced to create
> and maintain even more ugly [ Pretty :-) ] code in their software, when they could be
> spending time making more worthwhile improvements. There is a good reason for
> new standards to be discussed at length and incorporate feedback from experts - so
> that you don't have to keep going back and fixing it. And, even when something better
> comes along, all that yEnc code can't just go away; it will still be there, and still have to
> be maintained. People won't stop using yEnc overnight. It would take years to become
> uncommon.

I'm willing to waste a little of my time implementing it if it will stir some people into action. We need some kind of standard out there that can warrant the throwing away of every other encoding standard out there.
Anyone willing to undertake such a project? If there is a standard that replaces all the current standards, I imagine that yEnc, UUEncode, Base64 would phase out over time. A more naive wish is there could be an industry-wide
agreement to rip out all the other standards from their code, but I know the chances of that happening are slim.

Anyway, I say for Jeremy the old adage, "If you want something done right, you have to do it yourself". Jeremy, why don't you organize a group to oversee the development of a new all-inclusive MIME
standard? Is there any point to leaving the 7 bit aspects of MIME in there? Why aren't they ripped out (A question from someone who hasn't looked at the mime standard :)?

> Now, he seems to be planning to update the spec to include a means of using yEnc
> with MIME, which is the way everyone has told him it should be done. But he says
> he's going to do it within a few weeks! You can't add something to MIME in a few
> weeks, and there are good reasons for that. So, in reality, what he may be planning to
> do is bypass the standards process and simply publish a specification.

> There are two small problems (two that I have found, at least) with the MIME spec
> which would need to be addressed before the creation of a yEnc transfer-encoding.
> Why was MIME ignored for yEnc in the first place? Jürgen has said that MIME is
> not suitable because not all newsreaders support it, or support it fully. Does this
> make sense? You can't use MIME because it's not universally supported, so instead
> you create something new which isn't supported by a single newsreader in existence?

It appears that things are moving too slowly for his liking. This makes me think of huge multinational corporations that just lumber along and don't get anything accomplished but arguing and fighting. This (along with squelching
all competition) causes a slowdown in the growth of technology. I have no clue if that is the case with the MIME group, but it appears that Jürgen would like things to go a little faster. I definately agree with him on this, since I am
getting sick of all the messed up multipart postings I see on Usenet, and if the new changes being proposed to MIME can fix that (MD5 checksums, etc), then I would like to see that implemented as soon as possible. Since I don't have
the experience to do that and would rather not throw myself into yet another project, I hope people with experience can get the ball rolling. From my look at Google Groups, it seems that these things have been talked about for ages.
Why can't we have a little less talk and a little more action? From my experience on the Mozilla project, I see that people can sit discussing something for years. Sometimes, it's better to take the bull by the horns and try to - even
if it doesn't satisfy everybody - actually do something. For me, this means implementing something that has been talked about and discussed about forever because no one wants to (or has the time to) sit down and come up with a detailed proposal on how it should be accomplished.

> If you agree with me, what can you do to help? If you are the author of a
> Usenet newsreader, you probably have to implement yEnc at least for decoding

Sounds like a very good idea. I will propose this for Mail-News.

yEnc bug on bugzilla.mozilla.org

I have been looking through the binary newsgroups (as I am a regular lurker on many groups) and have been seeing all the people moaning about yEnc, and I can't say I blame them, as I have been moaning silently, also. That's the main reason I am planning on implemting this for Mozilla. That would leave one other thing before I was willing to switch from Outlook Express: Multipart message decoding (Hopefully better than OE's wimpy support), for which I have written a lengthy preliminary spec but don't have time to implement myself - Multipart messages bug.

Being a Mozilla developer, I would like nothing more than to use Mozilla's own software for news, and I will be caught between a rock and a hard place if Mozilla supports yEnc and not multipart decoding, and Outlook Express
supports multipart decoding and not yEnc (at least until people stop posting yEnc messages).

So Jürgen Helbing creates a public domain solution which is gaining popularity and Mr. Nixon is being ignored - and why? Implementation nitpicks? Please.

A more useful excercise may be to guess his employer from his list of 'reviews'

Does anybody really use usenet anymore?

I do. Some groups are mostly noise, but others are still pretty good.

As for the spam problem, maybe you can suggest to your ISP that they install Cleanfeed or similar. (Yes, that's the same site as the anti-yEnc page, which BTW I agree with.)

An alternate interface to the Usenet search can be found at http://www.exit109.com/~jeremy/news/deja.html.

I find this form much easier to use than the one Deja.com provides; it has also remained unchanged through all incarnations of Deja.com in recent memory.

By the way, here's a little gem that I found on ./ some time ago: Jeremy Nixon's Deja Power Search without all of the annoying stuff and it still has the threading option.

A search frontend, like this one? You can also go find some more frontends, they're out there, or you can just write your own.

... was Jeremy Nixon's Deja power search, especially after the redesign/relaunch. It's basically just a reorganization of the form from Deja's own power search page, but I find the slightly different interface (with no unnecessary graphics and no scrolling) to be simpler and quicker to use.

Unfortunately Jeremy doesn't have his own back archives ...
----

Presumably deja users will figure this out after reading two or three messages.

You and I may have figured this out, but I bet that the vast bulk of people will take quite a while to figure this out, if they indeed ever do. Newbies vastly outnumber the experienced on the web, and that won't change for a while.

And if you hate trying to use the Deja search interface, with its cluttered screen full of links and ads, there are alternatives. See my alternative front end for Deja, which is based on Jeremy Nixon's.

Deja Power Search - Friendlier front-end to the Deja power search by Jeremy Nixon

Here are my mirrors.. Remember to mirror early and often. Spread it far and wide! The best way to help is to mirror the software and join the EFF today!

Join the EFF to help fight this! http://www.eff.org

New Mirrors:
http://www.securityinsight.com
http://hiway1.exit109.com/~malice/

Fight for your rights!

Not mine, but I like the morphage...
Somebody has way too much time.

If Friends were filmed in Wisconscin

Any other suggestions for a good Usenet search engine?

My current choice is Deja, though I hate what's happened to the site as it's been portalized. I use an alternate page. Actually, I've created my own simplified, localhost search pages for the major search engines I frequent -- I don't actually hit the sites until I get results.

There are also tools like dejasearch which provide a command-line interface to search engines, and compile results to a single, local, file for later browsing.

That said, what alternative Usenet archives are there? I've used Remarq on the odd occasion, though it strikes me as too busy and unfriendly as well. Pity.