Skip to main content

Ralsina.Me — Roberto Alsina's website

Posts about arch linux

Android on x86: report

Since I ex­pect An­droid on tablets to be a big thing in 2010, I am ex­per­i­ment­ing with the clos­est thing I can get: An­droid in my eee 701 Surf 4G:

SDC14690

I got the test­ing An­droid 2.0 im­age from http://an­droid-x86.org. I had the 1.6 "stable" one but it was... well, it worked aw­ful (half the key com­bos or menu op­tions caused it to crash, re­boot or oth­er­wise au­to­com­bust).

So... how is it work­ing? Slow, but it has po­ten­tial!

The bad:

  • It boots quite fast... but my tricked full Arch Lin­ux in­­stall boots faster.

  • It works sloooooow, you can see in­­di­vid­u­al let­ters when you type in the search gad­get. I read this is a tem­po­rary prob­lem, though.

  • I am get­t­ing a "cas­­trat­ed" ex­pe­ri­ence be­­cause the open an­­droid app stores are not as well stocked as the of­­fi­­cial an­­droid mar­ket­­place (and come on, why the heck can't I get free apps from there???)

    I see ob­vi­ous holes in the app land­s­cape that I sup­­pose are well cov­­ered in the mar­ket (like, is there a Ra­­dio­­Tray re­­place­­men­t?)

    No text ed­i­­tor?

    No semi-de­­cent word pro­ces­­sor? Not even one that gen­er­ates HT­M­L?

  • The web brows­er is pa­­thet­ic. It may be nice for a phone, but for a "re­al" sys­tem? It's aw­­ful. You get the mo­­bile ver­­sions of all sites (ob­vi­ous­­ly) and many don't let you switch to the re­al ones! (even google does that, for Google Read­­er), and of course, no flash.

  • The email app is ter­ri­ble. You can't not-­­top-­­post!!!! "In-Re­­ply-­­To" is of­f-spec!

  • The WiFi set­t­ings are way too hid­­den. They should pop if you click on the wifi icon.

The good:

  • It shuts down in­­­cred­i­bly fast.

  • Some apps are quite nice, spe­­cial­­ly the Aldiko book read­­er is awe­­some (and I can share the ePub books with fbRead­­er on the arch lin­ux side.

  • The in­­­clud­ed SSH client has great ideas.

  • I love the "all your da­­ta is in the SD" ap­proach. I do the same thing with Lin­ux. In fac­t, I have the same ex­act da­­ta or­­ga­ni­za­­­tion now on both OSs :-)

  • The home screen with the slid­ing app draw­er: nice

  • The "grab­bable" sys­tem no­ti­­fi­­ca­­tions on the top bar: very nice

  • The "use the menu key to get the menu" thing? ge­nius ;-)

  • The "ev­ery­thing fullscreen all the time", thing? works on this screen.

  • App in­­stal­la­­tion is a solved prob­lem here.

  • I know I will be able to get Qt work­ing na­­tive... can't wait!

