suihkulokki rambling

CuBox

2012-01-18T22:06:00.001+02:00

Just recently arrived from DHL, a solid-run CuBox. I guess nobody who knows me will be surprised when I tell it features an ARM cpu. Specifically an Marvell Armada 510. It features ARMv7 compatibility, with a slight twist of replacing NEON extensions with iWMMX extensions. On the boasting side Armada 510 promises 1080p video decoding and OpenGL ES graphics acceleration (closed source, unfortunately).

The tiny form factor of CuBox is pretty much more than the impressive amount of connectors included;

* Gigabit ethernet
* 2*USB
* eSATA
* HDMI out
* s/pdif optical audio out
* microSD slot
* microUSB serial/jtag port

The last item being important as it makes CuBox unbrickable.. Some will probably lament the lack of WiFi/Bluetooth, but get everything in one device ;). Besides, the USB slots are there to be filled..

Getting started was an slightly rough ride, as in the included Ubuntu (10.04 LTS), X refused to start. After wrongly suspecting that my Display was at fault, turned out the microSD included was slightly corrupted, and some critical contents of xkb-data package were garbage. After reinstall of that package, everything worked, including playing Big Buck Bunny in FullHD with totem.

Biggest disappointment so far is the non-mainline kernel, based on old 2.6.32.9. Some mainline support of Armada 510 exist, but will it work with the proprietary graphics code?

QEMU with OpenGL ES acceleration

2011-06-27T19:13:00.000+03:00

In the graphics side, the major differences between ARM and X86 systems is that on ARM 3D acceleration is done with OpenGL ES. It is mostly a subset of modern OpenGL used on X86 desktop machines. From QEMU point of view this could mostly be ignored, as OpenGL was mostly used on games and specialist applications. This has now been changing, as desktops and user interfaces have started OpenGL to render graphics. Without acceleration, these user interfaces become slower than slugs crossing a tarpit.

For this reason, MeeGo introduced OpenGL ES acceleration support to QEMU. With the lack of easily available MeeGo QEMU images and test setup, I've created a test setup for Linaro 11.05 image.

Running torus opengl es1 demo from mesa-demos inside QEMU.

Getting replaced by scripts - and it feels good!

2011-04-04T19:23:00.001+03:00

As mentioned on Phils blog, Debian buildd's have now capability of autosigning builds. Today when arriving home I was greeted by an empty feeling - There was no builds to sign. The long standing routine had come to an end.

Good system administrators constantly look how to replace themselves with scripts and automation. Bad ones build job security by owning manual processes than nobody else can master.

With signing now done by some code instead of us, I (and other buildd admins) have more time and energy to work on irregular tasks - upgrading chroots, helping developers with porting problems etc. Not to mention blogging and updating ones own packages to sid..

Meanwhile, there are still some issues needing solving - $HOME isn't available on all buildds, -volatile ~~and binNMU's~~ need still manual signing. Certainly not the smoothest update, but it is already making life easier.

(unnofficial) Bits from ARM porters

2010-08-19T21:55:00.006+03:00

Quite a few things have happened recently in the Debian/ARM land

ARM and Canonical have generously provided us with bunch of fast armel machines. Four of these are now as buildd's, bringing the total of armel buildd's to 7. In other words, armel should no longer lag behind other architectures when building unstable packages.

One of machines, abel.debian.org has been setup as a porter box. It is faster (around 3x) than the older porterbox (agricola). All Debian Developers have access to the porterboxes.

The new buildds have allowed us to enable more suites. Thanks to Philipp Kerns work, armel builds now experimental, lenny-volatile, lenny-backports as well as unstable/non-free. Especially if you are using stable Debian, access to backports and volatile should make life happier :)

Finally, the next big thing is Hardfloat ARM port, effort being lead by Konstantinos Margaritis. This doesn't mean that the armel port is going away. Majority of ARM cpus sold are still without FPU, so the softloaf port (armel) will still have a long life ahead. Meanwhile, the armhf port will provide a more optimal platform for people with bleeding edge ARM cores (ARMv7 + vfp). Some people have been unhappy with the new proposed new port, and various alternatives have been proposed. However, armhf is currently the only solution being actively worked on.

