No Food for Thought

Food is something you should provide to your brain long before coming to this blog. You will find no food recipes here, only raw, serious, non-fake news for mature minds.

Duplicate form sections with jQuery - Improved

admin Friday May 27, 2016

Based on David Carr's excessively simple technique to duplicate form sections using JavaScript, here is my enhanced but still minimalist take, adding support for:

  1. select multiple
  2. starting the form with several sections already
  3. easy backend usage

This changes indices so they start at 0.
Image Duplicate Form Sections

//define template var template = $('#sections .section:first').clone(); //define counter var sectionsCount = jQuery('div.section:last').data('number'); function incrementIdentifier(id, sectionsCount) { if (id.substr(-1) == '0') { id = id.substr(0, id.length - 1); } return id + sectionsCount; } //add new section $('body').on('click', '.addsection', function() { //increment sectionsCount++; //loop through each input var section = template.clone().find(':input').each(function(){ //set id to store the updated section number newId = incrementIdentifier(this.id, sectionsCount); //update for label $(this).prev().attr('for', newId); //update id this.id = newId; var baseName = this.name; var array = false; if (baseName.substr(-2) == '[]') { array = true; baseName = baseName.substr(0, baseName.length - 2); } baseName = incrementIdentifier(baseName, sectionsCount); if (array) { baseName = baseName + '[]'; } this.name = baseName; }).end() //inject new section .appendTo('#sections'); jQuery('input[name=lastSection]').val(sectionsCount); return false; }); //remove section $('#sections').on('click', '.remove', function() { //fade out section $(this).parent().fadeOut(300, function(){ //remove parent element (main section) $(this).parent().parent().empty(); return false; }); return false; });

As a bonus, the PHP function I quickly crafted to ease processing the resulting $_REQUEST:

