elblogg

As a programmer and linux geek I often need, or at least want to write about code, scripts and commands on my blog, but as many of you know, displaying raw code in HTML is setting yourself up for failure. The simplest part of the problem is the fact that line breaks and whitespace might be significant, this is simply solved by putting the code inside a <pre> block. The more tricky part is that code often is full of characters like &, > and <. Characters that have a specific meaning in HTML and can’t be echoed directly. & needs to be typed as an HTML entity (&amp;), just as > (&gt;) and < (&lt;). Talking about HTML and XML code on your blog can be a really tedious task (as the above).

I have usually solved this by writing the code in a file first, and then running the file through this sed command

cat file.html|sed -e 's/&/&amp;/' -e 's/</&lt;/' -e 's/>/&gt;/'

But as I work on a Macintosh these days, I’ve been using TextMate a bit.. Not as much as i use OpenKomodo though. TextMate has some nice blogging capabilities. You can use it to post directly onto your blog, and it has shortcuts for converting sections of your post into HTML entities. Just select the text, and hit ⌘+&, 1

Edit: it seems like there is some compatibility problems with WordPress 2.7 and TextMate. The post was published two hours off, and as a private post.

For å forklare hvordan en brannmur fungerer nå vi først ta en kort titt på hvordan IP-nettverk fungerer. Dette er et meget forenklet bilde. Hver enhet i et IP-nett har en IP-adresse. Denne adressen identifiserer et grensesnitt på enheten, typisk et nettverkskort. Programmer som skal motta informasjon via UDP eller TCP lytter på en bestemt port på denne ip-adressen. Web-tjenere for eksempel lytter typisk på port 80. For eksempel er IP-adressen til tjeneren som serverer denne bloggen 70.85.31.150, og webtjeneren lytter på port 80 på denne ip-adressen.

Portnummer er det vanligste for en brannmur å filtrere på. Brannmuren på min webtjener kan for eksempel være satt opp slik at det bare er trafikk til port 80 som er tillatt, og at all annen trafikk vil bli avvist. Selv om det kjører programmer på tjeneren som lytter på andre porter. SSH for eksempel, som lytter på port 22.

Brannmuren kan også settes opp slik at den aksepterer bare trafikk til port 80 generellt sett, men dersom trafikken kommer fra en bestemt IP-adresse, så skal den også tillate trafikk til port 22.

Dette er i og for seg greit. Men, alle trusler kommer ikke utenfra. La oss si at du har en web-tjener som serverer bloggen din på en maskin hjemme, og så har du en arbeidsstasjon der du har allt det viktige arbeidet ditt.

Dersom web-tjeneren din blir hacket nå, vil det være enkelt for en inntrenger å komme seg videre til arbeidsstasjonen din, selv om all trafikk fra internett er blokkert inn til arbeidsstasjonen.