Update: thank canonical too

WebGL on N900

2010-06-07T16:38:00.000+03:00

With the recent "PR1.2" firmware upgrade of Nokia N900, a new feature was enabled in the browser - WebGL. WebGL is cool and scary. The cool part is that it is a chance to bring lots of games to to Linux users. The screenshot is from Match3D, a 3D tic-tac-toe game.

The best way to get started is with the Learning webgl tutorial. Passing through the lessons, some are clearly featuring buggy graphics. I don't know if the website, N900 browser or the OpenGL ES driver is being buggy. Which brings the scary part of WebGL - not only does one need to deal with buggy browsers, one has to deal with buggy 3D hardware/drivers! WebGL is still very much work in progress, and on N900 the webGL is rather an "easter egg" than a proper feature. For example the 3D graphics from the GPU does an extra roundtrip via CPU before appearing on the screen.

Other WebGL resources are planet WebGL for following blogs about WebGL, the Khronos Demo repository and more demos can be found at CubicVR site. The last CubicVR demos feature another scary new browser feature (not yet supported on N900) - audio processing in JavaScript.

I'm going to debconf10

2010-05-30T21:13:00.002+03:00

Jep, I'm coming. I bought flight tickets from Icelandair just weeks before Eyjafjallajökull changed from a little known volcano to something everyone knows (but probably can't spell if asked...). The volcano seems to have settled, but at some point I was really happy the ticket was paid with credit card, and at least I'd get my money back. After debconf we plan to travel around NY and nearby, but the accomodation appears to annoyingly expensive, I guess due august being the high season for travel...

In other news it is also possible that I'll visit aKademy 2010 in Tampere, Finland this year.

The Dark side of "Ad-supported" web

2009-11-03T19:24:00.003+02:00

Techcrunch wrote recently an enlightening article about Scam ads in social games.

Irony is the techcrunch article itself showing scam banners as well:

Cult of workarounds

2009-07-25T20:41:00.005+03:00

Wouters otherwise great document on daily buildd maintainance touches a pet issue of mine. There is a great example of a very, very common behaviour pattern in free software community. And I'm certainly as guilty of as Wouter from this behaviour.

Doing it wrong:

Note the 'tr'; this is to avoid 8bit characters from appearing in the mail, which might otherwise be converted to their quoted-printable version in transit to the buildd; and since buildd-mail (the part that receives that mail) does not understand MIME, this would corrupt the GPG signature. This way, we do lose a few characters from the changelog, but that doesn't really matter -- the source still contains the unmodified changelog entry.

Doing it right.

Why, when we have access to all the sources, we still prefer hacks and workarounds over fixes? We are wasting our biggest advantage over propiertary systems!

Why #2 - do we still have to fight 7bit issues in email? Any mailer deployed in the last decade support passing 8bit mail fine. But, not all mailers (most usually, exim or qmail) support _converting_ 8bit mails to 7bit, and thus don't _advertize_ 8BITMIME capability. And when a properly 8BITMIME supporting mailer needs to pass a mail to a smtp daemon that doesn't advertize 8bit capability, the sending mail daemon will happily convert the mail to quoted printable mime. Graah.

I'm Going to DebConf 9

2009-05-14T17:55:00.001+03:00

Turns out TAP is starting to fly Lisbon - Helsinki this summer, and thus offers cheapest flights from Finland to near debconf (at least with my ticket searching magic skill level). And a (night) train from Lisbon to Madrid goes via Cáceres. It appears one can't order the train tickets yet (from renfe.es), the reserving opens 60 days beforehand.

The not-slug: SheevaPlug

2009-02-26T20:03:00.002+02:00

popcon lists approximately 1000 arm/armel Debian installations. There is also listed 864 installations of nslu2-utils, letting us estimate that approximately 85% of debian/arm(el) installations are Linksys nslu2's. It is nicked sympathetically as "The Slug", which pretty accurately describes the performance of nslu2. Still, people have found absolutely amazing amount of ways to use their slugs. What would you do with something approximately 10x more powerful with same prize/size range?

Enter the Marvell SheevaPlug


