Howto get and install OpenOffice.org for Slackware

Quite often, in ##Slackware we (the regulars) see a request for OpenOffice.org for Slackware.

I have now moved this to the howto section for two reasons:

1. It will be easier for visitors of my site to find
2. It will be a lot easier for me (hopefully) to maintain

The new OpenOffice-Howto can now be found on this page…

Diverse mail/web projects to concentrate on.

So far I have made some excellent progress with cleaning up stuff on this box. I have switched over to a more normal account, and while this causes the occasional confusion of where I need to go, I am more happy with it. The only thing remains so far is my IRC Nickname and my old msn accounts which will be done in due time. Although on the subject of msn, considering that most contacts are already moved over [0], and I hardly get any IM’s on the other account, it may be something that should be rather easy :)

I have planned the following projects so far for June.

• Finish setting up apache/mysql/php goodness so I can download most of our old blogs and store and host them locally and then shut down those blogs that we no longer need. Purely for archival purposes.

• I also want to have a look and see if it is possible to have a decent local MTA running, so I can send email dirrectly from my machine to the intarwebs.

• Get a better understanding of how really GPG and all it murkiness works. I have some vague understanding of what it is supposed to do without getting to much in my way. However occasionally I run in stuff that makes me wonder if I am missing some bits of $knowledge. I hate that idea. So I need to work on that.

• Keep up with slackware-current. Currently a whole bunch of new technologies are being put to test (The most notably, the adding of HAL (and without the dreaded pam)). I am looking forward to having a play with that, and see if it all works as intended. I know people have mentioned it before, but slackware-current does look better by the day. I guess part of me is hoping on a ‘delay’ so we can perhaps something like KDE 4.0 in, but considering that KDE 4.0 is not due to be released until October at the earliest convenience, I guess I should not hold my breath.

• I am still looking if I can share all data between the different mail clients. Currently I am looking if I can make emails between Thunderbird, KMail and Mutt make behave they way they should.There are some things in Thunderbird which seem to work really nicely, which I am missing in KMail. [1][2]

• Ofcourse the usual stuff for SlackBuilds.org keeps popping up. Luckily we managed to get the queue down to 12 at the moment, but it is known that that can actually change overnight to at least double the amount. Still we managed to get a load shifted on that.

[o]:: Contacts for both my jabber and msn can be found somewhere on this blog. If you want to use it, do a bit of trouble and find it (or alternatively leave a comment).

[1]:: Don’t get me wrong KMail still rocks and probably I don’t do “enough” with it. One thing I am really missing is the different account seperation that Thunderbird can do. That way I could probably keep better track of what I am following.

[2]:: Mark Walling mentioned that perhaps having all mail dumped onto a local IMAP server, and have the various email clients directly read from there. This might be the solution eventually. I need to think more on that.

Why pkgsrc is bad.

The last couple of days I have seen several people asking if/how to use pkgsrc. What is pkgsrc actually?

The wikipedia entry defines it as following: pkgsrc (package source) is a package management system for Unix-like operating systems. It is used as the primary package management system on NetBSD.

Most people do quote the article of this site as the source of howto install pkgsrc on a slackware machine. Lets have a closer look on how this works shall we? [0]

Added NOTE: Just so people are clear about this. This blog entry is a rant against the article mentioned above. Please read the article first before commenting, as this explains where I come from.

During the initial install you have remove roughly 91%!!! of all slackware packages [1]. To me this seems at least a bit strange. This is not what a decent package tool should do. To replace half of your operating system with what *they* seem is right. Even swaret/slaptget don’t do this, and they manage to break more than their fair share of boxen.

The next step is to install a kernel source, and actually go about breaking the kernel headers. This to me seems absolutely preposterous. Not only are you stuck with one specific kernel, every time you upgrade your kernel, things might just break. There is a good reason why kernel-headers and kernel source are split apart [2]. I honestly can’t grasp why it is needed to go and break this.

Of course, pkgsrc can’t rely on Slackware’s ftp client, no we have to use NetBSD. It just all adds up in many different ways on how to ‘bork’ your system completely.And when all is said and done and you have added the 92% off all the applications back to your system (lets recompile everything!!) plus you are probably forced to use pkgsrc for the rest of your life.

The fun thing is that the author mentions that slackware-9.1 has a broken libstdc++.la and libsupc++.la. I have to really wonder if they are broken (and if they are why hasn’t anyone reported it) or are they broken after pkgsrc has basically done things to the system it wasn’t intended too and thus pkgsrc causes it. It seems to me that pkgsrc does install itself by default with a --prefix=/usr/local/ instead of --prefix=/usr/. If that is the truth, I wonder if installs all the packages into /usr/local/ as well.

Okay, granted, pkgsrc may have a huge database with over 6800 packages, but, quantity doesn’t always mean quality. A good example of that is to compare SlackBuilds.org versus linuxpackages.net, the latter having more packages but the quality of some of them are really really bad.

