.._________.__ __ .__
/ _____/| | _____ ________/ |_|__| ____ ____ ____ _____
\_____ \ | | \__ \\_ __ \ __\ |/ __ \ _/ ___\/ _ \ / \
/ \| |__/ __ \| | \/| | | \ ___/ \ \__( <_> ) Y Y \
/_______ /|____(____ /__| |__| |__|\___ > /\___ >____/|__|_| /
\/ \/ \/ \/ \/ \/
.___ _ _ _______ _______ _______ ________
| |_| || |_\ _ \ \ _ \ \ _ \ \_____ \ http://slartie.com/
| \ __ / /_\ \/ /_\ \/ /_\ \ _(__ <
| || || |\ \_/ \ \_/ \ \_/ \/ \ Giving you the heads up
|___/_ ~~ _\\_____ /\_____ /\_____ /______ / on everything console.
|_||_| \/ \/ \/ \/
===============================================================================
02 June 2013 -- slartie -- Final NEWSLETTER ISSUE 0003
===============================================================================
===============================================================================
WARNING IT'S FOR YOUR OWN GOOD
===============================================================================
If you're easily offended by foul language or views on a particular
matter, which might not agree with your own, you should probably get the
fuck out of this document right now. Seriously.
===============================================================================
INTRO
===============================================================================
I might as well admit it. As long as I do all the writing myself, this is
all just a bunch of rants with a divider here and there to let people know
that I'm changing topic. And that's actually fine with me. But...
If you for some reason have something that you'd like to add to the
newsletter, be sure to throw me a line. It could be anything - almost
anything. It has to do with Open Source in the *NIX realm. Other than
that, go for it.
If nobody else dares add to this newsletter, I'll just keep trucking.
===============================================================================
CONTENTS
===============================================================================
WARNING (It's for your own good)
INTRO (You just came from there)
CONTENTS (You are here)
TOPIC 01: My rant (Read the fucking manual)
TOPIC 02: IMAP Support (Get it right, you asshats)
TOPIC 03: BBS (Genuine nostalgia trip)
TOPIC 04: Links (Places to visit)
CLOSING (Final thoughts)
ABOUT (About the author)
LICENSE (Because we all need one)
===============================================================================
TOPIC 01: MY RANT READ THE FUCKING MANUAL
===============================================================================
I know this is a dead horse, but I won't stop clobbering it with a spiked
mallet. Why? Because it's apparently still not sinking in. Read The
Fucking Manual! Very straight forward and should be understood by
all. It's the single most important thing to learn when dealing with, well
anything really.
The *NIX community is growing out of its hardcore, geekdom roots and is
spilling into the mainstream aided by increasingly easy to use
distributions. I personally welcome the many new users to the exciting
world of GNU/Linux, but I fully expect them to do what the rest of us have
been doing for years - read the documentation. The documentation you find
in the Open Source space is the best there is, hands down. No matter what
your problem is, you can solve 95% of them by simply going through the
relevant part of the documentation that follows the program you're having
trouble with.
Sure there are examples of programs where the documentation seems like an
afterthought, but even then, the source code itself will often serve as
perfectly good documentation.
Let 'man' and 'info' be your favorite commands. Run 'man man' to read the
manual for the man program. Manception? There's usually a lot more
documentation than the initial man page you scroll through. Check the
documentation to see how to navigate it. See what I did there?
If you choose NOT to read the documentation, and pester me about a problem
you're having, I will 1) immediately detect your lack of man page reading,
and 2) stab you over the Internet.
Don't be surprised if people give you a hard time because you haven't done
any basic reading. In some IRC channels you will actually be completely
ignored until it's clear that you have been doing your homework. Once you
have presented your question, don't expect split second replies. We're all
volunteers, so we won't necessarily jump to the keyboard immediately to
conduct some secret Google-Fu (because most problems have been seen
before, and somewhere, someone wrote about it), trial and error testing or
simply spill the beans of wisdom to help you on your quest. Take a load
off, and go back to reading the fucking manual while you wait. You'll
learn something new every time.
===============================================================================
TOPIC 02: IMAP SUPPORT GET IT RIGHT, YOU ASSHATS
===============================================================================
Let's talk IMAP (RFC2060. Obsoleted by RFC3501) and the pains associated
with it.
The protocol has problems, but smart people have thought of ways to deal
with it (go brains!). Developers (not all) implementing IMAP into
applications, aren't picking up these smart brainwaves. My thinking:
laziness.
IMAP allows the user to create mailboxes (folders to you and me), so you
can file your messages (e-mails) in a way that makes sense to you. It also
lets you delete messages (quite handy) and mailboxes (ditto). This is how
we would normally handle e-mails. But working with e-mail on an open
connection to the mail server from several clients, is not entirely what
the IMAP designers had in mind, at least they didn't think things through.
Today we're trying to live with IMAP as is, but it takes some
brainpower. Reading RFC's should be what developers look at
first. Whenever a developer is messing with Internet technologies, they
should know the RFC's front and back. They're easy to read, understand and
to follow. But many developers today ignore RFC's or are even clueless
about what they are.
If the Internet was designed today, we'd be in all kinds of trouble. The
RFC's related to IMAP are as follows:
RFC2060 / RFC3501 - Internet Message Access Protocol - Version 4rev1
RFC2683 - IMAP4 Implementation Recommendations
RFC2180 - IMAP4 Multi-Accessed Mailbox Practice
There are more, but these are the ones I'd like to point out.
RFC2683 is from 1999, but still relevant. With that, and RFC2180 which it
refers to, developers are being handed ways to deal with IMAP properly,
despite its flaws.
When you want to access and use the same IMAP account and its mailboxes
from several different clients like: Windows Mail, Squirrel Webmail,
iPhone Mail.app, an so on, you could be in for a frustrating
experience. RFC2683 talks about this and refers to RFC2180 for more
detail.
The RFC gives perspective to the problems with using IMAP accounts from
several clients, and solutions/pointers as to how to work around these
problems. From what I have experienced in so many IMAP clients, a lot of
people are really not paying attention to the ground that's already been
cleared by others.
IMAP is not all that bright. IMAP is quirky and it really only has five
different ways to look at an email: "Answered", "Flagged", "Draft",
"Deleted" and "Seen".
Seen Message has been read
Answered Message has been answered
Flagged Message is "flagged" for urgent/special attention
Deleted Message is "deleted" for removal by later EXPUNGE
Draft Message has not completed composition (marked as a draft).
These are known as flags.
When you delete an e-mail from an IMAP server, using a client that will
recognize the deleted flag, that e-mail is usually shown striked out. When
EXPUNGE is sent, the e-mail goes away. You can add custom flags, but that
can create a whole different set of problems.
For years, POP3 has been king. With POP3 you have been used to downloading
your e-mails into folders, mess around with them, sort them, delete them,
mark them as spam or you throw them in the trash bin. That was fine,
because your e-mail was on your client. The server was just your roadside
mailbox that you emptied once a day. Everything you did with those
e-mails, the server would never know about.
In case you didn't want to limit yourself to one client, you could leave
the e-mails on the server, mess with a copy and at some point go to the
server, and delete them or whatever. Impractical, but it works.
IMAP makes it possible to deal with the messages directly on the server,
and let them stay there, rather than bouncing between local copies and
whatever's left on the server.
E-mail clients are still largely based on the POP3 mindset. You have a
bunch of standard folders for different things and you throw e-mails
around in these folders. Since IMAP only knows 5 different flags, which
aren't necessarily mailboxes, you would be looking at one big mailbox with
everything if the developers didn't care to add usage of flags at all.
Most do, however. The exception is 'Trash', 'Deleted Items', 'Deleted
Messages', 'Garbage', etc. Each client seems to have its own name for the
trash folder and not all of them are using the 'deleted' flag. If they do,
they still move the e-mail to a folder the user hasn't subscribed to (if
that's even an option), with the flag attached, and you're at the mercy of
that particular client if you want to delete the message entirely.
Example: You access your brand new IMAP account from Mail.app in Mac OS X
for the first time. You send a test message to yourself and see that all
is well. Then you set up the same account on your iPhone and you send a
message and all is well. Satisfied with the test you choose to delete the
e-mail from your iPhone. 'The message could not be moved to the mailbox
Trash.'. What happened? Everything you just read.
Mail.app for OS X can see the Trash folder, the iPhone can see the Trash
folder and a lowly webmail app can see it as well. Deleting the e-mail
from a webmail client, will put the message where it belongs - a mailbox
called 'Trash'. Both Mail.app's can see and open that trash folder, but
when you delete messages from those clients, that's not where they want to
put them. Why? Because the POP3 way of thinking is still in the forefront,
and the IMAP flags go out the window.
This isn't unique to Apple. Not by a long shot. Windows Mail will do it
too, as will some of the veterans like Eudora, The Bat, Pegasus etc. The
console e-mail clients in GNU/Linux and Unix will generally do it
properly. Mutt and Pine are good examples of clients that handle IMAP
well.
Everybody else - get your damn shit together! E-mail is still important,
and IMAP is hotter than ever. Gmail IMAP support? Shame on you
GOOG. Shame!
===============================================================================
TOPIC 03: BBS GENUINE NOSTALGIA TRIP
===============================================================================
The precursor to the Internet was known as a BBS (Bulletin Board
System). A BBS is a computer with a number of telephone modems attached,
that you call up with your own telephone modem and establish a peer to
peer connection in a terminal. Very basic stuff. And to anyone younger
than 30 or thereabouts, this probably sounds stupendously boring. Go play
in a busy street or something.
The most common setup was a single computer with a single modem. Phone
lines weren't any cheaper back then, so most BBS administrators (Or SysOp
as we used to call ourselves back then) usually stuck with just the one
phone line.
A BBS would typically have a message board, where you could post messages
in named groups with various topics. The Einstein reading this might
recognize this as USENET Newsgroups or the web forums of today. That's
right. Although people aren't completely sure, it would seem that USENET
was inspired by the BBS message boards, and web forums in turn were
inspired by USENET.
Another important area of the BBS would be the file area. Here you could
browse section after section of files that the SysOp and other users with
upload permissions had to offer. All the files were stored on that one
computer, the BBS ran on. In the early days that meant floppy-disk
wrangling for many SysOps, because hard drive storage space was
ridiculously expensive. A user would request a file, and the SysOp would
put in the correct floppy, so the user could get the download. Thankfully
after hard drives got a lot more affordable, the 'SysOp Disk Jockey' job
was a thing of the past.
Many European BBS systems made a name for themselves by specializing in
certain types of content. Some systems were into Sci-Fi stories, others in
virus source code and still others in Demoscene music, demos, intros and
so on.
Depending on how the SysOp ran his system, you might have an upload /
download ratio to maintain. That was to ensure you didn't just 'leech' all
the files from the BBS, but actually had to give something back. In
effect, help the BBS grow bigger (or better if you prefer). Other systems
required you to upload something that had to be approved by the SysOp
before you got any download permissions. Different systems, different
rules.
Most BBS systems also had live split screen chat, games (even
multiplayer), gateways to other messaging services like FidoNET, E-Mail
gateways, USENET message areas and a bunch of other stuff.
In short, the BBS was the Internet of the day. It started back in the mid-
to late 70s and keeps on living to this very day. Granted, the BBS way of
things isn't very popular anymore, but they're still around and you can be
sure that the SysOp running one of these systems will keep it purring as
long as he or she breathes.
I used to run a BBS back in the 90s. Best damn time of my life.
Come to think of it, I might even set up a BBS again at some point. This
newsletter adheres to the old-school ways of distributing information, so
why not distribute the newsletter itself on a BBS as well as the other
channels. More on that if I get around to it. And no, you don't need a
telephone modem. A telnet client and normal Internet access will do just
fine.
===============================================================================
TOPIC 04: LINKS PLACES TO VISIT
===============================================================================
Stuff I've mentioned in this newsletter deserves some link love, otherwise
you'd have to step out of your comfort zone and use a search engine. Where
would we be if that was required?!
This isn't WikiPedia (but I'll gladly link to it), so I'm only going to
link to stuff I think is worth looking at.
RFC2060 [ http://www.rfc-editor.org/rfc/rfc2060.txt ]
RFC3501 [ http://www.rfc-editor.org/rfc/rfc3501.txt ]
RFC2683 [ http://www.rfc-editor.org/rfc/rfc2683.txt ]
RFC2180 [ http://www.rfc-editor.org/rfc/rfc2180.txt ]
BBS [ http://en.wikipedia.org/wiki/Bulletin_board_system ]
Mystic BBS [ http://www.mysticbbs.com/ ]
FidoNET [ https://en.wikipedia.org/wiki/Fidonet ]
USENET [ https://en.wikipedia.org/wiki/Usenet ]
===============================================================================
CLOSING FINAL THOUGHTS
===============================================================================
I've deleted the CHANGELOG section, because it just seemed out of place. I
might as well just use the spot as a regular topic. For one thing it's
next to impossible to keep up with whatever the hell is going on in the
Open Source community. Then there's the whole ordeal about what to pick up
and highlight. It might be something that doesn't even remotely interest
me, but just so happens to be the most significant development of the
week. Fuck that. I want to write about whatever interests me.
Newsletters have always been a little weird. Very few of them have ever
had anything news related in them, and if they did, they were more of a
spotlight on an updated piece of software the writer already used. The
article would end up being a tutorial or a HOWTO, or simply a shoutout to
the developer. If it wasn't that, it would be a heads up about what had
been going on in the BBS, the FTP site, the what-the-fuck-ever.
Don't fret, because my newsletter is probably not going to be an
exception. I haven't done much of anything news related, at all. And I
like it that way.
Going forward, I will be doing tutorials on various crap. Actually I want
to stick to the HOWTO recipe as much as possible, rather than a hand
holding tutorial. I have no idea if I'll actually be able to pull that off
properly. The HOWTO style is great as a general resource, but it's harder
to write. I won't be cranking one of those things out every week, but I'll
work on them alongside the newsletter, which will be coming every Sunday
(or maybe even Saturday depending on your timezone).
===============================================================================
ABOUT ABOUT THE AUTHOR
===============================================================================
````...-------------......````` Slartie has been working
``...-----::////////:::----....```` with open source software
`...---:://+++++oo++++++//::---....`` and the community since the
`..-:://++ossyyyyysssssssso+//:--...` early 90s.
`.-:/+oossyhddmmmmdddddhyoo+//::-----.` `.`
`.-/+osyhhhdddmmmmmmmdhyyssoo++++/:---.`.+:` He's considered a little bit
`-::/+osssyhdmmmmNNmddddddmmmdhs+///---.:+: crazy by his peers. Mostly
`-::+osyyhdmmmmmmNmmNNNNNNNNmyo++oso/::-/s- because he likes working with
.:/oydmNNNNNNNNNNNNNNNNNmhsoyddmmdhys/:+s. the console so much.
./syhmNNNNNNNNNNNNNNNNNmddms//syooydds/++`
`:+ossssssyhmNNNNNNNNNNMmmdyo+os//shds//- His day job is (sadly one
:shdhhyoooyhdMNNNNNmdmmmddNmmdhssyhyo/-` might say) working with MS
.sdo+oyyhdhhmmdhdmdhyyhdNNNNNNNdhhhyo/. Windows clients and servers.
```/yysymNNNNNmddyyddyydmmNNNNNNNNmdhhs/.```
`````.`-osyhmNNNNNmmhsymdysydNNNNNNNNNmmdhy/.````` After hours are spent with
`.....--+yhmNNNNNNMmsoymmhssssdMNNNNNNNNmdy/--...- coding, tinkering, IRC and
:-:--://+ydNNNNNNNMy+ohmdyo+oshNNNNNNNNNmds/::--:- generally being a nerd.
::::::///smNNNNNNNMmddNNNNmmNNNNNNNNNNNNNds/::::::
///////++oyNNNNNhsso++yNMNNho++sso+sdNNNmho//:::/:
+++++++++ooymNNs:--...-/++:-...-:::-:omdhs+//::///
ooooo+ooooo+smh/-://-----:::::/+hho/:-/oo//++///++ You can get in touch using:
ssssoooooosooss/-/yNdhhhhhhmmmmmmmy/-...-:/++///++
ysssssssssssso:..:+hdysssss+++oos+/-.````./++//+++ Twitter: @slartie
yyyyssssssssss:.```.-:///:/++/++:.```````:+o++/+o+ IRC: slartie (FreeNode)
yyyyyysssssyys+.`````.-:/oyyo/:-..`````./+ooo+++oo E-Mail: [email protected]
===============================================================================
LICENSE BECAUSE WE ALL NEED ONE
===============================================================================
Slartie.com Newsletter (c) by slartie
Slartie.com Newsletter is licensed under a
Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
You should have received a copy of the license along with this
work. If not, see http://creativecommons.org/licenses/by-nc-nd/3.0/.
===============================================================================
02 June 2013 -- slartie -- Final NEWSLETTER ISSUE 0003
===============================================================================
Created with Emacs - http://gnu.org/software/emacs/