Best of Browsers

beautiful web

Recently, in a discussion regarding Mozilla Firefox/Ice-Weasel plug-ins that remove photos from the web, a few text-based browsers were brought up as a very simple way to get a similar (or possibly better) effect.  One of the things that I totally insist on having on any Unix-based system is a text-based web browser.  I once found myself using curl to pull pages down one at a time and manually viewing the html in nano to find a mirror list.  After that, I vowed to never do that again if it could be avoided.  Assuming that you are prone to experimenting with Xserver, like the framebuffer, or write programs that could crush whatever display server you use, it might be worthwhile to keep a text web browser available as a fallback.  Beyond simple need, there’s a few upsides to them that you won’t find in more graphical browsers.  They tend to help you to focus on what is actually written as opposed to the CSS, flash, and javascript applets that overrun the world-wide-web these days.  Also, they’re generally more compact and normally adopt themselves better to content dumps to stdout.

I will say that they are a large enough portion of my general workflow that on the little web-browser project that I co-wrote, I spent time making certain that there would be cross integration of bookmarks between it and links2.  Obviously, I consider them not only worth having, but something that I’d prefer to see everyone adopt.

As far as a compare and contrast, I’ll say that I tend to use links2 when I have mouse support.  I prefer emacs-w3m on systems that don’t have mouse integration.  In the end, this is really about the speed that I can navigate with them.  All of my other opinions and preferences are more “chocolate vs. vanilla” and I don’t expect everyone to share my tastes.  The ones that I’d strongly recommend are links2, links, elinks, lynx, and w3m.  While I do swear by emacs-w3m, that one is probably only well suited for emacs users.

I’d mentioned that these also adopt themselves well to scripting, so I guess that I at least owe an example.  Let’s assume I’d like to check the daily news from BBC-News, but only if it pertains to Russia.  I could grab headlines with something like:

elinks www.bbc.co.uk/news -dump | grep -i 'Russia'

That may not be a sensible use, but I think that it’s pretty easy to see how this idea can be used to get your local weather or any such web content dumped into a script.  Let your mind run free, and I’m sure that lots of useful (or at least interesting) ideas will come.  Happy browsing.

DJ’s Book of the Month – The C Programming Language

I realize that “The C Bible” isn’t the official title, but I’d go so far as to say that K&R’s “The C Programming Language” is as close to a holy book on C as has ever been written.

There is an indentation style based on this book (called K&R, after the authors), so take that as a sign of how influential it has been.  While I “may” use BSD-KNF for the examples, I still go back to this one and play with the ‘assignments’ at the end of each section.  It’s a game of mine to come up with better ways to perform the same task.

The book starts at chapter 0, which is highly humorous if you think about it, and by the time a new programmer makes it to the end of chapter 1, they should have a much stronger idea of how the C language works.  Unlike many of the programming books that are popular today, this one doesn’t come with a DVD of flash videos, and isn’t the biggest book ever written by any means.  On the flip side, if you actually do the little exercises, you’ll have written programs that count words, reverse input, strip lines of whitespace, and many other tasks that someone might actually want to do.  While these are significantly more challenging than many other books on the language, they’re actually useful examples that aren’t big on holding your hand so much as treating you like they wish for you to actually learn to program.

It doesn’t really focus on compilers, or have a step-by-step on how to set all of the basics up.  I don’t think that I’d refer someone to it who wished to learn C as their first language until they’d made it through some other resources first.  That being said, it’s perhaps one of the most concise and information-heavy books on the subject ever written.  I read that it was a “book by a computer programmer for computer programmers, not a book by a teacher for a student.”  Those aren’t my words, but are a very accurate assessment in my opinion.

If you’re wanting to learn C, or are already playing with some C programming, though, you must read it.  You simply cannot afford to ignore the information inside.

Distro Wars are Ignorant

This has nothing to do with this post.

The other day, like I do once every 3 months, I left my tiny corner of the world where I attempt to out-write my last sed line (hoping that one day I’ll be able to transcend all characters that aren’t “/” or “\”), looking for neat scripts, and playing with lower level programming.  Upon leaving my cave, I hit up a few Linux forums.

I noticed that some faceless internet guy had a totally stock Crunchbang Waldorf install screenshot.  He was praising the sub-500Mb startup, and I kid you not, ended his post with “#donewithubuntu”.  While complaining about hash-tags that aren’t used for commenting or followed by a ‘bang’ would certainly end in me ranting uncontrollably, it isn’t what I was really bothered by.  I wanted to reply with the screenshot of my <32Mb on boot Ubuntu and dwm build, but realized that I would be starting something that I have no intention of finishing.  I didn’t plan on ever coming back, and someone would probably mistake me for trying to show off Ubuntu as being better.  My point is, and has always been, that it’s all JUST Linux.  Perhaps it’s GNU/Linux, or BSD/Linux, or GNU/BSD, but that’s not what people argue about normally.

What gets me is that almost all of this zealotry is based on ignorance.  At the core, almost all Linux distros are infinitely flexible.  You can use Arch-linux with openRC, you can use systemd on Debian, etc.  You can get creative and build something totally original from the kernel and busybox.  The sky is the limit.  To argue over something, it needs to be founded in some kind of facts.  Let’s look at some examples:

“Ubuntu is bloated and purple.” – bad argument

“I tend to shy away from upstart and dislike Ubuntu’s CLA.” – much better.

