jmoiron.net

I've been trying out a few console only programs in the past week; a few programs that I had been meaning to try for some time. One of them was swaret, the SlackWARE Tool, and the other is Screen, the UNIX tool.

Swaret is pretty good and best of all maintains the transparent nature of the slackware package scripts. The only thing I don't really understand at this point is how it does its dependency resolving: since dependency checking is not built into slackware packages, I'm assuming that the only answer would be that dependency files are stored on the server. A short description, for those of you that do not care to click the link, is that its kind of like a mixture of portage and apt-get for Slackware.

Screen is of course is a rather old application that I first came across reading about Ratpoison and ways of using Linux efficiently with little or no use of X or a mouse. It's the kind of tool that simplify's almost everything you do by virtue of enhancing the building block of what makes you function: in this case, your shell. Screen creates a shell "session", where once inside it makes itself mostly unknown and gets out of your way. However, by hitting ^a, you can enter a few commands into screen. Some of the more useful ones are "c" and "0-9", which allow you to create new windows and flip back and forth between them, much like a tabbed terminal window. Say goodnight, gnome-terminal.

Lastly, screen lets you "detatch" and "re-attach" to sessions (much like loggin in and out), and keeps the terminals within screen alive even after you exit the shell you've called screen from. This allows you to pick up where you left off on any process that will consume your terminal (like IRC or a swaret --upgrade) from anywhere that has SSH (assuming you have sshd), and not only that but use the same ssh session to do multiple concurrent process, all potentially taking up a "window".

The combination of Screen, Swaret, and Sysadmin Class have got me thinking about another possible project in Python, but I'm hesitant to start something after I've left other things (like the admin module to my website or JTEX) so unfinished. However, I do have a large amount of newfound freetime, mostly gained by giving up my workaholic attitude towards the GBA project. The new project would probably be foolishly named "pacman", and the details as to what exactly it does and how it does it will be released when I decide on said details.

I was debating on whether or not to use PyGTK for this project or to try PyKDE and PyQT. Part of me said PyGTK because of familiarity, and another part of me said QT because kde is the default DE on slackware (in fact, initially I used this argument for gnome because so many people who use slack run gnome I forgot it wasn't default). I slightly entertained the Idea of using both, and developing my idea as a backend or a set of classes with which two separate frontends will interact. I'll have to see about how to get around installation difficulties this might give people who do not keep both QT and GTK (AND PyQT and PyGTK) around. Which is just about everyone.

The subject of this post directly correlates to the research I was doing, coming across random KDE+Python websites, and finally reading some comments to an article written at Lateral's site. Someone recommended gnome to this obvious KDE guy, and he politely replied "Sorry, I'm a KDE guy! Thank's though!". Holy shit!, said I, this man is able to be a maniac without being a zealot. This is something I cannot do; so I thought I'd at least attempt to explain some of the positions I take.

I use Linux because within 6 months of using it, I understood more about the way it worked than after 6 years of Windows. I can see through my Linux system and fix problems in ways that, with windows, would demand a re-intsall. I know how my system displays things, and understand how most of my programs work, and for me, this is an improvement over a system that "just works" only most of the time.

I prefer C to C++ because I personally have a strong dislike for syntactical inconsistencies brought on by C++'s confusing class syntax, and because I don't find the need for a low-level, high-level language. If you want to have a large project with object oriented methods of organization, then use a language who's object features are rich and simple to handle like Java or Python. If you want speed, then figure out which parts of your program need it, and program those in C. If you need to be at the machine level (no interpreter), the bite the bullet and use C which is (much like Linux vs. windows) transparent to the coder, as opposed to C++ which hides much of what it does behind syntax, sometimes with obfuscated results.

I use multiple De's and WM's. I've found that changing my workspace around is a good way to not only be preoccupied from work, but to constantly educate myself on how to improve performance within these environments. Whenever something new comes out, I usually try it. Whenever I find out something new, I try it. It happened with Blackbox, Fluxbox, Gnome 2.0, 2.2. 2.4, KDE 3.0, 3.1, and 3.2, and it will happen when Gnome 2.6 comes out soon, and again when the next version of Fluxbox comes out, and when the newest KDE comes out. De's and Wm's are one area where I do not fall into the trap of being a zealot. Konqueror kicks Nautilus' ass, and Kopete has nothing on Gaim. I'll use Evolution until I can't stand it's long load times, and then try out KMail. Whatever I need, I'll use.

And finally, and you knew it was coming, I like python because it's the cleanest language syntactically that I've ever used, and I never fully understood classes or strong/weak typing until I learned Python. I do believe that RAD and more importantly rapid application patching will be the tool that allows Open Source software to surpass proprietary software simply by the virtues of being Open Source and having the source to amend, and along with this I find Python to be the only language that I can truly develop rapidly with.