considered harmful

http://harmful.cat-v.org/software/
>2013
>using harmful software

harmful kitty :3

Errata: POP3 instead of SMTP

i agree with one thing though, jabber is shit comparing to irc

Errata: In this newsgroup, the IMAP guy says "cretin"
https://groups.google.com/forum/?fromgroups=#!topic/comp.emacs/Q1SeBV1kkIs%5B1-25-false%5D

>>37
I never liked UTF-8, I always thought we only needed ASCII
Then how Russians Israelis are supposed to intermix Hebrew and Cyrillic symbols in their code, you schlemazl?

So, I have two questions.

Is Plan9 an elaborate joke? I mean, I went to look at http://swtch.com/plan9port/man/man1/cat.html, for reasons that will become obvious later. It doesn't support any interesting flags (including "-v"), but all right, simplicity and shit.

But: "Read always executes a single write for each line of input, which can be helpful when preparing input to programs that expect line-at-a-time data." -- what the fuck? Did they break the fundamental pipe abstraction, so it's now kind of like streams but actually sometimes sort of messages?

Second, do I understand correctly that "cat-v" stands for "cat -v" and means that they intend to make visible the ugly stuff? Then, why doesn't Plan9 support "-v" switch, and what's the opposite of "-v" switch, the reverse operation?

>>37,40

By their own logic, their site shouldn't even exist:

Apache, lighttpd. -- thttpd, OpenBSD's fork of apache 1.3, nginx, or best of all: don't use HTTP.

I don't see them hosting a gopher server.

>>46
Blocking until you see a full line of input doesn't "break the fundamental pipe abstraction". It's actually a great example of how the abstraction works - read tokenizes input so the next process in the pipeline doesn't have to.

The -v switch is what's ``considered harmful'' in the title. cat concatenates files, so having a flag like -v that turns it into a filter makes no sense.

>>46
Pretty sure UNIX has handled text line-by-line for decades. Run cat, type ``hello'', hit Return, it prints ``hello''.