“I use Slackware and build my packages from source with gcc.” – Not an argument at all, but it is a good way to be totally ignored while people are having an A vs. B discussion.

The point, if there’s one to be found here, is that there is no purpose in being a distribution zealot.  It accomplishes nothing other than dividing an already small community of people who are just starting their journey, and those who have been around for a while are going to most likely just ignore the statement totally.  At their core, most designs are extremely modular and transparent in the Unix-like world.  With enough time and effort, you can make most any of them into any of the others.  It’s all about how each group has chosen to present a semi-finished product, and unless you’re going to be using it in a read-only manner, this is always subject to change.

Find what you like and that fits your needs, use it, and live happily.

Cool Script Share: gxpr

While I’ve been busy the last little bit, I thought I’d share a very interesting script that I ran across for anyone who wants a better cli calculator.  gxpr

I guess I could go into detail about how it works, but I’d rather simply link it here and let anyone who’d like to use it have access through the author’s github.

Warning: To “anti-Google” scripters, I’d be glad to hear of other ways to do the same thing using other crawlers.

the two paths

 

Recently, a friend linked in a forum signature to Master Foo Discourses on the Two Paths.  I’ve been thinking about this one a great deal recently.  While the entire Master Foo koans collection is meant to be funny, I think that it speaks volumes just how much reality there is in some of the tales.

I can say that I personally would consider myself to follow the Zen of Brutality.  This has a great deal to do with my current occupation, where we jokingly refer to ourselves as “firefighters.”  In essence, my job is to fix problems with industrial programming.  When I am called out, I come up with the quickest answer to correct errors and bugs that only appeared after being implemented.  The expectation is that whatever issue is there needs to be corrected as soon as possible so that normal functionality can resume.  Not all of my answers are elegant, and oftentimes I’ll get something to the point of operation long before coming up with a solution that serves to perform the original function in a error-free manner.  Much of what I do is the software equivalent of duct tape.

I carry this basic concept into everything that I do.

As an example of the two paths, I can think of a really clear example.  Xaos52 (who has commented previously on some of my blog posts) and I both have weather forecasts to terminal output scripts.  His is a wonderfully complex and well implemented bash script.  Mine is one line tied to an alias that dumps output from w3m to stdout and pipes to grep using regexs to filter out the lines of data I want.

So which one is correct?  Well, both of them to a certain degree.  Whereas I’m pretty certain that Xaos’s script was created with other users in mind, mine was created so that I could get the day’s weather forecast without leaving my terminal.  I never considered other users because I had no intention of anyone other than myself using it.  Being a one-liner, it would be easy to modify for other purposes, but it only works if you have w3m and it has the location hard-coded into it.  While you can do the same thing with elinks, or many other cli browsers, I don’t perform checks for all possible conditions because I know what I have installed.  The complexity of the implementation is determined by the intended usage.

In the end, I believe that it’s important to try to make things as clean as possible and as simple as possible.  Even the most complex programs should strive to remain clear and concise.  Even the simplest programs should strive to be as capable as possible of not behaving erratically due to a mistype.  The most important thing is to keep in mind is what your expectations are of the finished product.  Never lose sight of the primary goal, and the rest should work itself out.

The things you own

 

…don’t let them own you.

After a short holiday vacation, I have been trying to get back to my normal routine.  During this time, some packages from a major distribution that I use had a few changes that I personally didn’t care for.  This isn’t really a big deal, and it’s the cost of using package management in some cases.  It was easy enough to grab a tar of the original package, reconfigure it, and rebuild the package how I wanted it.

That being said, I often consider things such as “What if the developer of (foo_program that I love) just got tired of dealing with the hassle and stopped development totally?”  Normally, I have multiples fall-back options ready to use should such a thing actually happen.  I am not a huge fan of having a great deal of programs just sitting around, but some redundancy is not a bad idea.  Most of the time I don’t actually need them, but assuming that the world came to an abrupt end and emacs ceased to exist I would still like to be able to edit text without using ed.  I could in theory use cat, sed, and awk for everything, but that would be horrible.

This also applies to hardware.  I personally believe in learning the basics of the system you use to a high degree of efficiency so that you’re able to deal with changing software environments and don’t have to rely on the greatest new and improved hardware to simply maintain your normal workflow.  You really never know when you may need to be able to work on a P2 with a 512MB HDD, so you might as well have practices that could translate over to such a system.  Surprisingly, the newest KDE Environment still has a terminal emulator, so I wouldn’t have to go to great lengths to use my normal methods to get around in it.  The opposite story isn’t always true.  I’m not knocking KDE, or those who use it, but rather those who rely on clickable interfaces.  Some people simply prefer all of the extra animated widgets while being perfectly capable of dealing with a tty, and there’s nothing wrong with that.

My great concern is for those of us (and there are comics that support this) who could use some more time learning to still perform the same functions without our favorite software.  Please don’t let the things that you use be a crutch.

Also, in a subnote, I’d like to recommend a friend of mine’s blog http://beta.andrewrcraig.us/index.php?page=about.  Drew is one of the most stylish guys I know when it comes to minimal X interfaces…and is the author of probably the most bloated pure bash PS1 variable I’ve ever seen.  (Battery life in colorized ansi escape sequences for laptops….just “wow”.)  In the future, he’ll probably have some good stuff for those of you who like your desktop to look like a piece of art.