Skip to main content


 

Debian Day in Varese


I'm stuck home instead of being able to go to DebConf, but that doesn't mean that Debian Day will be left uncelebrated!

Since many of the locals are away for the holidays, we of @Gruppo Linux Como and @LIFO aren't going to organize a full day of celebrations, but at the very least we are meeting for a dinner in Varese, at some restaurant that will be open on that date.

Everybody is welcome: to join us please add your name (nickname or identifier of any kind, as long as it fits in the box) on https://dudle.inf.tu-dresden.de/debdayvarese2017/ before thursday, August 10th, so that we can
get a reservation at the restaurant.


 

On brokeness, the live installer and being nice to people


This morning I've read this.

I understand that somebody on the internet will always be trolling, but I just wanted to point out:

* that the installer in the old live images has been broken (for international users) for years
* that nobody cared enough to fix it, not even the people affected by it (the issue was reported as known in various forums, but for a long time nobody even opened an issue to let the *developers* know).

Compare this with the current situation, with people doing multiple tests as the (quite big number of) images were being built, and a fix released soon after for the issues found.

I'd say that this situation is great, and that instead of trolling around we should thank the people involved in this release for their great job.
blog
Questa voce è stata modificata (4 mesi fa)
Tobias 4 mesi fa
They did a wonderful job <3 Updating my Debian installation from 8 to 9 went without any problems.



 

Travel piecepack v0.1


Immagine/foto

A piecepack set of generic board game pieces is nice to have around in case of a sudden spontaneous need of gaming, but carrying my full set takes some room, and is not going to fit in my daily bag.

I've been thinking for a while that an half-size set could be useful, and between yesterday and today I've actually managed to do the first version.

It's (2d) printed on both sides of a single sheet of heavy paper, laminated and then cut, comes with both the basic suites and the playing card expansion and fits in a mint tin divided by origami boxes.

It's just version 0.1 because there are a few issues: first of all I'm not happy with the manual way I used to draw the page: ideally it would have been programmatically generated from the same svg files as the 3d piecepack (with the ability to generate other expansions), but apparently reading paths from an svg and writing it in another svg is not supported in an easy way by the libraries I could find, and looking for it was starting to take much more time than just doing it by hand.

I also still have to assemble the dice; in the picture above I'm just using the ones from the 3d-printed set, but they are a bit too big and only four of them fit in the mint tin. I already have the faces printed, so this is going to be fixed in the next few days.

Source files are available in the same git repository as the 3d-printable piecepack, with the big limitation mentioned above; updates will also be pushed there, just don't hold your breath for it :)
crafts blog


 

XMPP VirtualHosts, SRV records and letsencrypt certificates


When I set up my XMPP server, a friend of mine asked if I was willing to have a virtualhost with his domain on my server, using the same address as the email.

Setting up prosody and the SRV record on the DNS was quite easy, but then we stumbled on the issue of certificates: of course we would like to use letsencrypt, but as far as we know that means that we would have to setup something custom so that the certificate gets renewed on his server and then sent to mine, and that looks more of a hassle than just him setting up his own prosody/ejabberd on his server.

So I was wondering: dear lazyweb, did any of you have the same issue and already came up with a solution that is easy to implement and trivial to maintain that we missed?
blog

uhm, and now that I've had breakfast I realize that you were using user@example.com as the jid... sorry

from IRC:

<nicoo> Anyhow, the issue is that, for a X.509 cert to be valid for XMPP for example.com, it needs to have either example.com in its subjectAltNames (making it able to impersonate any other service on that domain, esp. HTTPS)
<nicoo> or it can have an SRV-ID in subjectAltName
<nicoo> Unfortunately, the CA/B rules don't allow CAs to issue SRV-ID names
<nicoo> There has been some tentative effort to change that, but it seems to be stalled: https://cabforum.org/pipermail/public/2016-September/008473.html
<nicoo> Here is the matching Let's Encrypt thread: https://github.com/letsencrypt/boulder/issues/1309
<nicoo> I did actually offer to implement it in Boulder (and had a stab at that on a local fork) but it's pointless as long as nothing changes on the CA/B side



 

Mobile-ish devices as freedom respecting working environments


On planet FSFE, there is starting to be a conversation on using tablets / Android as the main working platform.

It started with the article by Henri Bergius which nicely covers all practical points, but is quite light on the issues of freedom.

