Recommending the MSI MegaBook PR200WX-058EU laptop to Linux users

I recently bought a new MSI laptop and I am really pleased with my choice so far.

Since with the previous laptop I managed to kill two of my desired features, long battery life and pretty portable, I decided is time to look really well and see what the market has to offer.

I settled on a MSI PR200WX-058EU which has the following:

• built on a Centrino platform
• Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz
  
• Intel Corporation PRO/Wireless 4965 AG or AGN
• Intel mobile chipset
• 3GB of memory (yes, I would have enjoyed 4, but it seems the 32 bit barrier still decides hardware configurations)
• 320GB HDD
• DVD+/-RW
• Mobile GM965/GL960 Integrated Graphics Controller
• 12" wide screen (1280x800)
• 1 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet
• 8 cell battery by default (long battery life)
  
• 1 USB 2.0 Camera - uses luvc driver
• bluetooth
• 1 card reader
• 3 USB port, 1 HDMI, 1 D-sub 15 connector, 1 PCI Express port, modem port
• fingerprint reader
• an advertised weight of 1.8kg (I weighted it at 2.1kg with the 8 cell battery)
  

In other words a small and mobile powerhouse for which I payed 3800 RON (approx. 1100€). I'd say not too bad at all.

Thanks to Gonéri Le Bouder and some searches on the internet I concluded that
the brand is not bad at all, and now that I have it I really am sure.

Of course, I installed Debian Lenny on it (I also sent an installation report), and, in spite of the initial problems, I managed to make the laptop work pretty nice, but I am especially excited about the webcam, which works with the linux-uvc driver.


There were some issues, but I managed to fix some them while I have been ignoring some other. The LaptopTestingTeam page for MSI PR200 on the ubuntu wiki was very helpful.
What have I been ignoring?

• it seems that from time to time the battery charge status isincorrect, or acpi report that the AC is plugged in
• headphones don't automatically turn off the speakers
• fingerprint reader is not used yet, but I intent to experiment at some point with it (authentication via the fingerprint would be cool)
  
• the keyboard seems a little bit too hard (but I hope it will loose up with time)
• modem isn't probably working, but I don't think I'll ever try
• there are some issues in gnome-power-manager which cause strange behaviour and grief wrt screen brighness
• sleep doesn't work,but hibernation does
  

What would you do if I'd tell you that the battery lasts 4 hours or even more while the wlan is on and working (browsing and stuff like installing new packages, configs) with the brightness set to minimum?


I am really excited about this and I can say that I think I have found my next generation laptop, so if you're thinking of a cheap mobile powerhouse on which Linux must run, this laptop might be for you.

I find the following to be selling points (for a Linux buyer or others):

• comes with FreeDOS, so no extra money for an OS you don't use
  