| What | Slug     | SheevaPlug |
| CPU  | 266Mhz   | 1.2Ghz     |
| Cache| 32KB     | 32+256KB   |
| Flash| 8MB      | 512MB      |
| MEM  | 32MB     | 512MB      |
| Net  | 100Mb    | 1Gb        |

And that's not everything - SheevaPlug comes with SDIO slot and miniusb to be used as a serial console (and JTAG). No soldering needed for hacking.

Some more details on the LinuxDevices article.

For those of you who think that has one port too few of something, or don't like the wall-wart design, Other devices based on kirkwood SoC (which SheevaPlug is based on) are on the way from various ODM/OEM houses.

obligatory lenny post

2009-02-15T17:32:00.001+02:00

In practice for me, this that I finally had to setup stable buildd chroots for armel (ya!). This makes the Debian the first general purpose distribution to release with a ARM EABI port. Thanks for everyone who made this happen, even when the naysayers were claiming that Debian would be too inflexible for another arm port! The list of people who made this possible is simply too long to include in a blog post, and I'm afraid I would still forget someone...

For squeeze, I hope we can keep the name as the release theme and squeeze minimal Debian install into smaller disk and memory than what it takes with lenny :) For more specific squeeze plans on the armel port, we are looking at least into providing optimized versions of various libs (using HWCAP feature) and extending the amount of hardware supported. Not ARM-related directly, but I'd really like to see #206684 fixed finally.

re: how many bugs have you fixed today?

2008-12-16T21:30:00.002+02:00

Sorry Bastian, but that marthyrdon thing doesn't work. Debian has no shortage of talkers, GR-proposers, etc. We have shortage of people of actually doing stuff. Therefor it's only fair that people not bothering fixing bugs get criticized too. And not to mention that there is enough RC bugs open that you could *easily* fix one of them before making another blog post.

This post has been brought to you by fixing #508781 and #496104. (Can I has a meme plz?)

ps, that said, pretending reaching 0 RC bugs means we have a perfect release is delusional. Bugs are found at constant rate. If we fixed bugs faster and reached 0 RC bugs a month a go, the released lenny would now have all the RC bugs found during this month. Therefor it would make much more sense to align the release schedule based on something else, such as d-i schedule and fix any RC bugs left at that point with stable release updates. update: As noted by Dato, the release update essentially says the same.

armel/experimental buildd running

2008-12-16T00:57:00.002+02:00

As the continued freeze of lenny has driven lots of interesting uploads to experimental, it was finally time to setup a armel buildd for lenny. It' now approximately half away done, and with the current rate it should be building the last package of the queue (openoffice) in the end of this week.

Our priorities are literal interpretation of SC and DFSG

2008-12-16T00:21:00.005+02:00

The vocal extremists are not writing free software replacements for the propiertary firmwares. The only offered solution is "remove those non-free firmwares". That disconnects real world users from free software we provide. Which is directly against the *spirit* of SC:

Our priorities are our users and free software.

4222213

I am willing to change my opinion as soon as there are free firmwares for pc peripheral devices.

pimp my x40

2008-11-30T16:50:00.001+02:00

After a brief look at the market, I decided to keep using my sturdy X40. Looking at what could be done to improve the 4 years old workhorse, three things came to mind:

* new battery (old one dies in 45min, new one lasts easily 5+h)
* replace the hard drive (preemptively before it breaks)
* more ram (from 512MB -> 1.5G)

The only one worth detailing is the hard drive upgrade, since I decided to go SSD. less moving parts, less heat, less power consumption. I followed the Thinkwiki CompactFlash boot howto. This basically involves getting a CF-IDE adapter (from ebay, around $5) and any CF card. The first CF-IDE adapter $2.99, but it didn't work. After some research it was concluded that the SMT soldering was bad. The second adapter bought worked fine, and as a bonus the dimensions match the X40 HD perfecty:

In order to minimize writing to flash:

* Make sure root filesystem is mounted noatime,nodiratime (see /etc/fstab)
* make /tmp a tmpfs partition
* disable swap
* more tips can been seen at Linux on Flash guide