This was rectified by the article by David Boddie which makes an apt comparison of Android to “the platform it is replacing in many areas of work and life: Microsoft Windows” and criticises its lack of effective freedom, even when the OS was supposed to be under a free license.

I fully agree that lightweight/low powered hardware can be an excellent work environment, especially when on the go, and even for many kinds of software developement, but I'd very much rather have that hardware run an environment that I can trust like Debian (or another traditional GNU/Linux distribution) rather than the phone based ones where, among other problems, there is no clear distinction between what is local and trustable and what is remote and under somebody else's control.

In theory, it would be perfectly possible to run Debian on most tablet and tablet-like hardware, and have such an environment; in practice this is hard for a number of reasons including the lack of mainline kernel support for most hardware and the way actually booting a different OS on it usually ranges from the quite hard to the downright impossible.

Luckily, there is some niche hardware that uses tablet/phone SoCs but is sold with a GNU/Linux distribution and can be used as a freedom respecting work environment on-the-go: my current setup includes an OpenPandora (running Angstrom + a Debian chroot) and an Efika MX Smartbook, but they are both showing their age badly: they have little RAM (especially the Pandora), and they aren't fully supported by a mainline kernel, which means that you're stuck on an old kernel and dependent on the producer for updates (which for the Efika ended quite early; at least the Pandora is still somewhat supported, at least for bugfixes).

Right now I'm looking forward to two devices as a replacement: the DragonBox Pyra (still under preorders) and the THERES-I laptop kit (hopefully available for sale "in a few months", and with no current mainline support for the SoC, but there is hope to see it from the sunxi community).

As for software, the laptop/clamshell designs means that using a regular Desktop Environment (or, in my case, Window Manager) works just fine; I do hope that the availability of Pyra (with its touchscreen and 4G/"phone" chip) will help to give a bit of life back to the efforts to improve mobile software on Debian

Hopefully, more such devices will continue to be available, and also hopefully the trend for more openness of the hardware itself will continue; sadly I don't see this getting outside of a niche market in the next few years, but I think that this niche will remain strong enough to be sustainable.

P.S. from nitpicker-me: David Boddie mentions the ability to easily download sources for any component with apt-get source: the big difference IMHO is given by apt-get build-dep, which also install every dependency needed to actually build the code you have just downloaded.

P.S.2: I also agree with Davide Boddie that supporting Conservancy is very important, and there are still a few hours left to have the contribution count twice.
blog


 

Preseeding a debian installation on a libreboot computer


Preseeding a debian installation from the standard installer is as easy as pressing ESC at the right time and pointing it to the url of your preseed file, right?

It is, except when you're using libreboot, and you never pass through that “right time”, because you are skipping the installer's grub.

So, for future reference, here is the right incantation to use at the command line that you get by pressing c at the libreboot menu:


linux (usb0)/install.amd/vmlinuz auto=true url=http://webserver/path/preseed.cfg
initrd (usb0)/install.amd/initrx
boot


simple, once you've found it...

(ok, it took me less than one hour, but I don't want it to take another hour the next time)

#coreboot #libreboot #debian #preseed


 

New pajama


I may have been sewing myself a new pajama.

Immagine/foto

It was plagued with issues; one of the sleeve is wrong side out and I only realized it when everything was almost done (luckily the pattern is symmetric and it is barely noticeable) and the swirl moved while I was sewing it on (and the sewing machine got stuck multiple times: next time I'm using interfacing, full stop.), and it's a bit deformed, but it's done.

For the swirl, I used Inkscape to Simplify (Ctrl-L) the original Debian Swirl a few times, removed the isolated bits, adjusted some spline nodes by hand and printed on paper. I've then cut, used water soluble glue to attach it to the wrong side of a scrap of red fabric, cut the fabric, removed the paper and then pinned and sewed the fabric on the pajama top.
As mentioned above, the next time I'm doing something like this, some interfacing will be involved somewhere, to keep me sane and the sewing machine happy.

Blogging, because it is somewhat relevant to Free Software :) and there are even sources, under a DFSG-Free license :)
blog crafts
Questa voce è stata modificata (7 mesi fa)
Nice! And I have the same FSF Europe sticker on my laptop :-)



 

Modern XMPP Server


I've published a new HOWTO on my website:

Enrico already wrote about the Why (and the What, Who and When), so I'll just quote his conclusion and move on to the How.

