Usenet Encoding: yEnc

Intertia vs. Good Ideas by ksw2 · 2002-03-23 13:28 · Score: 3, Insightful

The article points out some interesting points why yEnc shouldn't be adopted... none of which will probably keep the community from adopting it, however. If it's here, and being used, that is a whole lot more intertia than common sense can usually gain. Er, betamax, anybody?

Re:Intertia vs. Good Ideas by Zeinfeld · 2002-03-23 13:52 · Score: 5, Informative

I have some sympathy with the article author, but not when it comes to the MIME issues. I have written plenty of IETF and other standards, I know the value of going through a standards process, however the IETF is not a place to do research, it is a place to standardise and improve existing protocols. The idea is that you start from code.
Breaking MIME is not something I would (do) lose sleep over. People in the MIME community screamed at us when we had the temerity to introduce the text/html content type, rather than use application/binary. They were completely obstructionist when it came to insisting on 8-bit clean transport for HTTP. In the end we treated them as damage and routed around them. HTTP uses several headers that the MIME people villified.
The functional issues raised are significant and it would be good to see them addressed. In particular using the subject line is pretty lame. Either you want the encoding format to be completely independent of MIME or you don't. I think that MIME independence would be the better route since then it would be easier to move to a more modern protocol such as BEEP. But using magic numbers and MD5 inside the encoding does not seem like a bad move.
The more interesting 'meta-point' however is that tweaking the encoding format is only scratching the surface when it comes to fixing UseNet. The main problem with USEnet is that it still has to route every single article to every single node whether it is going to be read or not. While the flood fill routing was a good scheme when NNTP was developed and the number of nodes was small it is needlessly wasteful now that we have hundreds of thousands of NNTP servers, it is just not necessary to have that level of redundancy to route arround censorship.

--
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Re:Intertia vs. Good Ideas by Spy+Hunter · 2002-03-23 13:58 · Score: 5, Insightful

I would argue that the adoption of a standard is a much better indication of its "goodness" than its technical features. yEnc has been adopted by lots of people because it solves problems that they have, therefore it is proven to be good. If someone fixes the flaws that this author talks about and makes a new scheme that works better, then it might get adopted. If it does, it will be because it solves real problems people have with yEnc. If it doesn't, that means that it is too much of a pain for people to switch and that the problems yEnc has are not that much of a problem for real users. I think this is probably the case. So you can't use filenames with double quotes. Big deal! Change them to single quotes or something! So one out of a thousand posts will be corrupted because of mis-recognized magic strings or something. Its not any worse than it was before, and the downloads are smaller! If the problems really are THAT bad, a solution will come and people will use it.

--
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Re:Intertia vs. Good Ideas by Tofuhead · 2002-03-23 15:05 · Score: 2

Yes. A shipping product beats theoretical vapor every time, or, as previous generations would have said it, "A bird in the hand is better than two in the bush." But, that doesn't mean the product couldn't have been done right the first time (particularly with the apparently large number of folks who had made recommendations that would have improved the spec, which the yENC author is only now hacking into it). I believe this is the article author's point.
< tofuhead >

--
It is still the dark of night.
Re:Intertia vs. Good Ideas by JordanH · 2002-03-23 15:35 · Score: 3, Insightful
- Er, betamax, anybody?
Not really comparable to the betamax vs. VHS debate. I've not seen anyone arguing that the alternatives, uuencode or base64, are better than yEnc, just that yEnc has serious deficiencies.
Perhaps Mr. Nixon is arguing that yEnc is worse than some wholly theoretical alternative.
Some of Mr. Nixon's points do seem interesting, but if he is convinced that there is a better alternative to be put forward, he should get the code out there. Anything else is just sniping.
Re:Intertia vs. Good Ideas by Rui+del-Negro · 2002-03-23 16:51 · Score: 3, Interesting

Betamax failed because it was a proprietary format. If Sony had allowed other companies to make it (like JVC did with VHS) it would still be around (20 years ago it was better than VHS is today). Betacam still dominates the broadcast world.

Now, yEnc looks like it was created by Microsoft. It's not a standard, it's a hack. The only way it can become a standard is by pushing it down people's throats and then using "public pressure" to force applications to support it.

To use a videotape analogy, it's like releasing magnetic tape reels after people had been using cassettes for years, just because the reels use slighlty lighter tape.

I hope yEnc in its current form is *not* supported by the industry. I think a company such as Forté could create a real standard using an encoding method similar to yEnc (it wasn't "invented" by yEnc's author, anyway). I think Agent's programmers, of all people, should know how hard it is to deal with these (non)standards, and could save themselves a lof of work in the future by making sure it's done right.

As it stands, yEnc is the same as UUEncode, only in smaller portions (actually it's worse, because you can sort of wrap UUE in MIME; you can't with yEnc).
Re:Intertia vs. Good Ideas by Chasing+Amy · 2002-03-23 17:30 · Score: 5, Insightful

> it is needlessly wasteful now that we have hundreds of thousands of NNTP
> servers, it is just not necessary to have that level of redundancy to route
> arround censorship.

I disagree entirely. Never underestimate the government's ability to stretch censorship to new levels.

Unless the very way NNTP servers operate is to gulp down and pass on each article for each newsgroup, the government would easily target those servers that spcifically carried groups or posts it doesn't like.

Pressure for news providers to drop certain groups began several years ago when the Vacco busts of people trading in child pornography led a news service to be criminally charged for the content of some groups and led other news servers in that state and elsewhere to drop gcertain groups thanks to their content. The charged news service took a plea even though they clearly would have won at trial or on appeal by claiming common carrier status, but hey, nobody wants to be the expensive test case.

Some may not see the problem with news servers being coerced by the government to drop those particular groups thanks to their contents, but the principle it sets is horrid. Certain "content owners" have of late been threatening to use the DMCA as a club to get news servers to drop groups which share TV shows and other such copyrighted material. If groups were more "localized" to a set of specific servers, or articles were localized to their originating servers, that would make it exceptionally easy for the DMCA to be used to require the "closure" of groups or removal of articles from USENET.

Furthermore, in this time of anti-terrrorist hysteria, the government has gotten away with the USA/PATRIOT mess already and is continually making some questionable choices. If it finds a newsgroup dedicated to dissent, or more spcifically dedicated to anti-globalism, for example, it cannot easily dstroy such a group because of the nature of USENET--the damage would be routed around by servers in other countries, even if every U.S. server could be forced to remove a group or article (not that they could be).

However, if the architecture of USENET were redesigned to localize groups or articles to subsets of servers--the likelihood of a government censoring USENET speech is magnified considerably.

It is the redundant architecture of USENET which will keep it free of censorship long after the WWW has been tamed--as it will be. Just look at the broiling mess within ICANN over officials trying to hand control of the WWW over to government-appointed reps. Eventually something like that will happen, and governments will cooperate with each other to make censorship in their mutual interests easier. Thanks to the architcture and nature of USENET, it will remain free and uncensored long after the WWW has fallen to censorship.

Just my 2 pence, though...

--

Chasing Amy
(We all chase Amy...)
"The more corrupt the state, the more numerous the laws"-Tacitus
Re:Intertia vs. Good Ideas by Chris+Siegler · 2002-03-23 19:13 · Score: 2

The main problem with USEnet is that it still has to route every single article to every single node whether it is going to be read or not. While the flood fill routing was a good scheme when NNTP was developed and the number of nodes was small it is needlessly wasteful now that we have hundreds of thousands of NNTP servers, it is just not necessary to have that level of redundancy to route arround censorship.

Just as a guess, I'd say most news servers only get a partial feed. Some avoid alt.binaries.* altogether certainly. And even when an ISP gets the whole shebang, they often sell access to smaller ISPs, so that the "tree" isn't nearly as nearly as big as it might be. So it's not really that bad.
Re:Intertia vs. Good Ideas by 3247 · 2002-03-24 02:19 · Score: 2

While the flood fill routing was a good scheme when NNTP was developed and the number of nodes was small it is needlessly wasteful now that we have hundreds of thousands of NNTP servers, it is just not necessary to have that level of redundancy to route arround censorship.
I believe this is no longer true for binary Usenet. There are a few hosts that carry binary newsgroups in a usable way (having some 100MB is not useful). Most servers can't handle the traffic induced by binary newsgroups.

--
Claus
Re:Intertia vs. Good Ideas by InsaneGeek · 2002-03-24 02:28 · Score: 2

>While the flood fill routing was a good scheme when NNTP was developed and the number of
>nodes was small it is needlessly wasteful now that we have hundreds of thousands of NNTP
>servers, it is just not necessary to have that level of redundancy to route arround censorship.

I don't think anybody is seriously thinking of having hundreds of thousands of NNTP servers for the purpose of getting around censorship. It's more of a way to minimize bandwidth, and works pretty much off the same principal as a cache server. It's main purpose has not changed much over the years bring the content closer to the end user who will want it. With the advent of broadband users pushing >1mb downloads from the a NNTP server, you want it as close as possible. Get 10-20 users downloading from an external usenet server simultaneously you tend to have big issues since instead of having on constant 1-3mb connection you might have a full T3's worth.
Re:Intertia vs. Good Ideas by Chasing+Amy · 2002-03-24 04:31 · Score: 3, Insightful

> ICANN's scope is the DNS system, upon which WWW, MAIL, NEWS, and everything else on the net currently relies.

Umm, that's the point.

He who controls DNS exercises immense influence on the Net, particularly the WWW. Giving control of the DNS system to delegates directly appointed by governments is a recipe for fostering censorship in the interests of those respective governments.

I.e., if DNS were in the hands of representatives appointed by governments, and some given websites were to be deemed undesirable--delete their DNS entries, and they go away. Poof. The instant DNS is controlled by governments, is the instant they begin implementing a system to instantly pull the DNS entries of websites which are "dangerous" and "patently offensive." Governments hardly ever agree on anything, but you can bet they'd agree to some deal-brokering--you support the "delisting" of our seditious sites, I'll support the delisting of yours.

USENET isn't as vulnerable because of its architecture. You can't just "delist" one newsgroup the same way you can delist one website.

If the ICANN higher-ups have their way and hand over the reigns to government-appointed reps, I guarantee you governments will take the opportunity to at least consider using their control of DNS to enable censorship.

--

Chasing Amy
(We all chase Amy...)
"The more corrupt the state, the more numerous the laws"-Tacitus
Re:Intertia vs. Good Ideas by Zeinfeld · 2002-03-24 07:03 · Score: 2

I disagree entirely. Never underestimate the government's ability to stretch censorship to new levels.
I think it is possible to reduce the bandwidth consumption of USEnet by at least one order of magnitude and introduce much better censorship resistance.
It is actually quite easy to block posts in the current flood fill algorithm, just introduce your own post with the same article ID.

--
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Re:Intertia vs. Good Ideas by Salamander · 2002-03-24 15:36 · Score: 2

The main problem with USEnet is that it still has to route every single article to every single node whether it is going to be read or not.

First, don't say "Usenet" (not an acronym BTW) when you mean "NNTP" and vice versa. While there are strong and obvious relationships between the two, they are different things.

Second, censorship-resistance was not and is not the main reason for NNTP working the way it does. I know somebody else already pointed that out, but it bears repeating.

Third, NNTP doesn't do flooding ("flood fill routing" is not a phrase with any kind of common meaning and is thus equivalent to a typo). NNTP is a point-to-point protocol, and is this incapable of flooding. Usenet doesn't use flooding either. For one thing, flooding is generally understood to mean "pushing" data everywhere it can go when it becomes available, whereas Usenet and NNTP have always been based on sending information where and when it is requested. For another, Usenet connectivity patterns are mostly tree-like and flooding - which refers to sending the same data along all possible paths to a single destination - is generally considered an inoperative term when only one path existed to begin with.

--
Slashdot - News for Herds. Stuff that Splatters.
Re:Intertia vs. Good Ideas by WNight · 2002-03-24 16:42 · Score: 2

Would I go through a huge hassle to make my web browser and MP3 player work 20% faster, or even Quake3? No. But I don't wait on those.

Would I go through the same hassle for 20% more bandwidth? Hell yes. I often end up waiting for downloads because I download 700MB images. Would I pay much for 20% faster CD Burning? Perhaps, if it still took 70 minutes like on my old single speed. But I wouldn't pay for the extra minute saved now that I can burn a disk in five minutes.

So perhaps you wouldn't care much about big savings in downloading from Usenet. But do you download much from Usenet? If not, does your opinion matter? Why not ask the people who use it? I think they've strongly indicated their views by starting to use yENC.

This isn't the same as a company forcing people to use something. This is the people choosing for themselves to find a tool to fill an important niche. It may not be terribly standard, but it's open. And as long as its consistent, that'll enable it to become a standard.

Yenc is great! by Mean_Nishka · 2002-03-23 13:31 · Score: 4, Informative

I for one am happy about Yenc's rapid adoption. My newsreader ( Xnews )software supports it, and I have noticed no difference in using Yenc over traditional binary encoding.