<?php /** * Treat $_REQUEST when working with duplicate-form-sections.js * $_REQUEST['numberedParameters'] contains the base name of the parameters to be converted into arrays * $_REQUEST['lastSection'] is the number of the last section (the number of sections minus 1) * Alters neither $_GET nor $_POST * @author Philippe Cloutier * @license MIT * @return boolean false on failure */ function numberedParametersToArrays() { if (! isset($_REQUEST['lastSection'])) { return false; } $numberedParameters = $_REQUEST['numberedParameters']; $lastSection = $_REQUEST['lastSection']; foreach ($numberedParameters as $numberedParameter) { $_REQUEST[$numberedParameter] = array(); for ($i = 0; $i <= $lastSection; $i++) { if (isset($_REQUEST[$numberedParameter . $i])) { $_REQUEST[$numberedParameter][] = $_REQUEST[$numberedParameter . $i]; } else { $_REQUEST[$numberedParameter][] = array(); } // We could unset the numbered parameters. } } return true; } ?>

And here is an adjusted usage example:

<form> <div id="sections"> <div class="section" data-number="0"> <fieldset> <legend>User</legend> <p> <label for="firstName">First Name:</label> <input name="firstName0" id="firstName0" value="" type="text" /> </p> <p> <label for="lastName">Last Name:</label> <input name="lastName0" id="lastName0" value="" type="text" /> </p> <p> Friends: <select name="friends1[]" id="friends1" size="2" multiple> <option>Alice</option> <option>Bob</option> </select> </p> <p><a href="#" class='remove'>Remove Section</a></p> </fieldset> </div> </div> <p><a href="#" class='addsection'>Add Section</a></p> <input type="hidden" name="numberedParameters[]" value="firstName"> <input type="hidden" name="numberedParameters[]" value="lastName"> <input type="hidden" name="numberedParameters[]" value="friends"> <input type="hidden" name="lastSection" value="0"> </form>

Note that there are similar solutions elsewhere. I am not saying this one is better than these.

You know you're getting old when...

admin Saturday May 7, 2016

You know part of your life is behind you when Debian is dropping support for your first computer (as well as your second). I can't help but feeling nostalgic when thinking about my good old Pentium 120 MHz (80502) and my AMD 450 MHz (K6-2). Ah, the good old times when CPU-s were the stars. Today, I do not even remember the model or frequency of the computers I work on, even though I chose them alone.

That being said, I'm happy Debian is finally making that move.

Are beta credit cards the right choice?

admin Sunday April 17, 2016

Tangerine bank started promoting its new Money-Back Credit Card several months ago. Wanting to avoid spending time on anything "beta", I did not request a card until, last month, I fell under the impression that the card was ready.

The ordering process was not bad, except for asking you to make a ridiculous choice between purchase categories granting extra money-back rewards. The process lets you define your credit limit.

When the package arrived, I was surprised to find the contract was printed on 4 unbound sheets of paper. But even more surprised to see the card's design:

Out of 4 adults asked, a single one could tell the right direction in which the card must be inserted (which is chip first, of course).

Running from Debian Project Leadership

admin Wednesday March 16, 2016

The 2016 Debian Project Leader election has started. For a second time, its result is quite predictable, as there is a single candidature.

After a single term, Neil McGovern has not offered himself again. A few years ago, I wrote about governance issues in my description of my involvement in Debian. Although elections are infrequent and the number of candidates has never been very high, the following table seems to show a downwards trend:

Number of DPL candidates per year
YearNumber of candidates

While I believe Debian should use liquid governance, I suggested that distributing the DPL role (using for example a Second in Charge) would help meanwhile. Some may argue that a second single-candidature DPL election this decade implies that candidatures for the 2IC role would be rare, since so few contributors are interested in even the DPL role.

There may be several factors behind the diminution of candidatures, including a diminution of activity. But it should still be observed that Software in the Public Interest, which is a lot less active than Debian, manages to find 8 directors. So I have an alternative interpretation for the low number of candidatures in past years.

In my description of my journey in Debian, I showed that half of Debian Project Leaders do not propose themselves again after their first term. Veteran developers know that becoming DPL often means burnout and the end of one's Debian involvement. So I propose that the decline in DPL candidatures is not due to the role's importance having diminished, but rather a realization of that importance being excessive (in other words, excessively demanding for the (null) compensation).

I am not convinced this year's candidate has as much maturity as the DPL role would call for. But even him seems aware of the DPL's importance, as he shows at the very end of his platform:

Mehdi Dogguy wrote:

Time commitment

The DPL role is very time-consuming. To be able to do it seriously, I will put on hold my other Debian activities for the duration of the mandate.

I will not be able to be a full-time DPL. Instead, I have the full support of my employer, who is very supportive of the work we do on Debian. I will be able to dedicate 20% of my work time to Debian tasks.

I am disappointed to see his platform does not propose any major improvement to governance. Which does not mean things cannot improve a bit:

Mehdi Dogguy wrote:
I do not intend to centralize all tasks, but will call for help Debian contributors whenever possible. I will invite Debian contributors who are good speakers to represent the project, rather than have the project rely solely on the DPL.

Hopefully, by distributing the role of spokesperson, the DPL can get a bit more time for decision-making.



The leader in office at the time of publication included the following in his electoral platform:

Neil McGovern wrote:
I will continue to communicate with the project - the daily DPL log as set up by Stefano is a great tool, and monthly bits mails are helpful to show the project what the DPL is up to.

Neil's Final bits from the (outgoing) DPL was only his third "bits" mail. And it contains:

Neil McGovern wrote:
That said, I'm not sure anyone except those who have experienced the job realize what a time commitment it is [...]

While the above is very revealing, I encourage leaders who will leave the office to provide an actual estimate of the amount of time they dedicated to the office, as well as an evaluation of how well they think they did.


After Neil dedicated most of his A year in the life of a DPL talk about his DPL term to a single issue (ZFS and its Common Development and Distribution License), he was asked by his predecessor about the time spent by DPL-s on licensing matters (at 33:05). Neil's answer eventually strayed from the question to discuss the DPL role and concluded with:

Neil McGovern wrote:
I am not convinced that this is a role that one person can take on—especially if they are not working full-time on the job—and be able to achieve everything that they want to.


The 2017 election is quite comparable to 2016's. There are twice as many candidates this year - 2 - but no more focus on governance. Mehdi Dogguy's platform is unchanged regarding governance. Mehdi also doesn't estimate how much time he committed to the role in his first mandate. As for Chris Lamb, his platform does not have 1 word on governance.


This year again, a single candidate is walking for leadership. The candidate, the current leader, presents a new platform which still has no word on improving governance, but which now discusses governance by describing his first term:

Chris Lamb wrote:

Being the DPL is an extremely hard job. Indeed, it's even difficult to explain exactly how, any statistics somehow do not quite capture it. However, I am now beginning to understand the look in previous Leader's faces when congratulating me on my appointment. Future candidates should not take nominating themselves lightly.


On the other hand, it is with some regret that a large amount of my effort and energy was consumed with mediating a significant number of complicated interpersonal and anti-harassment issues. I mention them here, not to moan or complain, but merely because these concerns, perforce, generate little-to-no external noise and are thus otherwise invisible.

More saliently, they cost a disproportionate amount of energy or "spoons" which — as they took myself and others away from furthering initiatives outlined in my platform — I was truly not convinced I would stand for re-election until very recently on a question of personal ethics. Indeed, I might not have done at all had it not been for some encouraging and deeply touching words from a number of close confidants. They stressed to me that a year, especially as the DPL, is not a long time. In some senses, they counselled, I should consider myself just getting started and only now prepared to start to take on the bigger changes.

While I congratulate Chris for describing his activity probably more than any other DPL, and while I know very well how painful time-tracking is, I deplore that once again no estimation of the time required/invested during the current term is published.

FHoS - Igor Escobar and the jQuery Mask Plugin

admin Monday March 7, 2016

Designing Web forms can still be a pain today. I thought HTML version 5 and its tel type input field could replace the complicated triple text fields used by our web tools. But due to lacking global phone number standardization, tel is quite useless. So I ended up integrating the jQuery Mask Plugin, which adds characters in a plain text field so "1234567890" is turned into "(123) 456-7890", or the format you want ("(000) 000-0000" is called a mask).

Everything seemed fine until I realized the plugin was pushing the masked values to the server. If the server had pushed a customer's current phone number as "1234567890", which was then masked by the plugin, it would come back to the server as "(123) 456-7890". In August 2015, raphaelm22 requested his solution to be adopted. Igor Escobar, the jQuery Mask Plugin's author, commented that he appreciated the "suggestion but [did not] belieave that [raphaelm22's] decision matches with what [he hoped] in terms of future of jQuery Mask." And without further explanation, he closed the ticket.

I took that occasion to properly report the problem raphaelm22 was trying to solve in ticket #371. And 2 days ago, Igor Escobar closed that ticket, without any explanation.

Dear Igor, if you read this, I am thankful to you for writing the plugin, but for authoring such a bug and for pretending it does not exist… I am hereby enshrining you into the infamous FHoS.

As always, admission into the FHoS is best considered as an incitation to leave it. In this case, you will have yourself expelled from the Hall by simply solving this issue, either by a code fix or by properly documenting it. I do hope your solution will be better than that proposed by raphaelm22.

Meanwhile, we are using the following ugly workaround at work, similar to raphaelm22's suggestion:

jQuery("form").submit(function() { jQuery('input.telephone').each(function() { jQuery(this).val(jQuery(this).cleanVal()); }); });

If you know of a fork without this issue or an equivalent plugin, please leave a comment to let me know.

TODO: Evaluate https://github.com/digitalBush/jquery.maskedinput
See also http://wiki.jqueryui.com/w/page/12137996/Mask

FHoS - Ana Beatriz Guerrero Lopez: Discussion is not an option

admin Sunday February 28, 2016

In January, I announced my "resignation" from Debian's public relations. My last contribution to the team was a few fixes and other improvements to its wiki page. All of these changes were integrally reverted by an editor who used the helpful edit summary "remove changes from chealer".

Those who have worked with me know how I deal with troublemakers. I am as respectful to them as they are respectful to their colleagues. I reverted the editor with the equally helpful edit summary "uh... I guess "remove changes from x" shall be a good enough explanation". The editor then again integrally reverted my revision with an even worse edit summary: "hi chealer, please do not make edits in this page.".

At this point, you may think this is just another episode from an open wiki. And you would be right, except for the fact that the editor in question is no other than Ana Beatriz Guerrero Lopez, who has been a Debian member for a decade, and who is one of the 4 team members recently "appointed" by project leader Neil McGovern. I was already contributing to Debian KDE when Ana joined the team, so she knows very well who I am.

All of that explains why I went as far as creating a discussion page for the team's page before going further. But that still wasn't enough to get Ana to try justifying what she had done. She would still "[revert] unwelcome changes". Not only that, but by the same reversion, she removed the link to that discussion page. Appropriately in a sense, since she also deleted the discussion page.

Thankfully, that latest reversion was not integral. Apparently, she finally accepted most changes. Those she still rejected may be an indication of what really bothered her.

To be fair, I am not the only former member Ana removed. Her very next edit removed the current members and emeritus members sections, commenting that "there is not[sic] such thing as "emeritus" members and everybody belongs to the publicity team". I certainly agree with the former statement. Congratulations, Ana, for being the first to have the guts to make that statement. Unless you were simply the first one to need such an edit, to justify your previous edit. As for everybody belonging to the publicity team, if the delegation was not a coup, and if "The listing below includes regular contributors also.", it is strange that this listing only includes the so-called "DPL-delegated members". And if your co-delegate found it important to have all members listed on the page, is it consistent that all of those who added themselves at her request (Thomas Vincent and yours truly) have been removed by your edits, just a few months later?

In the end, the answer to those questions does not matter. That we have to speculate is enough to diagnose a communication problem. And since this is not the first time you have serious issues communicating, I have the dishonor of hereby enshrining you into the infamous FHoS.

Your last edit to the wiki page is surely just the tip of your contribution to Debian. I have not followed your activity closely, but I am convinced you are a useful contributor. But this is no excuse to undo other people's work and to be incapable of civil discussion after a decade of participation in a huge project like Debian, at the risk of demotivating your colleagues.

Do not despair. The FHoS is one very special hall, which you can (and are encouraged to) leave. This is no more a condemnation to permanent humiliation than a challenge for the continuation of your contribution. Demonstrate that you have understood the importance of communication and I will have the true honor of removing you from the FHoS. Have the Debian wiki become a real discussion platform, so that no one can do something quite as bad again. Show me you got it to run a discussion system a la Flow, and I will replace this post with one singing your praises.

Bad stealers and good stealers

admin Saturday February 27, 2016

I was in first grade the first time I had something stolen from me. In fact, the stealer took Micro Machines I had temporarily exchanged with my electronic helicopter, so the owner of the stolen Micro Machines did not give me back my helicopter, which produced sounds when its buttons were pushed. I remember the poor child I was regretting that loss years later.

Since then, the only things which were stolen from me are 2 winter bikes (i.e. cheap bikes), a seat-post and a wheel. And only one of these thefts involved breaking a security device. Eventually, I realized I have always been lucky, in particular on that front. In recent years, I realized how lucky in particular I was for having never lost a wallet.

On January 23rd, I went to the gym. I put all my stuff in a locker to go warm up swimming. After a shower, I arrived at the pool and noticed it was unavailable. I took a couple minutes to memorize the schedule, went back to the locker room, dried my hair and went back to my locker about 15 minutes after leaving it. I noticed half of my stuff was missing, and realized it was not my lucky day.

I wondered if the stealer would bring back some of the stolen stuff he could not make use of, but the middle-aged security agent who received my deposition said he had never heard of such luck. While I was waiting for footwear and clothes needed to go back home, I realized how much time (and money) it would take to recover and buy again the more than 20 items I had been stolen. I asked 2 or 3 times whether some of my stuff had been recovered, without success.

At least initially, I even felt that some of my trust in others had been stolen. I was not done dealing with that mess when, 23 days after the theft, I received a call from the gym asking me to come get my stuff, which they had picked from a locker in a different locker room than mine 2 weeks earlier. I was so shocked that I failed to realize that they did not realize what had happened. They had cut the lock because users are not allowed to permanently let their stuff in a locker, and they had been waiting for 2 weeks for the owner to come claim his belongings. They did not realize it was not the owner of those personal items who had let them in that locker, which is why they did not feel compelled to contact me earlier.

When I claimed my stuff, I confirmed the attendant was right. Everything I had been stolen was there, except for my lock. Either that lock was cut by the stealer, or—much more likely—I had forgotten to lock it and the stealer used it to lock my effects in the locker where he left them. Everything else was there, including payment cards, gift cards, 170 CAD (which is more than I estimated I had been stolen), 2 controlled keys, and various other personal items worth a few hundred dollars.

I wish I could confirm I had forgotten to lock my locker, and I wish I could understand why. But I am a lot more curious about the stealer's behavior. Did his relatives ask him to bring back my possessions? Did he realize who he had stolen and decide the victim did not deserve this? Or did he simply change his mind fearing the consequences of getting caught?

Recovering my effects is far from having compensated the trouble of canceling and obtaining new cards, buying replacements, dealing with the risk of having a stealer with the keys of several buildings and possibly my address, temporarily bringing down my website, and more, but a lot of that could be blamed on my gym. The stealer involuntarily taught me a few important things about security, as well as how one's vision of his fellow citizens can easily be influenced by anecdotal events of one's history. For these lessons, for my goods of course, but also for your restitution's large restoration of my trust in mankind and my desire to work for it, I thank you, mysterious stealer.

I should use this opportunity to thank Vincent Amyot, who caught me trying to steal a pog when I was in sixth grade, and rightly warned other kids at school to stay away from me because I stole pogs (one by one!). And thanks to Guillaume Talbot, who caught me stealing his Internet account (in the good old time of dialup) and The Palace account (although he then remained my best friend for years). And thanks to the RFID tag I could not see which prevented me from stealing a magazine about Microsoft Windows from my college's library, an attempted theft which the free software zealot I was at that time considered ethical. You all made me realize I was not good enough to be a robber, and made me a bit less uncomfortable for having the privilege of being the victim of such a good stealer.

Mourrons donc, non?

admin Saturday February 13, 2016

C'est bien connu que notre vie dépend de nos organes.
C'est aussi bien connu que nos organes sont moins nécessaires après la mort.

Pourtant, à chaque fois que je reçois une carte d'assurance maladie, on me dit de déclarer mon consentement au don d'organes. Cet effort serait si nécessaire qu'on tente de me persuader à coup de marketing. « Signez don », dit le pamphlet. Je suis bien prêt à faire un effort pour le don de mes organes, mais pourquoi devrais-je soit…

  • Apposer un autocollant sur chaque nouvelle carte et le signer, tout en avisant mes proches de mon consentement
  • ou envoyer, par la poste, un formulaire de consentement

Si les beaux chiffres (comme les 8 vies potentiellement sauvées) que le gouvernement avance pour inciter au consentement sont vrais, la présomption de consentement n'aurait-elle pas autant plus d'intérêt?

Ce que je serais prêt à faire, c'est de demander la présomption de consentement. Mais la pétition 411 est fermée depuis des années. Le gouvernement y a même répondu, rejetant en prétextant que le consentement présumé dans d'autres pays a donné «un résultat mitigé». La réponse mentionne « la possibilité d'effets pervers, comme une perte de confiance du public dans le système de prélèvements », prétendant même que le consentement présumé « pourrait, à la limite, aggraver la pénurie d'organes ». Mais quelle confiance du public dans le système de prélèvements? Et comment le consentement présumé pourrait-il diminuer une telle confiance?

Je suis désolé si mon boycott vous condamne à la mort, mais en réalité, ce meurtre aura été commis par le gouvernement du Québec. Certainement pas par moi, car je serai mort.

Vous pourrez au moins vous conforter en pensant que vous ne serez privé que d'une vie dans une société encourageant l'égoïsme, et avec plus de considération pour ses cadavres que pour ses membres. L'altruisme est généralement plus coûteux que l'égoïsme. Mais sommes-nous condamnés à ce que l'altruisme soit toujours plus coûteux?

Je ne ferai pas de déclaration officielle de consentement tant qu'il me faudra le faire plusieurs fois ou par la poste, mais j'autorise par le présent paragraphe que mes organes soient donnés à ceux qui boycottent le don d'organes à refus présumé, à ceux qui ont consenti au don d'organes et aux mineurs. Sauf pour mon cerveau (que je réserve à notre gouvernement brain-dead, qui en a tant besoin d'un nouveau, même si le mien peut sembler sans cœur).

En espérant que ma foie dans ce boycott ne sera pas vaine et qu'il me permettra de voir le consentement présumé (tel qu'il existe en France) au Québec de mon vivant. Et pourquoi pas avant la baisse anticipée des opportunités de dons d'organes?

Mise à jour 2017-05-14 : Ma carte expire à nouveau. Aucun changement de situation, et toujours aucune action de ma part pour devenir complice de cet ignoble massacre. Nouvelle insulte : le formulaire qu'il faudrait remplir réfère au site de Transplant Québec avec une mauvaise adresse. Gros progrès!

Common lies

admin Monday February 8, 2016

We frequently lie. Some lies are very common. Here are the 3 most common lies on the Internet:

L'Actualité, March 2016, page 24 wrote:

1. LOL
2. Like
3. I Have Read and Agreed to the Above Terms and Conditions (and obviously agree to give up my first born)

LOL. OK, sorry… ha-ha. But when you think about it, what is a LOLler's biggest lie? That he is laughing a lot? Or that his digital life is so funny that he needed to create an acronym to communicate laughter to his online buddies? rolleyes

The above is so true that I repeated lie 3 while redacting this post. OK… in fact, I was only going to my website to write this post when I did so. I wanted to say I was redacting, but that's a small lie.

Issues using GNU/Linux as a "desktop" (PC)

admin Saturday February 6, 2016

I hit numerous issues when I moved my desktop from Microsoft Windows to GNU/Linux. When this started to feel like too many, I remember starting a document listing the main issues. Eventually, I hit many more issues, became familiar enough with the system to report some of them, and started reporting bugs, a process I am still far from having completed more than a decade later (thanks to our ability to produce new bugs being much more developed than our ability to reproduce our existing bugs). Therefore, I lacked the time needed to work on that list, and at some point, probably after having realized how huge that list would have to become, I gave up and must have deleted it.

Therefore, I was amused when I stumbled upon another list created by someone with the same objective last week. After going through that list, I guess I was right to give up on my list - it is a huge list of problems (and although I learned of that list because it received a 2016 update, it remains a huge list, despite the decade of progress since I started mine). In fact, I already knew there were millions of bugs and such a list could be as long and anecdotal as I wanted it to be, but overall, I find that Artem's long list does a good balance between listing overly specific issues and failing to list serious issues. Artem's list is highly imperfect - it is sometimes repetitive, at times unsubstantiated, and as he acknowledges himself, some issues are more disadvantages of GNU/Linux in comparison to other OS-en (in other words, it is a lot more than a list of bugs). There are many issues listed which I did not experience myself or even read about, and I am far from agreeing with every claim on that page. Some points just seem severe. Many issues affect software which is not used by most GNU/Linux users. That being said, I think that overall, that document gives someone considering to move their PC to GNU/Linux a good idea of what this involves.

One of the reasons why I gave up on my list is that determining whether an issue should make the list was hard. It depended not only on the issue's importance, but on the affected software's popularity. In any OS, virtually no software is used by everyone. But with GNU/Linux, that problem is made a lot worse by high fragmentation. And indeed, the very issue of fragmentation is part of the 9 general issues Artem listed is his summary. While some could point out that this is not an issue per se, it could instead be called a meta-issue, since fragmentation means extra complexity, more difficulty obtaining support for any specific GNU/Linux install and less developers available to work on each piece of software which has alternatives. Even though Artem's list has been updated, it is unfortunately hard to use it to estimate how fast issues are solved (which was probably my main goal), but it could be much faster without such fragmentation.

I have never suggested anyone to switch a PC to GNU/Linux. At best, I might have significantly influenced 4 people to make the switch. All of these are bachelors in computer science or computer engineering. At least 3 of these no longer use GNU/Linux as their primary OS. I do not regret having put my efforts into improving GNU/Linux rather than into directly recruiting new users. In fact, when reading Artem's list, it seems unreasonable for a system administrator to familiarize with GNU/Linux for the sole purpose of switching its own PC to GNU/Linux, unless that administrator intends to improve GNU/Linux... although as soon as I go back to Microsoft Windows for a day, I'm reminded that GNU/Linux is far from having a monopoly on problems.

While most of my contribution to Artem's list is probably the absence of even more items, I have contributed to some of the pages the list links to. But these contributions are a bit ironic:

  • One page is a KDE bug report which was closed by a KDE developer because it does not affect Wayland. My contribution there was to point out that the fact that KDE could be used without that bug did not mean that the bug was solved, since X.Org is still affected. The faulty developer did not reopen, and the ticket remains closed.
  • Image The other page linked I significantly contributed to is Wikipedia's article on Heartbleed, which I expanded, fully reviewed and maintained until it was assessed as a "good article". The very first Wikipedia article dedicated to an open source software bug. In a sense, Heartbleed was a great bug, as it highlighted how vulnerable free software can be, and was the trigger needed for the Core Infrastructure Initiative, the "new initiative" Artem mentions in his section "On a positive note". I like to think that the "Root causes, possible lessons, and reactions" section I created helped Jim Zemlin convince organizations to join the CII.

    I believe free software's success in the last decade has made its weaknesses obvious. Technically, free software is neither more or less secure than proprietary software. Each piece of software has its own security. But when I joined the free software movement, many claimed a piece of free software was generally more secure than a proprietary equivalent - for example, a GNU/Linux distribution would be safer than Microsoft Windows. Since then, history has disproved that myth, and Artem's article reflects that very well. Free software projects themselves did not necessarily improve. A decade after I filed Debian's ticket #339837, Debian has made some progress. http://security.debian.org no longer claims that Debian's average response time to security issues is under 48 hours, but still claims that "Debian takes security very seriously.", now without any supporting statistical claim. But as I write these lines, Debian's security bug tracker lists over 10 high-impact vulnerabilities (in the current Debian version) acknowledged by Debian itself, along tens of vulnerabilities still unrated.

    Some projects have performed more serious changes to actually improve their security. Following Heartbleed, OpenSSL has adopted a roadmap and a security policy. It created a blog, added members to its team, improved its performance reacting to reports of security issues, performed code cleanup, started a code audit, adopted a code review system and a code review policy.

    Unfortunately, others thought securing OpenSSL required forking. Therefore, in the wake of Heartbleed, a major fork appeared: LibreSSL (not to mention BoringSSL). As if OpenSSL and GnuTLS were not enough, we now have 3 equivalent libraries, and many lesser-known forks and equivalents. The very meta-issue Artem's Summary denounces in its fourth point.
    So while Heartbleed's long-term effect was great in a sense, in another sense, if lack of resources was the root cause of Heartbleed, it is not clear that a reaction which worsens fragmentation will be helpful. I will not claim that OpenSSL is not more secure than it was before Heartbleed, but in the long term, I doubt the reaction is very helpful for TLS library users.

A lot of my work on GNU/Linux was focused on the desktop. I am proud of the difference I made. Yet, I am not so proud of the result at this point. A lot has changed since I started working on GNU/Linux, and yet, much remains the same. Thankfully, one thing also remains unchanged: users of fully free software GNU/Linux distributions do not need to worry about vendor lock-in from their operating system.

Fully Free

Kune ni povos is seriously freethough not completely humor-free:

  • Free to read,
  • free to copy,
  • free to republish;
  • freely licensed.
  • Free from influenceOriginal content on Kune ni povos is created independently. KNP is entirely funded by its freethinker-in-chief and author, and does not receive any more funding from any corporation, government or think tank, or any other entity, whether private or public., advertisement-free
  • Calorie-free*But also recipe-free
  • Disinformation-free, stupidity-free
  • Bias-free, opinion-free*OK, feel free to disagree on the latter.
  • Powered by a free CMS...
  • ...running on a free OS...
  • ...hosted on a server sharedby a great friend for free