I now have an XMPP setup which has all the features of the recent fancy chat systems, and on top of that it runs, client and server, on Free Software, which can be audited, it is federated and I can self-host my own server in my own VPS if I want to, with packages supported in Debian.


How



I've decided to install prosody, mostly because it was recommended by the RTC QuickStart Guide; I've heard that similar results can be reached with ejabberd and other servers.

I'm also targeting Debian stable (+ backports); as I write this is jessie; if there are significant differences I will update this article when I will upgrade my server to stretch. Right now, this means that I'm using prosody 0.9 (and that's probably also the version that will be available in stretch).

Installation and prerequisites



You will need to enable the backports repository and then install the packages prosody and prosody-modules.

You also need to setup some TLS certificates (I used Let's Encrypt); and make them readable by the prosody user; you can see Chapter 12 of the RTC QuickStart Guide for more details.

On your firewall, you'll need to open the following TCP ports:


  • 5222 (client2server)

  • 5269 (server2server)

  • 5280 (default http port for prosody)

  • 5281 (default https port for prosody)



The latter two are needed to enable some services provided via http(s), including rich media transfers.

With just a handful of users, I didn't bother to configure LDAP or anything else, but just created users manually via:

prosodyctl adduser alice@example.org

In-band registration is disabled by default (and I've left it that way, to prevent my server from being used to send spim).

prosody configuration



You can then start configuring prosody by editing /etc/prosody/prosody.cfg.lua and changing a few values from the distribution defaults.

First of all, enforce the use of encryption and certificate checking both for client2server and server2server communications with:


c2s_require_encryption = true
s2s_secure_auth = true



and then, sadly, add to the whitelist any server that you want to talk to and doesn't support the above:


s2s_insecure_domains = { "gmail.com" }


virtualhosts



For each virtualhost you want to configure, create a file /etc/prosody/conf.avail/chat.example.org.cfg.lua with contents like the following:


VirtualHost "chat.example.org"
enabled = true
ssl = {
key = "/etc/ssl/private/example.org-key.pem";
certificate = "/etc/ssl/public/example.org.pem";
}


For the domains where you also want to enable MUCs, add the follwing lines:


Component "conference.chat.example.org" "muc"
restrict_room_creation = "local"


the "local" configures prosody so that only local users are allowed to create new rooms (but then everybody can join them, if the room administrator allows it): this may help reduce unwanted usages of your server by random people.

You can also add the following line to enable rich media transfers via http uploads (XEP-0363):


Component "upload.chat.example.org" "http_upload"

The defaults are pretty sane, but see https://modules.prosody.im/mod_http_upload.html for details on what knobs you can configure for this module

Don't forget to enable the virtualhost by linking the file inside /etc/prosody/conf.d/.

additional modules



Most of the other interesting XEPs are enabled by loading additional modules inside /etc/prosody/prosody.cfg.lua (under modules_enabled); to enable mod_something just add a line like:


"something";

Most of these come from the prosody-modules package (and thus from https://modules.prosody.im/ ) and some may require changing when prosody 0.10 will be available; when this is the case it is mentioned below.



  • mod_carbons (XEP-0280)
    To keep conversations syncronized while using multiple devices at the same time.

    This will be included by default in prosody 0.10.



  • mod_privacy + mod_blocking (XEP-0191)
    To allow user-controlled blocking of users, including as an anti-spim measure.

    In prosody 0.10 these two modules will be replaced by mod_privacy.



  • mod_smacks (XEP-0198)
    Allow clients to resume a disconnected session before a customizable timeout and prevent message loss.



  • mod_mam (XEP-0313)
    Archive messages on the server for a limited period of time (default 1 week) and allow clients to retrieve them; this is required to syncronize message history between multiple clients.

    With prosody 0.9 only an in-memory storage backend is available, which may make this module problematic on servers with many users. prosody 0.10 will fix this by adding support for an SQL backed storage with archiving capabilities.



  • mod_throttle_presence + mod_filter_chatstates (XEP-0352)
    Filter out presence updates and chat states when the client announces (via Client State Indication) that the user isn't looking. This is useful to reduce power and bandwidth usage for "useless" traffic.




@Gruppo Linux Como @LIFO
@lifo blog
Questa voce è stata modificata (5 mesi fa)
Tobias 5 mesi fa
I had some problems with the configuration. Hope to save others from long debugging time by adding them here as comment ;-)

Initially I had put the mentioned modules at the end of the modules_enabled block of the Prosody config file.. For some reason they never made it to become active and conversation never marked their XEP as available. My final solution was to move them atop the mention of the posix module, now they are all active.

@Tobias this is funny: I have them at the bottom between -- BEGIN ANSIBLE MANAGED MODLIST BLOCK (and the corresponding END) and they work, at least under jessie. I've just upgraded the server to stretch and haven't checked yet that they are all still working.

Maybe there was something else that was commenting them out? I have no idea if there is a block comment syntax in lua.

Anyway, great idea adding the comment here, in case it is useful to somebody else.



 

Candy from Strangers


A few days ago I gave a talk at ESC about some reasons why I think that using software and especially libraries from the packages of a community managed distribution is important and much better than alternatives such as pypi, nmp etc. This article is a translation of what I planned to say before forgetting bits of it and luckily adding it back as an answer to a question :)

When I was young, my parents taught me not to accept candy from strangers, unless they were present and approved of it, because there was a small risk of very bad things happening. It was of course a simplistic rule, but it had to be easy enough to follow for somebody who wasn't proficient (yet) in the subtleties of social interactions.

One of the reasons why it worked well was that following it wasn't a big burden: at home candy was plenty and actual offers were rare: I only remember missing one piece of candy because of it, and while it may have been a great one, the ones I could have at home were also good.

Contrary to candy, offers of gratis software from random strangers are quite common: from suspicious looking websites to legit and professional looking ones, to platforms that are explicitly designed to allow developers to publish their own software with little or no checks.

Just like candy, there is also a source of trusted software in the Linux distributions, especially those lead by a community: I mention mostly Debian because it's the one I know best, but the same principles apply to Fedora and, to some measure, to most of the other distributions. Like good parents, distributions can be wrong, and they do leave room for older children (and proficient users) to make their own choices, but still provide a safe default.

Among the unsafe sources there are many different cases and while they do share some of the risks, they have different targets with different issues; for brevity the scope of this article is limited to the ones that mostly concern software developers: language specific package managers and software distribution platforms like PyPi, npm and rubygems etc.

These platforms are extremely convenient both for the writers of libraries, who are enabled to publish their work with minor hassles, and for the people who use such libraries, because they provide an easy way to install and use an huge amount of code. They are of course also an excellent place for distributions to find new libraries to package and distribute, and this I agree is a good thing.

What I however believe is that getting code from such sources and using it without carefully checking it is even more risky than accepting candy from a random stranger on the street in an unfamiliar neighbourhood.

The risk aren't trivial: while you probably won't be taken as an hostage for ransom, your data could be, or your devices and the ones who run your programs could be used in some criminal act causing at least some monetary damage both to yourself and to society at large.

If you're writing code that should be maintained in time there are also other risks even when no malice is involved, because each package on these platform has a different policy with regards to updates, their backwards compatibility and what can be expected in case an old version is found to have security issues.

The very fact that everybody can publish anything on such platforms is both their biggest strength and their main source of vulnerability: while most of the people who publish their libraries do so with good intentions, attacks have been described and publicly tested, such as the fun typo-squatting one (archived on http://web.archive.org/web/20160801161807/http://incolumitas.com/2016/06/08/typosquatting-package-managers) that published harmless malicious code under common typos for famous libraries.

Contrast this with Debian, where everybody can contribute, but before they are allowed full unsupervised access to the archive they have to establish a relationship with the rest of the community, which includes meeting other developers in real life, at the very least to get their gpg keys signed.

This doesn't prevent malicious people from introducing software, but raises significantly the effort required to do so, and once caught people can usually be much more effectively prevented from repeating it than a simple ban on an online-only account can do.

It is true that not every Debian maintainer actually does a full code review of everything that they allow in the archive, and in some cases it would be unreasonable to expect it, but in most cases they are at least reasonably familiar with the code to do at least bug triage, and most importantly they are in an excellent position to establish a relationship of mutual trust with the upstream authors.

Additionally, package maintainers don't work in isolation: a growing number of packages are being maintained by a team of people, and most importantly there are aspects that involve potentially the whole community, from the fact that new packages that enter the distribution are publicity announced on a mailing list to the various distribution-wide QA efforts.

Going back to the language specific distribution platforms, sometimes even the people who manage the platform themselves can't be fully trusted to do the right thing: I believe everybody in the field remembers the npm fiasco where a lawyer letter requesting the removal of a package started a series of events that resulted in potentially breaking a huge amount of automated build systems.

Here some of the problems were caused by some technical policies that caused the whole ecosystem to be especially vulnerable, but one big issue was the fact that the managers of the npm platform are a private entity with no oversight from the user community.

Here not all distributions are equal, but contrast this with Debian, where the distribution is managed by a community that is based on a social contract and is governed via democratic procedures established in its constitution.

Additionally, the long history of the distribution model means that many issues have already been met, the errors have already been done, and there are established technical procedures to deal with them in a better way.

So, shouldn't we use language specific distribution platforms at all? No! As developers we aren't children, we are adults who have the skills to distinguish between safe and unsafe libraries just as well as the average distribution maintainer can do. What I believe we should do is stop treating them as a safe source that can be used blindly and reserve that status to actual trustful sources like Debian, falling back to the language specific platforms only when strictly needed, and in that case:

actually check carefully what we are using, both by reading the code and by analysing the development and community practices of the authors;
if possible, share that work by becoming ourselves maintainers of that library in our favourite distribution, to prevent duplication of effort and to give back to the community whose work we get advantage from.

Edit: fixed broken typosquatting url
blog
Questa voce è stata modificata (9 mesi fa)


 

The Cat Model of Package Ownership


Debian has been moving away from strong ownership of packages by package maintainers and towards encouraging group maintainership, for very good reasons: single maintainers have a bad bus factor and a number of other disadvantages.

When single maintainership is changed into maintainership by a small¹, open group of people who can easily communicate and sync with each other, everything is just better: there is an easy way to gradually replace people who want to leave, but there is also no duplication of efforts (because communication is easy), there are means to always have somebody available for emergency work and generally package quality can only gain from it.

Unfortunately, having such group of maintainers for every package would require more people than are available and willing to work on it, and while I think it's worth doing efforts to have big and important packages managed that way, it may not be so for the myriad of small ones that make up the long tail of a distribution.

Many of those packages may end up being maintained in a big team such as the language-based ones, which is probably better than remaining with a single maintainer, but can lead to some problems.

My experience with the old OpenEmbedded, back when it was still using monotone instead of git² and everybody was maintaining everything, however, leads me to think that this model has a big danger of turning into nobody maintains anything, because when something needs to be done everybody is thinking that somebody else will do it.

As a way to prevent that, I have been thinking in the general direction of a Cat Model of Package Ownership, which may or may not be a way to prevent some risks of both personal maintainership and big teams.

The basic idea is that the “my” in “my packages” is not the “my” in “my toys”, but the “my” in “my Cat, to whom I am a servant”.

As in the case of a cat, if my package needs a visit to the vet, it's my duty to do so. Other people may point me to the need of such a visit, e.g. by telling me that they have seen the cat leaving unhealty stools, that there is a bug in the package, or even that upstream released a new version a week ago, did you notice?, but the actual putting the package in a cat carrier and bringing it to the vet falls on me.

Whether you're allowed to play with or pet the cat is her decision, not mine, and giving her food or doing changes to the package is usually fine, but please ask first: a few cats have medical issues that require a special diet.

And like cats, sometimes the cat may decide that I'm not doing a good enough job of serving her, and move away to another maintainer; just remember that there is a difference between a lost cat who wants to go back to her old home and a cat that is looking for a new one. When in doubt, packages usually wear a collar with contact informations, trying to ping those is probably a good idea.

This is mostly a summer afternoon idea and will probably require some refinement, but I think that the basic idea can have some value. Comments are appreciated on the federated social networks where this post is being published, via email (valid addresses are on my website and on my GPG key) or with a post on a blog that appears on planet debian.

¹ how small is small depends a lot on the size of the package, the amount of work it requires, how easy it is to parallelize it and how good are the people involved at communicating, so it would be quite hard to put a precise number here.

² I've moved away from it because the boards I was using could run plain Debian, but I've heard that after the move to git there have been a number of workflow changes (of which I've seen the start) and everything now works much better.
blog


 

kvm virtualization on a liberated X200, part 1


As the libreboot website warns: there are issues with virtualization on x200 without microcode updated.

Virtualization is something that I use, and I have a number of VMs on that laptop, managed with libvirt; since it has microcode version 1067a, I decided to try and see if I was being lucky and virtualization was working anyway.

The result is that the machines no longer start: the kernel loads, and then it crashes and reboots. I don't remember why, however, I tried to start a debian installer CD (iso) I had around, and that one worked.

So, I decided to investigate a bit more: apparently a new installation done from that iso (debian-8.3.0-amd64-i386-netinst.iso) boots and works with no problem, while my (older, I suspect) installations don't. I tried to boot one of the older VMs with that image in recovery mode, tried to chroot in the original root and got failed to run command '/bin/bash': Exec format error.

Since that shell was lacking even the file command, I tried then to start a live image, and choose the lightweight debian-live-8.0.0-amd64-standard.iso: that one didn't start in the same way as the existing images.

Another try with debian-live-8.5.0-i386-lxde-desktop.iso confirmed that apparently Debian > 8.3 works, Debian 8.0 doesn't (I don't have ISOs for versions 8.1 and 8.2 to bisect properly the issue).

I've skimmed the release notes for 8.3 and noticed that there was an update in the intel-microcode package, but AFAIK the installer doesn't have anything from non-free, and I'm sure that non-free wasn't enabled on the VMs.

My next attempt (thanks tosky on #debian-it for suggesting this obvious solution that I was missing :) ) was to run one of the VMs with plain qemu instead of kvm and bring it up-to-date: the upgrade was successful and included the packages in this screenshot, but on reboot it's still not working as before.

Immagine/foto

Right now, I think I will just recreate from scratch the images I need, but when I'll have time I'd like to investigate the issue a bit more, so hopefully there will be a part 2 to this article.
#debian-it blog
updatish: apparently it's not "recent version of debian" that works, it's "32 bit version of debian" that does.

I thought I had done an amd64 installation with the netinstall, but actually it was an i386 one.



 

One Liberated Laptop


Immagine/foto

After many days of failed attempts, yesterday @Diego Roversi finally managed to setup SPI on the BeagleBone White¹, and that means that today at our home it was Laptop Liberation Day!

We took the spare X200, opened it, found the point we were on in the tutorial installing libreboot on x200, connected all of the proper cables on the clip³ and did some reading tests of the original bios.

Immagine/foto

While the tutorial mentioned a very conservative setting (512kHz), just for fun we tried to read it at different speed and all results up to 16384 kHz were equal, with the first failure at 32784 kHz, so we settled on using 8192 kHz.

Then it was time to customize our libreboot image with the right MAC address, and that's when we realized that the sheet of paper where we had written it down the last time had been put in a safe place… somewhere…

Luckily we also had taken a picture, and that was easier to find, so we checked the keyboard map², followed the instructions to customize the image, flashed the chip, partially reassembled the laptop, started it up and… a black screen, some fan noise and nothing else.

We tried to reflash the chip (nothing was changed), tried the us keyboard image, in case it was the better tested one (same results) and reflashed the original bios, just to check that the laptop was still working (it was).

It was lunchtime, so we stopped our attempts. As soon as we started eating, however, we realized that this laptop came with 3GB of RAM, and that surely meant "no matching pairs of RAM", so just after lunch we reflashed the first image, removed one dimm, rebooted and finally saw a gnu-hugging penguin!

We then tried booting some random live usb key we had around (failed the first time, worked the second and further one with no changes), and then proceeded to install Debian.

Running the installer required some attempts and a bit of duckduckgoing: parsing the isolinux / grub configurations from the libreboot menu didn't work, but in the end it was as easy as going to the command line and running:


linux (usb0)/install.amd/vmlinuz
initrd (usb0)/install.amd/initrd.gz
boot



From there on, it was the usual debian installation and a well know environment, and there were no surprises. I've noticed that grub-coreboot is not installed (grub-pc is) and I want to investigate a bit, but rebooting worked out of the box with no issue.

Next step will be liberating my own X200 laptop, and then if you are around the @Gruppo Linux Como area and need a 16 pin clip let us know and we may bring everything to one of the LUG meetings⁴

¹ yes, white, and most of the instructions on the interwebz talk about the black, which is extremely similar to the white… except where it isn't

² wait? there are keyboard maps? doesn't everybody just use the us one regardless of what is printed on the keys? Do I *live* with somebody who doesn't? :D

³ the breadboard in the picture is only there for the power supply, the chip on it is a cheap SPI flash used to test SPI on the bone without risking the laptop :)

⁴ disclaimer: it worked for us. it may not work on *your* laptop. it may brick it. it may invoke a tentacled monster, it may bind your firstborn son to a life of servitude to some supernatural being. Whatever happens, it's not our fault.

(edit: added tags)

#coreboot #libreboot
Questa voce è stata modificata (9 mesi fa)
Aaaand second laptop liberated (no pictures, they wouldn't be significantly different from the ones of the first).

(mostly: I still have the original wifi card, until I can find one supported by a free firmware)



 

Debconf streaming and kudos to the video team


With Debconf being in South Africa, a lot of people (like me) probably weren't able to attend and are missing the cheese and wine party, mao games and general socialization that is happening there.

One thing we don't have to miss, however, are the talks: as usual the video team is doing a great job recording and streaming all talks so that people can still participate a bit from their home.

What they do, however, requires a lot of manpower, so if you are attending Debconf please consider volunteering to help: from my experience last year they are very nice people who are welcoming towards new contributors and they have periodical training sessions to help people getting started with the various tasks. More informations about video team meetings and training session are in the topic of the IRC channel, #debconf-video@OFTC.

I don't think there are cookies involved (which just proves that the video team isn't evil), but you may get a t-shirt and you will get a warm fuzzy feeling of having helped people around the world.

@Debian #debconf


 

Busy/idle status indicator





About one year ago, during my first Debconf, I've felt the need for some way to tell people whether I was busy on my laptop doing stuff that required concentration or just passing some time between talks etc. and available for interruptions, socialization or context switches.

One easily available method of course would have been to ping me on IRC (and then probably go on chatting on it while being in the same room, of course :) ), but I wanted to try something that allowed for less planning and worked even in places with less connectivity.

My first idea was a base laptop sticker with two statuses and then a removable one used to cover the wrong status and point to the correct one, and I still think it would be nice, but having it printed is probably going to be somewhat expensive, so I shelved the project for the time being.

Immagine/foto

Lately, however, I've been playing with hexagonal stickers and decided to design something on this topic, whith the result in the figure above, with the “hacking” sticker being my first choice, and the “concentrating” alternative probably useful while surrounded by people who may misunderstand the term “hacking”.

While idly looking around for sticker printing prices I realized that it didn't necessarly have to be a sticker and started to consider alternatives.

One format I'm trying is inspired by "do not disturb" door signs: I've used some laminating pouches I already had around which are slightly bigger than credit-card format (but credit-card size would also work of course ) and cut a notch so that they can be attached to the open lid of a laptop.

Immagine/fotoImmagine/foto

They seem to fit well on my laptop lid, and apart from a bad tendency to attract every bit of lint in a radius of a few meters the form factor looks good. I'll try to use them at the next conference to see if they actually work for their intended purpose.

SVG sources (and a PDF) are available on my website under the CC-BY-SA license.
blog
Sandro 1 anno fa
Ma a questo punto a che servono due ? Basta girarne uno solo.

@Sandro I due sono perché dietro ad uno c'è scritto "hacking", dietro all'altro c'è scritto "concentrating", per i casi in cui "hacking" può esserere frainteso.

E sì, sul portatile in ogni momento ne va uno soltanto.



 

Free Software dreams


Tonight I've dreamt I was inside Widelands, as a barbarian being invaded by the atlanteans.

I've had the same thing happening to me a few times with Battle for Wesnoth

Mayyybe it is a sign that lately I've been playing it too much, but I'm quite happy with the fact that free software / culture is influencing my dreams.

Thanks to everybody who is involved into Free Culture for creating enough content so that this can happen.
blog
Tobias 1 anno fa da open socialverse
sweet dreams :-)



 

StickerConstructorSpec compliant swirl


This evening I've played around a bit with the Sticker Constructor Specification and its template, and this is the result:

Immagine/foto


Now I just have to:

* find somebody in Europe who prints good stickers and doesn't require illustrator (or other proprietary software) to submit files for non-rectangular shapes
* find out which Debian team I should contact to submit the files so that they can be used by everybody interested.

But neither will happen today, nor probably tomorrow, because lazy O:-)