In fact, Yenc will help pay-per-gigabyte Usenet users achieve a greater bang for their buck. Anything that saves money is a good thing!!

--
www.lonseidman.com

Re:Yenc is great! by Wesley+Felter · 2002-03-23 13:35 · Score: 2

...I have noticed no difference in using Yenc over traditional binary encoding.

Did you read the article? One of its major points was that traditional binary encoding sucks, and instead of yEnc, people should come up with something better.
Re:Yenc is great! by BlueJay465 · 2002-03-23 13:56 · Score: 2

Dammit! They should do something better! What exactly, I dunno. But they gotta do something.

This is what I interpreted from the article, A rant about the use of a new type of encoding because it is a new take on the old. So what if it is kludgy. It seems to be working. I don't see any new type of encoding coming down the pipe that would be considered a next-generation-USENET-type-of-thingy.

Hell, maybe USENET has lived beyond it's usefulness and does need an overhaul, but I seem to remember a time when people were bitching "Stop posting in base64! The rest of us can't read these files!" or even "Stop posting in JPG format! It takes too long for my poor 286 to decode JPGs instead of GIFs"

All this appears to be is more of the same. The haves versus the have-nots.
Re:Yenc is great! by Dwonis · 2002-03-24 03:34 · Score: 2

That's pure bullshit. Criticism should be welcome in all technical circles. If you don't like criticism, then go do something else.

the point of the article by dunkelfalke · 2002-03-23 13:31 · Score: 2, Insightful

instead of breaking the standard, code it right, wait till it matures, use it then.

--
"It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap

DIME? by leighklotz · 2002-03-23 13:36 · Score: 3, Informative

There are some proposals in thee XML and Web Services arena for dealing with some of the problems tha yEnc is skirting.

One, called DIME, is a MIME-like system that handles binary content, chunks, etc.

http://www.oasis-open.org/cover/dime.html

yEnc is terrible. by Anonymous Coward · 2002-03-23 13:37 · Score: 2, Insightful

I had scripts that automatically got some a.b* newsgroups, but after the invention of this bastardized yEnc piece of crap, all my scripts are broken, and I'm 2 months behind on data for our clients.

BTW, I work for a pr0n site :) Only e-biz that's thriving still.

Agent by Account+10 · 2002-03-23 13:37 · Score: 4, Informative

Forte released Agent 1.91 2 days ago with yEnc support. it looks like Mr. Nixon is fighting a losing battle.

Re:Agent by evilviper · 2002-03-23 20:28 · Score: 2

Well, just about every operating system on earth has PLIP available. By your logic, that must mean PPP will be dead soon.

--
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Re:Agent by IHateEverybody · 2002-03-23 22:14 · Score: 2

The funny part is the Mr Jurgen doesn't even like it's current inception. Check the Follwing link

That message is a week old and was sent in response to a one week delay in the release of Agent 1.91 (the first version with yEnc support). And in any case, the link you provided shows Mr. Juergen being very complementary to Forte Inc. and the Agent development team.

Since then Agent 1.91 has been released and Mr. Juergen posted this message to the Agent newsgroup thanking the Agent team.

--
Does this .sig make my butt look big?

Is usenet dead? by Warped-Reality · 2002-03-23 13:38 · Score: 2

NOTE: This is actually a question, not a troll

Does anybody really use usenet anymore? everytime i've poked around on my ISP's NNTP server, it seems to be filled with 90% spam, and non-spam posts seem to always be grossly offtopic. And no, i'm not just talking about the alt.binaries groups either.

--
This is not the greatest sig in the world, no. This is just a tribute.

Re:Is usenet dead? by mmusn · 2002-03-23 13:46 · Score: 2, Funny

Brings to mind Yogi Berra: "The trouble with that place is: it's so crowded that nobody goes there anymore."
Re:Is usenet dead? by dattaway · 2002-03-23 13:57 · Score: 2

Usenet is very much alive and a great way to bring together communities who like to share original material, even in binary newsgroups. My favorite is alt.binaries.pictures.motorcycles.sportbike where I can see many insane pictures posted on an impulse not found on websites.

The binaries groups I have seen have been pretty much noise free. If the users are vigilant and like to use physical means to squash spammers, the forum is void of abuse.
Re:Is usenet dead? by mmontour · 2002-03-23 13:58 · Score: 2

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.)
Re:Is usenet dead? by Graymalkin · 2002-03-23 13:59 · Score: 2

I use Usenet all the time (pun intended). While there is a good deal of spam in some groups others are pretty light on the spam. For me Usenet is the place to turn when I run into a problem in Linux because I've found there is a lower proliferation of idiots using it unlike IRC which is filled with 15 year olds blabbering about RTFM. It also has some pretty good discussions on several topics if you hunt around a bit.

--
I'm a loner Dottie, a Rebel.
Re:Is usenet dead? by maggard · 2002-03-23 14:00 · Score: 2

Does anybody really use usenet anymore?

Yes.
That's why folks care about the yEnc issue. If it were a fight over, say, a Gopher implementation do you imagine there'd be much discussion?
Usenet is in trouble, it may be mortally wounded, but it'll be around for awhile yet and in that time lots of folks use it.

--
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
Re:Is usenet dead? by Sabalon · 2002-03-23 14:56 · Score: 2

Yeah...but once you get outside the porn groups the signal-to-noise ratio gets better :)

As someone else said, there are plenty of idiots posting the same questions over and over (groups.google.com anyone?), and topics tend to degrade, but for the most part, the groups that are actually dedicated to something are pretty decent. The Tolkien groups, the linux groups, some of rec.arts groups.
Re:Is usenet dead? by MillionthMonkey · 2002-03-23 15:04 · Score: 3, Interesting

I never post to it. (And after finding my ten year old posts to alt.drugs sitting in plain sight on Google, I doubt I ever will again!) But I do searches through newsgroups all the time when I'm looking for answers to obscure technical questions, or when I want to know if anyone's come across the same bug that I'm having trouble with at the moment. USENET might have more crap, but sometimes crap is what you want! You don't always want your search results to get choked up with corporate stuff. If you're doing Java programming for example, and you want to find out why class X doesn't work, a normal web search is difficult to control because all you get is bullcrap from Sun, and a zillion identical javadocs for class X that people leave around on their HTTP servers. I want to find out what people are complaining about, or whether anyone actually USES a certain API I'm considering. For getting a feel for what's going on in the field, without getting snowed under by marketing materials from a vendor, USENET is great. It isn't as corporatized.

Of course, the existence of alternate web based bulletin board systems like this one decreases its relevance for search purposes. And it's suffocating under the weight of all that spam. But USENET is still the biggest forum out there, and it's still the one that's the most easily searched.
Re:Is usenet dead? by RFC959 · 2002-03-24 03:49 · Score: 2

Oh, hell no. comp.os.linux.*, comp.os.solaris.*, comp.sys.sgi.*, comp.unix.*...all are pretty active and relatively spam-free. Plus, your ISP may have local groups: depending on the quality of the ISP and its users, these can be very good and are entirely spam-free (unless one of the local users decides to spam them, which would be a spectacularly stupid move).
Re:Is usenet dead? by ncc74656 · 2002-03-24 13:03 · Score: 2

Does anybody really use usenet anymore? everytime i've poked around on my ISP's NNTP server, it seems to be filled with 90% spam, and non-spam posts seem to always be grossly offtopic.

Maybe it depends on what newsgroups you frequent. The worst that I usually see is flamage over abandonware in comp.sys.apple2, which is jihad fodder for some. Aside from a few easily-filtered kooks, several of the comp.sys.ibm.pc.hardware.* groups offer decent S/N. Last time I checked, comp.os.linux.* wasn't too bad either.

--
20 January 2017: the End of an Error.

no no no by SETY · 2002-03-23 13:38 · Score: 3, Insightful

The author of the article seems to keep saying there isn't a problem with USENET encoding, but then goes onto complain that yenc shouldn't be used. He points out flaws in how this encoding scheme is implemented. fine fine fine.

There was a market for this thing, it spread like wild fire. It's too bad that no one made a better spec and program (the author aludes that there was planty of time to do this). yenc meets the "GOOD ENOUGH" criteria, thus it will be used, shitty, non-robust standard or not.

Re:no no no by Plutor · 2002-03-23 15:30 · Score: 2

It's this kind of thinking that has made MSIE's broken HTML and Outlook's poor security the industry standards. Just because people can stand shitty software doesn't mean we need to give it to them.

yENC by arsaspe · 2002-03-23 13:40 · Score: 4, Insightful

I'm all for standardisation... but sometimes it takes _forever_ to get something standardized. If someone writes a better product, they generally don't want to wait for it to be declared a standard, especially with something like uuencoding which has been around as long as usenet, and isn't going to be replaced in a hurry unless someone comes out and waves a product around yelling "hey try this. it works better". Ogg Vorbis isn't a standard by any means. Hell, it is still on RC3. _but_ a lot of people are using it because it has far better sound compression than mp3. You don't hear people complaining that Vorbis has jumped the standardisation process do you?

Personally I can't see why we can't just send the data as 8-bit binary. uuencode and similar encoding formats should have died out with UUCP years ago, since there is no physical reason why 8bits can't be sent over the wire anymore.

Re:yENC by MSG · 2002-03-23 14:04 · Score: 2

Ogg Vorbis isn't a standard by any means

Ogg Vorbis has a specification for its file format that doesn't break any previously specified standard. Therefore, Ogg Vorbis can be called a standard.

yEnc, on the other hand, breaks the NNTP standards, and will likely break the MIME standard. That's the difference. yEnc must fit within the standards already specified for the transmition methods it uses, and does not.
Re:yENC by arsaspe · 2002-03-23 14:46 · Score: 2

Yes, but my point was that there isn't a physical reason why data cannot be sent in 8bit format, only a software one. Rather than trying to accomodate ancient protocols that do not make use of modern technology, we should be updating them. (And yes I am aware that getting everyone to update to a new version of NNTP that isn't fully backwards compatible would be a big job... but it needs to be done. The best example of this is IPv6- we need to upgrade, but no one wants to go through the teething problems that will result)
Re:yENC by Rui+del-Negro · 2002-03-23 17:16 · Score: 3, Insightful

A "standard" is not the same as "a common thing", or even "something that most programs can read". For example, most programs can't read YCrCb TIFF files (Photoshop included), but these files do follow the TIFF specification, hence they are standard.

When you create an encoding method that is going to be used to transfer data across a network, you need to ensure that this method is compatible with everything along the way. When you send an e-mail with an Ogg file attached, this file is encoded in a way that enables the servers and the client at the other end to identify it, check its integrity, reconstruct it, process it, delete it independently from the rest of the message, etc. It doesn't matter what the file itself is (Ogg, MP3, TIFF, Doc, XYZ, etc.); these methods work with any file, regarldess of its type or contents.

8 bits can be sent over the wire, and in fact are sent over the wire. But to make sure the servers (and the clients) can tell where one file (or part of the file) ends and the next one begins, you need to "wrap" the data in a package that programs can understand. That's what MIME does. It says "this part is the message text in HTML", "this part is the message text in plain text", "that part is an image", "that part is an executable file".

Instead of using this "universal" packaging system, yEnc forces programs to look for specific strings and try to guess where things begin and end. And it has no mechanism for identifying individual parts in a multi-part post (again, programs must look at the text or message subject and try to guess).

Doing something right is usually not much harder than doing something wrong. And when people get used to something that's broken, they won't want it fixed.
Re:yENC by JamieF · 2002-03-23 18:14 · Score: 3, Insightful

It's interesting that it took this long for an ancient problem to be sorta kinda attacked, if not solved. Maybe this is because the Usenet infrastructure has changed to the point where 7-bit is silly, but why is this something that's just being addressed now? Don't tell me this is a brand new problem that the best minds of the news admin community couldn't have figured out by now.

One approach to short-circuit standards is to take the rogue approach that Netscape did, which is very different from the one folks keep accusing Microsoft of. That approach is to take an almost-suitable standard and extend it, in the same spirit, with the intent that your well-thought-out extension will be adopted later. Of course they did a less than perfect job, but the idea is sound: don't wait for the spec, lead it, while making it possible for it to remain open. That's different from the Microsoft approach of "Embrace, Extend [and Exterminate]" wherein you add undocumented proprietary features that lock you into a single vendor's solution. A hell of a lot of what's in the HTML 4 standard was released as a non-standard but documented extension by Netscape in 1.1 and 2.0. Some of that was bad (blink, and arguably frames), but when you judge Netscape, try to separate the new HTML tags from the bugs, because it's the bugs (and having to code around them) that make the web such tower of Babel.

So basically what I'm saying is, if MIME is almost there, CAREFULLY THINK THROUGH and implement the extensions you want, and implement it already. Or, pick something other than MIME. But, don't start from scratch and make mistakes that have already been learned from and solved. Build on the good decisions of the past. The real crime is solving the same problem, badly, over and over; getting ahead of a standards body while keeping intentions pure and decisions wise is not nearly as bad.
Re:yENC by drinkypoo · 2002-03-24 09:11 · Score: 2

