Log in

No account? Create an account
Здесь вы можете увидеть:
- общие заметки о жизни;
- найденный мной юмор на просторах интернета и реала;
- копания с Debian/Linux/etc;
- заметки про Финляндию
- и много другой всякой фигни.


Verified on Debian 9, amd64.

Unlike some scary instructions may suggest (try searching for 'jolla phone linux connect' or 'jolla phone linux file transfer'), just transferring the pictures taken with the Jolla phone camera to your Debian machine can be done simpler and faster than enabling developer mode on the phone and doing SSH-over-USB. In this case, there happens to be a nice Debian package for the task which requires zero configuration:

  1. connect the Jolla phone via USB, click on 'MTP transfer' in the phone pop-up;
  2. install jmtpfs via your favourite package manager, e.g.:
    $ sudo cupt install jmtpfs
    The following packages will be installed:
    jmtpfs [0.5-2+b2(stretch)]
    libmtp-common [1.1.13-1(stretch)]
    libmtp-runtime [1.1.13-1(stretch)]
    libmtp9 [1.1.13-1(stretch)]
    Need to get 40,1KiB/355KiB of archives. After unpacking 2699KiB will be used.
    Do you want to continue? [y/N/q/a/rc/?] y

  3. mount the data to some user directory, e.g.:
    $ mkdir jolla
    $ jmtpfs jolla
    Device 0 (...) is a Jolla Sailfish (...).

  4. the pictures are ready to be processed by any file manager or picture organiser:
    $ cd jolla/
    $ ls
    Mass storage

  5. after we're done, the directory can be unmounted:
    $ fusermount -u jolla


Reading the discussion on debian-devel about shared library dependencies in C/C++, I wondered if it's possible to link with a shared library without having an absolute dependency on it.