Edit: now that I'm awake I realized I forgot to thank @Enrico Zini Zini and MadameZou for their help in combining my two proposals in a better design.

Source svg
@enrico zini blog
Questa voce è stata modificata (1 anno fa)


 

Pyra preorders


If you've met me at a conference you may have noticed that instead of a laptop I was using a handeld which looks like a laptop scaled down to nintendo DS size, the OpenPandora.

I've used it as my main computing device while travelling for a few years, even for work (as a programmer)so happily that when EvilDragon announced at FOSDEM (link points to youtube video) that he was working on a successor device I started saving money for it even before I knew many details about the specs, other that they would have been way better than the Pandora ones (which is getting painful to use a browser on, because of its 256MB RAM).

Immagine/foto

Now this successor device is almost ready, they have opened the preorders, and they have already reached the absolute minimum number of orders for mass production and are almost there for a more reasonable number of 1000 devices, so if you want a chance to get one of the first batch devices now it's time to visit their store.

A few highlights, from my point of view, include:

* It will run Debian with just a custom kernel/bootloader (and a few configuration only packages): most of the kernel mods are being submitted upstream, so maybe one day there won't even be a need for this kernel (but e.g. with Pandora upstream didn't accept the custom way they managed the keyboard; on the Pyra the keyboard is managed in a more standard way, but there may be other similar issues).