Personally I can't see why we can't just send the data as 8-bit binary. uuencode and similar encoding formats should have died out with UUCP years ago, since there is no physical reason why 8bits can't be sent over the wire anymore.

First: UUCP is not dead. It is still in use, and still useful in places where there is no (afforable) broadband and the quality of POTS lines is trash.

Second: UUCP is capable of sending binary data. uuencode/uudecode is just for embedding 8 bit data in something which doesn't support it, such as mail, or USENET news. This is why we have base64 encoding in MIME mail.

News send via UUCP was batched, which translates to being tarred and compressed, though it was possible in later versions to plug in other transfer protocols to replace the "g" protocol (Zmodem was a popular replacement, for obvious reasons) and to use other batching methods, including zip.

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"

there is no real bloat associated with uuencode by mmusn · 2002-03-23 13:43 · Score: 3, Interesting

Uuencoded text will compress down to nearly the same size as its corresponding binary (or less, if the binary can be compressed). That kind of compression is now a standard part of modems, Internet protocols, and many file systems. Even the CPU overhead of compressing and decompressing that kind of data is negligible. If yEnc doesn't end up using less space on disk and doesn't end up using any less bandwidth than uuencode, indeed, "why encode" in yEnc and break a lot of software that expects USENET posts to be text-only?

Re:there is no real bloat associated with uuencode by A+Commentor · 2002-03-23 18:02 · Score: 3, Interesting

Uuencoded text will compress down to nearly the same size as its corresponding binary (or less, if the binary can be compressed). That kind of compression is now a standard part of modems, Internet protocols, and many file systems.

I have yet to see any DSL or cable modem with compression. So for most of the heavy binary users, uuencode data will not be compressed. And on regular modems it won't be smaller than the the yEnc, since if, as you say, the binary can be compressed, then the yEnc will be compressed..

Even the CPU overhead of compressing and decompressing that kind of data is negligible.

Do you run a heavily used news servers to provide proof that the CPU overhead is 'negligible'.

--
Looking for any old 8-bit Heathkit/Zenith software/hardware - http://heathkit.garlanger.com
Re:there is no real bloat associated with uuencode by A+Commentor · 2002-03-24 07:01 · Score: 3, Interesting

Oh, come on, think. Even if your modem doesn't compress, you can get compression at the level of a tunnel or at the level of your news transfer protocol.

For 99% of the people, getting the tunneling software on your system will be easy, getting your news server to install software on their software will be alot harder...

--
Looking for any old 8-bit Heathkit/Zenith software/hardware - http://heathkit.garlanger.com

Adoption of yEnc by jonbrewer · 2002-03-23 13:43 · Score: 4, Interesting

I am seeing smaller binaries as a result of yEnc. This is fine. The problem is, my favorite binaries grabber has no idea what to do with the files, and won't even download them. I figured out how to make Agent download them, but A. I hate Agent (and don't understand why anyone likes it!) and B. the binaries don't always decode.

As I'm a lifetime lurker (well eight years, but it seems a lifetime!) I can only choose not to download yEnc encoded binaries. And no one will know! (my news server doesn't log downloads) It's all up to the posters to adopt or not.

Re:Adoption of yEnc by Backov · 2002-03-23 14:17 · Score: 2, Informative

Check out Newspro, it's better than most binary grabbers.. I wouldn't use it for reading text newgroups, but XNews is good for that.. Newspro lets you combine headers from multiple servers. I download from my paid usenet server plus the @home servers and regularly saturate my connection at 500k/sec.. A buddy across town gets 700k/sec.

Newspro - http://www.usenetopia.com

XNews - http://xnews.3dnews.net/

Newspro is shareware, XNews is freeware.. They're both good, for different things.

Cheers,
Backov

--
In the law there is no overlap between theft and copyright infringement whatsoever.

Yeah, and off the web too! by eddy · 2002-03-23 13:44 · Score: 2

In fact, lets kill off mime altogether, and get this multimedia crap out of our inboxes. Email/Usenet is for plain text, period.

I second this. Also, let's make it so that non-validating and just generally malformed XHTML documents are rejected by browsers, and can be filtered out of google. plain HTML =

I'd just love to turn on a "[ ] Reject non-validating pages" option in google and see the world wide web with new eyes :-)

--
Belief is the currency of delusion.

yEnc = XMODEM part deux by phr2 · 2002-03-23 13:55 · Score: 4, Insightful

In the old CP/M days there was no standard way to transfer files over serial connections, except maybe Kermit. Kermit was slow because of its ping-pong protocol (no packet window--that was added later) and because it encoded binaries as printing characters. Ward Christensen invented XMODEM, which basically dumped the file through the wire as 8-bit characters, with very crude error checking and file headers. yEnc does something pretty similar for Usenet articles. It's a crude method for posting binary files as 8-bit characters instead of 6-bit characters. That of course cuts down transmission time considerably.

Despite its problems, XMODEM took off because it filled a need, just as yEnc does. Nixon's complaint that shrinking files by 35% won't make Usenet any smaller because people will just post more files is besides the point; it's like saying getting a 35% salary increase won't help your finances because you'll just buy more stuff with the extra money. Most people want that extra 35%, and JÃ¼rgen stepped up to the plate and delivered it.

Thankfully, as far as I know, nobody railed against Ward Christiansen the way Nixon does against Helbing. XMODEM's problems became obvious and the solution was to introduce YMODEM and then ZMODEM. XMODEM is still around, but its successors (and of course serial IP) have pretty much supplanted it. Ward's initial efforts are still deeply appreciated.

Yes there's the problem of legacy software, but a protocol that's only been around for a few weeks or months can't have that much of a legacy. The only programs that currently support yEnc are the ones whose maintainers react pretty fast to new developments, and those maintainers are likely to also quickly pick up any revisions/fixes to yEnc.

So the solution Nixon should be calling for is not a years-long bureaucratic standardization process that will get yEnc 1.3 entrenched while the standardization is happening. The solution is to fix yEnc's problems and release a new version as fast as possible, before the old version gets spread around too widely.

Re:yEnc = XMODEM part deux by dbarclay10 · 2002-03-23 15:52 · Score: 2

Yes there's the problem of legacy software, but a protocol that's only been around for a few weeks or months can't have that much of a legacy. The only programs that currently support yEnc are the ones whose maintainers react pretty fast to new developments, and those maintainers are likely to also quickly pick up any revisions/fixes to yEnc.
The incompatibility problem isn't with clients. The problem is with the NNTP(newsgroup) servers. Some ancient servers will choke if there are eight-bit characters in the message.

I still feel that moving to an eight-bit encoding system is fine, but let's be clear about what the issues are, okay? :)

--

Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Re:yEnc = XMODEM part deux by slashdot_commentator · 2002-03-24 02:22 · Score: 2

Yes there's the problem of legacy software, but a protocol that's only been around for a few weeks or months can't have that much of a legacy.

But what if it takes a year before an "improved" standard comes about? Everyone starts jumping around, forcing the new standard down people's throats. Then these poor non-commercial coders have to drop what their doing and implement the new protocol (including interpretation, and debugging time). (The commercial programmers have to go through it too, but I have no sympathy for people who are being remunerated for it.) If they don't react, they risk losing their userbase because they are perceived as being slow with "critical" improvements.

Nixon's complaint has to do with the fact that its not a thoroughly thought out implementation of a standard. Its a kludge. Nixon feels is that it is so apparently flawed, it will need to be reimplemented with corrections. This will cause a lot of angst for developers and users to deal with flawed software, and frequently upgrading it. And for what? The benefits may not even be that spectacular.