I am not sold yet, Arch is just so much faster right now, and it can do so much more, but...

  • I am get­t­ing a touch­screen for it, so I can ex­pe­ri­ence it more the way it's meant to be ex­pe­ri­enced.

  • I am us­ing it a lot to read at night in bed (Just fin­ished Mak­ers, read it, it's cool!).

  • I am us­ing it for ca­­su­al mail read­­ing (I refuse to re­­ply with that bro­ken ap­p).

  • It's a pret­­ty nice alarm clock, so it's be­­com­ing my bed­­side OS.

I'll write an­oth­er re­port once I have the touch screen or a new (hope­ful­ly faster!) ver­sion run­ning.

Packaging and shipping is HARD

I have worked re­al­ly hard on Mar­ave, a full screen ed­i­tor in the style of ommwriter, Dark­Room, Write­Room, py­Room, etc. I have worked very hard and I want users to use it.

Or not even that, I want them to have a chance of us­ing it.

That means I want it to work on Win­dows (and maybe OSX some day, too, if some­one helps me). Which mean­s, I have to pak­age it for win­dows.

Let's do a quick com­par­i­son here from the points of view of the us­er and the de­vel­op­er.

The User, In Linux

This is in Arch Lin­ux, which is what I use, in oth­er Lin­ux vari­ants it will be pret­ty much the same once Mar­ave is a bit more well known.

yaourt -S marave-svn --noconfirm

That gets the code from SVN (right now it's the best way, lat­er I will pack­age re­leas­es, too), all re­quired de­pen­den­cies, builds and in­stall­s. It takes all of 15 sec­onds in my note­book.

Af­ter that, you have a ful­ly work­ing Mar­ave.

In case it's not pack­aged for your dis­tro, just in­stall PyQt (which sure­ly is) and run this com­mand:

easy_install marave

The User, in Windows

You go to http://­mar­ave.­google­code.­com, click on "Mar­ave-0.5.win32.ex­e" (Not linked yet, it's not fin­ished), then down­load a 10MB pro­gram. That is a 10MB pro­gram be­cause win­dows does­n't be­lieve in pack­ages and de­pen­den­cies. On Lin­ux, a Mar­ave pack­age could be un­der 1MB (most of it im­ages), and not be ex­e­cutable, just da­ta.

Of course nowa­days web browsers don't ac­tu­al­ly run pro­grams on down­load, so... let's see it as a gallery!

110111105613-My-Desktop

Yes, save it.

11011111220-My-Desktop

Dou­ble click to open it

11011111417-My-Desktop

Yes, I agree

11011111514-My-Desktop

Sure, what­ev­er

1101111167-My-Desktop

Nice...

11011111750-My-Desktop

Good to hear!

Now, this Mar­ave that just got in­stalled may or may not cur­rent­ly work be­cause of a miss­ing MSVCR90.DLL but that's for the next sec­tion...

The Developer, in Linux

First, here's the big­gest prob­lem a Lin­ux pack­ager can have:

Since Mar­ave is a new ap­p, and I de­vel­op it in the rather cut­ting-edge Arch Lin­ux, it us­es some newish fea­tures on­ly avail­able in re­cent ver­sions of Qt. In fac­t, it does­n't work with PyQt < 4.6, which is not avail­able in some slow dis­tros, like De­bian, or even in a not-lat­est Ubun­tu.

So­lu­tion? Well, I could just ig­nore it, but what the heck, let's fix it in­stead!

Thanks to PyIn­staller it's not even hard to do, here's the spec file:

a = Analysis([os.path.join(HOMEPATH,'support/_mountzlib.py'), os.path.join(HOMEPATH,'support/useUnicode.py'), 'marave/main.py'],
            pathex=['/home/ralsina/trunk/trunk'])

pyz = PYZ(a.pure)
exe = EXE(pyz,
        a.scripts,
        exclude_binaries=1,
        name=os.path.join('build/pyi.linux2/main', 'marave.exe'),
        debug=False,
        strip=False,
        upx=True,
        console=0 )

coll = COLLECT( exe,
            a.binaries,
            [('radios.txt','marave/radios.txt','DATA')],
            Tree('marave/icons','icons'),
            Tree('marave/backgrounds','backgrounds'),
            Tree('marave/clicks','clicks'),
            Tree('marave/stylesheets','stylesheets'),
            Tree('marave/themes','themes'),
            a.zipfiles,
            a.datas,
            strip=False,
            upx=True,
            name=os.path.join('dist', 'marave'))

Use this, and PyIn­staller will pro­duce a nice fold­er full of ev­ery­thing Mar­ave needs to run on any Lin­ux.

OTO­H, if you can re­ly on a re­cent PyQt be­ing avail­able, it's al­so sim­ple. Here's a pack­ag­ing con­fig­u­ra­tion for a sim­i­lar pack­age in Arch Lin­ux (I must con­fess not hav­ing done one for Mar­ave yet). For oth­er dis­tri­bu­tions it should be about as sim­ple, if more ver­bose, and some­one else prob­a­bly does it for you:

# Contributor: Roberto Alsina <ralsina@kde.org>
pkgname=python-rst2pdf
pkgver=0.12.1
pkgrel=4
pkgdesc="Create PDFs from simple text markup, no LaTeX required."
arch=('i686' 'x86_64')
url="http://rst2pdf.googlecode.com"
license=('custom')
depends=('python' 'setuptools' 'docutils' 'pygments' 'python-reportlab' 'python-simplejson' 'pil')
source=(http://rst2pdf.googlecode.com/files/rst2pdf-$pkgver.tar.gz LICENSE.txt)
optdepends=('uniconvertor: vector images support'
            'python-svglib: SVG support'
            'python-wordaxe: hyphenation'
            'pythonmagick: PDF images support')
build() {
cd $startdir/src/rst2pdf-$pkgver
python setup.py install --root=$startdir/pkg || return 1
install -D ../LICENSE.txt $startdir/pkg/usr/share/licenses/python-rst2pdf/COPYING
install -D doc/rst2pdf.1 $startdir/pkg/usr/share/man/man1/rst2pdf.1
}
md5sums=('ea6beda9a46f34ba42c4c94d48cc607a'
        '416f8046c66b9476cdbacda69a673afe')

And that's all you need to know about the process of pack­ag­ing your app for Lin­ux. It's easy to do, and most of the time, easy to do right!

Now, let's go to our fi­nal sec­tion...

Windows for the developer

First, re­mem­ber that of re­ly­ing on the sys­tem's ver­sion of Qt? For­get it, there is no sys­tem ver­sion avail­able. And no python ei­ther. And noone is go­ing to in­stall it or your ap­p, so it's "ship ev­ery­thing your­self" mod­e, or noth­ing.

But any­way, PyIn­staller works for Win­dows too! So, us­ing the same spec file, it work­s. Right?

Well, no beause of two prob­lem­s.

Problem 1: You need an installer

Users are not go­ing to open a zip some­where, then do a short­cut to the bi­na­ry on Win­dows, so you need to do some op­er­a­tions, and that means an in­stall­er.

Here's what I came up with to use NSIS, a free in­stall­er cre­ator for Win­dows:

;--------------------------------
;Include Modern UI

!include "MUI2.nsh"

;--------------------------------
;General

;Name and file
Name "Marave"
OutFile "Marave-0.5.win32.exe"

;Default installation folder
InstallDir "$LOCALAPPDATA\Marave"

;Get installation folder from registry if available
InstallDirRegKey HKCU "Software\Marave" ""

;Request application privileges for Windows Vista
RequestExecutionLevel user

;--------------------------------
;Interface Settings

!define MUI_ABORTWARNING

;--------------------------------
;Pages

!insertmacro MUI_PAGE_LICENSE "LICENSE"
!insertmacro MUI_PAGE_DIRECTORY
!insertmacro MUI_PAGE_INSTFILES

!insertmacro MUI_UNPAGE_CONFIRM
!insertmacro MUI_UNPAGE_INSTFILES

;--------------------------------
;Languages

!insertmacro MUI_LANGUAGE "English"

;--------------------------------
;Installer Sections

Section "Install"

SetOutPath "$INSTDIR"
File /r "dist\marave"


;Store installation folder
WriteRegStr HKCU "Software\Marave" "" $INSTDIR

;Create uninstaller
WriteUninstaller "$INSTDIR\Uninstall.exe"

;Create shortcuts
CreateDirectory $SMPROGRAMS\Marave
CreateShortCut "$SMPROGRAMS\Marave\Marave.lnk" "$INSTDIR\marave\marave.exe" ; use defaults for parameters, icon, etc.
CreateShortCut "$SMPROGRAMS\Marave\Uninstall Marave.lnk" "$INSTDIR\Uninstall.exe" ; use defaults for parameters, icon, etc.

SectionEnd


;--------------------------------
;Uninstaller Section

Section "Uninstall"

Delete "$INSTDIR\Uninstall.exe"
RMDir /r "$INSTDIR"

DeleteRegKey /ifempty HKCU "Software\Marave"

SectionEnd

It's com­pa­ra­ble to the ef­fort of build­ing a pack­ag­ing file, re­al­ly, ex­cept ev­ery time you want to test it... you in­stall it. There is no way (AFAIC­S) to see what's in­side the in­stall­er ex­cept run­ning it!

When things fail, you get no er­ror mes­sages, at least not the kind that is use­ful for a de­vel­op­er, the guy that needs to know what went wrong.

And af­ter it's fin­ished, you may end with a non-­work­ing pro­gram be­cause of...

Problem 2: system libraries don't exist

Python 2.6 bi­na­ries are built us­ing Vis­ual Stu­dio. That means they re­quire the Vis­ual Stu­dio Run­time, specif­i­cal­ly MSVCR90.DL­L. That con­tains what on Lin­ux would be con­sid­ered part of libc. (lin­ux guy: imag­ine apps that de­pend on a spe­cif­ic libc... hard to do!)

On Lin­ux that's part of the sys­tem. Fur­ther, if you want­ed, you can re­dis­tribute it. On Win­dows... well, it's a bit dif­fer­en­t.

  1. It's part of the "Vi­­su­al C++ re­dis­­tribu­ta­bles"

  2. In­­stalling that does­n't guar­an­­tee it will work (yes, I have tried)

  3. The li­­cense for those 're­dis­­tribu­ta­bles' says you can't make them avail­able for down­load.

    I have been told that in­­­clud­ing that in your in­­stal­l­er is fine and dandy, but how is that not mak­ing them avail­able for down­load?

So what can you do when you need a li­brary and can't ship it and the us­er won't in­stall it?

Well, that's why there is no Win­dows bi­na­ry of Mar­ave yet. Of course if any­one can help, I'd be re­al­ly, re­al­ly hap­py!

Simple KDE Trick #2: using remote desktops with avahi, krfb and krdc

Most peo­ple nowa­days have more than one com­put­er. Of­ten, you are us­ing one, and would like to do some­thing in an­oth­er. In this video, I will ex­plain how triv­ial it is to do that with­out leav­ing your seat in a mod­ern Lin­ux us­ing KDE.

We will use the fol­low­ing:

  • Avahi, a ze­ro­­conf im­­ple­­men­­ta­­tion to let you find your com­put­ers in your net­­work with­­out wor­ry­ing about IP ad­­dress­es, DNS, etc.

  • kr­f­b, the KDE Re­­mote Frame Buf­fer. This is a pro­­gram to share your desk­­top over the net­­work.

  • krd­c, the KDE Re­­mote Desk­­top Clien­t, a VNC, RDP clien­t, which is what you use to see a desk­­top shared via kr­f­b.

I am sure users of oth­er op­er­at­ing sys­tems or desk­top en­vi­ron­ments will say they can do it just as eas­i­ly. In that case, feel free to do your own videos ;-)

Keep in mind that ac­cess­ing re­mote desk­tops over the in­ter­net is a whole dif­fer­ent beast, and this so­lu­tion is not meant for that case.

As usu­al, this video was record­ed us­ing qt-record­my­desk­top. There was mi­nor edit­ing us­ing men­coder.

The com­put­er used is the orig­i­nal Asus eee PC 701 4G, so you can see this is not ex­act­ly a hard­ware-in­ten­sive op­er­a­tion. I find the eee's small screen is great for this kind of ful­l-screen de­mo, be­cause it's not big enough to drown the im­por­tant part­s.

About 80% of what's wrong with Linux users, all in a post

My post about Arch Lin­ux from yes­ter­day got post­ed at tux­ma­chines and there was a com­ment there.

I can't re­ply at the site be­cause:

  • It re­quires lo­­gin.

  • I can't find a place to get an ac­­coun­t.

  • It has freak­ing google ads pop­ups

So I re­ply here be­cause:

  • Hey, it's my own blog, so I can do what­ev­er I wan­t.

Here's the com­ment by hus­sam with my (ad­mit­ted­ly ranty) re­spon­se:

I've been us­ing Arch­Lin­ux as my on­ly dis­tri­bu­tion/­op­er­at­ing sys­tem since ear­ly 2006. It is re­al­ly a good dis­tri­bu­tion but late­ly there have been a lot of re­al­ly bad choic­es which I call bad com­pro­mis­es:

1. Too many Arch­Lin­ux users think gnome/kde are bloat and in­stead in­stall some half de­vel­oped win­dow man­ag­er and some ter­mi­nal em­u­la­tor and call it a "min­i­mal­ist" desk­top.

Why is that any of your busi­ness? And what "com­pro­mise" is there?

2. Op­tion­al de­pen­den­cies are the worst idea ev­er. If a pack­age is linked against lib­some­thing.­so then lib­some­thing should be a de­pen­den­cy not an op­tion­al de­pen­den­cy. Mak­ing lib­some­thing an op­tion­al de­pen­den­cy just be­cause "min­i­mal­ist" users don't want to in­stall de­pen­den­cies is plain stupid.

That's not what op­tion­al de­pen­den­cies are for. For ex­am­ple, con­sid­er the ex­am­ple I men­tioned, rst2pdf. It can use python­mag­ick. It can al­so not use it. You will lose one small fea­ture that AFAIK on­ly one per­son ev­er used. If you need that fea­ture, the man­u­al tells you what to do: in­stall python­mag­ick.

Maybe there should be a pac­man op­tion "in­stall opt­de­pend­s" which turns op­tion­al de­pen­den­cies in­to reg­u­lar ones. That would make you hap­py and keep oth­ers hap­py too.

3. Bad lead­er­ship. Aaron is fan­tas­tic guy but I know at least two Arch­Lin­ux de­vel­op­ers who can do a much bet­ter job.

That's just stupid and mean.

4. Too many Arch­Lin­ux users now like bad­ly au­to­ma­tion scripts like yaourt or what­ev­er it is called.

Parse er­ror. And then again: yaourt is great. You don't like it? Act as if it does­n't ex­ist and be hap­py. You seem to have a big prob­lem ig­nor­ing peo­ple who dis­agree with you. That's a re­al­ly, re­al­ly se­ri­ous per­son­al flaw. I sug­gest you grow up.

5. Too many noobs who do dumb things like peo­ple adding their users to hal, disk and dbus group­s.

Sure, they should add them­selves to op­ti­cal and stor­age. So what? It's a sim­ple prob­lem and it has a sim­ple so­lu­tion.

Then again, the ad­dus­er scripts prob­a­bly should do that for reg­u­lar us­er ac­counts. Af­ter al­l, who wants to cre­ate a reg­u­lar us­er that can't use re­mov­able stor­age? And if said use case ex­ist­s, that should be doable by re­mov­ing the user, and not vicev­er­sa!

On the oth­er hand, I don't give a damn, be­cause I can fix it triv­ial­ly.

The main rea­son why I don't think I will switch to an­oth­er dis­tri­bu­tion soon is that cre­at­ing Arch­lin­ux pack­ages from scratch is very easy and the initscript sys­tem is re­al­ly fan­tas­tic.

All in al­l, Arch­Lin­ux is a re­al­ly strong dis­tri­bu­tion now and it's con­stant­ly grow­ing.

I ex­pect you, like most elit­ist poseurs, will run away when you feel Arch is too pop­u­lar and ac­ces­si­ble to "too many noob­s" or some sim­i­lar non­sense.

Which, like the ti­tle says, is why you are a big part of what's wrong with Lin­ux user­s.

Why I STILL use Arch Linux

Yes­ter­day I had one of those mo­ments where I feel very hap­py about my dis­tro of choice, Arch Lin­ux. Since the last time I post­ed about Arch seems to have been over two years ago (time flies when you are hav­ing fun!), I think it's time to ex­plain it.

I want­ed to test rst2pdf against re­port­lab from SVN, wor­daxe from SVN and do­cu­tils from SVN, and I want­ed it to be sim­ple.

So­lu­tion: I just pack­aged them in AUR!

Now, whenever I need to check rst2pdf agains wordaxe trunk, I just need to yaourt -S python-­wor­dax­e-svn and I can go back to stable wordaxe with yaourt -S python-­wor­daxe.

The svn pack­age will al­ways be the cur­rent trunk with­out any mod­i­fi­ca­tion­s, and I can switch back and forth in about 45 sec­ond­s, with­out mess­ing up my sys­tem's pack­ages.

Also, I can keep my installed SVN packages updated by doing yaourt -Su --de­v­el every now and then.

How would I have done that us­ing De­bian or a RPM dis­tro? I sup­pose by go­ing around the pack­ag­ing sys­tem (which I hate) or by do­ing a pri­vate re­po (which is so ... lame?) or by do­ing a pub­lic re­po (which is freak­ing work).

Re­al­ly, if you are a coder, I can't think of a Lin­ux dis­tro that makes life eas­i­er than Arch. Pret­ty much ev­ery­thing is there (12K pack­ages in un­sup­port­ed!) and if it is­n't, it's a 5-minute job to slap it in­to AUR and help the com­mu­ni­ty.

Sup­pose you are do­ing a KDE ap­p. On most dis­tros you need to in­stall your own from-­source copy of kdelibs to have the lat­est and make sure it's not screwed by dis­tro-spe­cif­ic patch­es.

On Arch? Patch­ing up­stream is frowned up­on. Not hav­ing the lat­est ver­sion is frowned up­on. So it's pret­ty much the ide­al en­vi­ron­ment to de­vel­op against KDE, or GNOME, or PyQt or what­ev­er.

If my life was not 150% com­mit­ted al­ready, I would try to be­come an Arch de­vel­op­er, or at least a TU (Trust­ed User). Maybe next life!


Contents © 2000-2024 Roberto Alsina