* It has been designed with modularity in mind: the CPU board is socketed on the main board and in the future upgrades may require just replacing the CPU board. I haven't read the details on the actual licensing, but it seems that the hardware design will be open enough that 3rd party boards may also be a possibility.

* just like on Pandora: real keyboard. hardware analog volume wheel. Huge user-replaceable battery (I don't think that there are any independent reviews of the pyra battery yet, but the one on the Pandora is still able to go through a day of FOSDEM — i.e. alternating often between on with wifi and suspendend — and only go down to 50% or so charge). Stylus (and 3d-printed quill) friendly touchscreen. Long term support from the producer.

* The 4G version has been designed in such a way that the GSM modem can be actually turned off (just like on the Neo900)

There are of course a few bad parts:

* PowerVR. The good news is that there is a risk that no 3d drivers will be available at all, and this means that the Pyra has been tested and considered good enough with just (FOSS) software acceleration.

* The price: yes, it is expensive. I'm happy I've saved money in advance for it, otherwise I wouldn't have been able to afford it. Some of it is a problem of small production, some is actual product quality. If you consider that it can take the place of both a laptop (and small ones are getting quite expensive, now that netbooks have disappeared) and a smartphone (I don't do lots of voice calls) it will start going down from "oh so **** high" to "high, but not unreasonably so"

