1. Thunderbird sucks

    Mutt website says: “All mail clients suck. This one sucks less.” Then Mutt-NG adds “Mutt sucks less - but it still sucks!”. And this is true. Thunderbird definitely sucks. But I still use it.

    I have three email accounts: private one (own server, Dovecot + Postfix) and two work ones on Gmail. And 240GB SSD for /home partition so from time to time I have to clean something. This time it was ~/.thunderbird/ taking about 48GB

    But 48 is still better than 100GB it took in past. Still far too much. So let’s check why it takes so much.

    The biggest folder had 57900 files (1.8GB total). Thunderbird said it has 1801 messages, 48.9MB in total. Each message stored over THIRTY times. Maildir format, Gmail account.

    Went to another folder. 823MB in 77345 files on disk. Thunderbird said 3107 messages, 30.7MB in total. Maildir format again, same Gmail account.

    Ok, let’s check Dovecot one. Turns out that this one is mbox based. The biggest one was 2.1GB on disk, 526MB according to Thunderbird.

    For each of them, I went with “repair folder” button which is “drop whatever is on disk and fetch again from server”.

    And then went through folders and disk usage went to even 14GB. But now it started to fetch everything so time will show how it ends.

    Bug reported. Do not care much will it get solved or ignored.

    Alternatives?

    Evolution was worse than Thunderbird when I tried to use it one-two years ago. Do not remember details now.

    KMail is not usable due to lack of OAuth support for SMTP. There was code written for it but it is not available in Fedora yet.

    Written by Marcin Juszkiewicz on
  2. Where and when mistake was made?

    I am tired of useless discussions. Tired of “we are talking about servers and desktop, not toys” which needs to happen in EVERY arm64 discussion sooner or later. It was that way in “Qt: GL or GLES on arm64” thread on debian-arm ML or recently on #debian-boot when I tried to find out how to get graphical installer working on arm64.

    There was a mistake done at some point probably. Maybe aarch64 should start with A72 cores, GICv3 and multicore server chips. And mobile market get fast v7 cores at same time. To make a clean split.

    On arm64 Fedora has graphical installer for last few releases. Took a while to debug X11 and kernel to find out why it requires config file when it should not. We wrote some patches (better than ones in linked post) and got them merged. I can take Mustang, put graphics card and install operating system using keyboard, mouse and monitor. Just like it is on boring computers.

    Debian? Same machine, same config — you need to grab serial cable and second computer. Because it is Arm system so it is supposed to be one of those small toy boards people give to kids to play with, right?

    Sure, I could sit and discuss with people but it does not work. You always get someone with ‘I use R/Pi zero as a desktop’ (or other insane setup) and then thread dies as every normal person leaves.

    So sorry, but I do not plan to spent any time on improving operating system installers. Never mind which distribution it will be.

    Written by Marcin Juszkiewicz on
  3. AArch64 on AWS

    I woke up today, looked into news stream on my phone and bang! Amazon announced Arm systems being available in AWS. Nice!

    Red Hat Enterprise Linux 7.6 is one of operating systems available from day one. Boots, runs and all the boring things you expect from operating system. It is nice to see new systems run RHEL out of the box.

    So, what to do with such EC2 instance? I know that some people plan to move their x86-64 based cloud infrastructure to aarch64. Several projects will add them into their pool of AWS instances to have another architecture available in their CI systems. Lot of people will run one just to check how it differ from their daily x86-64 systems.

    As those are not bare metal systems you are not able to run OpenStack or play with virtualization but if you are using containers (Kubernetes on Arm anyone?) then it probably can be something to play with.

    Written by Marcin Juszkiewicz on
  4. Red Hat Platform Enablement meeting week

    Last week I was in Vancouver, Canada again. At the time when Linux Plumbers conference took place. But it was not the main reason as I went there to meet people from Platform Enablement team at Red Hat.

    Linux Plumbers

    The idea was simple — gather everyone in one place at same time and let them talk. Conference was selected to give something else to do at same time. And we were visible — for 473 attendees about 60 was from Red Hat.

    Red Hat team before going for team dinner
    Red Hat team before going for team dinner

    I was talking with most of RH people to find out who they are, what they are working on etc. It ended in a lot of interesting discussions. Also many talks with non-RH people. The ‘so you are IBM now’ phrase happened just a few times.

    There were funny moments too. Like one when Dave Airlie responded with “ah, you are the ‘arm64 + radeon guy’” ;D

    Vancouver

    As there was no breakfast option in ‘The Burrard’ hotel I went for a walk to find some. Davie street is full of bars, diners, restaurants (but most of them open at 11:00). Interesting graffiti, cannabis stores (as it is now legal in Canada) and lot of LGBT rainbows everywhere.

    Band graffiti
    Band graffiti
    Some "Safe space" monument
    Some “Safe space” monument
    Tanning salon
    Tanning salon
    Cannabis Store
    Cannabis Store
    Fountain
    Fountain
    Shore
    Shore
    A-maze-ing Laughter
    A-maze-ing Laughter

    Toronto

    Due to one of my flights being cancelled I had to choose: weekend in Vancouver, weekend in Toronto or rebooking whole trip. So I decided to go to Toronto and meet friend there.

    On Saturday I meet Karol and we had long walk. It was good to not discuss about ARM or OpenStack — we went for visual effects instead as this is Karol’s area of expertise. Maya, Houdini, Renderman, Mr. X, ILM, Pixar and other names were going over. I was told “they work on Houdini in that building” and later “here Maya is developed” ;D

    So I asked about photo realistic movies — are they possible now? Turns out that yes, they are. But it is too expensive to make.

    During weekend I did over 20 kilometers by just walking through the city. Some random photos below:

    Thimble monument
    Thimble monument
    Pink Panther graffiti
    Pink Panther graffiti
    Dog graffiti
    Dog graffiti
    Rabbits graffiti
    Rabbits graffiti
    Leslieville graffiti
    Leslieville graffiti
    Together sidewalk graffiti
    Together sidewalk graffiti
    Halloween decorations
    Halloween decorations
    Small house between bigger ones
    Small house between bigger ones
    TORONTO city sign with buildings
    TORONTO city sign with buildings
    TORONTO city sign
    TORONTO city sign
    Me and TORONTO city sign
    Me and TORONTO city sign

    It was great week. Despite sleep deprivation ;D

    Written by Marcin Juszkiewicz on
  5. 20?8 is year of acquiring?

    In 2007 I started working for OpenedHand. They became acquired by Intel in 2008. Today I am working for Red Hat (for over 5 years now). And we have 2018 and it became acquired by IBM.

    I came back home in the evening with plans for some cider and episode of some TV series (probably “Ozark”). But when I landed on a couch and took a look on my phone it shown set of notifications. Telegram, Facebook, Messenger…

    And all of them were about one thing: Red Hat being acquired by IBM. First I looked and sources were Bloomberg and CNBC. At that phase I thought “ok, it can be a rumour” so my answer was “can not comment”.

    But then I went for Red Hat mailbox. And there were links to more serious places: IBM newsroom and Red Hat announcement.

    Looks like tomorrow will be interesting day. Full of reading mails.

    Written by Marcin Juszkiewicz on
  6. OpenStack Superuser Award nomination for my Linaro team

    During last few years Linaro Enterprise Group (recently renamed to Linaro Datacenter and Cloud Group) was working on getting OpenStack working on AArch64 at same level as it works on x86-64 architecture. And I am proud to be member of that group ;D

    We started our adventure with Liberty, migrated to Mitaka and then Newton. And we stayed there for a while with Developer Cloud to make sure that all those projects which rely on it can use VM instances for their work.

    In meantime we were contributing to several OpenStack projects to get everything working properly. Main one was Kolla as we needed good way of cloud deployment but also Nova, Disk Image Builder and others.

    Took us Pike and Queens to get to the point when we could create new setup of Developer Cloud. In clean way, using containers generated by one of OpenStack projects. No more in-house solutions.

    Our team always consisted people from several countries and companies because this is how Linaro works — there are Linaro employees, there are assigned engineers from member companies etc. We cooperated with our kernel people, packagers, developers from several open source projects (libvirt, RDO, CentOS, Debian) and more.

    Some people were running tests, some were doing image builds, package builds. Others were managing to keep us focus and to get it delivered as we planned to.

    We attended several OpenStack related events (PTG, Summit etc) to tell people how AArch64 support looks like in all those projects. Gave several talks about how OpenStack works for us.

    Was it lot of work? Stackalytics graphs show that it took a while. And it was worth it.

    Now we got nominated to OpenStack Superuser Award. It is an achievement which would not be possible without all people working on it during last few years.

    So, go, read about nominees and vote for us!

    Written by Marcin Juszkiewicz on
  7. QML - Quality Matters Last?

    In 2004 I was newbie in embedded Linux area. Decision to buy Sharp Zaurus instead of HP iPaq got me to Qt/e world rather to GTK one. I was also KDE user rather than GNOME2 as well so I can say that I liked Qt already.

    All those sizes in pixels, paddings and margins I saw in GTK code made me feel sick each time I had to edit UI of some application. No idea why developers went that way…

    In Qt world all you had to do was launching Qt Designer, put some UI elements into window, apply some Layout elements and build your app. No need to deal with padding/margin settings etc cause library that for you.

    In meantime Qt developers added QML as a new way to do UI for Qt applications. I ignored it’s existence until now…

    Few days ago Michał Schulz did nice work on improving my Modland player. He also moved it’s UI from old Qt Designer one to QML.

    Modland player with QML based UI
    Modland player with QML based UI

    For now UI is hardcoded to 800x480. I have tried to make it scalable but have a feeling that QML is against me.

    Look at Authors/Modules part. It is simple layout, right?

    • label
    • listView
    • label
    • listView

    In Qt Designer UI I would select those four elements, put into GridLayout and it would scale properly. So I tried that for QML. Labels survived, listViews got 0x0 size.

    And the only ‘design tool’ to edit QML is Qt Creator. Which gets fugly unstable once you try to play with QML designs…

    So I looked at files describing UI. And you know what I found there? Old GTK nightmares… Positioning elements with pixels, sizes in pixels. Pixels! Not some magical “dp units”. There is no way to say “make this element 10em tall” like you can with CSS.

    And it is not only with Modland player UI. Same it with QML examples…

    WTH happened with Qt developers? Or was “QML is only for embedded devices, do not use on desktop” phrase got removed from documentation by mistake?

    Written by Marcin Juszkiewicz on
  8. How fast is APM Mustang?

    During Linaro Connect there was a possibility to play with ThunderX2 workstation. I remember that Arnd Bergmann was comparing speed of kernel compilation with his AMD Threadripper workstation.

    Test was simple — checkout 4.18 source, use arm64 defconfig and do build of ‘Image modules’ with as many threads as you have cpu cores. He did several builds with limiting to one cpu, to disable cpu threads etc but idea stays the same.

    Dual socket ThunderX2 (28 cpu cores, 4 threads per core iirc) did that in about 2 minutes. So did Arnd’s Threadripper machine.

    So I decided to check that on my local hardware. Mustang needed 38 minutes, my i7-2600K based desktop did that in 9 minutes 20 seconds.

    For comparison: I was told that Synquacer with it’s 24 Cortex-A53 cores does that in about 16 minutes.

    Is it fast? Do not think so. But who would assume that retro hardware will be fast…

    Written by Marcin Juszkiewicz on
Page 13 / 106