• wifi works
• webcam works with luvc
• no big problems during install (the most severe are already fixed)
• long battery life, even when using wifi (4+ hours in browsing+some package installation mode, according to my tests)
• light enough to carry around easily (2.1kg, 2.4kg with charger)
• nice design - some people asked me if I bought a MacBook
• 4 state kill switch for all possible combinations for wifi/bluetooth
• hibernate works with 2.6.24 or newer (sleep doesn't, but I will try a few things later)
  
• there's no mechanical latch for the lid, there is a magnet, so there's no plastic to be broken, the laptop is more robust
• the 8 cell battery is thicker than the regular one, allowing better ventilation
• it seems it doesn't get too hot to put on my lap (still, I am a little afraid of blocking its ventilation due to the fabric of my clothes, so I'll probably try to carry around a hard paperboard or something like that)
• the big resolution 1280x800 (for this screen size) seems to partly compensate for the reduced physical size of the screen (12")
• bright screen

So, thanks again to Gonéri, Debian Installer team, LVM2 maintainers, Ubuntu Laptop Testing team, linux uvc developers, Lilo developers and maintainers, all the nice people who made and still make Debian possible.

fast translation bug report via icedove

Here's a quick way to report po-debconf transalations:



Courtesy of Quicktext

---

Update: the image above is an animated gif and some viewers might not be able to render such images correctly. Apparently even on the blog the animation isn't visible unless you click on the image itself.

obscene VNC

I guess obscenity wasn't thought of in xvnc4viewer. Feel free to submit a BR.

OH MY GOD!

This can't be true! How can someone trust such a key?

Does anybody have a reasonable explanation for such an abomination?



Update: It seems it is unclear to some people what is the problem with this key. There are multiple identities (apparently different people) for the same key. So, in layman's terms, multiple different people are using exactly the same key to certify their identity.

I really don't understand how this could work in real life. Maybe is a case of misunderstanding what gpg is about?

when printouts don't help to revoke a GPG key

It's official, I am revoking my gpg key because after my laptop returned from service[1] I realized is a bad idea to change the passphrase just before a long break away from a routine that would help the brain to cement the new passphrase. In other words, I forgot the passphrase.

So, let's get the revocation certificate printout and revoke that gpg and generate a new one. All is good and fine until you realize that „I” (capital i) and „l” (low case „L”) look very much the same on paper. Oops!

So, what do you do? How many „I/l”-s are there in the certificate? Let's find out...


0 eddy@bounty ~/tmp/revoke $ cat template
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: A revocation certificate should follow

iEkEIBECAAkFAkbYOQUCHQIACgkQY8Chqv3NRNquGgCgxdMDrhycNcoJsaeeg7hk
8vVJZzsAnRicsfjcZnUtmLIsys6KK48FbJ4h
=I5o9
-----END PGP PUBLIC KEY BLOCK-----

Well, I'm not going to count, I'll remove the header and footer and see from there...

0 eddy@bounty ~/tmp/revoke $ cat template.in | tr -d '[a-zA-HJ-Z0-9=]'
II
I
I

Ok, so we have 16 possible combinations, not that many.

0 eddy@bounty ~/tmp/revoke $ for i in l I ; do for j in l I ; do for k in l I ; do for l in l I ; do cat template.in | sed -e "s#I#$i#" -e "s#I#$j#" -e "s#I#$k#" -e "s#I#$l#" > $i$j$k$l.mid ; done ; done ; done ; done
0 eddy@bounty ~/tmp/revoke $ md5sum *.mid
eab3a5e312bc0314ac2b3d4536bda2f6 IIII.mid
63a9dd10e381b8ff5c758ab3467a5c45 IIIl.mid
63a9dd10e381b8ff5c758ab3467a5c45 IIlI.mid
919d8494c9990c68f50bc9df61f269bc IIll.mid
63a9dd10e381b8ff5c758ab3467a5c45 IlII.mid
919d8494c9990c68f50bc9df61f269bc IlIl.mid
919d8494c9990c68f50bc9df61f269bc IllI.mid
919d8494c9990c68f50bc9df61f269bc Illl.mid
63a9dd10e381b8ff5c758ab3467a5c45 lIII.mid
919d8494c9990c68f50bc9df61f269bc lIIl.mid
919d8494c9990c68f50bc9df61f269bc lIlI.mid
919d8494c9990c68f50bc9df61f269bc lIll.mid
919d8494c9990c68f50bc9df61f269bc llII.mid
919d8494c9990c68f50bc9df61f269bc llIl.mid
919d8494c9990c68f50bc9df61f269bc lllI.mid
919d8494c9990c68f50bc9df61f269bc llll.mid

Oops, that's not ok... I guess I've been replacing some of the characters more than once.

Take 2:
0 eddy@bounty ~/tmp/revoke $ for i in l I ; do for j in l I ; do for k in l I ; do for l in l I ; do cat template.in | tr 'Il' '-'| sed -e "s#-#$i#" -e "s#-#$j#" -e "s#-#$k#" -e "s#-#$l#" > $i$j$k$l.mid ; done ; done ; done ; done
0 eddy@bounty ~/tmp/revoke $ md5sum *.mid
eab3a5e312bc0314ac2b3d4536bda2f6 IIII.mid
eab3a5e312bc0314ac2b3d4536bda2f6 IIIl.mid
eab3a5e312bc0314ac2b3d4536bda2f6 IIlI.mid
eab3a5e312bc0314ac2b3d4536bda2f6 IIll.mid
7150fa775c83c276223a30d373671333 IlII.mid
7150fa775c83c276223a30d373671333 IlIl.mid
7150fa775c83c276223a30d373671333 IllI.mid
7150fa775c83c276223a30d373671333 Illl.mid
63a9dd10e381b8ff5c758ab3467a5c45 lIII.mid
63a9dd10e381b8ff5c758ab3467a5c45 lIIl.mid
63a9dd10e381b8ff5c758ab3467a5c45 lIlI.mid
63a9dd10e381b8ff5c758ab3467a5c45 lIll.mid
919d8494c9990c68f50bc9df61f269bc llII.mid
919d8494c9990c68f50bc9df61f269bc llIl.mid
919d8494c9990c68f50bc9df61f269bc lllI.mid
919d8494c9990c68f50bc9df61f269bc llll.mid

Oops, that's not good either. Doh, sed works on lines.

Take 3:

Make a one line out of the template and try again:

0 eddy@bounty ~/tmp/revoke $ cat template.in
iEkEIBECAAkFAkbYOQUCHQIACgkQY8Chqv3NRNquGgCgxdMDrhycNcoJsaeeg7hk8vVJZzsAnRicsfjcZnUtmLIsys6KK48FbJ4h=I5o9

0 eddy@bounty ~/tmp/revoke $ for i in l I ; do for j in l I ; do for k in l I ; do for l in l I ; do cat template.in | tr 'I' '-' | tr 'l' '-' | sed -e "s#-#$i#" -e "s#-#$j#" -e "s#-#$k#" -e "s#-#$l#" > $i$j$k$l.mid ; done ; done ; done ; done
0 eddy@bounty ~/tmp/revoke $ md5sum *.mid
66ab0a0bed219db8499debabb9a41c0b IIII.mid
e02c1751c4491ce5db1ebe9e64d8eadc IIIl.mid
c96a33f821d3fba84f655aa986084320 IIlI.mid
998c5c4219a5afdd77f82c9fc9818f6f IIll.mid
e08fe6c5380765d12c4f5e4090a7d9c6 IlII.mid
24241b58c231900b02ebb0410183983e IlIl.mid
72040a77e7cca9a91abf2bb0d51c00dd IllI.mid
a02e8645f3593f5c3549b49adef04bc2 Illl.mid
99a1a47c853ed760ef1f58cba7b75916 lIII.mid
c48bf75f30be46ec576a46a1d5664a93 lIIl.mid
717e9dfdc0d3fba973ba66ccb57d69dc lIlI.mid
3e9a2c937fd269d85c09b449b4da17de lIll.mid
4d283333d1d62086328dbc72425a645d llII.mid
542a7c00e99aad5137975581e57a92c9 llIl.mid
ef0e0a2daad7a933b620331a86455c23 lllI.mid
bdf852887308830475a506f8daad9624 llll.mid

That's better. Now let's put those lines back in place:

0 eddy@bounty ~/tmp/revoke $ for I in *.mid ; do cat $I | sed -e 's#\(eeg7hk\)#\1-#' -e 's#\(K48FbJ4h\)#\1-#' | tr '-' '\n' > $I.good ; done


And revoke that key...

0 eddy@bounty ~/tmp/revoke $ for I in *.mid.good ; do echo "$I:" && (cat header $I footer) > template && gpg --import -a template ; done
IIII.mid.good:
gpg: CRC error; 73689A - 239A3D
gpg: read_block: read error: invalid keyring
gpg: import from `template' failed: invalid keyring
gpg: Total number processed: 0
IIIl.mid.good:
gpg: CRC error; 73689A - 979A3D
gpg: read_block: read error: invalid keyring
gpg: import from `template' failed: invalid keyring
gpg: Total number processed: 0
IIlI.mid.good:
gpg: key FDCD44DA: "Eddy Petrișor " revocation certificate imported
gpg: Total number processed: 1
gpg: new key revocations: 1
gpg: public key 67D8E867 is 987014 seconds newer than the signature
gpg: public key 67D8E867 is 987014 seconds newer than the signature
gpg: public key 67D8E867 is 987029 seconds newer than the signature
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 2 signed: 139 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: depth: 1 valid: 139 signed: 667 trust: 138-, 0q, 0n, 1m, 0f, 0u
gpg: next trustdb check due at 2008-10-09
IIll.mid.good:
gpg: CRC error; 239A3D - 979A3D
gpg: read_block: read error: invalid keyring
gpg: import from `template' failed: invalid keyring
gpg: Total number processed: 0


Cool!


[1] I know is almost a half a year, but I've been busy and hoping

Motorcycles DO EXIST on the road!

Some of you might have noticed that in the recent weeks I wasn't active at all online. This was because I was on a vacation in Italy. On the way back I was eager to write about my experiences, but after entering Romania, I found out that may parents had been involved in a motorcycle accident due to a careless driver.

The accident took place on the second day of the Orthodox Easter (on the 28th of April)[1] while my parents were coming back from my sister's, just 20 km away from my home town, Caracal, in a village called Zănoaga. There, a Daewoo Cielo was parked on the left side of the road[2], facing the direction towards Caracal. The driver decided that it was a good idea to turn his vehicle and, according to his declaration, instead of looking himself if there was anything comming, he asked a passenger if there were any cars comming.

Since a motorcycle is not a car, I guess the passenger thought it was OK to answer "no".

So the driver simply started his maneuver and managed to occupy the entire right lane, according to the accident schematics (I saw the official police schematics of the accident site with my own eyes). There were only 30 cm from the front most point of the car to the ditch on the right side of road, while the rear wheels were on the mark indicating the axis of the road. That left only 2 meters free on the opposite lane out of the 6.60 meters wide road, so there was no way for my father (driving the motorcycle) to avoid the collision, in spite of the fact he was travelling at about 40-50 km/h[3], within the legal speed limit (50 km/h).

My father barely had enough time to avoid the central pillar and aim for the rear right door of the car, obviously, a safer place to hit. Still, this wasn't enough to keep my mother on the motorcycle, a safer place for her than anywhere on the road.

My mother was projected over my father and over the car, and, luckily, landed on the side of the road, between the asphalt and the ditch, on an area covered with grass. She landed straight onto her head (the helmet protected her really well), and the shock of the landing propagated along the spine, resulting in the fracture of the L1 vertebra. She also got a fissure in the right clavicula, but that should already be OK now.

My father managed to remain on the motorcycle, but the impact was violent enough that he managed to bend the gas tank and has two huge bruises on the inside of his thighs (one for each leg). He also accuses pains in his shoulders and the lower end of the spine (unfortunately he "managed" not to do the medical investigations after the accident), but I hope all of these will pass soon and will have no ill effects. Also, out of sheer luck, at that time, my father was wearing a full-face helmet, contrary to his habit of earing an open-face helmet; due to this, his face was protected and suffered no harm, while the chin of the helmet broke after the impact with the motorcycle windshield. Also some deep scratches starting from the half of the helmet windshield up to the top of the helmet were the signs of a (probably second) violent impact with the motorcycle windshield.



So, the next time you are on the wheel, please look out for motorcycles, too. Motorcycles do exist on the road!

Also, I advice anyone driving a motorcycle to wear good protection equipment like a full-face helmet, jacket, pants, boots, gloves, etc. These helped a lot my parents, and will help you too, if, God forbid, you are involved in an accident.


My mother is in a cast that covers her from hips to shoulders to help with the fracture recovery and also wears a collar (just for safety reasons since she is suffering of spondyloses).
My father is able to walk (with some pain) and seems not to have any injures (I will take him for a close investigation some time soon in spite of his stubbornness).



[1] worrying for us (me and my future spouse), my parents didn't told us and waited for us to return to Romania
[2] in Romania the vehicles travel on the right side of the road, so the driver also drove on opposite lane, a fact which, according to the law, is punished with the suspension of the driving license
[3] he speed was confirmed by the measurements done by the police

Finally I made time for it and I have it!

Heh, now I can ride!

News from other worlds

I was recently forced to face once more the limitations and quirks of rpm. This is more painful, when looking at a more capable system like .deb.

When building a .deb package, the debian/rules file is pretty much the heart of all things happening, with debian/control and debian/changelog as the lungs and the liver(? maybe) .

Having different files for the maintainer scripts makes possible things like automatic (but repetitive) generation/modifications of those scripts. This can be useful in some situations when the postinst should do stuff depending on the current contents of the released upstream source (sorry, I know I am being vague, but I can't detail too much). The source package is then generated and the resulting package can be rebuilt 1000 times and the resulting postinst will not be different for a given release. But this is always done in the same way, no matter the upstream version.

Fatality one - the spec is fixed, saint, but still can be altered... still, not in due time

So the basic idea is to have postinst.in as a source for postinst, which is created during the configure stage and later removed on clean. This is possible and works on deb.

Try the same on rpm and you will fail. This is because, although the spec file supports file inclusions, the altered files are merged into the spec right at the beginning of the build process, and you end up with no or an outdated postinst. A later rebuild of the same package would do the trick, but that is wrong for more than one reason.

Fatality two - why fatality one was met

All of this is made in order to overcome yet another rpm limitation: rpm can't assist too much on upgrades; you can't simply upgrade packages properly from one version to another, because rpm doesn't have the notion of letting the scripts know which version is installed over which; it only tells that it is an upgrade or not.

This has lead some people believe rpm isn't able to upgrade at all. Glad to tell them they're wrong (still rpm sucks and is brain dead).

Fatality three - why rpm based system fail to have upgrade support today

Want another RPM limitation? RPM has this brain dead idea that on upgrade the "proper" order and way to call the maintainer script(lets) is:

• new-preinst 2
• new-postinst 2
• old-prerm 1
• old-postrm 1

The numbers 1 and 2 are literally what is passed to the scripts and mean "the number of the installed versions of the same package that will exist after the current operation finishes". No versions of any kind, no other parameters, no rollback, no nothing, just 1 or 2.

And by letting the scripts of the old version run AFTER the scripts of the new one means that you have to explicitly prepare the packages for a later upgrade support (and the best idea is to do NOTHING in the old prerm and postrm scripts on upgrades, since nobody is clairvoyant to see what would be the right course of action for upgrade in future releases).

More bad ideas from the rpm land (glad not to be there)

In somewhat related news, the fedora people are discussing now around the rejection of being able to have package names contain non-ascii characters, characters like kanji, kanas, cyrillic characters or any other characters. Even if I am pro-l10n, this wreaks of bad idea scent from a mile afar.

They aren't probably aware that even unicode is broken (if you see the same glyphs in the comparison table, that is proof unicode is broken) but that is their decision and I am glad I am not in that lost land.

mistranslations - how to deal with it

Aigars, you could use what I already made for the compedia creation. The code is available on i18n.debian.net in my home dir (I thought I exposed it on alioth, too, but I just checked and is not).

The results for latvian are also present.

email harvesting prevention - simple and efficient

On this page I've seen this nice way of preventing email addresses harvesting (I have noscripts installed):



When javascript is enabled/permited, it looks like this:


The code is really simple and could be easily automatically applied to pages (the code obfuscates even more, but that is irrelevant - see the original source for the code):

<script language='JavaScript' type='text/javascript'>
<!--
var prefix = 'ma' + 'il' + 'to';
var path = 'hr' + 'ef' + '=';
var addy35780 = 'g.martinez' + '@';
addy35780 = addy35780 + 'pcbsd' + '.' + 'es';
document.write( '<a ' + path + '\'' + prefix + ':' + addy35780 + '\'>' );
document.write( addy35780 );
document.write( '<\/a>' );
//-->\n </script><script language='JavaScript' type='text/javascript'>
<!--
document.write( '<span style=\'display: none;\'>' );
//-->
</script>This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
<script language='JavaScript' type='text/javascript'>
<!--
document.write( '</' );
document.write( 'span>' );
//-->
</script>

BTW, the PC-BSD site looks really nice, unlike Debian's.

Debian Games Team - have source, but do not import :-/

JoeyH wrote a while back some thoughts on why he hates the DGT SVN repo (mainly our policy to import just the incomplete source of packages - usually just the debian/ directory).

He updated that blog entry and latter said:

Update: I realized after posting this that while the space gains on alioth might be illusory, there is certianly a space gain for people checking the whole repo out. What's really needed is a way to keep all the upstream sources in svn, but check them out only when wanted, and check out all the debian directories for cross-game work.

I was thinking, how about having a different area of the repo where the full source is present and which pulls the debian directory as an external from the current location?

I know it has the huge disadvantage that anything outside of the debian/ directory, but part of the diff, is, for sure, lost. (Still, there is also another team policy to not track anything outside debian directly, except through patches[1], except for really exceptional cases, but even then, there is a need for a strong justification).


Would that work? (I know git-svn doesn't support externals properly, yet, so there's not much gain).


[1] I know Joey, you hate those, too

pbuilder - /etc/pbuilderrc no longer a conffile (333294)

I have just finished a completely functional patch for pbuilder's bug #333294. I started this during debconf7, to be more precise, just after Junichi's talk about pbuilder. This patch makes pbuilder smarter smarter about the information it places in the MIRRORSITE variable of the /etc/pbuilderrc.

And now that file is no longer a conffile[1], and it asks some questions via debconf. And since debconf is translatable, there is a Romanian translation, too.

I have published my changes in my pbuilder git repo on alioth.

Anyone interested in the changes can pull from that repo:

git://git.debian.org/git/users/eddyp-guest/pbuilder.git
or
http://git.debian.org/git/users/eddyp-guest/pbuilder.git


[1] this was the main reason the patch wasn't good enough, since modifying a conffile is RC.

TDebs - arch is not important, is it?

Updates:

1. the arch issue raised by Frans was not the object of my post. Also, not all points are invalid/reiterated, just the ones iterated here. Thanks Frans.
2. add a note that there is an image that proves that .mo endianness is irelevant - usefull for readers that might miss that

---

While looking at Neil Williams' talk(hi-res/lo-res) from FOSDEM about cross building and tdebs I was STUNNED about the many (not all, thanks Frans) points that were reiterated during that talk when there were already answered.

Well, I guess you have to repeat yourself a lot to get your ideas through to the other side. So, let's do that.

All (except the first) of the following have been already answered one way or another on the TDebs wiki page.

Q: .mo files are arch independent or not? Neil asks again on his blog.
A: It doesn't matter, does it?

0 eddy@bounty ~ $ file /usr/share/locale/ro/LC_MESSAGES/wormux.mo
/usr/share/locale/ro/LC_MESSAGES/wormux.mo: GNU message catalog (big endian), revision 0, 228 messages
0 eddy@bounty ~ $ uname -a
Linux bounty 2.6.24.2-bounty #1 SMP Wed Feb 13 02:34:09 EET 2008 x86_64 GNU/Linux

(there is a picture here which proves my point, if you can't see it, click here).



Q: The packages file will explode
A: No, that's addressed.

Q: How do you select languages?
A: Simply use what we have and expand on that.

Q: Do tdebs support anything else than gettext?
A: Yes.

Building in a sarge chroot might not always work

Adeodato correctly points out that building under a Sarge chroot, and expecting the package to work on Sid, might not always[1][2] work mainly because of ABI changes and similar changes. Thus, I am forced to clarify this a little.


Generally, the binaries in the packages we produce do not dynamically link to anything other than libc6, libstdc++5 (yes, 5, not 6) or some internal libraries, so we don't have to worry about ABI changes, at least, not yet.


So, a disclaimer is in order: unless you know what you're doing, you probably are better off building packages for each of the supported Debian distros.

Thanks Adeodato for the heads-up.

[1] unless your package is a special case
[2] or, better said, in most cases

---

udate: fixed the link to dato's post