Posts Tagged ‘ps’

Fun with LaTeX

Thursday, March 26th, 2009

So I have finally gotten my shit together and seriously started putting my ideas for the FS/OS course into writing. $DIETY knows cultivating those ideas has taken long enough… I started out, as I usually do, with my trusty LaTeX template: \documentclass[english,a4paper,utf8]{report} \usepackage[utf8]{inputenc} \usepackage{verbatim} \usepackage[dvips,bookmarks=false]{hyperref} \hypersetup{ colorlinks=true, citecolor=black, filecolor=black, linkcolor=black, urlcolor=blue } \author{} \title{} \begin{document} \maketitle \tableofcontents \input{./00_chapters} \bibliographystyle{unsrt} \bibliography{./bibtex/ref} \end{document} I then proceeded to copy the old build-system which mra rigged for us while doing our bachelor thesis, and all seemed good and well, until I realized that the hyperrefs (i.e. supposedly clickable URLs) weren’t all that clickable. I was baffled. What had gone wrong? Had I missed to install a required package? Why then had not rubber (which the build-system use) died with an error? No, packages seemed fine. Had I found a feature which Adobe Acrobat Reader possessed, but Evince didn’t? Nope, opening the pdf-file in didn’t yield a better result (only a slower result… jeebuz acroread is bloated…) I knew that I had gotten clickable links to work in LaTeX-generated pdfs before, so what was different? Ah! It might be that I used mra’s old build-script, the one he wrote before learning about rubber. Ok,$ less bin/makedoci.sh told me all I needed to know. The relevant procedure in that file was:

1. call latex
2. call bibtex
3. call latex
4. call latex
5. call dvips
6. call ps2pdf

As it turns out, the new “rubberized” build-system called rubber with flags -d and -f (i.e. produce pdf output, and force compilation). At the same time I was following up another lead, trying to figure out the documentation for the hyperref package in CTAN. I may have spent too little time reading the actual content in there, but when I came over a list about drivers and \special commands, I started seeing some patterns.

rubber -d calls pdftex, and it might have just been easier to switch “dvips” in the hyperref configuration in the template, but then I’d have to check and possibly dig even deeper to find what the actual string to put in the configuration should be.

This was less attractive since I knew that the current template had worked before (using dvips). But that would involve finding out if rubber could pass through DVI, to PS, and then to PDF. Coincidentally, this is just what rubber -p does.

Which sortof create a really cute little circumstance, to create a pdf-file, you call rubber with the flags -p -d and -f.

PDF, rubber -p -d -f, get it? XD

Forkbombs

Tuesday, March 3rd, 2009

I’ve been going through my bookmarks and trying to organize them (that stumbleupon fed the firefox bookmarks every time I upvoted something hasn’t helped), and among the bookmarks I found this little gem, about how you can thwart forkbombs before they are able to do any serious damage.

In /etc/security/ there is a file called limits.conf, which can be made to control a whole host of different settings. With the hardware of today I find a hard kill limit of 150 processes to be on the cheap side (on the other hand, executing ps aux | wc -l on my system reveals that right now, 117 processes are running, 32 of which are owned by “me”, 71 by root and 16 by various other system users (cupsys, ntp, mysql etc).

On a side note, I love pipes and grep.

$ps aux | grep root | wc -l 71$ ps aux | grep patrik | wc -l
32
\$ ps aux | grep -v patrik | grep -v root | wc -l
16

It might not be necessary to allow more than 150 processes, but on the other hand I would find it irritating hitting this limit (although hitting it would probably indicate that I have to much crap running at the same time) and the real use for this limit on a single-user system would most likely be to ward off the effects of unwittingly doing something stupid (executing a forkbomb is stupid), so one can probably afford to raise this limit a bit higher, to 200-300 processes.

UPDATE:

After having forwarded tuss’ brilliant idea of having hesa incorporate this little tip in his C class (preferably before teaching about the fork(); function), hesa shot it down *mumble*platform specific solution*mumble*. This is of course true, and should serve as just another good reason to switch from Windows ;D

In any case, it got me thinking. Ubuntu, which inherits from Debian, seem to be identical in the important things. /etc/security/limits.conf does indeed seem to exist in Debian as well. And Red Hat, so presumably in Fedora as well.

Slackware however, seem to store this data in the file “limits” directly under /etc/ (i.e. /etc/limits). It is by no means an exhaustive search, but Googling for “[your_favorite_distro]” and “limits.conf” or “limits” or “limiting processes” should hopefully reward you.

UPDATE2:

I spell like a douche…