Frequent changes to a program is no big deal. (What didn't work right, now does.) Frequent changes to a protocol is a disaster. The programs' problem is not limited to correctly implement the new standard; it needs to interpret and then "properly" deal with the previous version(s). After all, how is program supposed to figure out if its a yEnc v0.9a and a yEnc v.093x? yEnc doesn't embed that kind of information in its format. And will the Forte reader be able to properly decode yEnc encodings by Pan? That can only be certain when there is an unambiguous protocol definition. ...and then everyone needs to do the upgrade tango! This is the mess that Nixon (and others) would like to avoid.

The only programs that currently support yEnc are the ones whose maintainers react pretty fast to new developments, and those maintainers are likely to also quickly pick up any revisions/fixes to yEnc.

Interesting, but all this change is actually being driven by the posters, not the newsreader developers. I've seen this firsthand in the alt.binaries.multimedia.* groups I frequent. They replace the uuencoding phase with the yEnc, treating it like old-style uuencoded posts, and then send the nntp articles. If people want their movies or tv episodes (before they expire in 2 days), their only choice is a yEnc capable newsreader. I'm sure the newsreader maintainers would have been more than happy to wait for a better standard.

So the solution Nixon should be calling for is not a years-long bureaucratic standardization process that will get yEnc 1.3 entrenched while the standardization is happening. The solution is to fix yEnc's problems and release a new version as fast as possible, before the old version gets spread around too widely.

I agree; waiting for the MIME committee to releases a standard before implementing yEnc would be like waiting for the Federal Gov't to issue TCO standards before creating the first personal computer. The solution was for the media posters to pass on the current yEnc implementation. If the flaws were obvious enough to require reworking yEnc, then the public should wait for the better implementation. I can understand why Nixon would have reservations about implementing a MIME-like standard without the MIME committee's approval. But then yEnc should not try to implement a MIME compatible kludge, and Nixon should ditch the complaints of yEnc not being a MIME compatible standard.

--
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
Re:yEnc = XMODEM part deux by phr2 · 2002-03-24 02:54 · Score: 3, Insightful

But what if it takes a year before an "improved" standard comes about?
That's the point--right now, the only yEnc implementations are in programs maintained by people who jumped on things quickly. So by fixing yEnc right now instead of waiting a year, you avoid trapping users of the slower moving programs. The slower moving programs simply aren't using yEnc yet.
I agree yEnc should have been more carefully thought out before being released. But its problems are not obscure. They are obvious to people who have dealt with these issues before. I don't think years of study and a lot of iterations are needed to figure out how to fix yEnc's problems. It should be possible to fix them quickly and get the fixed version out there before too many people are using the old version.
Re:yEnc = XMODEM part deux by slashdot_commentator · 2002-03-24 03:47 · Score: 2

NO, you miss the point! yEnc flaws cannot be corrected and implemented in a week!!! It cannot be fixed right now! And 30 different individuals trying to implement what they think is wrong with yEnc gives you 30 incompatible news readers!

I am not advocating waiting a year for a better standard. I am not in favor of waiting for the MIME committee to define a new standard. I am against "forcing" users to use yEnc as is, right now. (And this is being "forced" by the media newsgroup posters. The yEnc author cannot force yEnc's adoption on USENET. But he is actively encouraging it, even though it will need to be trashed in a couple of months.) It will result in a lot of grief when the yEnc author puts together a revised protocol in a couple of months. You do not grasp the problems that will be created by adopting the flawed yEnc now.

--
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
Re:yEnc = XMODEM part deux by kesuki · 2002-03-24 08:17 · Score: 2

You're forgetting after z come aa ab ac ad... all the way to zz.

--
https://www.gnu.org/philosophy/free-sw.html

Re:Why this is bad by oolon · 2002-03-23 13:57 · Score: 2

Pan supports yenc to name one, lots of *nix tools available to decode, encode and post. Don't want to change software? You can still use tin to tag all the parts save them to disk and use an extenal decoder. This was the only way before with many *nix news readers. So not much change really just a different filter to use! Yenc like another much loved binary tool "par files". Seems to have been available on *nix first not second.

Is it good is it bad? To late its here.

James

Save /. Money... by smoondog · 2002-03-23 14:04 · Score: 3, Funny

Hey, if this guy adopts it, he could save slashdot some money...

-Sean

He can't be actually using binaries groups by Talla · 2002-03-23 14:08 · Score: 2, Interesting

What he's whining about is that it didn't fix every other problem in addition to overhead, and if anyone should actually bother making some huge new mime standard, now they won't have that carrot.

Obviously, if the rest of the problems were as big as he's trying to claim, yEnc would only be a minor setback for a new and more comprehensive standard, but the fact is that the 35-40% overhead of current standards is by far what's most annoying to usenet users. After we got PAR (parchive.sourceforge.net), reposts have been reduced drastically (except for pr0n and partly warez groups, where the dumb people with shitty servers rules).

Also, he's trying to say that because the increase in volume will outgrow the savings, there really is no savings. What kind of logic is that? Let's stop making processors faster, we'll just find bigger problems for them to be too slow for anyway, so what's the point?

After the introduction of PAR and yEnc, as a long time binaries downloader, I'll say the actual content of multimedia groups has more than doubled, and probably tripled, the last 6-9 months. That's progress to me.

Standards ARE important... here's why. by gambit3 · 2002-03-23 14:10 · Score: 5, Insightful

In one sentence, standards ARE important because they allow for the most people to get the most benefit.

I work in an industry that relies heavily on standards, and my job deals specifically with standards. Making sure that WE follow standards, and making sure that other vendors follow standards.

Sure, they're slow to develop. But they're the best for interoperability, and that's crucial. In my line of work (for a major Mobile Phone System NSS provider), I have to deal with other providers that have to follow the same standars we do. That allows both of our products to communicate. This gives the end consumer (i.e., Cingular, Sprint, etc.,) the option to buy from different vendors. This forces us to make better products. This forces us to be more efficient. This forces our competitors to do the same thing. In the end, everybody wins.

The other alternative is what I see as the Micro$oft approach: Standards be dammed, I'm going to do it this way, and f*ck everybody else. It's the same approach that gives you security holes in your browser, because, well, who needs the standards?

I can't believe I'm reading comments like "well, it's here and it works so what's the problem?"
The problem is the future.
The problem is the inability to send an SMS from a CDMA service like Sprint to a GSM one like Voicestream. That's what happens when you blow off standards.
The problem is the inability to read an M$ Word doc that was sent to a Linux user.
Ignoring standards and going off on your own (especially, going off BADLY on your own) just divides us.
Good standards help us all. They give us better products. The lower costs.
CD-Rs. FireWire. PCI. countless others.

Besides, as the article begins by asking: Just what problem were they trying to solve?

--
Watch the Teaser Trailer for "The Lightning Thief" Her

Re:Standards ARE important... here's why. by Anonymous Coward · 2002-03-23 16:33 · Score: 2, Insightful

"Besides, as the article begins by asking: Just what problem were they trying to solve?"

Faster, better and cheaper posting downloading of files.

"Standards be dammed, I'm going to do it this way, and f*ck everybody else."

That's what the standards guys said to the yEnc guy so he released his specs and source and said have at it. Now instead of waiting for a solution, we have one. Can it be improved? Sure but now the bar is raised for those who want to do it right
Re:Standards ARE important... here's why. by Lars+T. · 2002-03-24 08:21 · Score: 2

Faster, better and cheaper posting downloading of files.
Of pr0n and warez, stuff that could just as well be propagated through the web and FTP.

--
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck

Humor - "standards" by Seth+Finkelstein · 2002-03-23 14:15 · Score: 2

I see nobody has said it yet:

Standards are crucial. And the best thing about standards is: there are so many to choose from!

Sig: What Happened To The Censorware Project (censorware.org)

Re:Humor - "standards" by Seth+Finkelstein · 2002-03-23 17:23 · Score: 2

You could at least credit Andy Tanenbaum if not quote him correctly.
Thanks for the correction. I got the version I used from the "fortune" files, and it didn't have an author attributed.
Sig: What Happened To The Censorware Project (censorware.org)

yENC isn't even important by Anonymous Coward · 2002-03-23 14:17 · Score: 2, Insightful

The big savings on binaries is coming from .PAR files.

If you don't know what they are, then you haven't been on usenet for a while.

But essentially, it allows you to stripe you sets with parity so that you can lose up to "n" posts and the PAR programs can rebuild the missing pieces.

I believe this has helped the backbone tremendousl.

Re:yENC isn't even important by Sadfsdaf · 2002-03-23 20:13 · Score: 2, Interesting

Incidentally, many people in alt.binaries.news-server-comparison (one of the places Jeremy hangs out) are very opposed to PAR files and say they cause an increase in bandwidth. I don't know if Jeremy's one of them.

An excellent idea would be to make a new format where yEnc and PARs are combined. Imagine this: get rid of RARs, PARs and SFVs altogether. Post a file as one big file and have 1% parity. Tbe parity will be for individual posts (not enire RAR archives like before). 1% is more than enough since a 500 message post will have 5 parity messages. Most incomplete files only have about 3 or 4 missed messages and the 5 will fix those INDIVIDUAL POSTS. If that isn't enough, a few more parities are generated.

I find this idea MUCH more important than silly nitpicks on implementation. Of course, this can eliminate yEnc from the face of the earth if this was implemented, simply because it makes downloading binaries much much easier and simpler.

I've emailed Jurgen about this, but his reason was that it'd make adding in this way too complicated for news client maintainers.

Those who want to push a MIME format should implement this and create a new standard, everyone will jump from the yEnc bandwagon onto this like they jumped from the UUE bandwagon to yEnc.

Pan by Alien+Being · 2002-03-23 14:23 · Score: 2, Informative

And Pan's got it too. Tastes great, less filling!

I wonder if it's in CPAN yet...
Module Convert::yEnc (P/PN/PNE/Convert-yEnc-0.03.tar.gz)

Yep. Works for me!

Re:concretely: this is why you don't need it by willy_me · 2002-03-23 14:27 · Score: 2

I'm glad I'm not the only one who saw this. Seriously, the arguement that yEnc encoded files will consume less space on servers seems very flawed. Any good server should see a uuEncoded message and store it in compressed form on the server.

When you know it's a uuEncoded file, it should be very easy to write a speedy compression algorithm. Even just use a standard Huffman algorithm - it was originally designed to be implemented by hardware for storage devices (think tape drives) and wouldn't impose any real overhead on a modern server. I just can't see why we have to implement a new standard before it's ready.

Willy

Counterpoints to all of Jeremy Nixon's main points by Harumuka · 2002-03-23 14:29 · Score: 2, Flamebait

Uuencoding relies on searching for "magic strings" in the message body of a Usenet post. This is unreliable, error-prone, and has already led to problems with certain client software. It is absolutely the wrong way to go about tagging message content, because what you really want is something reliably machine-readable and precisely specified. However, yEnc also relies upon magic strings in the body.

There is no reason to despise magic strings. They work, and cannot ever occur in the user data. All yEnc magic strings start with =y, = being the escape character. Ctrl-Y does not need to be encoded, so yEnc is free to use =y for it's own purposes (e.g. =ybegin, =yend). Jeremy Nixon continues his misled rant...

With a uuencoded multi-part post, client software typically uses the Subject line of the post to attempt to determine the filename, and to tell where the segment falls in the sequence. This is obviously a terrible way to do it.

No, using the subject line is not obviously a terrible way to determine filenames, segments, and anything else. I find it very convienent to know exactly what my yEnc files will be saved as, how big they are, and how many parts they are in inside the subject line. Nixon says "Sure, it works out most of the time, but it is imprecise and error prone (especially when spaces are used in filenames)" This is blatently false nonsense. Quotes reliabily allow clients to discern the filename. It's not "imprecise and error prone" by any stretch of imagination.

When non-ascii characters are used in message headers, software currently just has to guess what they mean. Jürgen's filename specification cannot even be used to reliably reproduce his own name.

I give them that. Non-USASCII data in headers is a pain, and a large powerful organizational bodies needs to agree on a character encoding standard. Oh wait, they already did - Unicode!

but gives no method to specify a filename which happens to contain quotes, which is not uncommon

False again. I've never had a filename containing quotes on my Windows box. If we expect newsgroups standards to reach everyone, we must use the lowest common denominator. Similar to how ISO9660 used 8.3 filenames, but on a higher level.

And the bandwidth savings? That's an illusion. A smaller encoding scheme gives us exactly one benefit: faster downloads and uploads for the users

Which is exactly what the creators of yEnc intended.

Meanwhile, the transition creates confusion for the users

They mean "AOL users" of course. Usenet hasn't had a new encoding format in 6 years, it's about time. Adopting this format should be as easy as switching from Napster to OpenNap to Morpheus to Grokster to Blubster and so on.

When Jürgen found that going through an actual standardization process within MIME would take time, he chose to ignore MIME in favor of getting something out there right away.

I don't blame him. Jurgen is a coder, not a politician. I would have done the same thing.

In short, yes I agree yEnc needs to be more polished. But the point is it works right now, and it's working great. It filled a gap in Usenet, itched a stratch to borrow an ESRism. Once yEnc is standardized as Y.32049 Annex D or whatever those standard organizations call it, we will use it. Until then, yEnc forever!

--
What do you think of MusicCity now?

Re:Screw luddites by Wolfier · 2002-03-23 14:33 · Score: 2

While I quite agree to your "screw the luddites" idea, and I think yEnc is a progress, I'm not sure if HTML postings in usenet can be classified as a "progress", especially when this trivial idea does not need any imagination to accomplish. "Yay, we have HTML, let's slap it onto everything!!"

Not only isn't HTML postings an important "technical advancement", not everyone thinks HTML postings look better, either - surprise.

I, for one, deliberately killfile HTML postings and filter HTML emails because I don't need the funny colours that distract contents, and the security concerns associated with scripts, images, "runnable" postings and cookies.

Plus, every single piece of HTML posting and email I've seen are spam anyway. Why bother?

If you want to post HTML contents, there is a place it should be done and it is called "the web". I don't complain HTML postings in web pages because it is what the HTTP was designed for - and there are already many decent methods built in or around an application called "browser" to protect yourself from security hazards and spams. I cannot say so for newsreaders, at least yet.

Re:concretely: this is why you don't need it by Reality+Master+101 · 2002-03-23 14:39 · Score: 2

The new modem standards apparently even have special compression modes for HTML, and if uuencode and base64 matter, modems and other compressors could recognize them as well.

That's great ... if you use a dial-up modem. Personally, I think any more incentive we can give to stamp out dial-up modems, the better.

--
Sometimes it's best to just let stupid people be stupid.

Re:Screw luddites by squiggleslash · 2002-03-23 14:44 · Score: 2

As an example, I post HTML to Usenet. Intentionally. And I will continue to do so.

Please continue to do so. Killfiling by Content-type: text/html is relatively easy to do, and it's certainly easy for the rest of us to avoid downloading form-over-content crap posted by clueless bandwidth hogs.

Death to the luddites!

Whatever.

Personally I don't think someone who wants to be able to ssh into their shell account from work/etc and read USENET, rather than rely on (easily monitored) Google, or who doesn't want to run up a large phonebill downloading approximately 5-6x as much data as necessary, or who finds that there's no way of GUIfying the newsreader they've found works best for them, is a "luddite." I'd say they're using their common sense. And I'd say someone who describes them as a "luddite" and "living in the past" is someone whose respect for others is demonstrably lower than ought to be necessary for posting on Usenet. If there was a Usenet "licence", I'd argue that the name callers and bandwidth hogs ought to have their's revoked.

But YMMV.

Being on the Internet is about accepting standards. Some of those standards may not be perfect for you, but it's certainly not impossible to stick by them, and you can make your point easily enough and still follow them. Most people do. Get over it.

--
You are not alone. This is not normal. None of this is normal.

Re:Screw luddites by Reality+Master+101 · 2002-03-23 14:46 · Score: 2

Not only isn't HTML postings an important "technical advancement", not everyone thinks HTML postings look better, either - surprise.

So should the web return to the days of pure ASCII? Should Slashdot disallow any HTML postings? HTML is useful. Look at how it used on Slashdot -- italics, boldface, links, etc. Not to mention that proportional fonts are infinitely easier to read.

I don't complain HTML postings in web pages because it is what the HTTP was designed for...

How can you possible be in favor of HTML on the web, yet not in favor of HTML in Usenet? Put it this way: If Usenet were invented today and they included HTML, could you honestly say it would occur to you to say, "you know what would make this better? ASCII only!"

I cannot say so for newsreaders, at least yet.

Depends on your newsreader. If you're using a Windows newsreader, it typically uses the IE COM component to display the HTML.

--
Sometimes it's best to just let stupid people be stupid.

Re:Screw luddites by Reality+Master+101 · 2002-03-23 14:49 · Score: 2

So if straight ASCII is so great, why do you use HTML in your Slashdot posts?

Grumble mutter bah humbug

Your sig is particularly appropriate for your post.

--
Sometimes it's best to just let stupid people be stupid.

Re:Usenet? Please go away! by Sabalon · 2002-03-23 14:51 · Score: 3, Insightful

Lets see...Napster is dead. Morpheus is dead. Morpheus part 2/gnutella is a zombie (perhaps it's just me - I have yet to have it actually pull down a file for me. It keeps telling me the other end is busy or something.) Even when they were alive, you get half way through and someone cuts you off...or you find out that 80M download that took a whole day was actually mislabled.

On Usenet...sure - you don't get to search and finding a file involves posting a request and hoping someone fulfills, but you get bandwidth - assuming you want to pay for it...you get files that are there (assuming you have decent retention.) and not dependant upon someone being online. And unless you have a crappy server, you don't get halfway through a download and someone decides to kick you off. And 99% of the time, what something is posted as is what it is.

As for the replication - well, there is no one point of failure. As well, you don't have one site getting the shit hammered out of it either. I pay $9/mo for usenet...I get three fast servers to choose from and some high GB limit.

If I had to go to the same server as everyone else, you'd have the same problem that moviefone had when star wars tickets went onsale online - DOA - all with nice corporate control of content.

Technical arguments against yENC, blah by Tofuhead · 2002-03-23 14:55 · Score: 4, Insightful

It should be pointed out that this site, linked from yENC's own website, goes into more technical detail regarding the technical flaws of yENC. The fact that it's linked from yENC's own site is proof that the author is at least familiar with the concerns that people have with his implementation.

I personally still find it difficult to argue against the article author's point that THERE WAS NO RUSH to force yENC out the door in such an unpolished form. After so many years of waiting for something better, why ignore the recommendations of those you are trying to help?

< tofuhead >

--
It is still the dark of night.

Re:Change we must by Wakko+Warner · 2002-03-23 14:55 · Score: 2, Insightful

The key theme here is that people on usenet whine. A Universal Truth, as it were.

- A.P.

--
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"

Re:Screw luddites by squiggleslash · 2002-03-23 14:56 · Score: 2

Erm...

1. Slashdot is only accessable from web browsers.
2. Slashdot is an HTML forum.
3. HTML is fine. Posting it to Usenet isn't. See comments about cost of downloading, newsreaders, standards, etc.

Stop setting up straw men.

--
You are not alone. This is not normal. None of this is normal.

A few words from the original author by Ruddygore · 2002-03-23 14:57 · Score: 5, Informative

Well then. When I put that page up, I honestly didn't expect many people to read it outside news.software.nntp and a few curious folks in alt.binaries.news-server-comparison. I certainly wan't expecting to get Slashdotted. Well, that's fine, except that the uproar might have waited a little bit.

In my essay, I state that what Usenet needs is "a better way to post Binaries". The next piece of the puzzle, of course, is to answer the question, "What IS a better way to post binaries?" I was thinking about finishing that page up tonight, but I am writing code at the moment instead.

So, when reading my comments, just keep in mind that, yes, I DO have some answers to that question, too. It's just that it's a bit of a more time-consuming question, so that page isn't done yet.

This time around, though, I will make sure to include a prominent warning to NOT run off and implement the ideas as quickly as possible, and to please not use all of Usenet as beta-testers. The idea that whatever gets done fastest is best just doesn't work for me. There were good reasons I didn't go and get people to implement my smaller encoding ideas when I first wrote the code. If only the yEnc implementor had continued where I left off rather than going down his rather misguided path...

All the comments are welcome. I've been getting some interesting email, too, of course. Many programmers of Usenet client software absolutely despise the thing and are quite annoyed at the amount of their time it is wasting. I guess it's just more of that never-ending divide between the users and the techies. So it goes.

yEnc is here, that's for sure. Now we just have to try to deal with it.

Jeremy

Re:A few words from the original author by Bishop · 2002-03-23 16:33 · Score: 2, Insightful

Because Usenet works, and an "efficient P2P system" does not exist.
Re:A few words from the original author by Wesley+Felter · 2002-03-23 18:38 · Score: 2

IMHO, Usenet is good for binaries because the person doing the transmission only has to upload a file once for lots of people to download it (like a web server) but it is hard for an ISP to squelch it because of the automatic propagation to other ISPs.

I agree that these are good properties, but they aren't unique to Usenet. Both Freenet and MNet only require a file to be uploaded once and they both automatically propagate popular files. But they don't automatically propagate unpopular stuff like Usenet does.
Re:A few words from the original author by sparrowjk · 2002-03-23 18:42 · Score: 3, Insightful

Your essay is the best summary I've seen so far of the reasons not to use yEnc. You have done a service to those of us who have been annoyed with yEnc -- now we don't have to explain it to anyone, we can just point them to your essay.

So, be it resolved that yEnc leaves much to be desired.

However, if yEnc is the impetus which actually gets the community moving toward implementing a good, solid standard, then it will have served its purpose. Perhaps if we had had yEnc 5 years ago, we would have a standard already. But we didn't, and now we must pay the piper.

Since people aren't going to give up the advantages of yEnc without a substitute, the priority going forward is clear: to develop a better standard. If it truly is better (and not simply another hack) then ensuring its wide adoption shouldn't be too much of a problem. If, however, people can't be persuaded to switch, so much the worse for Usenet -- but no point in dwelling on doomsday scenarios. As you say, the cat is out of the bag, and all we can do is damage control.

Don't bother downloading now by DiveX · 2002-03-23 15:02 · Score: 2

Either it is /.ed to hell or the server is having major problems (not that they are exclusive). A lot of people are having the download stop at 10-15%. All this for a simple 2 meg file. If someone already has it, throw it to a binary group and provide a link.

--
Cave, wreck, and deep diver.

Re:Don't bother downloading now by Account+10 · 2002-03-23 15:22 · Score: 2, Informative

It is posted to alt.binaries.warez.ibm-pc Subject: As Requested a UUencode version of Agent 1.91 with yEnc [1/2] - a32-191.exe Message-ID: <q7Pm8.81615$rr6.1172226@news.webusenet.com>

Consider the source by JohnA · 2002-03-23 15:06 · Score: 2, Flamebait

I'm not sure if it is still true, but I know that Jeremy Nixon (the author of the article) worked at Supernews (now ReMarq) as one of their chief engineers. Not to be jaded, but it stands to reason that he would be against a technology that will decrease the data transferred by customers who pay by the gigabyte.

Re:Consider the source by Burdell · 2002-03-23 15:49 · Score: 3, Insightful

Actually, Supernews is now part of Critical Path (the RemarQ name went away). And yes, Jeremy Nixon does work for Supernews. He also wrote Cleanfeed, the anti-spam program that Usenet admins everywhere to make news bearable to read.
The "he's against it because it saves bandwidth" argument makes no sense. If it saves users a little bandwidth, it saves Supernews many many times that much bandwidth, lowering their costs (which means they don't have to charge users as much to provide the same service). It also saves disk space, meaning Supernews doesn't have to buy new disks quite as soon. And a good bit of Supernews' business is in the corporate (outsourced ISP) service, which they don't charge by the gigabyte (they have speed caps, not monthly download quotas).
The problem is that any savings are just an illusion; this is just a momentary blip in the growth of Usenet. Since yEnc doesn't have the 100% market penetration that uuencode and MIME have, people are more likely to post binaries in multiple formats, causing storage and bandwidth needs to increase, not decrease.
Re:Consider the source by Ruddygore · 2002-03-23 15:55 · Score: 2, Informative

If you think this is going to decrease the amount of data transferred by customers, you need to take off those rose-colored glasses. I suspect it won't affect that at all.

Smaller encoding helps us (the providers), it doesn't hurt us. (Besides, one look at the Supernews price list versus the competition will reveal that metered individual accounts are hardly the main focus.) With the customers the actual money comes from, less downloads would increase the margins, not decrease them. In fact, to a lesser extent, it would do so with the individual accounts as well -- the pricing on individual Usenet accounts (at almost all of the top providers) is such that the margins are lower at higher download levels. At the highest levels, it's nearly break-even. So less downloading would even be somewhat better there.

If you really think that I'm against a smaller binary encoding scheme, then you completely missed the point of my essay -- and you also must have missed the part about how it was my first experimental code, implementing smaller encoding, from which yEnc was hatched. If I truly wanted to avoid smaller encoding, why would I have implemented it in the first place? Why would I have done it in public and then sent the code to several people, explicitely releasing it into the public domain? You think I would have done that to prevent the spread of smaller encoding?

Had Jürgen picked up where I left off and did the thing right, I would be singing an entirely different tune.

Jeremy
Re:Consider the source by Ruddygore · 2002-03-23 16:19 · Score: 2, Insightful

More, smaller messages -- what difference do you think that would possibly make?

My answer to yEnc is brewing, and frankly, I'm not arrogant enough to push anything which is "my" answer to yEnc. There are a lot of people out there who know what they are talking about and it would be stupid not to listen to them. So, don't look for "my" answer to yEnc... look for "the" answer to yEnc, developed not by one hacker but by a group of people who know what they're doing.

Jeremy

Re:Screw luddites by Reality+Master+101 · 2002-03-23 15:07 · Score: 2

Stop setting up straw men.

No, it's not a straw man. Look past your "it's always been done that way" attitude, and think about it. Why is a Slashdot HTML forum "good" and a Usenet HTML forum "bad"? History is not a reason. Standards are meant to be enhanced.

Sheesh, some geeks are worse than PHBs on this issue. It reminds me of that shipping company commercial where the boss drones on about the fact that "we've always shipped this way. We will always ship this way" while the young employee stands there mocking him.

Why do I have a feeling that all the old farts are going to have to die off before this issue goes away?

--
Sometimes it's best to just let stupid people be stupid.

Re:There's a lot of irony by J'raxis · 2002-03-23 15:07 · Score: 2, Interesting

How is MIME complex? Heres a simplistic MIME message I just wrote out by hand in about 5 minutes:

From: jraxis ("J'raxis 270145") To: dwsauder Subject: Foo Content-Type: multipart/mixed; boundary="foo12345" Here's your foo.jpg. --foo12345 Content-Type: image/jpeg Content-Disposition: attachment; filename="foo.jpg" Content-Transfer-Encoding: base64 [ base64 data ...] --foo12345--

You want checksumming? MIME provides a Content-MD5 (which is more reliable than CRC). yEnc could have just been registered as a new form of transfer-encoding (along with base64, quoted-printable, etc.) and happily merged into MIME.

--
Liberty in your lifetime

Encoding efficiency isn't a BIG deal by Sloppy · 2002-03-23 15:07 · Score: 4, Insightful

If, by any chance, you're transferring things over a modem (v42bis' lzw) or ssh vpn (zlib's deflate) or possibly other types of links, then you're probably not going to notice a difference anyway. The systematic encoding inefficiency that goes with base64 and uuencoding, results in a substantial lack of entropy that will be picked up on and exploited by good compression algorithms. Then end result won't be quite as good as having efficient encoding to begin with, of course, but it will be in the same ballpark. There's no way it'll be anywhere near a 33% difference.

This sounds like something that would have been useful 15 years ago before compression was widely used, and when people were still writing newsreaders. Now it looks like a waste of time and an excuse to get people to "upgrade" their software.

--
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.

Problems, Solutions, and Change by _Sprocket_ · 2002-03-23 15:13 · Score: 2

This post has me thinking a bit. At first, I'm all with it. Yea! Progress. Let's go.

In the case of yEnc, someone found a problem and (Freely, as in public domain even) offered a solution if people wish to adopt it. People are adopting it. Progress is happening.

And then I hit:

As an example, I post HTML to Usenet. Intentionally . And I will continue to do so. The green-screen luddites need to stop whining and upgrade their newsreaders. Yes, ASCII newsreaders can strip out (or render to some degree) the HTML. And no, I don't care about the extra bandwidth. There's a reason that newspapers and magazines use italics, boldface and bullet lists.

And I can't help but think "wow - what a jerk." Why? Not because I don't have newsreaders and email clients capable of handing HTML based messages. Not because I dislike HTML itself (open standard - yay). But because HTML seems to be completely unneccisary in these environments.

Now... sure. There are some forums that might bennifit from it. Times where typefaces and bulletlists, etc. really add value to information. Maybe even times where some forms of information NEED this technology or it becomes very difficult to portray. But I rarely see it.

Instead, HTML based messages in Email and Usenet tend to increase the overhead with no real added value to the content. In some cases, they are used to attempt various shennanigans such as web-bugs (not to mention worms, etc). Little wonder tech-heads dislike it.

Change must happen. But when you run around trying to force change for change's sake rather than to solve real problems, then you simply become a problem yourself.

Transfer speed isn't the only reason for it. by jridley · 2002-03-23 15:20 · Score: 2

Because people with premium news services (AKA, ANYONE that's serious about large binary downloads, the people at which yEnc is aimed):
- have megabyte quotas, both upload and download
- pay by the megabyte for their downloads

Also, this saves space on the server hard drive. NO WAY are usenet servers compressing data on their hard drives. It's one of the most challenging situations for a hard drive, they're not going to wreck their performance by using compression. Having less data means more retention on the server.

I personally have a Newsguy extra account, grandfathered at 1GB per day. I EXHAUST MY QUOTA by about 10AM, most days. I still do, but by then I've gotten 30% more data.

It's not all about transfer speed. yEnc means people with download quotas get 30% more stuff per day.

Re:Transfer speed isn't the only reason for it. by jridley · 2002-03-24 01:23 · Score: 2

No, they're NOT counting the data compressed. At least, none of the servers I've subscribed to.

Well, it's a moot point anyway because pretty much everyone's already using it.

I can tell you that my upload and download times are way down for posting now that I'm using yEnc.
Re:Transfer speed isn't the only reason for it. by jridley · 2002-03-24 01:29 · Score: 2

Oops, sorry, I misread your comment.

This doesn't make any sense. The cost to the provider is primarily the bandwidth to get the data to me. In the agreements we have at work with our IP peers, I don't see anything that says "we're billing you for compressed data amounts, not actual data amounts." I assume the news providers have the same deal.

I don't really know, so I'll shut up about it until I can find out.

BTW the "add to the NNTP spec" argument is not terribly practical. First, most people don't have the knowledge to define a spec that would be acceptable to server operators (I'm sure there are a lot of things to be considered). And even if it was defined, you'd have to wait for the server software companies to implement it, and then wait for the news providers to roll it in. I bet it couldn't be done in less than 2 years.

By defining the yEnc spec as they did, it's totally in user-space and up to the user and user's programs to implement.

Re:Screw luddites by squiggleslash · 2002-03-23 15:23 · Score: 2

Why is a Slashdot HTML forum "good" and a Usenet HTML forum "bad"?

I've already given you the reasons why posting HTML in Usenet is *BAD*. Posting HTML in Slashdot is OK because Slashdot is designed to be read by webbrowsers. Oh wait, I've already told you that too! Additionally, just as going out of your way to deliberately format stuff as HTML in Usenet is likely to make things harder for normal users, going out of your way to make things appear as "plain text" (which Slashdot, unlike most graphical newsreaders, forces to be shown as fixed font text), will make it more difficult for users to read your comment.

Standards are meant to be enhanced.

Standards are not meant to be "enhanced" unilaterally, otherwise they're not standards.

Why do I have a feeling that all the old farts are going to have to die off before this issue goes away

So we're back on the insults again. Come on, I've already explained to you exactly why posting HTML is a bad thing in Usenet. You so far have set up a straw man hypocracy argument about posting HTML in an HTML forum, and now you're back to name calling and claiming anyone who disagrees with you lives in the past. What you haven't done is address the actual reasons why people want HTML out of Usenet.

And until you do, and perhaps even come up with practical solutions to these problems, I don't plan to take you seriously. I doubt anyone else does either.

--
You are not alone. This is not normal. None of this is normal.

Re:This is why it is bad by dvdeug · 2002-03-23 15:24 · Score: 2

In fact, lets kill off mime altogether, and get this multimedia crap out of our inboxes. Email/Usenet is for plain text, period.

Yes, because everyone who doesn't speak English should just shut up. You did realize that MIME is the only standard on how to send non-ASCII plain text across email, didn't you.

Re:concretely: this is why you don't need it by jridley · 2002-03-23 15:24 · Score: 3, Informative

See my other post in this thread. It's not all about dl speed or even drive space. Most serious usenet large binary downloaders use a premium news service, and they ALL have download/upload quotas and/or pay by the byte schemes. yEnc gets you 30% more for your buck on those servers.

Re:Screw luddites by Glytch · 2002-03-23 15:28 · Score: 2

I was going to post a long technical piece on why what you're doing is wrong, but, essentially, it all boils down to the fact you're just a prick.

Re:Screw luddites by mikeage · 2002-03-23 15:31 · Score: 2

Let's have some moderation (not the select a category, but some moderate views) here. I agree that <i> and <b> can enhance a posting. What the other poster was commenting on, and which I agree (since I often connect via modem, often 28.8, sometimes even 14.4)is that excessive HTML is useless. It doesn't add to the content, it just gives it a little extra pizzaz, which is not always good.

--
-- Is "Sig" copyrighted by www.sig.com?

Re:On a related note... by dimator · 2002-03-23 15:43 · Score: 2

Thanks for the tip, but I've tried that too (in fact, they resolve to the same IP). The last line of the traceroute is:
16 so-1-3-0-0.SVCS-RTR1.RES.verizon-gni.net (141.156.255.46) 97.166 ms !A 97.214 ms !A 97.336 ms !A

Where the !A means access to the host is prohibited. (I'm going to have one hell of a time trying to convey this to a tech support moron.)

--
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"

Re:Screw luddites by dvdeug · 2002-03-23 15:44 · Score: 2

Sheesh, some geeks are worse than PHBs on this issue.

You propose a method that many people can't read,
and while it's supposed to look better if you can read it, it frequently just looks like over-elaborate crap.

Geeks believe in content over packaging, at least more than your average person. HTML offers very little in an email or newsgroup environment, where messages are quickly written, but often come with huge overdone packaging. Geeks also like to use their computers via text links, and HTML is not friendly to that. Somehow it should not be surprising that they aren't happy with HTML in those enviroments.

Re:Screw luddites by pyramid+termite · 2002-03-23 15:44 · Score: 2

So should the web return to the days of pure ASCII?

And when was that? You do know that HTML is an intregal part of the WWW, don't you?

How can you possible be in favor of HTML on the web, yet not in favor of HTML in Usenet?

Because the newsreader I use doesn't know what to do with it and the way a lot of the people who use HTML on Usenet do it, it doubles the length of the post.

Put it this way: If Usenet were invented today and they included HTML, could you honestly say it would occur to you to say, "you know what would make this better? ASCII only!"

For a medium that outside of the binaries newsgroups was designed to post text messages? Why wouldn't ASCII only be better for plain text? I actually think a lot of web pages have gone overboard and have worsened the bandwidth/content ratio considerably. There's nothing wrong with lean and mean.

If you're using a Windows newsreader, it typically uses the IE COM component to display the HTML.

While allowing other possibly malicious components to wreak havoc with your system - a problem that never happens with plain text messages, does it?

Go ahead. Post HTML on Usenet. But you should know if I read it, it's going to look like a hard to read text message with a lot of bracketed garbage and I'll be more likely to skip over your posts in the future.

What newsgroups do you read, anyway?? by Russ+Nelson · 2002-03-23 15:46 · Score: 2

I've heard this "is usenet dead" crap one too many times. Comp.lang.python isn't dead. Soc.religion.quaker isn't dead. comp.protocols.tcp-ip.ibmpc isn't dead (okay, so it doesn't have a lot of traffic, but the principals read it, which is what matters).
-russ

--
Don't piss off The Angry Economist

Standards for Usenet encoding??? by roystgnr · 2002-03-23 15:51 · Score: 3, Insightful

Can *anyone* look at the uuencoded, mime encoded, and other similarly mangled into 6bit, 70 character-per-line standards, and honestly tell me that Usenet was designed with binary file transmission in mind?

There are no Usenet binary transmission standards, just a few different hacks to make it work. If this guy's new hack makes it work better, good for him.

Re:Usenet? Please go away! by Shelled · 2002-03-23 15:54 · Score: 2, Interesting

"But what's the possible justification for continuing to use Usenet to share files? Aside from inertia."

Discovery, that's why. Napster (Napster?, talk about dead!) and the like are great for finding a name you already know. By design, that's all it can do. Do a search for "early '80's Boston punk" for example and see what you get. This is where Usenet excels. Enthusiasts congregate into groups and upload files they enjoy, meaning a far better chance that I'll enjoy them too. I'm continually discovering great bands through Usenet that would remain unknown had I relied on name-search based file sharing.

Look ma, no mouse! by dattaway · 2002-03-23 16:00 · Score: 2

Oh no! slashdot is beautifully rendered in a textual browser such as lynx and lightning quick over a 9600 baud cellular modem. If you never tried viewing this site under lynx, you may be surprised at the artistic detail of the formating.

Over to the left where the links take the shape of an ascii candle flame followed by more links presented in an intuitable format. Rob was generous leaving this site accessable to the more mature historical browsers.

What a miserable bugger by darien · 2002-03-23 16:01 · Score: 2, Insightful

I lost sympathy about here:

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 [...] big deal.

So effectively, what he's saying is, in effect: "this system changes nothing, and is of no benefit, except that it makes more data available on the Usenet and gives users faster uploads and downloads. So it's worthless."

This guy obviously hasn't had to use a metered dial-up account for a while. A 33% saving on transfer times is an enormous benefit. I feel quite insulted by the way he seems to think it's of no importance, as if my time and money aren't worth anything. "What's the rush" indeed! I'd happily tear up MIME and MD5 tomorrow if it would speed up my transfers by a third.

If yEnc is so widespread, it can only be because there's a demand for it. And if there's a demand for it, why the hell shouldn't programmers support it? Last time I checked, RFC's weren't enforced by law. The Net has seen a million non-standard hacks, and has, for the most part, assimilated the good ones and outlived the bad. yEnc is by no means the worst, and it brings real benefits to tens of thousands of people every day. I say leave it alone - or if you have to oppose it, at least oppose it constructively, for Christ's sake!

Re:What a miserable bugger by Ruddygore · 2002-03-23 16:12 · Score: 2, Informative

You just gotta love the speculation that runs rampant around here.

FYI, I am using a metered dialup account (actually ISDN, which isn't much faster, just more reliable). I cannot get unlimited, high-speed access (yet, I keep hoping). I pay well over $100 per month for Internet access at a fraction of the speed of peoples' cable modems and DSL lines, and it would be quite a lot more if I left it nailed up 24x7.

You, like several others here, seem to have somehow gotten the impression that I am opposed to smaller encoding. I can only conclude that someone is spoofing my web host's DNS and some of you are reading a different page than the one I wrote.

Jeremy

Re:Screw luddites by Reality+Master+101 · 2002-03-23 16:02 · Score: 2

How do you reconcile putting in this assertion: [etc]

Because it's absurd to argue about features in an application (i.e., Slashdot, Usenet) based on what protocol it uses. Either a feature is useful, or it is not. You can't have it both ways -- either HTML is good for discussion groups (Slashdot OR Usenet) or it is not.

--
Sometimes it's best to just let stupid people be stupid.

Screw Elegance by Deflatamouse! · 2002-03-23 16:02 · Score: 2, Troll

If everyone is as anal as the poster of this story and cares about elegance and "pretty code" and whatnot, we all would not be using a x86 processor because its architecture is just "sooo damn ugly!!". Get over it. If it works, it works, does it really matter how anything is implemented if it does its job just perfectly fine?

Personally, I will adopt anything that will make my life (not the developer's life) easier. yenc allows me to download 30-40% less, so I use it. Why? because if I don't use it, I won't be able to obtain the mp3s, the games, the warez, the pr0n, etc, etc, etc that I wanted :) Real life is not pretty, deal with it... stop living in fantasy world.

Re:Why yEnv is good for the software companies by foonf · 2002-03-23 16:03 · Score: 2

Most progressive newsreaders group multi-part binary posts together pretty well. That really isn't a problem at all. And the reason for the multi-partness doesn't have to do with a particular encoding scheme, but with the line number limit many servers impose on posts.

--

"(Man) tries to live his own life as if he were telling a story. But you have to choose: live or tell." --Sartre

Good idea, but... by Firecaster · 2002-03-23 16:09 · Score: 3, Informative

... the implementation sucked.

I leech regularily from alt.binaries.anime and the related newsgroups. When the yEnc posts started coming in, I simply upgraded my newsreader to the newest version. But a LOT of people out there use Agent, and it was absolute pain to combine/decode all the yEnc posts that started popping up all over the place. The worst of it is that the yEnc posters were basically saying, "Start living in the present and upgrade". Nevermind that at the time that only yEnc-capable newsreaders were for Windows...

I mean, I don't know, but this sounds a lot like the OS wars that have been going on for quite some time. Some people simply don't want to have to switch newsreaders. Some people don't want to have to switch OSes. And that's fine, because it's a free world out there. I like the idea of yEnc (I get more out of my Easynews account), but I really don't think it should have been introduced so quickly.

~ Firecaster ~

Two Problems: by NeuroManson · 2002-03-23 16:09 · Score: 5, Interesting

One: yENC, when it was unveiled, did not really allow most conventional newsreaders any opportunity to adapt, til after the fact. This is akin to perhaps releasing zip files long before any archival software was actually available to open them... So do most of the folks using usenet for binaries get the opportunity to at least *choose* the way they do their downloads? Nope, they also are forced to adapt, or lose out...

Two: Loss in transmission... I've been downloading yENC attachments for the last month, and out of them, found over 50% loss/corruption in posting... Not due to retention/propagation either... Just files missing large chunks... Now this *could* be due to some problems on the senders' end, but it seems just a little *too* coincidental that almost all of the losses have occured with yENC uploads...

--
Just because you can mod me down, doesn't mean you're right. Shoes for industry!

Re:Two Problems: by weave · 2002-03-23 19:08 · Score: 2

Yeah, I've seen the same thing. Xnews started supporting it almost right away and hence I started to use it (or basically, not care about it since Xnews handled it transparently).
I too have noticed a large number of corrupted files in downloads from giganews, something I never saw before yEnc. (giganews has large retention and excellent completion rates. It wasn't lack of completion that caused it...)
At this rate, I'm paying more (by the gig) because I am throwing out so many corrupted downloads.. :-(
Re:Two Problems: by NeuroManson · 2002-04-05 08:38 · Score: 2

The difference is pretty simple when you consider the following: The average number of computer users numbered in the low millions, if not the high hundreds of thousands... AND the zip format was almost immediately known (practically open source when you think about it)... Those who sent out files with .zip extensions would let people know where they could find the software to decompress said files...

Making matters worse, you have millions of people looking at these files asking "WTF?!? How do I open these?!? (especially with Outlook Express or other generic off the shelf news clients)

Look at the yENC format, and you'll immediately note the difference... Nobody posting it tells you WHERE to find the nessesary software to open the attachments, at best you will find a description of why yENC is being used, nothing more...

--
Just because you can mod me down, doesn't mean you're right. Shoes for industry!

Re:Screw luddites by dvdeug · 2002-03-23 16:11 · Score: 2

either HTML is good for discussion groups (Slashdot OR Usenet) or it is not.

One huge difference between Slashdot and Usenet is that Slashdot only permits a subset of HTML tags in posts. If Usenet HTML would limit itself to a similar subset, then it would be much more platable.

Also, Slashdot has already limited itself to those who can handle HTML, so why not permit HTML in posts? Usenet is and always has been available by plain text, so HTML gets much more scrutiny.

Re:Seems silly to be complaining.... by khuber · 2002-03-23 16:21 · Score: 4, Insightful

This is wrong thinking. NNTP is an internet protocol and yEnc should play by the rules of internet protocols. It does not and that's why it is bad. You can't break building codes to build your house and justify it because you saved a few bucks. "Hey...it seems to not collapse" "it hasn't caught on fire yet!"

In particular, there is no yenc RFC and yenc does not use MIME which is the agreed upon standard for encoding binary attachments. Yes, uuencode is a gross grandfathered format, but it is still 7 bit clean.

Releasing problematic improperly specified encodings that break internet protocols is not being a good citizen. "it works" is a poor justification. it does not work, and breaks compliant software.

-Kevin

Reminds me of Napster data format by topham · 2002-03-23 16:28 · Score: 3, Insightful

This just reminds me of the napster data format. Anybody ever read the reverse engineered specs? It's scary. It looks like it was designed by a monkey. And not a smart one.

yEnc sounds like a good idea, and a horribly bad implementation.

Eight bit characters and old servers by phr2 · 2002-03-23 16:28 · Score: 2

What happens to those servers now, on the normal text newsgroups, where lots of messages appear with accented characters?

And how many "ancient" servers are really handling the (huge-traffic) binary newsgroups where yEnc encoding is appearing? I would have thought old servers were made for much lower news volume and couldn't handle the load.

I'm not a news guru though. I just read the stuff sometimes.

Re:Screw luddites by Reality+Master+101 · 2002-03-23 16:55 · Score: 2

He didn't. He thought it had its place, but that place wasn't Usenet. Phenomincally easy to understand, you pretended - you lied, if you like - that he was arguing that HTML was an evil by itself.

*sigh* Of course, it has be a problem with me ("lied"??) -- it couldn't be that you're not understanding the point I'm making.

The point is that he recognizes the advantages of HTML on the web and on Slashdot, yet is unwilling to consider those advantages for Usenet. I turned the argument around -- if ASCII is so great for Usenet, then why not all ASCII for the web?

Both the web and Usenet are publication protocols. They just go about them in very different ways. I find it very useful to be able to italicize, boldface, embed links, have lists, etc in my publications, not to mention the advantages of proportional fonts.

--
Sometimes it's best to just let stupid people be stupid.

Jeremy's right, but it's too late now. by Charles+Kerr · 2002-03-23 17:00 · Score: 5, Interesting

I'm one of the authors of the Pan newsreader and agree with Jeremy's analysis of yEnc. yEnc repeats many of uu's mistakes, so news clients have to search text/plain messages for =ybegin and =yend blocks instead of looking in the headers.

But yEnc's bandwidth savings are real, which is a huge win for alt.binaries users. yEnc has been the most-requested feature for Pan over the last month. (0.11.2.90 supports it.) IMO yEnc is the format to use for multiparts right now.

Hopefully yEnc will motivate others to come up with a mime-friendly alternative encoding for Usenet. yEnc Considered Harmful is another yEnc opposition page that suggests mzip compression, but I haven't seen any public discussion of it yet.

If/when such a replacment comes along, Pan will support it too and add an are-you-sure dialog for yEnc postings.

Re:Jeremy's right, but it's too late now. by slashdot_commentator · 2002-03-24 04:11 · Score: 2

BTW, kudos on the 0.11.2.90 release.

My response to yEnc was basically to sit on my thumbs watching all the movies & tv shows go into a yEnc-encoded oblivion until you guys put out the yEnc compatible Pan. (...Like I was going to switch to a windoze newsreader... bah!) Only lost two weeks worth of TV and movies...

--
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon

More like it used to be by medcalf · 2002-03-23 17:28 · Score: 3, Insightful

It used to be that someone did something useful, then the community, through use choices, adopted it as standard. Then, if there were flaws, these would be ironed out with an updated standard, usually all or mostly backwards-compatible with the original implementation. It's gotten to where new standards are useless, either because companies (like, say, RealNetworks or MS) refuse to submit their protocols/formats for public use/review, or because the standards committees (say, for Java (before it was pulled) or the W3C) argue for years without actually doing anything.

I, for one, am happy to see a useful format publically available.

--
-- Two men say they're Jesus. One of them must be wrong. - Dire Straits

Re:Screw luddites by pyramid+termite · 2002-03-23 17:43 · Score: 2

The point is that he recognizes the advantages of HTML on the web and on Slashdot, yet is unwilling to consider those advantages for Usenet.

What's the major advantage to HTML on the web? You can link to other pages on the web, knowing they're there.

Now how would one use HTML to link to other posts on Usenet and be sure they're there? Could you write a post linking to several later posts you were planning?

No. The only thing you can really do with HTML on Usenet, seeing as binaries such as images are prohibited on text groups, is to present text. (Unless you're running malicious scripts.) And guess what? You don't need HTML to do that - you don't even need it to post web links, as one can just copy and paste them into a browser.

I turned the argument around -- if ASCII is so great for Usenet, then why not all ASCII for the web?

Because, dumbass, it couldn't be a web, then, could it? Maybe, before telling us how Usenet should work, you ought to learn how the web works first.

Well by Trepidity · 2002-03-23 17:46 · Score: 2

I'm glad you agree that Microsoft Word is proven to be one of the best programs in existence. =]

--
10 PRINT CHR$(205.5+RND(1)); : GOTO 10

the author responds... by flip-flop · 2002-03-23 17:49 · Score: 2, Interesting

As some of you might already have noticed, the author of yEnc responds to several of the points raised in his FAQ (scroll down to near the end of the page). His replies (to questions such as "Some people say that yEnc is badly designed and was rushed without proper discussion. Is this right?") seem quite realistic and sensible to me, and I get the feeling some of the accusations levelled at Jürgen in the article weren't entirely fair.

Re:All of Mr. Nixon's points are easily refuted by Anonymous Coward · 2002-03-23 18:11 · Score: 3, Informative

"Whatever kind of "confusion" this guy is referring to is nonexistent. yEnc downloading and decoding with the right software is as transparent as uudecoding. Promise. People don't have to relearn anything."

Well people do now have to think of yENC's longer lines. Where before my ISP newserver let me post 5000 lines of uue material now I only get 2280 with yENC. Longer lines under yENC. That's why Agent 1.91 has such a small line length as the default. Yes the payload is the same but you have to think a little different or just rediscover your servers limits.

A shame by wdr1 · 2002-03-23 18:57 · Score: 2, Interesting

A shame his article isn't better written. It seems Nixon has some good arguments as to how to make yEnc better, but is having trouble making them.

Nixon seems intelligent, but he doesn't want to understand that his problems, as an admin, are different from those of his users. To quote:

And the bandwidth savings? That's an illusion. A smaller encoding scheme gives us exactly one benefit: faster downloads and uploads for the users.

... and ...

The problem here isn't that we need a smaller encoding scheme, the problem is that we need a better way to post binaries on Usenet.

Well not really. What Nixon wants is a better way to distributed binaries on Usenet. Based upon the popularity, what the users want are faster downloads. That "exactly one benifit" seems to be pretty signifcant to them. As a admin, I'd guess that Nixon has pretty much high-speed access almost all the time. In that type of an enviroment, it's easy to forget the pain of life with a modem.

That disconnect is further demostrated by the iron-clad assertation that Usenet, in it's current form, is near perfect:

What was so broken? Nothing. Usenet was working just fine, and people were posting and downloading binaries just fine.

To me that conveyed a very unwelcoming aditude to anything that might rock the boat. Nixon feels everything is okay right, but it seems a lot of users seem to feel there is room for improvement.

More progress is likely to be made if the admins stop and understand why users are eger to adapt yenc instead of trying to dismiss as ignorant why they do so.

-Bill

--
SlashSig Karma: Excellent (mostly affected by moderatio

Re:All of Mr. Nixon's points are easily refuted by Ruddygore · 2002-03-23 20:04 · Score: 2, Informative

As a "pretty active Usenet poster and binary downloader," I bet you know your stuff pretty well. You could switch to anything in a short time, I bet. That's great, so could I. You're not looking at the average user, though.

Since I put my page up, my mailbox is overflowing with messages from people who are agreeing with me, but for the wrong reason -- they are saying, yeah, right on, this yEnc thing sucks, I can't figure the thing out and I can't get half the binaries anymore, how do we get everyone to go back to the old way?

If you just look at the people who know what they're doing and know it well, of course you won't see much confusion. But a popular binaries group easily has several thousand times as many people downloading as it has posting, so I think you are grossly underestimating the level of confusion this is causing among the regular users.

I'm not worried about confusing them; it's inevitable. What I'm worried about is confusing them too many times in a row.

Jeremy

Where are Amazon and BT? by Snowfox · 2002-03-23 20:04 · Score: 2

Shouldn't nVidia, Bezos or British Telecom be stepping in about now to claim a patent on encoding 8-bit data as 8-bit data?

Whats your point? by Crass+Spektakel · 2002-03-23 20:59 · Score: 2, Insightful

In the very early 1990 I was using subnet, which was assimilated by usenet meanwhile, with uucp and wazoo.

Even way back then there was vital interest in more efficient filetransfer. uudecode simply sucked. Everybody agreed to this.

But what did happen in the last 12 years?

Nothing.

There are now more powerfull uudecode-implementations, but I havent really seen anything practical invention in the basics.

I totally agree that yEnc is a quickshot with none thinking at all and its weird and so on. But the usenet-gods havent done anything wort mentioning in the last 12 years and they will not do in the next five years. They lost it and are now crying for not getting asked. Sad fate, but graveyards are half full of indispencable people and half full of people who dispenced with them..

--
"Life is short and in most cases it ends with death." Sir Sinclair

Kiss my....... Ass!!!!! by ainsoph · 2002-03-23 21:03 · Score: 2

you may be surprised at the artistic detail of the formating.

LOL...man...

Re:concretely: this is why you don't need it by Anne+Thwacks · 2002-03-23 21:11 · Score: 2, Insightful

If there is any reason why you dont need it, its becauwe People using 7-bit for pass-though traffic should be excommunicated.

7-bit died BEFORE THE PC- That's over 20 years ago. I seriously doubt there are any PDP11s still on the internet, and AFAIK nothing else felt the need to pack three 6-bit chaaracters into a 3 character file extension. Apart from that, it was a 16 bit machine and did 8-bit chars. Almost all other 7-bit hacks were dead before the PDP-11 was even launched. (except POCSAG pagers - now there is a seriously SAD protocol!)

The best answer is dotn compress for transmission - let the modem/imodem/NIC/why do it IF THERE IS A SUITABLE STANDARD, and if not, let the appropriate standards committee fix it, cos they have the tools for negotiation a compatible standard at run time.

--
Sent from my ASR33 using ASCII

History by stox · 2002-03-23 21:43 · Score: 2

Speaking as previous long time user of CBBS ( the birthplace of Xmodem ), I will point out that Xmodem enjoyed a great acceptance in the BBS community prior to adoption of support for Kermit. Early versions of Kermit were extremely inefficient compared to Xmodem, but it was the only game in town if you were interested in tranfers to and from MVS mainframes. Kermit quickly ruled the domain of inter-architecture tranfers, while XModem, and it's derivatives quickly dominated the PC domain.

And years later, there was the legendary KA9Q code. :->

--
"To those who are overly cautious, everything is impossible. "

Not so new by nrosier · 2002-03-23 22:04 · Score: 2, Informative

I don't know who was first and I'm sure this is not the only other tool/compressor but here in Belgium, we've been using a tool called Bommanews (b-news.sourceforge.net) for a while now because of rediculous upload-limits by the local cable-ISP. We're not allowed to run servers (ports &lt 1024 are blocked), have un upload-speed-limit of 128kbit/s and only 15% of our total traffic can be upload so some guy came up with this to allow easy distribution of files through the news-server. Because it's so popular, our ISP finally had to setup a 2nd news-server just for binary postings as the other one was overloaded (serves them well).

Re:Why yEnv is good for the software companies by IHateEverybody · 2002-03-23 22:46 · Score: 2

As a Deja.com shareholder, I followed the talks between Deja and Google last January very closely. I learned many interesting things about company strategy, usage patterns, and targeted markets. But one thing that I'll never forget is this one chilling statistic: 98% of binaries traffic on Usenet is pirated software or illegal pornography (by volume), and 93% by number of posts.

Ummm, you are familiar with the three kinds of lies right? Besides, pirated software and porn (whether legal or illegal) posts can take up hundreds of megabytes and are blown up by about 33% by less efficient encoding schemes like MIME and uuencode. This is why their "volume" is so high.

For the first time, I truly felt appreciative to Deja for all of the efforts they expended in keeping this illicit content off of their fine service.

Actually, it was quite easy for them. They just didn't save any binary content on their fine service so it was easy to keep the illicit stuff off.

And just for the record, whoever wrote up that 93% pr0n and warez posts statistic wasn't focusing just on alt.binaries.pictures.aviation or alt.binaries.pictures.astro. I have never once encountered anything like what you'd see on goats.cx (something I alas can't say about /.) in a binaries group that was dedicated to something wholesome like aviation or astronomy. Those groups tend to be filled with pictures of airplanes and stars.

And that brings me to my point: yEnc sucks. yEnc is a horrible standard. Just like uuencode, it forces you to track down all 56 posts that constitute the 1337 warez release or all 7 posts of your kiddie porn movie.

And just like uuencode, most serious Usenet users can use yEnc savvy newsreader like XNews or Agent to track down, join, and decode all 56 posts of your illegal copy of Bloatware 2002 automagically.

--
Does this .sig make my butt look big?

Re:Why this is bad by oolon · 2002-03-23 23:24 · Score: 2

Yes I did know it was available and it use it, and this unix was my point, I obviously didn't make it clear enough. People were saying yenc was a windoz thing. I was trying to say it is not, as par is not. Windos users were the first to get clicky clients, not working impletementations.

Re:Not all programs require yEnc in the subject li by nagora · 2002-03-24 00:54 · Score: 2

Instead it scans the file itself.

What happens when the posting is about yEnc and includes a description of how the encoding starts and ends? Does it know that that's not really an attachment?

TWW

--
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"

Re:Counterpoints to all of Jeremy Nixon's main poi by nagora · 2002-03-24 02:00 · Score: 2

There is no reason to despise magic strings.

You don't have much programming experience, do you? Magic strings are a dire way to do anything. MIME has been around for quite a long time now and was invented as a solution to all the problems of magic strings in messages, the obvious one being how difficult it is to handle a message about the magic strings (Outlook still can't handle these). MIME makes sure that the strings are unique to the message, not the class of attachment.

Data about the message should all be in the header. This is so obious that it is hard to imagine what you think the header of a message is for.

No, using the subject line is not obviously a terrible way to determine filenames, segments, and anything else.

The subject line is for the subject. What the fuck are you smoking? Why not the From line or the X-Envelope line? Because that's not what they're for!

find it very convienent to know exactly what my yEnc files will be saved as, how big they are, and how many parts they are

Your client should tell you that from properly formatted headers; the Subject line is for the subject.

If we expect newsgroups standards to reach everyone, we must use the lowest common denominator.

So, no yEnc then. You are arguing that we can't change anything but that we should embrace any half-arsed new encoding that comes along

Which is exactly what the creators of yEnc intended.

I think you are confused about who the creators of yEnc was; one aim of any new encoding should be reliability.

I don't blame him. Jurgen is a coder, not a politician. I would have done the same thing.

Class-level magic strings belong in the museum along with line numbers in source code; Jurgen isn't much of a coder if he doesn't understand this.

But the point is it works right now, and it's working great.

It sort of works sometimes right now, if the spec had been put in as a MIME type it could have worked well all the time in a few months. As you say, Usenet has waited 6 years so why not a few months extra and get it right?

TWW

--
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"

Re:Counterpoints to all of Jeremy Nixon's main poi by 3247 · 2002-03-24 02:12 · Score: 2

There is no reason to despise magic strings. They work, and cannot ever occur in the user data. All yEnc magic strings start with =y, = being the escape character. Ctrl-Y does not need to be encoded, so yEnc is free to use =y for it's own purposes (e.g. =ybegin, =yend). Jeremy Nixon continues his misled rant...

Nowhere does the yEnc spec talk about "Ctrl-Y" (octet value 25). It does talk about "=y", being the equal sign (ASCII 61) and the Latin small letter y (ASCII 121).
This character sequence, of course, can appear in any text message.

Inform yourself before propagating such nonsense!

--
Claus

News Readers yEnc and pr0n by ellem · 2002-03-24 03:22 · Score: 2

Forte Agent _finally_ has yEnc support in the product (version 1.91.) My guess is Outlook Express will follow. People will not have their pr0n and warez messed up to the point that they cannot download it. As for the "war" these two seem to be having let me boil it down in schoolyard terms: Nixon: It's mine give it back! Jurgen: I already gave it away!

--
This .sig is fake but accurate.

Re:Screw luddites by Reality+Master+101 · 2002-03-24 03:41 · Score: 2

What's the major advantage to HTML on the web? You can link to other pages on the web, knowing they're there.

Wha'choo talkin' 'bout, Willis? There is NOTHING about the web that guarantees a page "is there". In fact, the whole "linked" nature of the web is totally an illusion. All you're doing is marking a piece of text as something that should be inserted into your browser's address bar if you click on it. There's nothing magic about a link.

Now how would one use HTML to link to other posts on Usenet and be sure they're there? Could you write a post linking to several later posts you were planning?

Who cares about linking to Usenet posts? Just being able to link to web sites would be an advantage.

You don't need HTML to do that - you don't even need it to post web links, as one can just copy and paste them into a browser.

As you can on the web. Who needs links when you can just cut/paste into the browser? After all, that's all a link does anyway. The point is that it's a convenience, which is just as convenient in a Usenet post.

Maybe, before telling us how Usenet should work, you ought to learn how the web works first.

Perhaps you should take your own advice.

--
Sometimes it's best to just let stupid people be stupid.

Number of servers. by mindstrm · 2002-03-24 03:53 · Score: 2

Also.. are there hundredsof thousands of news servers nowadays? I think we are dealing with smaller numbers of larger servers now.. with news services like newsfeeds.com and such becoming increasingly popular hubs for usenet.

yEnc will be in Mozilla at some point, BTW by slashbrent · 2002-03-24 04:11 · Score: 2

Just thought some of you Mozilla fans might be interested to know that there is already an open bug in bugzilla 119964 to support yEnc in Usenet postings.

Recent posting indicate that some of fellow Moz contributors may be taking this issue and fixing it ahead of the planned "future" date already assigned by the developer - if any of you can do this fairly quickly, i'm sure the rest of us MailNews users would appreciate your efforts!

--

Moderators need an additional choice: "Karma Whore" for people who cut-and-paste articles as their comments!

standards compliance by MenTaLguY · 2002-03-24 04:40 · Score: 2

That could be because yEnc breaks the NNTP and MIME standards. Some (many?) NNTP and MIME-compliant servers won't pass yENC correctly.

--

DNA just wants to be free...

I don't know if I trust it... by Kymermosst · 2002-03-24 05:18 · Score: 2

After all, the website has a decoder in "Pearl", but not "Perl."

--
"Alcohol, Tobacco, Firearms, and Explosives" should be a convenience store, not a government agency.

Let's take it one step further by Stavr0 · 2002-03-24 06:46 · Score: 2

We just saved about 30% bandwith with yEnc. Let's implement PARchive redundancy (reed-solomon) right in the protocol. Sure, we're back to the original size, but all that'd be needed is 70% of any parts of the usenet post to successfully reconstruct the original file, so the 30% is not wasted.

My ISP (cable) has a quite short retention period in the binary newsgroups (it's like they do it on purpose!) and many files are broken from missing multiparts. Integrating yEnc and PAR would solve that problem once and for all.

Re:Let's take it one step further by rhaig · 2002-03-25 02:59 · Score: 2

that's a client issue. If you want to tke the code for your favorite client and have it watch subject headers for multi-part posts and have it "resume" then go for it.

If you're thinking that you should be able to post your 56MB file in a single post to alt.binaries.Imadumbass, then you don't get why they are multiparted in the first place. news servers are typically configured to limit article size. Default on INN is about 100K. depending on the news admin, sometimes it's more, sometimes less.

--
"We are not tolerant people. We prefer drastically effective solutions"

Re:Agent 1.91 by spudnic · 2002-03-24 09:11 · Score: 2

You're right, the main goal for Mozilla isn't selling more units to be profitable. However, in something like browsers, market share is indeed important. The more people who adopt Mozilla as their primary browser the better. Once companies start seeing that the number of IE users is decreasing as Moz users increase, they'll be more receptive to not using IE only features in their web design. This would be a win for everyone.

.

--
load "linux",8,1

Re:Screw luddites by Reality+Master+101 · 2002-03-24 09:51 · Score: 2

HTTP was DESIGNED to transport HTML.

Actually, there's nothing about HTTP that's HTML specific, other than having a specific content-type.

The Usenet Protocol was DESIGNED to transport plaintext. Newsreaders that read HTML off postings do it by ugly hacks, that don't always work.

Roads were originally designed to carry horse traffic, but that doesn't mean we shouldn't adapt them as necessary when cars were invented.

If you can control your newsreader like you do with your browser, I'd not reject HTML-on-usenet as much.

Well, I can, since my newsreader uses the IE Browser object for displaying HTML. Still, I do sympathize with the fact that HTML can be abused on Usenet. I think that means we should have better newsreaders/browsers, not that HTML is intrinsically bad.

BECAUSE the design and implementation of the protocol undoubtedly would be DIFFERENT than the original Usenet so they can handle HTML INHERENTLY.

The only change that I can think of is that we wouldn't ship around messages with two copies, which would obviously be a plus. Still, it's not a perfect world and I think the advantages far outweight the disadvantages.

--
Sometimes it's best to just let stupid people be stupid.

You're comparing apples and oranges by Trepidity · 2002-03-24 10:08 · Score: 2

You're comparing a seven year old version of Microsoft Word to the current version of StarOffice. How about either comparing Word 95 to other word processors available in 1995 or comparing Word XP to the current version of StarOffice?

--
10 PRINT CHR$(205.5+RND(1)); : GOTO 10

Re:This is why it is bad by ncc74656 · 2002-03-24 12:49 · Score: 2

I hate to break the news to you, but Usenet is not just for text discussions any more.

Has it ever been? I was downloading software posted to comp.binaries.apple (what's now called comp.binaries.apple2) as far back as 1989. If Usenet was ever text-only, that would've been before my time. :-)

--
20 January 2017: the End of an Error.

Re:Screw luddites by Wolfier · 2002-03-24 15:01 · Score: 2

Roads were originally designed to carry horse traffic, but that doesn't mean we shouldn't adapt them as necessary when cars were invented.

It is exactly my point - posting HTML on today's Usenet is analogous to putting cars on roads built 100 years ago.

Roads built 100 years ago were built for horses. Roads built today are built for cars.

While engineers have adapted roads and bridges to cars by making their surfaces smoother and increasing their capability of carrying heavier loads, the Usenet hasn't undergone such adaptation yet.

If I want to drive a car on 100-year-old road I can, for example, get an AWD and drives like there's no road. In this case, it is the car that's adapting for the old road. However, no similar adaptation has been gone through HTML yet. (HEY!!! It triggers something - now I think using WML on Usenet is the best thing)

Still, it's not a perfect world and I think the advantages far outweight the disadvantages.

I agree, that the advantage outnumbers the disadvantages. But for me, the disadvantages associated with security and eyesores associated with spams far outweighs the advantages. So you see, whether it is more advantageous or not, it is in the eye of the beholder.

Have a nice day.

Re:Counterpoints to all of Jeremy Nixon's main poi by Harumuka · 2002-03-24 17:56 · Score: 2

Perhaps you should inform yourself. And I quote:

=yend is again similar to UUencode (end).
The combination =y at the line start cannot occur elsewhere
- because '=' is the escape char and 'Ctrl+Y' is not an escaped character.

--
What do you think of MusicCity now?

Re:Screw luddites by pyramid+termite · 2002-03-25 02:18 · Score: 2

Who cares about linking to Usenet posts? Just being able to link to web sites would be an advantage.

As someone said to me, "There is NOTHING about the web that guarantees a page "is there"."

The point is that it's a convenience, which is just as convenient in a Usenet post.

Some newsreaders actually change plain text urls to clickable links. Without inconveniencing the majority of Usenet readers by presenting a bunch of bracketed crap.

You know, you old school HTML people need to get with the program ... Why post HTML when you can post DIVX files of you talking and people can see you talk and stuff ... 90% of communication is nonverbal. You're making us miss so much!!

Re:concretely: this is why you don't need it by rhaig · 2002-03-26 03:49 · Score: 2

Any good server should see a uuEncoded message and store it in compressed form on the server.

wow...

you've never run a news server have you?

I just can't see why we have to implement a new standard before it's ready.
Do you work in Redmond?

--
"We are not tolerant people. We prefer drastically effective solutions"

155 of 417 comments (clear)