tag:blogger.com,1999:blog-206635242024-03-07T11:58:27.290+02:00Funkyware: ITCeteraFree Software entrepreneurship: Debian, Ubuntu and beyond.Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.comBlogger83125tag:blogger.com,1999:blog-20663524.post-22234065117206031502023-11-16T10:31:00.003+02:002023-11-16T11:38:58.897+02:00dhcpcd almost ready to replace ISC dhclient in Debian<p>A lot of time has passed since my previous post on my work to make <b>dhcpcd</b> the drop-in replacement for the deprecated ISC dhclient a.k.a. <b>isc-dhcp-client</b>. Current status:</p>
<ul>
<li>Upstream now regularly produces releases and with a smaller delta than before. This makes it easier to track possible breakage.</li>
<li>Debian packaging has essentially remained unchanged. A few Recommends were shuffled, but that's about it.</li>
<li>The only remaining bug is fixing the build for <b>Hurd</b>. Patches are welcome. Once that is fixed, bumping <b>dhcpcd-base</b>'s priority to important is all that's left.</li>
</ul>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com2tag:blogger.com,1999:blog-20663524.post-70332742266232692072022-07-03T11:52:00.001+03:002022-07-03T11:57:48.633+03:00Refactoring Debian's dhcpcd packaging<p>Given news that ISC's DHCP suite is getting deprecated by upstream and seeing how <b>dhclient</b> has never worked properly for DHCPv6, I decided to look into alternatives. ISC itself recommends Roy Maple's <b>dhcpcd</b> as a migration path. Sadly, Debian's package had been left unattended for a good 2 years. After refactoring the packaging, updating to the latest upstream and performing one NMU, I decided to adopt the package.</p>
<p>Numerous issues were exposed in the process:</p>
<ul>
<li>Upstream's <b>./configure</b> makes BSD assumptions. No harm done, but still...</li>
<li>Upstream's <b>./configure</b> is broken. <code>--prefix</code> does not propagate to all components. For instance, I had to manually specify the full path for manual pages. Patches are welcome.</li>
<li>Debian had implemented custom exit hooks for all its <b>NTP</b> packages. Since then, upstream has implemented this in a much more concise way. All that's missing upstream is support for <b>timesyncd</b>. Patches are welcome.</li>
<li>I'm still undecided on whether <code>--prefix</code> should assume <code>/</code> or <code>/usr</code> for networking binaries on a Debian system. Feedback is welcome.</li>
<li>The previous maintainer had implemented plenty of transitional measures in <b>maintainer scripts</b> such as symbolically linking <code>/sbin/dhcpcd</code> and <code>/usr/sbin/dhcpcd</code>. Most of this can probably be removed, but I haven't gotten around verifying this. Feedback and patches are welcome.</li>
<li>The previous maintainer had created an <b>init.d</b> script and <b>systemd</b> unit. Both of these interfere with launching <b>dhcpcd</b> using <b>ifupdown</b> via <code>/etc/network/interfaces</code> which I really need for configuring a router for IPv4 MASQ and IPv6 bridge. I solved this by putting them in a separate package and shipping the rest via a new binary target called <b>dhcpcd-base</b> along a logic similar to <b>dnsmasq</b>.
<li>DHCPv6 Prefix Delegation mysteriously reports <code>enp4s0: no global addresses for default route</code> after a reboot. Yet if I manually restart the interface, none of this appears. Help debuging this is welcome.</li>
<li>Support for Predictable Interface Names was missing because Debian's package didn't Build-Depends on <code>libudev-dev</code>. Fixed.</li>
<li>Support for priviledge separation was missing because Debian's package did not <b>./configure</b> this or create a system user for this. Fixed.</li>
<li>I am pondering moving the Debian package out of the <b>dhcpcd5</b> namespace back into the <b>dhcpcd</b> namespace. The 5 was the result of an upstream fork that happened a long time ago and the original dhcpcd package no longer is in the Debian archive. Feedback is welcome on whether this would be desirable.</li>
</ul>
<p>The key advantage of <b>dhcpcd</b> over <b>dhclient</b> is that works as a dual-stack DHCP client by design. With privilege separation enabled, this means separate child processes handling IPv4 and IPv6 configuration and passing the received information to the parent process to configure networking and update <code>/etc/resolv.conf</code> with nameservers for both stacks. Additionally, <code>/etc/network/interfaces</code> no longer needs separate <b>inet</b> and <b>inet6</b> lines for each DHCP interface, which makes for much cleaner configuration files.</p>
<p>A secondary advantage is that the dual-stack includes built-in fallback to <b>Bonjour</b> for IPv4 and <b>SLAAC</b> for IPv6. Basically, unless the interface needs a static IP address, this client handles network configuration in a smart and transparent way.</p>
<p>A third advantage is built-in support for DHCPv6 Prefix Delegation. Enabling this requires just two lines in the configuration file.</p>
<p>In the long run, I feel that <b>dhcpcd-base</b> should probably replace <b>isc-dhcp-client</b> as the default DHCP client with priority Important. Adequate IPv6 support should come out of the box on a standard Debian installation, yet <b>dhclient</b> never got around implementing that properly.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com2tag:blogger.com,1999:blog-20663524.post-78495287790955188202021-09-07T14:08:00.001+03:002021-09-07T14:21:21.327+03:00sudo apt-get update && sudo apt-get dist-upgrade<p>Debian 11 (codename <b>Bullseye</b>) was recently released. This was the smoothest upgrade I've experienced in some 20 years as a Debian user. In my haste, I completely forgot to first upgrade <b>dpkg</b> and <b>apt</b>, doing a straight <b>dist-upgrade</b>. Nonetheless, everything worked out of the box. No unresolved dependency cycles. Via my last-mile Gigabit connection, it took about 5 minutes to upgrade and reboot. Congratulations to everyone who made this possible!</p>
<p>Since the upgrade, only a handful of bugs were found. I filed bug reports. Over these past few days, maintainers have started responding. In once particular case, my report exposed a CVE caused by copy-pasted code between two similar packages. The source package fixed their code to something more secure a few years ago, while the destination package missed it. The situation has been brought to Debian's security team's attention and should be fixed over the next few days.</p>
<h4>Afterthoughts</h4>
<p>Having recently experienced hard-disk problems on my main desktop, upgrading to Bullseye made me revisit a few issues. One of these was the possibility of transiting to BTRFS. Last time I investigated the possibility was back when <b>Ubuntu</b> briefly switched their default filesystem to BRTFS. Back then, my feeling was that BRTFS wasn't ready for mainstream. For instance, the utility to convert an EXT2/3/4 partition to BTRFS corrupted the end of the partition. No thanks. However, in recent years, many large-scale online services have migrated to BRTFS and seem to be extremely happy with the result. Additionally, <b>Linux</b> kernel 5 added useful features such as background defragmentation. This got me pondering whether now would be a good time to migrate to BRTFS. Sadly it seems that the stock kernel shipping with Bullseye doesn't have any of these advanced features enabled in its configuration. Oh well.</p>
<h4>Geode</h4>
<p>The only point that has become problematic is my Geode hosts. For one things, upstream <b>Rust</b> maintainers have decided to ignore the fact that i686 is a specification and arbitrarily added compiler flags for more recent x86-32 CPUs to their i686 target. While Debian Rust maintainers have purposely downgraded the target, <b>RustC</b> still produces binaries that the Geode LX (essentially an i686 without PAE) cannot process. This affects fairly basic packages such as <b>librsvg</b>, which breaks SVG image support for a number of dependencies. Additionally, there's been persistent problems with <b>systemd</b> crashing on my Geode hosts whenever <b>daemon-reload</b> is issued. Then, a few days ago, problems started occurring with C++ binaries, because GCC-11 upstream enabled flags for more recent CPUs in their default i686 target. While I realize that SSE and similar recent CPU features produce better binaries, I cannot help but feel that treating CPU targets as anything else than a specification is a mistake. i686 is a specification. It is not a generic equivalent to x86-32.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com1tag:blogger.com,1999:blog-20663524.post-38943483029925236802021-02-28T09:40:00.002+02:002021-02-28T16:46:07.033+02:00Shipping Debian with GNOME X.XX.0 is an extremely bad idea<p>Since the freeze has slowly crept in, now is the time to revisit my pet peeve with <b>Debian</b>'s release process: to publish a new Debian release as soon as <b>GNOME</b> published a new X.XX.0 version. This is an extremely bad idea: X.XX.0 releases tend to lack polish, their translations are not up-to-date and several silly bugs that hamper the user experience (what the <b>Ubuntu</b> guys call "paper cuts") exist. Those issues tend to be fixed later when GNOME X.XX.1, X.XX.2, etc. bugfix releases are published. However, Debian has a policy of <i>not</i> pushing non-security releases onto a stable distribution. In this particular case, there are only two valid alternatives: either release Bullseye with GNOME 3.38.X or change the Debian policy to allow pushing 3.40.X bugfix releases via <b>bullseye-updates</b>.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com2tag:blogger.com,1999:blog-20663524.post-73511714612455942582016-08-07T20:18:00.002+03:002016-08-07T20:18:49.380+03:00Debian within a Windows partition?A few years ago, I remember that Ubuntu had a trick that allowed the distribution to be installed as one large file within a Windows partition. Does the same thing exist to install Debian?Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com3tag:blogger.com,1999:blog-20663524.post-29095319068065720112013-03-20T08:13:00.001+02:002013-03-20T08:13:26.402+02:00Outstanding issue in Debian: unroutable public v6 IP<p>Given how Debian and Ubuntu nowadays enable IPv6 support by default, the routing table includes some IPv6 entries by standard. However, this has the unpleasant side-effect that <strong>lib C</strong> tries to connect to public IPv6 addresses, even in a case when the only IPv6 entries are for <strong>loopback</strong> and <strong>local link</strong>. Apparently, libc incorrectly assumes that the mere presence of any IPv6 means that there is a usable default IPv6 route. This results in, among other things, <strong>APT</strong> failing at fetching packages from the Debian repository if the DNS rotation returned the IPv6 address for the server first. I was thus wondering whether libc6 could be made to reject public IPv6 addresses, in cases when the host has no IPv6 gateway in its routing table? Or would there be a smarter way to prevent applications from failing at contacting IPv6 addresses whenever there is no IPv6 connection to the outside world?</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com21tag:blogger.com,1999:blog-20663524.post-4688924232972245672012-12-07T16:37:00.002+02:002012-12-07T16:39:35.672+02:00xf86-video-geode 2.11.14<p>A few days ago, I pushed out version 2.11.14 of the <b>Geode X.org</b> driver. This is the driver used by the <b>OLPC XO-1</b> and by a plethora of low-power desktops, micro notebooks and thin clients.</p><br />
<p>This release mostly features long-overdue fixes to rendering issues under <b>GTK3+</b> and <b>xulrunner</b>, plus yet more ongoing changes to make this driver compile under recent X servers.</p><br />
<p>Sadly, the release took place much <a href="http://bugs.debian.org/692600">too late</a> to be included into the upcoming stable Debian version, Wheezy, which is already deeply into freeze, pending publication.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0tag:blogger.com,1999:blog-20663524.post-23619818556556448572012-09-15T18:49:00.001+03:002012-09-15T19:01:51.260+03:00HTML5: Firefox without FlashOver the past few days, I decided to purge <b>Gnash</b> and <b>LightSpark</b> from my laptop to see whether my Internet experience would be affected in any dramatic way. Amazingly, a number of sites seem to offer video content encoded in <b>Theora</b> (VP3) or <b>WebM</b> (VP8). Sadly, a handful of popular sites such as <b>Vimeo</b> insist upon using the <b>H.264</b> (MPEG-4) CODEC, which cannot be safely supported on Free Software because of unclear licensing issues that might impose an ulterior usage fee onto the end-users.<br />
<br />
The good news is that the Mozilla Foundation has decided to avoid the issue together: starting with the most recent release of the mobile version of <b>Firefox</b>, content decoding is offloaded to the platform's native media CODEC library. On most Free Software platforms, this means that <b>Gstreamer</b> will handle the content and, in turn, use <tt>gstreamer-plugins-bad</tt> to perform the decoding. However, Gstreamer support is still rather sketchy, as attested by <a href="http://bugs.debian.org/682917">this Debian bug report</a> and thus disabled by default. This leaves me wondering how little is missing for this to properly work. Would either <b>Canonical</b> or <b>Red Hat</b> perhaps be interested in funding this?Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com1tag:blogger.com,1999:blog-20663524.post-42242284584835522262012-09-01T15:01:00.000+03:002012-09-01T15:02:42.294+03:00Bounty: PulseAudio: implement compression into the RTP modules<p>I'm looking for someone – preferably based within the IBAN zone – to implement compression support into PulseAudio's RTP modules. Please contact me via my Ubuntu address for details.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0tag:blogger.com,1999:blog-20663524.post-9391264761549633462012-05-29T10:05:00.000+03:002012-05-29T10:05:56.184+03:00OpenWRT: accepting Router Adverts from the ISP in White Russian?<p>As we are getting closer to the <strong>World IPv6 Day</strong>, I thought that I'd see if I can upgrade my WRT54GL's OpenWRT (White Russian) installation to accept Router Adverts from the ISP to acquire an IPv6 address (rather than via a 4-to-6 tunnel broker, which seems to be the most documented case), and to propagate its IPv6 address space to my local network via my WRT45GL's <tt>radvd</tt>. Unfortunately, most of the instructions out there concern newer OpenWRT releases to which I cannot upgrade to because their software base takes up significantly more space than White Russian does. Still, I figure that someone in the community must have already succeeded at configuring their WRT54GL for this and might be able to help. Anyone? :)</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com5tag:blogger.com,1999:blog-20663524.post-25648480279176222372012-03-13T13:07:00.002+02:002012-03-13T13:22:41.425+02:00Ubuntu: LTS to LTS+1 upgrade leaves cruft<p>Over the past few weeks, I upgraded my <strong>Ubuntu</strong> hosts to the <strong>Precise</strong> release due to be published next month. While the upgrade on my desktops from Oneiric to Precise went mostly well, the upgrade of my terminal server from Lucid to Precise was more daunting. In short: too many packages leave an undue amount of cruft behind, namely tons of obsolete configuration files that are not correctly handled by maintainer scripts, to either delete obsolete files or to rename them to the currently valid filename. At Debian, these oversights are periodically monitored using <strong>piuparts</strong> and reported to the package maintainer, but Ubuntu doesn't seem to offer this sort of automated Quality Assurance process yet. Perhaps this would be something worth developing?</p>
<p>PS: For those who wonder how I spotted those obsolete configuration files, I simply enabled the <code>FLAUSCH</code> environment variable before running <code>upgrade-system</code>.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com4tag:blogger.com,1999:blog-20663524.post-1437119103797556042012-02-14T12:27:00.004+02:002012-02-14T13:29:08.545+02:00Adopted: ispell-et, myspell-lv, rus-ispell.<p>Over recent months, I have been pondering the relevance of my Free Software involvement a lot:</p>
<p>More than anything, it constantly feels more and more like several important distributions and projects are moving in directions that break with the old ways far too radically, by breaking software usability rules such as <cite>"least surprise"</cite>, <cite>"works out of the box"</cite>, and <cite>"if it ain't broken, don't fix it"</cite> either to try new approaches to addressing existing needs or simply for change's sake.</p>
<p>Another aspect lies in my usual motivation for packaging or adopting software: because I need it and nobody else bothered doing it. Further reflection made me ponder what, correspondingly, are my usual reasons for dropping software: because what exists already works and because everybody and their grand-mother already invented a million of ways to handle the same issue.</p>
<p>Which brings us to today's news.</p>
<p>What prompted me to hand the dictionary packages I maintained over to someone else was a combination of <cite>"no longer need it"</cite> and <cite>"it already works fine as it is."</cite></p>
<p>For instance, the <strong>Estonian</strong> dictionaries haven't seen any upstream release since the initial one in 2003. While I still use Estonian daily in my online communications, the last 9 years have mostly been spent making minor changes to the dependencies and maintainer scripts, just to keep the package compliant with current <strong>Debian</strong> packaging policies and with ongoing improvements to the <code>dictionary-common</code> maintainer tools. This is not the sort of work that requires any knowledge of the Estonian language, so I felt that having dictionary-common developers handle those technical transitions in a clean and across-the-board way for as many dictionary packages as possible would be more productive than me trying to keep track of those changes by myself.</p>
<p>A similar case applies to the <strong>Latvian</strong> dictionaries. While there have been occasional upstream releases, some of which required patching the source code, maintaining the package has mostly been about tracking Debian policy changes and dictionary-common functional changes. Additionally, my interest for learning Latvian has dramatically dropped over the years, so I no longer saw any point in remaining involved in maintaining the package.</p>
<p>Ditto for the <strong>Russian</strong> dictionaries: occasional upstream releases, occasional patches, regular packaging upgrades to keep up with the Debian policy and with dictionary-common functionality, but no longer much of anything than a passive interest in practicing my Russian.</p>
<p>One of the developers behind dictionary-common, <strong>Agustin Martin Domingo</strong>, frequently helped me make sense of the changes I needed to track in the past, so he gladly accepted taking over the technical maintenance of all 3 packages. The Estonian dictionaries, while extremely skim in the breadth of vocabulary they cover, remain useful, but are essentially deprecated, as the upstream author is working on a spell checking engine similar to what <strong>Voikko</strong> does for <strong>Finnish</strong>, which is why maintaining them will be a rather easy task for Agustin. Meanwhile, <strong>Aigars Mahinovs</strong> passively remains on board for the Latvian dictionaries, while the Russian dictionaries have been adopted by <strong>Mikhail Gusarov</strong>, in both cases with Agustin assisting on technical matters.</p>
<p>Basically, I feel that passing the maintenance over to people whose motivation remains high is a better way to guarantee those packages' future than leaving them in my unmotivated hands and I'm glad that I found someone to keep on packaging them.</p>
<p>PS: happy Valentine's day to everyone!</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0tag:blogger.com,1999:blog-20663524.post-85997209554204018562012-01-03T17:49:00.003+02:002012-01-03T18:06:12.627+02:00xf86-video-geode 2.11.13<p>A few days ago, I pushed out version 2.11.13 of the Geode X driver. This is the driver used by the <a href="http://www.laptop.org">OLPC XO-1</a>, by a plethora of thin clients such as the <a href="http://www.thincan.com">ThinCan</a>, by low-power desktops such as the <a href="http://www.linutop.com">Linutop</a> and by a few notebooks such as the <strong>eCafé EC800</strong>.</p>
<p>While this release indeed features a few bugfixes (mainly to keep this driver compilable on the latest X server), the lion's share of the changes involve a complete overhaul of the build scripts, courtesy of Gaetan Nadon. The key motivation for this overhaul was to acknowledge the efforts made by third-party contributors to make the driver compile on BSD variants. Sure enough, this release finally compiles on FreeBSD and, low and behold, on Hurd.</p>
<p>However, the hybrid nature of Debian's FreeBSD kernel-based GNU operating system variant posed an additional challenge, because it provides usable support for Video for Linux version 2 (V4L2), but without the full complement of Linux definitions. This resulted in one post-release commit (included in Debian and Ubuntu package 2.11.13-2), following which my assertion that we could now safely define this package as <code>Architecture: any-i386</code> finally proved to be a safe one for Debian-based operating systems.</p>
<p>At this point, I'm curious as to how many more operating systems, especialy BSD variants, can finally use this driver. Patches to further improve support of non-Linux systems are welcome.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com2tag:blogger.com,1999:blog-20663524.post-14041357220078019622011-09-24T18:50:00.002+03:002011-09-24T19:00:48.994+03:00Proposed updates for CUPS-PDF packages at Ubuntu<p>For those who use CUPS-PDF on <strong>Ubuntu</strong>, I have pushed some updated packages into <em>Lucid-proposed</em>, <em>Maverick-proposed</em> and <em>Natty-proposed</em>, mainly to make the package's post-install actions bulletproof, so that automated installs and PPD updates take place in a flawless way. Comments from anyone who tested these package updates are welcome on Launchpad bug <a href="https://bugs.launchpad.net/ubuntu/+source/cups-pdf/+bug/805947">#805947</a>. Once these updates have been approved, I'll go through the daunting task of reducing the <code>debdiff</code> down to its utmost essential components and attempt to submit a <em>stable-update</em> to <strong>Debian</strong> as well.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0tag:blogger.com,1999:blog-20663524.post-85818864566937319122011-08-13T20:28:00.003+03:002011-08-13T20:45:13.266+03:00Configuring GNOME themes for both gconf and dconf?<p>For a number of years, I've been making myself metapackages that pull favorite packages and pre-configure the desktop environment to use my favorite global default settings. This currently means configuring the <code>gconf</code> keys for the GTK theme, icon theme and background image for GDM. Until now, I implemented this by calling <code>gconftool-2</code> directly in <code>postinst</code> as user <code>gdm</code> but <strong>Lintian</strong> recently started warning me that the correct way to do this would be by calling <code>gconf-schemas</code> or <code>update-gconf-defaults</code> instead. I was thus wondering, would anyone have any sample code that accomplishes this? To further complicate things, GNOME 3 has transitioned from <code>gconf</code> to <code>dconf</code>, which suggests that a slightly different method needs to be used to perform the same. Would anyone have any sample code to implement this? Thanks in advance to anyone who can help me with this!</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com5tag:blogger.com,1999:blog-20663524.post-29597992104587252852011-02-13T21:46:00.005+02:002011-02-13T22:37:16.120+02:00X.org video driver Geode 2.11.12<p>Today we published version 2.11.12 of the X.org Geode driver, code-named "Squeezing the Wheezy out of Debian" in honor of the recent Debian stable release. 2.11.12 is yet another minor bug-fixing release, this time featuring yet another EXA fix for the LX component, courtesy of the OLPC team, plus the removal of an obsolete V4L1 include that was preventing the building of the <code>ztv</code> video input component of our driver since Linux kernel 2.6.38 - thanks to the Fedora and Ubuntu teams for spotting this!</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0tag:blogger.com,1999:blog-20663524.post-9380592263956873182010-12-11T20:08:00.003+02:002010-12-11T20:20:48.592+02:00Adding default support for Airport remote sinks in PulseAudio<p>In another case of "what were they thinking?" it has been my displeasure to find that support to discover remote Apple Airport audio sinks is not enabled by default in PulseAudio and, in practice, enabling this requires the user to install <code>paprefs</code> just to enable the loading of two modules (<code>module-raop-discover</code> and <code>module-zeroconf-discover</code>) that really should have been loaded via the global <code>/etc/pulse/default.pa</code> by standard. The question is, why? I perfectly understand not enabling the <em>publishing</em> of local audio sinks by default, but why prevent the <em>discovery</em> of remote audio sinks by default? More to the point, why force the end-user to jump through hoops and Google for hours just to enable something that really should have worked out of the box?</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com1tag:blogger.com,1999:blog-20663524.post-17261716339370307092010-11-29T19:11:00.003+02:002010-11-29T19:25:34.582+02:00New GPG key released - signatures welcome<p>Having rediscovered the wonders of GPG, I finally got around generating myself a 4096R key, signing it with my old key and issuing a <a href="http://q-funk.iki.fi/debian/transition_1E0CB9CD_to_C4B4D7B6.txt">transition statement</a>. Given this, if</p>
<ol>
<li>You happen to have signed my old 1E0CB9CD key at DebConf5 in 2005, at Solutions Linux 2008 or at some Free Software event in Finland or in the Baltic countries over the past 7 years and</li>
<li>You're satisfied with the content of the transitions statement,</li>
</ol>
<p>your signature would be appreciated on my new C4B4D7B6 key.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0tag:blogger.com,1999:blog-20663524.post-9650878686359545732010-11-10T16:27:00.003+02:002010-11-10T16:45:51.750+02:00Ubuntu kernel at 1000Hz with PREEMPT enabled?<p>Back when Linux kernel 2.6 was released, one of the immediate benefits that I noticed was how beautifully responsive my desktop had suddenly become. As it turned out, Linus figured out that he would create a buzz to accompany kernel 2.6's release by having a default clock rate of 1000Hz. However, the excitement was short-lived and kernel defaults were soon brought back down to a more conservative rate of 250Hz, allegedly because some peripheral chips could not handle such a high frequency bump without producing an increased amount of processing errors.</p>
<p>Adding insult to injury, Ubuntu defaults eventually dropped another responsiveness enhancement, kernel preemption, allegedly because the goal was to have a one-size-fits-all kernel shipping with Ubuntu and preemption was detrimental to the kernel performance when the host is used as a server, which was a problem because Ubuntu had somehow decided to shift its focus from the desktop market towards the more lucrative server market.</p>
<p>While there is nothing wrong with universally-safe kernel defaults or with a corporate decision to shift a distribution's focus towards more lucrative markets, it nonetheless left me pondering what would be the best way to get a 1000Hz kernel with preemption on my desktops, without constantly having to crank out my own kernel packages. As such, I was wondering if there would be enough traction from desktop users to justify producing such a kernel and to make it available as a post-install option from the Ubuntu repository?</p>
<p>PS: I'm already aware that a specialized Ubuntu kernel is available to cater for the needs of audio production, but my understanding is that it has power management disabled, because it can interfere with the real-time operation of MIDI devices, while normal desktop users would definitely <em>want</em> to have power management enabled.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com5tag:blogger.com,1999:blog-20663524.post-14089698952530159082010-11-07T12:55:00.003+02:002010-11-07T12:58:13.136+02:00Ubuntu no longer ships debian/changelog since Natty?<p>Since a few days, I have started to notice that the "Debian" changelog that normally ships with packages no longer appears with a number of recent package updates. Is this intentional?</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com2tag:blogger.com,1999:blog-20663524.post-61094960246729782202010-10-14T16:01:00.003+03:002010-10-14T16:08:13.761+03:00An old GRSec feature I miss in stock Linux 2.6 kernels<p>Ages ago, when building my own kernel packages was my main hobby, I used to apply the <a href="http://www.grsecurity.net">GRsecurity</a> patch to my kernels. One of the main benefits I found in this patch was that it would make the kernel terminate or, if that failed to have any immediate effect, downright kill any application that suddenly requests an unreasonable amount of system resources. I was wondering if stock Debian and Ubuntu kernels offered any similar feature that could be enabled e.g. via some <code>/sys</code> register?</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com2tag:blogger.com,1999:blog-20663524.post-3043262268731429642010-08-27T19:18:00.006+03:002010-10-16T12:22:24.837+03:00Batch-editing EXIF data to add copyrights?<p>I've recently become more serious about my photographic hobby and it dawned onto me that manually editing each JPEG to add my copyright was entirely the wrong approach. Thus, I was wondering if anybody would know of a Free Software tool that can batch edit the EXIF data in JPEG images? What I'd like to accomplish is simple:</p>
<ul>
<li>Add the string <code>Copyright ©$YEAR Martin-Éric Racine</code> where $YEAR is directly extracted from the original EXIF data's day when the picture was taken.</li>
<li>Optionally, produce smaller versions of the source images to an output folder as TFCD samples for my models to take home.</li>
</ul>
<p>Preferences go for a tool that is already packaged for Debian or Ubuntu but, worst comes, I could package the software myself.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com9tag:blogger.com,1999:blog-20663524.post-63861928067543166752010-08-23T14:27:00.002+03:002010-08-23T14:36:33.307+03:00X.org video driver Geode 2.11.9<p>Released just a few hours ago:</p>
<blockquote>We are pleased to announce this maintenance release of xf86-video-geode. It features a plethora of bug fixes, a few documentation updates and one performance enhancement. This release also marks the return of Advanced Micro Devices to the development team. Please read the content of NEWS for more details.</blockquote>
<p>In practice, this Geode 2.11.9 release mostly fixes the growing number of rendering issues that were exposed with each successive release of the X.org server core. Among other things, it restores the ability to correctly view video streams on Totem and other media players, it fixes icon rendering bugs that affected various desktop environments and web browsers, it removes all remaining compiler warnings and, as a byproduct of fixing one rendering issue, the speed of our driver improved dramatically.</p>
<p>This is one release that will definitely please users of the OLPC XO-1 and of thin client hardware running on LTSP!</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com0tag:blogger.com,1999:blog-20663524.post-41608336876398476892010-07-18T10:45:00.005+03:002010-07-18T10:52:57.291+03:00Firefox is a CPU killer!<p>Since a couple of days, the mere act of launching Firefox is sufficient to get my Dell D430's CPU to overheat to the point of shutting itself down, within a few seconds of launching the application. Two questions:</p>
<ul>
<li>Who the heck are the bastards that designed a laptop with such poor ventilation?</li>
<li>Who the heck are the bastards that coded such a hideous piece of bloated browser?</li>
</ul>
<p>I know that I've previously vented out frustration over Firefox's shortcomings, but now this application-specific CPU overheating crap is just too much. Dammit!</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com5tag:blogger.com,1999:blog-20663524.post-23970718339139735232010-07-06T09:27:00.013+03:002010-07-06T13:50:43.954+03:00On pohjantähden alla, Tää koti mulla mainen, Mä elämästä laulan...<p>My girlfriend and I were out picking up a cake at the bakery last week, when my phone rang:</p>
<ul>
<li><cite>Hello, I'm calling about your application. I just spent the last hour discussing your case with my boss and there's just one thing that bothers us: do you ever intend on paying your residual taxes?</cite></li>
<li>I received those payment slips right after I became unemployed and, as you know, living off unemployment benefits in this country's most expensive city doesn't exactly leave anyone with money to spare...</li>
<li><cite>Say no more! Moving to the capital for this job was a real shocker. The rents are so bloody expensive here! Anyhow, do you intend on taking care of those residual taxes as soon as you get a job?</cite></li>
<li>Yup, just like I said in my application.</li>
<li><cite>Alright, then I guess that everything is in order. We can start processing your application today. We obviously cannot make any promise about how long that's gonna take, but I would think that the decision should come fairly soon.</cite></li>
<li>Wow! That's excellent news! Thanks again for your help!</li>
<li><cite>You're welcome, sir. Have a nice day!</li>
</ul>
<p>Without knowing, at that moment, I had just become a citizen of the country in which I have been living for the past 12 years. It was only yesterday, upon receiving the decision in the mail and looking at the date on the certificate that I realized that, when I got the phone call, the decision had already been made and the bureaucracy was only looking for reassurances that I fully intend upon acquitting my civic obligations as soon as humanely possible.</p>
<p>To say that reading the decision was a highly emotional moment is an understatement. Trying to explain the intensity of this moment to my girlfriend, I compared it to the day when a teenager reaches adulthood. This instant brought a similar feeling: suddenly, the whole EU opens its doors to me and I'm free to decide how to best use the opportunities it offers.</p>
<p>What next?</p>
<p>For now, completing this government training to become a bureaucrat. Funnily enough, becoming a citizen resolved the whole issue of background checks, which also suddenly triples the number of possible venues for the on-job part of the training. In my case, it looks like I'll be spending the next few months at the Ministry of Employment and Entrepreneurship, working on EU projects that fund R&D efforts and export sales ventures in each member state.</p>
<p>After that, I'm not sure.</p>
<p>On one hand, I'd like to apply for the Ministry of Foreign Affairs' KAVAKU recruitment program for future diplomats. On the other hand, that ministry is extremely picky about whom it accepts and it's not particularly known for favoring naturalized individuals. This being said, our current Minister recently published rather ambitious plans to completely reform the Ministry by bringing in seasoned professionals from the private sector who could efficiently promote Finnish know-how and products abroad, rather than hiring more of the same Public Administration graduates, so, who knows? Maybe the time is right for someone like me to join the ranks of the Finnish diplomacy?</p>
<p>An other option that I'm considering is to permanently move to Estonia. When my last job there ended, I was left with the feeling that I could have accomplished a lot more, if only I were in a legal position to move there, rather than commute a couple of times a week. Beyond the pioneering work that myself and my diplomat friends at the Estonian embassy did in Turkey, there was a demand for us to perform the same magic in other countries of interest to Estonia. Unfortunately, not being in a position to be on-site and no longer having a job that paid for me to be there often enough meant that I had to pass on that opportunity. Now, seeing how one of my friends recently left the diplomacy and is open to new challenges, I'm wondering if now might be a good time to resume our operation and prepare our next campaign?</p>
<p>Wow... So much to think about, now that a whole continent opened its doors to me. Hienoa! Olen suomalainen.</p>Martin-Érichttp://www.blogger.com/profile/00394315280689943764noreply@blogger.com4