Generally I'm very happy with the results of the upgrade. X40 is now most of the time completly silent, without the spinning and clicking HD. Fan turns on less often than previously. The cheapo compactflash is fast enough on reading, and the REALLY slow write speed is usually not a problem thanks to the loads of RAM. Ofcourse, the exception is when a application uses fsync() ... which leads to.

FIREFOX SUCKS GOAT BALLS WHEN RAN FROM A SLOW SSD

Seriously. It's like watching snail cross a tarpit. That's what happens when you fsync() a 30MB places.sqlite on a 6MB/s write speed flash media every fucking time a page has finished loading (and seeming every now and then too). Now here's a really simple workaround: make ~/.mozilla tmpfs and rsync it to/from a backup dir every time you log in/out.

* /etc/fstab: tmpfs /home/user/.mozilla tmpfs size=100m,user 0 0
* and two helper scripts:


aardvark:~$ cat bin/mozilla-mount
#!/bin/sh
mount /home/$USER/.mozilla
rsync -av /home/$USER/.mozilla-safe/ /home/$USER/.mozilla/
aardvark:~$ cat bin/mozilla-umount
#!/bin/sh
rsync -av /home/$USER/.mozilla/ /home/$USER/.mozilla-safe/
umount /home/$USER/.mozilla

It does what mozilla should be doing in the first place - write to temporary files when running and on exit synchronize to the real database and fsync(). With this hack, suddenly the web browser UI doesn't freeze every time a page has finished loading.

You'll also want to disable the urlclassifier anti-forgery tool, which can grow to a over 50MB sqlite database which also gets fsynced all the time...

When Linux doesn't mean freedom

2008-11-10T22:28:00.000+02:00

I actually think it's a bit of an insult if people think of Motorola's EZX or MAGX (and now Android) phones as "Linux phones". Because all the freedoms of Linux (writing native applications against native Linux APIs that Linux developers know and love, being able to do Linux [kernel] development) are stripped.

- Harald Welte

This is something that has worried me too for quite a while. For years we have now had Linux phones available in form or another (well, mostly in far away countries you happen not to be at). Yet with the exception of openmoko none of them allow native application development. Yet all the same time you can go to the nearest phone shop and grab HTC windows CE phone or a Nokia Symbian phone, which actually give you the freedom to writing and running your own software on them.

Now we have the situation that HTC's most locked device* is their only Linux device - The Android G1.

Incidentally, you can install Debian/armel on T-mobile G1, but only until Google engineers manage to fix the hole that gives you r00t.

Marvell 78x00 board

2008-09-13T09:21:00.000+03:00

What we are having here is a quite non-typical ARM based motherboard. It features a pre-production version of Marvell 78x00 series ARM SoC, clocked at 1GHz. It features multiple on-board sata and gigE connectors, as well as pci-e slots and DDR2 ram slots. Fairly "meh" in x86 world, but on the ARM world most systems are designed mainly for low power consumption, tiny size and low cost. Which, while creating allows creating many exciting devices, makes finding meaty buildd's tricky. When we intruduced armel port, the security people rose the concern that arm buildd's are too slow. Especially from the security Point of view, where getting security fixes out fast is important - every second of waiting for security builds to finish someone could be exploited!

Luckily, some people from Marvell had heard about our need and arranged to donate a developer board for us!

So far, the build speed improvement, compared to our current (Thecus N2100) buildd's is very promising. When looking at build times of some slow-building packages which likely will see security uploads:


Package   | Thecus | MV78100 | HPPA  | MIPS
linux-2.6 | 39h    | 11h     | 6h    | 17h
webkit    | 17h    | 5h      | 3h    | 4h
qt4-x11   | 59h    | 17h     | 7h    | 13h
xulrunner | 14h    | 4h      | 1.5h  | 3h

We see that with a Marvell board we are more in the line with other architectures. And the production hardware is going to be even faster! There is a dual-core version as well, but it's not SMP. Both cores are independent, and would basically both run their own Linux image. If manage to find a easy way to implement and manage that, we could run two theoretically run two independent buildd instances on the same board.

See the Linux Devices article for more details about the MV78x00 in general.

can I has roaming

2008-09-09T00:27:00.000+03:00

kopteri pihalla 5am

2008-08-30T08:06:00.001+03:00