Dette er grunnen til at vi har det som kalles demilitariserte soner (DMZ (DeMilitarized Zone). En demilitarisert sone er et eget nett, som for dine andre maskiner ser ut som om det er en del av internett, og for utsiden ser ut som er en del av ditt lokale nett. Det er altså en brannmur både mellom din maskin, tjeneren din og internett.

På denne måten må en fremdeles gjennom brannmuren for å nå arbeidsstasjonen fra web-tjeneren, og iogmed at all trafikk fra internett er blokkert mot arbeidsstasjonen vil ikke dette kunne gjøres.

Ver dog obs på at problemer med hacking av arbeidsstasjoner som oftest er initiert fra innsiden, ved at brukere besøker nettsteder som er infisert med nettlesere som ikke er sikre.

Dette er noe du kun kan gardere deg mot ved å alltid ha 100% oppdatert programvare, og god antivirusbeskyttelse. Dersom det brukes en proxy, kan slike brukes til å filtrere bort skadelig innhold i nettsider, ved å kjøre dem igjennom et antivirus før de siden sendes videre til brukeren. Her kan en også filtrere bort tilgang til nettsider basert på deres innhold, og for eksempel tvilsomme navn i adressene.

En kan også blokkere trafikk til bestemte IP-adresser på bestemte porter på samme måte for utgående trafikk som for innkommende trafikk.

I have a laptop with a rather low resolution screen. It is limited to 1024x768px, so I have had a bit of envy for the Ubuntu eee users that have a nice and practical user interface for smaller screens. I have for a while already removed the taskbar, since I realized that I didn’t use it that much, and it steals a whopping 24px of the vertical screenspace.

I discovered the netbook remix, that is the user interface in Ubuntu eee right after Ubuntu 8.10 was launched. I had already updated to 8.10, and the Netbook remix wasn’t available for 8.10 at the time.

Read the rest of this entry »

The chumby device is an interesting device, being one of the few open source electronic gadgets and all. But sadly, its the hardware that’s open source. And for me that is really a bummer, since I’m a software hacker. I’m not that confident with the soldering iron. That means that the fact that the hardware in this device is open source doesn’t matter that much to me, especially since I’ve found only one producer and reseller of the Chumby, namely the chumby store. And they don’t even ship to Norway!

And, the stuff that I find interesting with such a device is the ability to make my own software for it, displaying the stuff I want it to, and controlling the other stuff in my home from it. (Like the HTPC system etc.). And thats where the chumby really disappoints me. First off, I’d need to program the user interface in Adobe Flash, which is a thing I don’t know how to do, and I don’t have the tools. The open source support for creating flash applications are appalling too, so to make good applications I would have to buy the commercial non-open software from Adobe. Which don’t even run on Linux. So then I’d have to install Windows on my machine to run it etc. etc. I don’t hate my freedom that much.

On the other hand, I could get an Nokia N810 device, the hardware there is closed source, but the software is completely open. I could program my applications using Python and GTK. Even more, the N810 is more powerful, it has a bigger display, and the device is smaller. Okay. It’s not smaller than the actual electronics inside the chumby, but its a lot smaller, or at least thinner than a unmodified chumby. It even can run from batteries. And, there’s nothing that prevents me from doing the same type of hacks that people does with the chumby. Very few people actually modifies their chumby, they mostly modify the casing of the chumby. Like this guy:

(Chumby hack published in MAKE Vol. 16)

Okay, this post turned out to be a rant, but live with it.

If you’re really trying, you will always be able to write completely unreadable code in any programming language. All the language designers attemts to force you to write readable code, and even making it so the easiest way ahead, even for quick hacks is to write it as readable and reusable code will fail if you’re really trying to write unreadable code.

This guy is obviously concerned about “job security”. (not the blog author, but the code author)

#!/usr/bin/env python
import os,sys
C=os.chdir
S=os.system
M=os.mkdir
J=os.path.join
A=os.path.abspath
D=os.path.dirname
E=os.path.exists
W=sys.stdout.write
V=sys.argv
X=sys.exit
ERR=lambda m:W(m+"\n")
PRNT=lambda m:W(m+"\n")
assert len(V)==2,"you must provide a sandbox name"
SB=V[1]
H=A(D(__file__))
SBD=J(D(H),SB)
C(SBD)
PST=J(SBD,'bin/paster')
VAR=J(SBD,'var')
ETC=J(SBD,'etc')
S("mkdir -p "+VAR)
PRNT("restarting "+SB)
CMD=";".join(['source %s'%J(SBD,'bin/activate'),PST+" serve --daemon --pid-file=%s/sandbox.pid --log-file=%s/sandbox.log %s/sandbox.ini start"%(VAR,VAR,ETC)])
PRNT(CMD)
S(CMD)
PRNT("All done!")
X(0)

Aaannd… Heres my understanding of the code:

#!/usr/bin/env python
import os,sys
 
#bail out if there's no sandbox specified
assert len(sys.argv)==2,"you must provide a sandbox name"
sandbox=sys.argv[1]
 
#get the dir of this script
home=os.path.abspath(os.path.dirname(__file__))
 
#sandboxdir is this dir/sandboxname
sandboxdir=os.path.join(os.path.dirname(home),sandox)
 
#go into the root of the sandbox
os.chdir(sandboxdir)
PST=os.path.join(sandboxdir,'bin','paster')
VAR=os.path.join(sandboxdir,'var')
ETC=os.path.join(sandboxdir,'etc')
 
#make var directory if it doesnt exists
if not os.path.exists(VAR):
    os.mkdir(VAR)
 
print "restarting "+sandbox
 
# Build the system commands required to restart the sandbox
cmds=[]
cmds.append('source %s' % os.path.join(sandboxdir,'bin','activate'))
cmds.append(PST+" serve --daemon --pid-file=%s/sandbox.pid"
            "--log-file=%s/sandbox.log %s/sandbox.ini start" % (VAR,VAR,ETC))
CMD=";".join(cmds)
PRNT(CMD)
 
#run the cmds
if os.system(CMD) == 0:
    print "All done!"
    sys.exit(0)
else:
    print "Ooops. failed."
    sys.exit(1)

I got an email from userfriendly.org today, announcing something that obviously needs to be pushed onto my wishlist…

oh. yeah!

… is greater than zero.

Python is a dynamically, strong typed programming language. In my opinion that makes it more important to have good tools than for statically typed languages. Sadly, it also makes it more difficult to create great code analysis tools and IDEs. Meanwhile, I find more people in the Python community that is happy coding with Vi(m) even for quite large projects, than in the Java community. My guess is that that is because the tool support for Python has been poor.

When your IDE shouts at you with red lines under your function calls because it’s not able to look up in your custom libraries, of course you’ll refuse to accept it, and go back to your simpler editor.

Torbjørn Nordbye implemented the awesome Ruby support for Netbeans, and has now started on the work to give us Python awesomeness in Netbeans as well.

As mentioned in the comments of a previous blog post I have a good example of simple, obvious bugs that could stay in your application for years, without anyone noticing them, because that piece of code run almost never. Bugs that good tools, and/or compilation of staticly typed languages would find for you, but that unittesting and manual testing of your application probably wouldn’t find.

This is a bug that Tor found while testing his Python support for Netbeans, when he pulled in the datetime module that ships with Jython. There, in some exception handling the code references the non-existent class ValuError, which probably should be ValueError. A simple typo that has been undiscovered for a long time.

We all make errors. Good tools make us do less of them, and find them faster.