The original ``cat -v'' paper (hosted on the site at http://harmful.cat-v.org/cat-v/unix_prog_design.pdf) recommends writing a separate program, vis, whose job it is to print non-visible characters. This way it can be used in conjunction with any program, not just cat.

>>49
This PDF appears to be malformed. Page 3:
(The file copy program found on operating systems like or is an example.)

>>46
How is the -v flag for cat ``interesting''? I'll never understand.

>>47
Gopher is even shittier than HTTP. It enforces Latin-1 at the protocol level, and there's no way to change it.

>>40,42
Totally agree. The only Minus I have of POP3 is that you have to Fetch ALL the email. And you are right that SMAP is not used, it is in the Beta stages still. It needs testing. I'd prefer a STOMP protocol for implementing a simpler IMAP.

>>45
I am not against UTF-8, for exactly those reasons. The thing that I dislike in the UTF-8 Character set is things like: ⁇﹖⁈⁉‽‼❕❗❢❣ꜝꜞꜟ﹗！ᵃ ᵇ ᶜ ᵈ ᵉ ᶠ ᵍ ʰ ⁱ ʲ ᵏ ˡ ᵐ ⁿ ᵒ ᵖ ʳ ˢ ᵗ ᵘ ᵛ ʷ ˣ ʸ ᶻ⁰ ¹ ² ³ ⁴ ⁵ ⁶ ⁷ ⁸ ⁹ ⁺ ⁻ ⁼ ⁽ ⁾ ₀ ₁ ₂ ₃ ₄ ₅ ₆ ₇ ₈ ₉ ₊ ₋ ₌ ₍ ₎

Basically unnecessary things, esp. things that can be represented using simple circumventions and discourse. I dislike the most things that are repeated. What is wrong with ☺ when ^.^ is just enough. I just saved 2 bytes whoopee!

>>46
I think it is more of a satirical piece. But there are some truths in there. I tried cracking only the page on this discussion.

>>47
Hahaha, so right. I would have used gofish just to make the readers cry to make it more ironic.

>>49
Or sed for that matter. Their hack made my day.

>>51
Neither do I ¯\(°_o)/¯

>>52
Um, character set does not determine how connection control is handled. HTTP, POP3, IMAP, NNTP, etc. have only used US-ASCII bytes to handle their connection controls, since you do not need that many bytes to represent flow. The only minus is markup in the flow. HTTP is the most cluttered protocol of them all, using paragraph long specifications for a simple GET and POST. I rather support Waka than live with the cluttered specifications of HTTP/1.1. Gopher does it right, in that you only need a byte to represent something. One Byte, nothing more.

Also Latin-1 is well within UTF-8, so much it is backwards compatible!

>>53
The thing that I dislike in the UTF-8 Character set is things like: [...]
Blame Unicode and the Unicode Consortium. They try too hard to make their character set a complete typesetting and graphics package. I guess they ran out of useful glyphs a while ago.
UTF-8 itself is fine. It's a good encoding.

>>53
Uh, so you leave accented letters, Cyrillic, JEWS' alphabet, Nikita's alphabet, hanzi, hiragana/katakana/kanji and hangul out just because Unicode went too far?

Doesn't sound fair to me.

>>54,55
Woah, you /prog/s misread. UTF-8 is absolutely fine, it is a great encoding. I am barking about some characters that are stupid, not the encoding. Of course I welcome all alphabets and glyphs, esp. the Chinese ones that have not been added since their are too many. There is even lots of room for more in case we make more glyphs, and we can change them at any time. I especially like the Klingon Unicode character set.

>>56
Then call it the Unicode character set. UTF-8 is an encoding, not a character set.

>>53
Gopher does it right, in that you only need a byte to represent something. One Byte, nothing more.
You can't seriously be this full of shit. Mail protocols come with de facto and actual-RFC standards to turn base64 back into useful information, at the cost of 33% space overhead. Gopher has no such thing; servers serve up whatever, clients always treat it as Latin-1 and try to display it as such.

Also Latin-1 is well within UTF-8, so much it is backwards compatible!
Plain ASCII is literally the only overlap between UTF-8 and Latin-1.

Actual gopher users (as opposed to hipsters who pretend to like gopher because it's ``obscure'', but don't actually use it) recognise this is a problem, and one Gopher+ doesn't address. Exactly one server implementation and exactly one client can use cap files to specify encodings, but that still leaves output mangled on every other client, and requires (in principle) an additional connection per request.
UTF-8-by-default would go a long way toward fixing gopher, but explicit control semantics (yes, like HTTP's headers) would be even better.

>>57
K I will.

>>58
Gopher as well as HTTP supports MIME, and use it to support other datasets. The client only need to call the file in gopher, and read the MIME of what it will do to interpret the file. HTTP does the same, with more Markup and verbosity than needed in the headers. MIME is fine on its own.

You are blaming client programs for their stupidity, not the gopher protocol. Where have you seen UTF-8 characters/bytes in HTTP/1.1? I sure would like to see some. I do not see it in the standard:
http://tools.ietf.org/html/rfc2616

>>59
Your inane MIME drivel misses the point. Gopher, as a protocol, specifies Latin-1 for text encoding, and is designed to transfer text across the Internet. This is a deficiency in the protocol, and the fact that you could hypothetically pile on other protocols is the same sort of harmful bullshit that got us HTML email and XML configuration files.

Where have you seen UTF-8 characters/bytes in HTTP/1.1? I sure would like to see some. I do not see it in the standard
http://tools.ietf.org/html/rfc2616#section-14.17

Learn to read.

>>60
I read it. That is MIME. Gopher uses it too, but we call it BinHex and UUEncode:
http://tools.ietf.org/html/rfc1436

Only a suggestion is made to use Latin-1 is for those stupid client programs.

And where am I suggestions to use other protocols? All I am saying use the BEST tool for a job.

This page should be ignored. The authors of the page clearly don't know what they are talking about. There are a few good suggestions in there, like using JSON instead of XML. However, the good is vastly outweighed by the bad.

Tk instead of Qt?
8c instead of GCC?
Sam instead of Vim?

It's contrarian for the sake of being contrarian. That in itself makes the page more harmful than many of the apparently harmful things listed.

I'm I on /pol/ here?

>>62
YHBT gracefully

>>62
Certainly, the more I look on its pages. At least suckless.org has their content correct.
But Qt? GTK+ is more cleaner and comprehensible. Even then, I just use ncurses and libcaca if GUIs are needed.

But Qt? GTK+ is more cleaner and comprehensible. Even then, I just use ncurses and libcaca if GUIs are needed.

>>61
I wish I could believe you're just trolling, but there are a lot of genuine morons on the Internet and you're definitely behaving like one of them.

I read it. That is MIME.
That is MIME built into the standard, dipshit.

Gopher uses it too, but we call it BinHex and UUEncode:
Bullshit. That doesn't even slightly resemble the flexibility of MIME.
Suggesting you use it to try to hide gopher's broken approach to character encoding means not using 0 or 1 files, and (more importantly) never using links, because 4 and 6 aren't parsed as gophermaps. So, you know, the things gopher was actually designed for.

Only a suggestion is made to use Latin-1 is for those stupid client programs.
RFC 1436 isn't one of those ones that painstakingly defines ``should'' and ``may'' and ``must''. Here, ``should'' is ``must''.
Those stupid client programs are literally all of them.

All I am saying use the BEST tool for a job.
And I'm saying that that tool is never gopher, because gopher is broken.

Google Gopher, LLLLLLLLLEEEEEEEEELLLLLLLLLLL

>>66
Yeah, if needed. I deal with data, using PostgreSQL and Berkeley_DB, so I do not have to make many GUIs. If I do for businesses, I use ncurses, I am done. You do not need much to run a business with.

>>67
I see, so we both agree that UTF-8 encoding and bytes are not used in http, but MIME's specification of Content-Type:text/plain;charset=UTF-8;encoding=B;encoded-text=gyYjOTU2O2sgJiM1NDE7ZQ==;

We know MIME is integrated in multiple protocols, but why the other headers. And what is wrong with placing MIME on a UUEncoded labeled file? Should not a protocol be ignorant of a datatype and encoding of a file, and allow the client to process the file through description headers? And we are not talking about protocols with the exact purpose to know what the data transfer and encoding should be like RTP, libpq, SHOUTcast, SSH, etc..

Links are also specified in documents, which the client should be able to handle, like any real clients do. Here are real ones at work:
http://en.wikipedia.org/wiki/Gopher_(protocol)#Native_Gopher_support
http://gopher.floodgap.com/overbite/

What kind of job do you do that may not use gopher? I seldom need it myself, but when comparing to what most web sites use and need, gopher is enough. A real broken protocol is something like SVN and XMMP. Even FTP if we want to talk about how vulnerable it is.

s/through description header/through its description header/

s.Content-Type:text/plain;charset=UTF-8;encoding=B;encoded-text=gyYjOTU2O2sgJiM1NDE7ZQ==;.Content-Type:text/plain;charset=UTF-8;encoding=B;encoded-text=gyYjOTU2O2sgJiM1NDE7ZQ//;.

omg, who let /g/animal out

If you lack the education and mannerisms expected of a gentleman, you probably should refrain from using faggot names.

>>69
You're even dumber than Cudder. Go play in traffic.

>>48,49
Blocking until you see a full line of input doesn't "break the fundamental pipe abstraction". It's actually a great example of how the abstraction works - read tokenizes input so the next process in the pipeline doesn't have to.
It's not that it blocks until it sees a full line, it's that it guarantees that it will output the full line with a single `write` call, presumably so that it will be returned by a single `read` call to the next program in the pipeline. Which means that those programs rely on a broken stream abstraction: suddenly fragmentation is no longer an implementation detail but an essential side-channel, the stream protocol is transformed into a datagram protocol, in a completely ad-hoc, unreliable way.

What's even more ridiculous, this can't possibly work correctly on UNIX because there's no `read` function variant that allocates the buffer for you, as large as necessary. So the downstream programs that relies on its `read`s returning entire lines every time passes a fixed-size buffer, and guess what happens when the line is longer that that buffer: either the program just breaks, or it reallocates the buffer and tokenizes input again -- in other words, duplicates the work that `read` program did, making it unnecessary.

Obviously most real programs will do the former, because lines longer than 8k don't real. This bullshit is one of the most perfect examples of the smelly unix hacker culture I've ever seen.

>>49
Pretty sure UNIX has handled text line-by-line for decades. Run cat, type ``hello'', hit Return, it prints ``hello''.

NO!

That's the terminal's line buffering. Read gets absolutely nothing until you press enter. If you pipe shit into cat instead of having it bind to line-buffered stdin, read gets input in blocks, which are independent from where the '\n' is.

Making a general I/O system call internally line-buffered is idiotic.

>>76
Thank you, I was thinking about this today and was about to post the exact same thing.

What books should I read if I want to be knowledgeable about le UNIX like you guys?

>>78
The C Programming Language:
http://net.pku.edu.cn/~course/cs101/2008/resource/The_C_Programming_Language.pdf
Then Linux System Programming:
http://seesee.pbworks.com/f/linux.pdf

>>76
But text is naturally divided into lines.

Why do you hate the universal interface that is plaintext?