Compulsory water metering

Reply to
dennis
Loading thread data ...

Its not the size that matters (!!), its the viruses and malware that can be carried in it.

Reply to
Tumbleweed

That is a function of the reader. If it doesn't execute scripts, which aren't really html anyway, it is perfectly safe.

Reply to
dennis

A damn nuisance. Perhaps? Sorry, couldn't resist!

Reply to
Terry

So where does it have an opportunity to be compressed? There's no compression in NNTP, or the underlying protocols.

Reply to
Bob Eager

Now come on Bob, don't let a technical reality spoil a good story :-)

Reply to
Andy Hall

It would be a shame to admit that he didn't understand where compression can be used if it is worth it.

like:-

Compressed file systems to save disk space. Modem compression to save bandwidth.

and that's only the ones most end users have been using for years.

Neither of them requires the "standard" to include compression to work.

Reply to
dennis

LOL! Well, I was probably influenced by the fact that I was teaching the TCP/IP stack last week...

Reply to
Bob Eager

That's not a problem. The problem is the vast amount of extra bandwidth required on the Internet.

Again, that doesn't affect the Internet at large. Each news article is transmitted thousands of times...and each time it can be bloated by HTML. No compression there.

Reply to
Bob Eager

Unless you wish to remain isolated you will change your mind to co-operate rather than stick two fingers up to everyone. There is only one good answer to your stupid comments and that's to kill-file you.

Just don't expect any help from anyone - because they won't be listening.

[kill-filed]
Reply to
John Cartmell

You are inventing problems to support your beliefs. Usenet traffic is insignificant so you can forget it in the big picture as far as the internet goes. Even with binaries thrown in it is still a tiny amount of the total. It is not a valid reason to avoid html.

Reply to
dennis

OK, I'll leave you to your 'beliefs'.

Reply to
Bob Eager

That's fine but comes at the expense of performance and/or cost.

That happens anyway.

However, the issues begin to show themselves as soon as graphics are added (which tends to happen in HTML environments). Graphics file formats are already compressed.

This is why well designed web sites targetted at an audience that might have low bandwidth have carefully chosen graphics of limited sites.

Even with high speed connections, it becomes very apparent when somebody has produced a crappy site with lots of megapixel images.

This is missing the point. Usenet was intended and remains primarily a text medium. It was and is designed to be accessible regardless of bandwidth available. Many groups have a no-graphics policy.

People wanting a rich text and pretty pictures experience can do so via web based groups. For example, Yahoo Groups does that quite well.

However, Usenet using NNTP is not that place.

Reply to
Andy Hall

Good, solid learning. I wonder what Jon Postel would think of it all (wastage of internet resources) if he were still alive.

It's all too easy nowadays....

I think that anybody wanting to put graphics in Usenet articles should have to configure UUCP connections to run with obscure and flakey modems run over transatlantic links and make them work reliably without running up a phone bill the size of the national debt.....

That would learn 'em.

Reply to
Andy Hall

Try some common sense.

How many text Usenet messages are there a day?

Compare that to 60 billion+ emails, web browsing, P2P and you will also see that Usenet is insignificant. It is becoming even more insignificant every day. You really do need to rethink some of your out of date, meaningless arguments.

Reply to
dennis

It is.

Reply to
Frank Erskine

He didn't think a lot...it was around when he was. I know a close friend of his very well - Mike Padlipsky.

Incidentally, Mike wrote an RFC that never made it into the archives although it's in the index. Not a particularly remarkable one, but I have a copy. What's interesting is that (despite the number having no significance to the subject material) it is the real RFC666...!

Reply to
Bob Eager

there is no such thing as 'perfectly safe' with html, for example until recently pictures could cause malware to be executed, who knows what other bugs are out there.

Reply to
Tumbleweed

This misses the point completely.

There are two.

Within major countries in the West and in the Northern hemisphere there is good bandwidth within and between major carriers and most service providers. Between major countries there is also good bandwidth in most cases.

However, there are certainly areas of the world where bandwidth is extremely expensive and performance poor either for logistical or telco monopoly reasons. For example, in South Africa, which is hardly the back and beyond, one pays 4-5 times UK prices for an ADSL connection that is capped at a very modest data volume. If one wants to download a few GB of files, it's actually cheaper to take a weekend flight to Hong Kong and sit in an Internet cafe to do it.

Secondly

While internet core bandwidth in general is fairly good, access at the edges remains poor in many places, for example if one lives some way from a telephone exchange. Of course high bandwidths are advertised but are only available in major conurbations.

Users should have the choice, in terms of the internet applications that they use, to be able to make the best use of what they have. It is no joke trying to access graphically rich services when one only has 56k dialup.

The point is that the limitations are where the user is, not in the core of the internet, so it's meaningless to refer to the traffic and content volumes there.

If you want to have something with all the graphical bells and whistles because you have good connectivity, then fine - it's called web groups and blogs. Please go and use them.

However don't expect to get any agreement from people who choose to use a text based medium because they find it fast and convenient.

Reply to
Andy Hall

Hadn't heard of that one..

0666 Specification of the Unified User-Level Protocol. M.A. Padlipsky. November 1974. (Not online) (Status: UNKNOWN)

What was it about?

Reply to
Andy Hall

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.