The issue comes often when one has a piece of software which could use extra functionality the shared library (let's call it biglib) provides, but the developer/maintainer doesn't want to force all users to install it. The common solution seems to be either:

- defining a plugin interface and a bridge library (better detailed at here);

- dlopen/dlsym to load each library symbol by hand (good luck doing that for high-level C++ libraries).

Both solutions involve dlopen at one stage or another to avoid linking with a biglib, since if you do that, the application loader will refuse to load the application unless biglib and all of its dependencies are present. But what if application is prepared to fallback at run time, and just needs a way to be able to start without biglib?

I went ahead to check what if there was a stub library to provide all symbols which the application uses (directly or indirectly) out of biglib. Turns out that yes, at least for simple cases it seems to work. I've published my experimental stub generator at https://github.com/jackyf/so-stub .

For practical use, we'd also need a way to tell the loader that a stub library has to be loaded if the real library is not found. While there is many ways to instruct the loader to load something instead of system libraries (LD_PRELOAD, LD_LIBRARY_PATH, runpath, rpath), I found no way to load something if a system library was not found. In other words, I'd like to say "dear linker/loader, when you're loading myapp: if you didn't find libfoo1.so.4 in any of system directories configured, try also at /usr/lib/myapp/stubs/ (which'd contain stubbed libfoo1.so.4)". Apparently, nothing like "rpath-fallback" exists right now. I'm considering creating a feature request for such a "rpath-fallback" if the "optional libraries via stubs" idea gets wider support.


You live in Finland? You work on a FLOSS project or a project helping FLOSS in a way or another? Apply for FUUG's limited sponshorship program! Rules and details (in Finnish): http://coss.fi/2014/06/27/fuugin-saatio-jakaa-apurahoja-avoimen-koodin-edistamiseksi/ .


Cupt 2.6

Cupt 2.6 is released to Debian unstable. Some prominent changes, citing from NEWS-file:

  • Subcommands 'markauto' and 'unmarkauto' are now first-class management actions: can cause more actions in the same run (usually auto-removals) and
    have positional counterparts '--markauto' and '--unmarkauto'.

  • New options '--asauto=yes', '--asauto=no' and '--asauto=default' to control whether packages, (directly) installed by some management action, should be marked automatically or manually installed.

  • New choice 'rc' (show reason chain) in the actions preview prompt.

  • New options '--select=traditional' and '--select=flexible' to control how many versions of packages are chosen for management actions.

  • New options '--must', '--try', '--wish' and '--importance=' to control management requests' importance, allowing specifying optional requests and
    their priority.

  • New 'functional selectors' ("FSE") syntax for advanced version selection in any subcommands which accept binary/source version expressions. The
    subcommand 'search' got a new option --fse.

  • New, enabled by default, possibility to generate and use index-of-index files to speed up building the package cache.

  • General support for "[ key=value... ]" option syntax in sources.list. Specific support for 'trusted=yes' and 'trusted=no' options.

  • Apply id version suffixes (^) to version strings to differentiate versions with same version string but different/uncomparable hash sums, so no versions are skipped anymore.

  • Support for 'InRelease' metadata files.

  • Numerous improvements in speed and memory usage.

  • All new features, as usual, are introduced in the tutorial. Enjoy and send bug reports!


While release of Debian wheezy getting is closer and closer, Cupt's development version also moves forward bit by bit.

A couple of particularly interesting features -- showing full reason chains and functional selectors -- may be summarized by this screenshot.

And, as a fresh experiment, I placed a feature to widen functional selecting capabilities to Catincan, a (new?) crowdfunding platform for open source projects. Let's see how it goes.


DPL game

Inspired by http://blog.zouish.org/posts/dpl_game/. The order is chosen by a fair dice roll.

Wouter Verhelst
Russ Allbery
Bill Allombert
Paul Wise


Из двух сервисов, из которых первый удобный и бесплатный, а второй менее удобный и платный, я не всегда выберу первый. Абсурд? Отнюдь, дело в том, что объявленный бесплатным ("free", "no charge") сервис по факту таковым является редко.

Забывается, что плата заключается не только в деньгах. Регистрируясь на сайте, пользователь обычно вынужден согласиться с "пользовательским соглашением" и/или "условиями пользования ресурса". Иногда ещё и с "политикой приватности". Если коммерческая компания предоставляет вам бесплатный сервис -- вряд ли она делает это из альтруизма. Нет, компания приобретает некоторые права на ваши данные.

Детали при этом сильно разнятся, но, например, IM-сервис ICQ приобретает(ал?) исключительное право на всё, что вы пересылаете с помощью одноимённого протокола (да-да, если вы отправили программный код коллеге по ICQ, этот код больше вам не принадлежит), а работо-ориентированная социальная сеть LinkedIn объявляет себя вправе подать на вас в суд, если вы предоставите сервису некорректные данные. Некоторые сервисы помельче просто и незатейливо пишут "мы можем поменять договор в одностороннем порядке", что равносильно подписи на чистом листе.

Да, эти сервисы обычно сравнительно удобные и не требуют денег, но не предлагайте мне вступать в пользование ими, не прочитав хотя бы договор. Я же своей стороны предложу не столь традиционные, но гораздо менее требовательные альтернативные инструменты, многие из которых бесплатны в широком смысле слова, то есть не требуют ничего, кроме времени на установку. А если так уж не хочется разбираться в новых вещах, извольте -- нет ничего лучше простого человеческого общения, где каждый -- нечто большее, чем одна из сотни миллионов учётная запись в книге лиц.

Ссылка в тему: http://www.finalnews.ru/kiberbezopasnost/chastnoy-zhizni-bolshe-net.html .


На днях бело-синяя социальная сеть, кою я посещал время от времени посмотреть личные сообщения, а также редкие интересные тексты и картинки из "ленты новостей", обрадовала меня сообщением о том, что "вашу страницу пытались взломать", но несмотря на то, что "она в безопасности", меня просят "указать телефон" для "предотвращения в подобного в дальнейшем". Всё это на красивом (даже вычурном) литературном русском языке, с картинкой супермена для привлечения внимания и расстановкой жирного шрифта в нужных местах. Какая забота, и всё для одного меня. Ах да, просят очень настоятельно -- кнопки "продолжить, не указывая телефон" не наблюдается.

Ну, в общем, вы поняли -- пока там висит эта "просьба", в этой соцсети меня не будет. Пишите на почту, в Jabber, на крайний случай в ЖЖ. Лишнее напоминание о том, что не стоит держать все яйца в одной корзине.


A status update for what changed since Squeeze release and what is the state of Cupt in Wheezy. No new things for those few who follow small blog posts or the changelog, but an overview for, maybe, softly or newly interested.

Cupt, the high-level package manager for Debian with a console interface and therefore APT's competitor, continued its development since the first stable series. In the second major version it's rewritten in C++(11), got many new features such as numerous improvements in the depedency resolver and the dpkg action scheduler, the support of index diffs, the tutorial, wget-based download method, position action override options, logging, colored action preview prompt, treeish detailed error messages if no solutions were found, to name most important. That said, if you want multiarch, CDROM repository support or, say, some exotic download method, -- Cupt won't suit, at least for now. Project-wide support is also still almost completely missing as many developers accept no more than two package managers.

The "bug-freeness" aim still holds, at the moment of writing there is no unfixed runtime bugs of priority normal+. Here I thank again those people who reported bugs, you all definitely made Cupt better. I am sure there are bugs still which wait their time to show up, but that's hardly avoidable.

All in all, 2.x is a big step forward from 1.x. Not a last step -- development continues.