And when all is said and done, you have a package manager that gets into your way. The beauty of the pkgtools on slackware is, it doesn’t get into your way. It does the job and it does it well. I can to a certain point understand people wanting to use a certain tooling, but if you have to first break your system to actually use that tooling you really have to wonder what exactly it is you are doing.

[0] – Please note that the article is actually based on slackware-9.1. Which is quite different from slackware-11.0

[1] based on the fact that Patrick considers Slackware to be a full install and not counting the packages in extra/

[2] See rworkmans reply on linuxquestions for a good explanation

final note: Yes, I am highly biased :D

How to stop X from listening on port 6000

One of the things that most people not need. The X-server listening on port 6000. You’ll only need this if you plan to do really remote sessions with X.

Other than that, you could pretty much shut this down (besides there are other ways if you want to achieve this. This can be best achieved doing the following:

create the following shellscript and put it in /etc/X11/xinit/xserverrc:

#! /bin/sh

exec /usr/X11R6/bin/X -nolisten tcp

If you have a slackware-current machine, you may want to edit the code to reflect it like this:

#! /bin/sh

exec /usr/bin/X -nolisten tcp

and then restart X. and voila, port closed. You should be able to check this with ps aux | grep X. Thanks to phrag and dadexter.

Another thing I found, is that KDE already does this by default. Having a look at the KDM config file: (/opt/kde/share/config/kdmrc) shows the following:

[X-:*-Core]
AllowNullPasswd=true
AllowShutdown=All
NoPassEnable=false
NoPassUsers=
ServerArgsLocal=-nolisten tcp
ServerCmd=/usr/X11R6/bin/X -br

However. It only stops X listening when it is being run from runlevel 4, meaning that seperate Xsessions (for example started via startx -- :1) will still listen.

left todo:
Research how gdm and xdm handle this.
Post this on Slackwiki

The End of Slurpy And Slackupdate

It’s with a bit of sadness that I have decided just five minutes ago that I will no longer continue my work on slurpy and sub consequently it’s predecessor slackupdate.

Slackupdate’s development started from a very simple script which I decided to add some code to make it just a little bit more workable. Other patches I send into the author were ignored while I continued to write more and more code into slackupdate, until I came to realise that about 90% of the bash code was written purely by me.

I decided at that point that I would abadon the project as the orginal author, had stopped responding to my emails, that the project should get a new name.

And thus, Slurpy was born. Slurpy stood for “Slackware Linux Update and Rsync Program.” And to be honest, it worked well. It employed various bash-arrays to make some nifty desciscions (like which parts for KDEi to install and such more). In fact I know several people who actually helped to debug it (thanks Jay) and who also used it, and reported great success with it.

Slurpy was a complete overhaul and rewrite of the code, making it more modular and capable of more (among others, the ability to burn CD’s). At some real distant point in the future I was planning to offer a direct CLI mode and a Dialog mode (ala slackware packages tools).

However lately I have been too busy with other projects (see also previous post) and I have in all honesty not looked back at it. With all the changes also happening in -current I don’t think slurpy has it’s place right now. I tend to become more “hard lined” in some points of slackware maintenance. No doubt hanging with some people who also thing this way just reinforces this ;)

If someone ever wants the (perhaps ugly) code of either slurpy or slackupdate, just drop me a mail. It was a fun project while it lasted, and it thought me quite a bit about shell scripting, but at the moment I don’t have neither the time and the energy to develop it any further

ToDo lists

I am a great fan of ToDo lists (I am sure that this is due to my mentor brainwashing me, hammering the needs for list in me, when I was doing  my thesis and subsequent working in an ITIL based organisation where written out plans and to do lists where also much part of doing your daily job. I have to admit that lists do have their place, especially if you have a fuzz ball brain like me occasionally.

However as I was discussing todo lists in #slackman a while ago, somebody brought up the concept of the “spiraling ToDo list of Doom“. It’s quite an interesting image, but indeed somewhat aptly named.

I myself use mostly DevToDo, which seems in a small way to serve its purpose. Still I am still suspect to the trapping of the spiralling list of Doomness. Basically it comes from once having found an adequate solution to actually trying to fill everything into the todo list. Result? A huge todo list with 49 items, and a feeling of not accomplishing anything at all really. The reason: Distraction.

Life is full of little distractions. A friend of mine (Thanks StevenR!) mentioned “Time Management for System Administrators” (O’Reilly Press) to me. Having had a change to read through some parts of the book (Yay for Google Books!), I think this is one book that anyone really should read. Okay, it is focussed on System Administrators and IT-People, but I think by the look of it it contains enough information to be usefull for anybody. And as soon as I can afford it, I really want to go and get this book (Hint! Hint! Hint!).

Lately I have started to make a little bit of progress by deleting and doing away with those projects I really have no plan of ever fullfilling. It’s the little “oh I have a look at that or I’ll make a package/slackbuild for this, because people want it.” And after adding it to do the todo list it’s just sit there.

Still I have lots of projects to do, so I guess I better get on with things ;) I am sure there was a point to this post somewhat, but I forgot, heh.