Disclaimer: I have preordered one, so I am interested in the success of the project because it will mean better software and better support for the device.

Edit: forgot the link to the press kit the images comes from, which also includes more infos on specs etc.
blog
Questa voce è stata modificata (1 anno fa)


 

Who would you trust?



Random person on the internet ha scritto:
The distribution model is broken! if you get your software from a distribution you have to trust the package maintainer not to add malicious code!


While the concern is valid, who would you rather trust? A random upstream author who pushed their code on github or somebody who went through a long procedure to prove their trustworthiness before they were granted the ability to put code in the distribution unsupervised?
blog


 

Happy #ilovefs


Happy I love Free Software Day!

Immagine/foto

My life has been full of Free Software for more than 15 years and listing all the software and projects I've used or interacted with would take a long post (and I would be sure to forget someone), so if you are reading this and are involved in Free Software: thank you! I may have used your work in the past, I may be using it some time in the future, or I may never use it personally, but you are making the world I live in a better place anyway.

Special thanks go to the local LUGs, where I've met my SO and to the @Debian project, where I've met a few people I can call friends.

@LIFO @Gruppo Linux Como #ilovefs


 

BDFSM


Enrico Zini coined the BDSM Free Software Manifesto (formerly Definition, which however isn't as precise as a description and more importantly doesn't fit in a cool geeky acronym):

I refuse to be bound by software I cannot negotiate with.


This begged to be turned into a cross-stitch wall hanging. I couldn't refuse.

Immagine/foto

More information and context for the phrase can be found in the notes for Enrico's talk at DebConf 2015: "Enrico's Semi Serious Stand-up Comedy". Note that while fully textual, the topics may be considered not really SFW, and some of the links definitely aren't. It also includes many insights into the nature of collaboration and Free Software Communities, so I'd recommend reading it (and watching the video recording of the talk) anyway.

I've finally also published the pattern on my website:

* The image I've used while embroidering
* kxstitch project (converted now that kxstitch is back into Debian)
* kxstitch generated PDF

Edit: fixed broken links to kxstitch resources.
blog crafts
Questa voce è stata modificata (2 anni fa)