sienestyskausi

2008-08-27T18:43:00.001+03:00

aji cristals from k-market

2008-08-09T19:06:00.000+03:00

Creating community friendly embedded systems

2008-06-30T23:35:00.000+03:00

Netgear has jumped the bandwagon and released Open Source Wireless-G Router (WGR614L). Like the earlier Linksys WRT54GL, it's an existing model with a Linux "L" added to end. It does not really add any hardware to make it community friendly, the "open source" part feels like just a marketing gimmick.

With just a couple of small features, these devices could really become community friendly:

Serial port. A kingdom for a router or NAS with a proper serial port! Or at least a pre-solder the serial headers and provide a cable with a TTL shifter.
Unbrickable bootloader. Alternatively, a relatively hard to brick bootloader like Linksys NSLU-2 has.
Mainlined kernel. No "Linux 2.4.22 + binary drivers" crap, like this netgear device.
Widespread availability. The community is around the world.
Documentation.

Not as necessary, but nice to have features for a community-oriented product:

JTAG. So one gets to unbrick it in case bootloader went bonkers. Also allows the community to develop the bootloader.
Extensibility. Just adding a USB port gives any device huge amount of extra possible uses. A SD slot would give loads of storage space. etc..
Contacts with engineers and developers from the manufacturer. Don't just market to the community, be part of the community :)

User interfaces and security are HARD

2008-06-27T13:56:00.000+03:00

You know what the problem is? Webbrowser developers think they're developing the most important application for any computer. -Wouter

Weeelll.. Looking at the the long posts you and others on planet.d.o have written about a browser, one might get the opposite conclusion :) Considering the amount of work and daily business (online banks, shops, news, other services), browser is the most important application after email - and even for email many people use a browser...

Users are good at noticing usability problems. However, their proposed solutions are usually unreliable.

I'm just as annoyed as the next planet writer about the new self-signed SSL dance of FF3. But I do not pretend to know the correct solution. When dealing with security issues, knee-jerk fixes can lead to disasters. Likewise in UI design, the first idea that gets into mind probably isn't the best one.

horsmia

2008-06-16T01:20:00.001+03:00

blog moved

2008-05-30T09:30:00.000+03:00

Buch of quickies:

First, I'm moving from livejournal to blogger. Mainly because blogger allows me to email pictures/videos from my cellphone and automatically converts them to blog entries. To avoid spamming planet with unnecessary entries, only postings tagged with "Debian" be syndicated to p.d.o.
Was invited to UDS and Prague. Quite different from conferences where I've been before (debconf, FOSDEM). Less time spent with one person presenting and rest of room listen, more time people discussing the topic of session. Atleast this was the case in the Mobile track I mostly followed.
Testing scripts now consider Armel a Release architecture. \o/. The armel debian-installer should also be part of debian-installer beta2 really soon(tm) . Only getting testing-security running properly is tricky at the moment...
fuck I'm old now.

beagleboard

2008-05-30T00:22:00.000+03:00

While I have your Attention, one of the most interesting ARM projects at the moment: beagleboard . There is _huge_ variety of ARM developer boards available, but this one has a couple of really interesting bits

Powered by OMAP 3530, a 600MHz ARM Cortex A8 + kitchen sink chip. Most boards are either expensive or have a "bottom-of-line" cpu.
Didn't I complain that TI isn't open enough? Well, since then TI now has released thousands of pages documentation for OMAP3, made omap 35xx available or purchase for anyone, and is even working to get DSP and 3D bits of OMAP3 available. And they go further - beagleboard documentation (link at bottom of elinux wikipage for boeagleboard) has everything including schematics.

2008-05-23T21:41:00.000+03:00

rest of prague pictures

2008-05-23T20:06:00.000+03:00

praha, matkalla illalliselle

2008-05-20T12:31:00.000+03:00

corinthia towers

2008-05-19T20:20:00.001+03:00

praha, kaupunki

2008-05-18T19:55:00.000+03:00

praha, corinthia towers

2008-05-18T19:52:00.000+03:00

cafe amour

2008-05-10T22:21:00.000+03:00

videokuva kännykästä testi

2008-05-07T15:20:00.000+03:00

Test