Stuff I have written/presented
Submitted by gwolf on Wed, 11/26/2014 - 10:49
On November 14, as a great way to say goodbye to a semester, a good friend came to my class again to present a topic to the group; a good way to sum up the contents of this talk is "everything you ever wondered about persistent storage".
As people who follow my blog know, I like inviting my friends to present selected topics in my Operating Systems class. Many subjects will stick better if presented by more than a single viewpoint, and different experiences will surely enrich the group's learning.
So, here is Rolando Cedillo — A full gigabyte of him, spawning two hours (including two hiccups where my camera hit a per-file limit...).
Rolando is currently a RedHat Engineer, and in his long career, he has worked from so many trenches, it would be a crime not to have him! Of course, one day we should do a low-level hardware session with him, as his passion (and deep knowledge) for 8-bit arcades is beyond any other person I have met.
Submitted by gwolf on Tue, 11/25/2014 - 00:41
The line of BASIC code that appears as the subject for this post is the title for a book I just finished reading — And enjoyed thoroughly. The book is available online for download under a CC-BY-NC-SA 3.0 License, so you can take a good look at it before (or instead of) buying it. Although it's among the books I will enjoy having on my shelf; the printing is of a very enjoyable good quality.
And what is this book about? Well, of course, it analizes that very simple line of code, as it ran on the Commodore 64 thirty years ago.
And the analysis is made from every possible angle: What do mazes mean in culture? What have they meant in cultures through history? What about regularity in art (mainly 20th century art)? How would this code look (or how it would be adapted) on contemporary non-C64 computers? And in other languages more popular today? What does randomness mean? And what does random() mean? What is BASIC, and how it came to the C64? What is the C64, and where did it come from? And several other beautiful chapters.
The book was collaboratively written by ten different authors, in a Wiki-like fashion. And... Well, what else is there to say? I enjoyed so much reading through long chapters of my childhood, of what attracted me to computers, of my cultural traits and values... I really hope that, in due time, I can be a part of such a beautiful project!
Submitted by gwolf on Fri, 11/21/2014 - 13:29
Almost two months ago I posted our keyring status graphs, showing the progress of the transition to >=2048-bit keys for the different active Debian keyrings. So, here are the new figures.
First, the Non-uploading keyring: We were already 100% transitioned. You will only notice a numerical increase: That little bump at the right is our dear friend Tássia finally joining as a Debian Developer. Welcome! \o/
As for the Maintainers keyring: We can see a sharp increase in 4096-bit keys. Four 1024-bit DM keys were migrated to 4096R, but we did have eight new DMs coming in To them, also, welcome \o/.
Sadly, we had to remove a 1024-bit key, as Peter Miller sadly passed away. So, in a 234-key universe, 12 new 4096R keys is a large bump!
Finally, our current-greatest worry — If for nothing else, for the size of the beast: The active Debian Developers keyring. We currently have 983 keys in this keyring, so it takes considerably more effort to change it.
But we have managed to push it noticeably.
This last upload saw a great deal of movement. We received only one new DD (but hey — welcome nonetheless! \o/ ). 13 DD keys were retired; as one of the maintainers of the keyring, of course this makes me sad — but then again, in most cases it's rather an acknowledgement of fact: Those keys' holders often state they had long not been really involved in the project, and the decision to retire was in fact timely. But the greatest bulk of movement was the key replacements: A massive 62 1024D keys were replaced with stronger ones. And, yes, the graph changed quite abruptly:
We still have a bit over one month to go for our cutoff line, where we will retire all 1024D keys. It is important to say we will not retire the affected accounts, mark them as MIA, nor anything like that. If you are a DD and only have a 1024D key, you will still be a DD, but you will be technically unable to do work directly. You can still upload your packages or send announcements to regulated mailing lists via sponsor requests (although you will be unable to vote).
Speaking of votes: We have often said that we believe the bulk of the short keys belong to people not really active in the project anymore. Not all of them, sure, but a big proportion. We just had a big, controversial GR vote with one of the highest voter turnouts in Debian's history. I checked the GR's tally sheet, and the results are interesting: Please excuse my ugly bash, but I'm posting this so you can play with similar runs on different votes and points in time using the public keyring Git repository:
So, as of mid-October: 387 out of the 482 votes (80.3%) were cast by developers with >=2048-bit keys, and 95 (19.7%) were cast by short keys.
If we were to run the same vote with the new active keyring, 417 votes would have been cast with >=2048-bit keys (87.2%), and 61 with short keys (12.8%). We would have four less votes, as they retired:
So, lets hear it for November/December. How much can we push down that pesky yellow line?
Disclaimer: Any inaccuracy due to bugs in my code is completely my fault!
Submitted by gwolf on Sat, 11/08/2014 - 10:25
The following text is not mine. I'm copy-translating a text a dear friend of mine just wrote in Spanish, in Facebook. He writes far better than I do (much better than most people I have known). I am not also a great translator. If you can read Spanish, go read the original.
- Antonio Malpica. After what appears to be the bitter and sadly expected end of a sad, terrible, unbelievable collective social rupture we have lived for ~50 days.
And what comes next? How can it come? How can we expect it? I have no way to answer. We, the country's people, are broken.
Submitted by gwolf on Wed, 10/29/2014 - 15:47
Last Wednesday I had the pleasure and honor to have a great guest again at my class: José María Serralde, talking about real time scheduling. I like inviting different people to present interesting topics to my students a couple of times each semester, and I was very happy to have Chema come again.
Chema is a professional musician (formally, a pianist, although he has far more skills than what a title would confer to him — Skills that go way beyond just music), and he had to learn the details on scheduling due to errors that appear when recording and performing.
The audio could use some cleaning, and my main camera (the only one that lasted for the whole duration) was by a long shot not professional grade, but the video works and is IMO quite interesting and well explained.
Submitted by gwolf on Thu, 10/23/2014 - 13:05
Petter posted yesterday about Listadmin, the quick way to moderate mailman lists.
I am a fan of automatization. But, yes, I had never thouguht of doing this. Why? Don't know. But this is way easier than using the Web interface for Mailman:
$ listadmin fetching data for firstname.lastname@example.org ... nothing in queue fetching data for email@example.com ... nothing in queue fetching data for firstname.lastname@example.org ... nothing in queue fetching data for email@example.com ... nothing in queue fetching data for firstname.lastname@example.org ... [1/1] ============== email@example.com ====== From: firstname.lastname@example.org Subject: Invitación al Taller Insumo Producto Reason: El cuerpo del mensaje es demasiado grande: 777499 Spam? 0 Approve/Reject/Discard/Skip/view Body/Full/jump #/Undo/Help/Quit ? a Submit changes? [yes] fetching data for email@example.com ... nothing in queue fetching data for firstname.lastname@example.org ... nothing in queue fetching data for email@example.com ... nothing in queue fetching data for firstname.lastname@example.org ... nothing in queue fetching data for email@example.com ... nothing in queue fetching data for firstname.lastname@example.org ... nothing in queue fetching data for email@example.com ... nothing in queue fetching data for firstname.lastname@example.org ... nothing in queue fetching data for email@example.com ... nothing in queue fetching data for firstname.lastname@example.org ... nothing in queue fetching data for email@example.com ... nothing in queue
I don't know how in many years of managing several mailing lists I never thought about this! I'm echoing this, as I know several of my readers run mailman as well, and might not be following Planet Debian.
Submitted by gwolf on Fri, 10/17/2014 - 11:24
Two days ago, Drupal announced version 7.32 was available. This version fixes a particularly nasty bug, allowing a SQL injection at any stage of interaction (that means, previous to the authentication taking place).
As soon as I could, I prepared and uploaded Debian packages for this — So if you run a Debian-provided Drupal installation, update now. The updated versions are:
And, as expected, I'm already getting several attacks on my sites. Good thing that will help you anyway: Even though it won't prevent the attack from happening, if you use suhosin, several of the attacks will be prevented. Yes, sadly suhosin has not been in a stable Debian release since Wheezy, but still... :-|
Partial logs. This looks like a shellcode being injected as a file created via the menu_router mechanism (shellcode snipped):
While the previous one is clearly targetting this particular bug, I'm not sure about this next one: It is just checking for some injection viability before telling me its real intentions:
So... looking at my logs from the last two days, Suhosin has not let any such attack reach Drupal (or I have been h4x0red and the logs have all been cleaned — Cannot dismiss that possibility :-) )
Anyway... We shall see many such attempts in the next weeks :-|
[update] Yes, I'm not the only one reporting this attack in the wild. Zion Security explains the same attempt I logged: It attempts to inject PHP code so it can be easily executed remotely (and game over for the admin!)
For the more curious, Tamer Zoubi explains the nature and exploitation of this bug.
Submitted by gwolf on Tue, 10/14/2014 - 11:58
Two causally unrelated events which fit in together in the greater scheme of things ;-)
In some areas, the world is better aligning to what we have been seeking for many years. In some, of course, it is not.
In this case, today I found our article on the Network of Digital Repositories for our University, in the Revista Digital Universitaria [en línea] was published. We were invited to prepare an article on this topic because this month's magazine would be devoted to Open Access in Mexico and Latin America — This, because a law was recently passed that makes conditions much more interesting for the nonrestricted publication of academic research. Of course, there is still a long way to go, but this clearly is a step in the right direction.
On the other hand, after a long time of not looking in that direction (even though it's a lovely magazine), I found that this edition of FirstMonday takes as its main topic Napster, 15 years on: Rethinking digital music distribution.
I know that nonrestricted academic publishing via open access and nonauthorized music sharing via Napster are two very different topics. However, there is a continuous push and trend towards considering and accepting open licensing terms, and they are both points in the same struggle. An interesting data point to add is that, although many different free licenses have existed over time, Creative Commons (which gave a lot of visibility and made the discussion within the reach of many content creators) was created in 2001 — 13 years ago today, two years after Napster. And, yes, there are no absolute coincidences.
Submitted by gwolf on Fri, 10/03/2014 - 13:58
Back in 2009, I set up githubredir.debian.net, a service that allowed following using uscan the tags of a GitHub-based project.
Maybe a year or two later, GitHub added the needed bits in their interface, so it was no longer necessary to provide this service. Still, I kept it alive in order not to break things.
But as it is just a silly web scraper, every time something changes in GitHub, the redirector breaks. I decided today that, as it is no longer a very useful project, it should be retired.
So, in the not too distant future (I guess, next time anything breaks), I will remove it. Meanwhile, every page generated will display this:
(of course, with the corresponding project/author names in)
Consider yourselves informed.
Submitted by gwolf on Tue, 09/30/2014 - 09:01
I got word via the Electronic Frontier Foundation about an act of injustice happening to a person for doing... Not only what I do day to day, but what I promote and believe to be right: Sharing academic articles.
Diego is a Colombian, working towards his Masters degree on conservation and biodiversity in Costa Rica. He is now facing up to eight years imprisonment for... Sharing a scholarly article he did not author on Scribd.
Many people lack the knowledge and skills to properly set up a venue to share their articles with people they know. Many people will hope for the best and expect academic publishers to be fundamentally good, not to send legal threats just for the simple, noncommercial act of sharing knowledge. Sharing knowledge is fundamental for science to grow, for knowledge to rise. Besides, most scholarly studies are funded by public money, and as the saying goes, they should benefit the public. And the public is everybody, is all of us.
And yes, if this sounds in any way like what drove Aaron Swartz to his sad suicide early this year... It is exactly the same thing. Thankfully (although, sadly, after the sad fact), thousands of people strongly stood on Aaron's side on that demand. Please sign the EFF petition to help Diego, share this, and try to spread the word on the real world needs for Open Access mandates for academics!
Some links with further information:
Submitted by gwolf on Thu, 09/25/2014 - 11:37
I am among the lucky people who got back home from DebConf with a brand new computer: a Banana Pi. Despite the name similarity, it is not affiliated with the very well known Raspberry Pi, although it is a very comparable (although much better) machine: A dual-core ARM A7 system with 1GB RAM, several more on-board connectors, and same form-factor.
I have not yet been able to get it to boot, even from the images distributed on their site (although I cannot complain, I have not devoted more than a hour or so to the process!), but I do have a gripe on how the images are distributed.
I downloaded some images to play with: Bananian, Raspbian, a Scratch distribution, and Lubuntu. I know I have a long way to learn in order to contribute to Debian's ARM port, but if I can learn by doing... ☻
So, what is my gripe? That the three images are downloaded as archive files:
Now... that is quite an odd way to distribute image files! Specially when looking at their contents:
And what is bad about them? That they force me to either have heaps of disk space available (2GB or 4GB for each image) or to spend valuable time extracting before recording the image each time.
Why not just compressing the image file without archiving it? That is,
Now, wouldn't we need to decompress said files as well? Yes, but thanks to the magic of shell redirections, we can just do it on the fly. That is, instead of having 3×4GB+1×2GB files sitting on my hard drive, I just need to have several files ranging between 145M and I guess ~1GB. Then, it's as easy as doing:
And the result should be the same: A fresh new card with Bananian ready to fly. Right, right, people using these files need to have xz installed on their systems, but... As it stands now, I can suppose current prospective users of a Banana Pi won't fret about facing a standard Unix tool!
(Yes, I'll forward this rant to the Banana people, it's not just bashing on my blog :-P )
[update] Several people (thanks!) have contacted me stating that I use a bashism: The <(…) construct is specific to Bash. If you want to do this with any other shell, it can be done with a simple pipe:
That allows for less piping to be done on the kernel, and is portable between different shells. Also, a possibility would be:
Although that might not be desirable, as it avoids the block-by-block nature of dd. I'm not sure if it makes a realdifference, but it's worth saying :)
And yes, some alternatives for not unarchiving the file — Here in the blog, an anon commenter suggests (respectively, for zip and .tar.gz files):
And a commenter by IRC suggests:
Submitted by gwolf on Tue, 09/23/2014 - 13:23
I am tired of finding how to get my users to happily print again. Please help.
Several years ago, I configured our Institute's server to provide easy, nifty printing support for all of our users. Using Samba+CUPS, I automatically provided drivers to Windows client machines, integration with our network user scheme (allowing for groups authorization — That means, you can only print in your designated printer), flexible printer management (i.e. I can change printers on the server side without the users even noticing — Great when we get new hardware or printers get sent to repairs!)...
Then, this year the people in charge of client machines in the institute decided to finally ditch WinXP licenses and migrate to Windows 7. Sweet! How can it hurt?
Oh, it can hurt. Terribly.
Windows 7 uses a different driver model, and after quite a bit of hair loss, I was not able to convince Samba to deliver drivers to Win7 (FWIW, I think we are mostly using 64 bit versions). Not only that, it also barfs when we try to install drivers manually and print to a share. And of course, it barfs in the least useful way, so it took me quite a bit of debugging and Web reading to find out it was not only my fault.
So, many people have told me that Samba (or rather, Windows-type networking) is no longer regarded as a good idea for printing. The future is here, and it's called IPP. And it is simpler, because Windows can talk directly with CUPS! Not only that, CUPS allows me to set valid users+groups to each printer. So, what's there to lose?
Besides time, that is. It took me some more hair pulling to find out that Windows 7 is shipped by default (at least in the version I'm using) with the Internet Printing Server feature disabled. Duh. OK, enable it, and... Ta-da! It works with CUPS! Joy, happiness!
Only that... It works only when I use it with no authentication.
Windows has an open issue, with its corresponding hotfix even, because Win7 and 2008 fail to provide user credentials to print servers...
So, yes, I can provide site-wide printing capabilities, but I still cannot provide per-user or per-group authorization and accounting, which are needed here.
I cannot believe this issue cannot be solved under Windows 7, several years after it hit the market. Or am I just too blunt and cannot find an obvious solution?
Dear lazyweb, I did my homework. Please help me!
Submitted by gwolf on Mon, 09/22/2014 - 13:13
OK, it's almost one month since we (the keyring-maintainers) gave our talk at DebConf14; how are we faring regarding key transitions since then? You can compare the numbers (the graphs, really) to those in our DC14 presentation.
Since the presentation, we have had two keyring pushes:
First of all, the Non-uploading keyring is all fine: As it was quite recently created, and as it is much smaller than our other keyrings, it has no weak (1024 bit) keys. It briefly had one in 2010-2011, but it's long been replaced.
Second, the Maintainers keyring: In late July we had 222 maintainers (170 with >=2048 bit keys, 52 with weak keys). By the end of August we had 221: 172 and 49 respectively, and by September 18 we had 221: 175 and 46.
As for the Uploading developers, in late July we had 1002 uploading developers (481 with >=2048 bit keys, 521 with weak keys). By the end of August we had 1002: 512 and 490 respectively, and by September 18 we had 999: 531 and 468.
Please note that these numbers do not say directly that six DMs or that 50 uploading DDs moved to stronger keys, as you'd have to factor in new people being added, keys migrating between different keyrings (mostly DM⇒DD), and people retiring from the project; you can get the detailed information looking at the public copy of our Git repository, particularly of its changelog.
And where does that put us?
Of course, I'm very happy to see that the lines in our largest keyring have already crossed. We now have more people with >=2048 bit keys. And there was a lot of work to do this processing done! But that still means... That in order not to lock a large proportion of Debian Developers and Maintainers out of the project, we have a real lot of work to do. We would like to keep the replacement slope high (because, remember, in January 1st we will remove all small keys from the keyring).
And yes, we are willing to do the work. But we need you to push us for it: We need you to get a new key created, to gather enough (two!) DD signatures in it, and to request a key replacement via RT.
So, by all means: Do keep us busy!
Submitted by gwolf on Thu, 08/28/2014 - 10:04
I love to see there is a lot of crypto discussions going on at DebConf. Maybe I'm skewed by my role as keyring-maint, but I have been involved in more than one discussion every day on what do/should signatures mean, on best key handling practices, on some ideas to make key maintenance better, on how the OpenPGPv4 format lays out a key and its components on disk, all that. I enjoy some of those discussions pose questions that leave me thinking, as I am quite far from having all answers.
Discussions should be had face to face, but some start online and deserve to be answered online (and also pose opportunity to become documentation). Simon Josefsson blogs about The case for short OpenPGP key validity periods. This will be an important issue to tackle, as we will soon require keys in the Debian keyring to have a set expiration date (surprise surprise!) and I agree with Simon, setting an expiration date far in the future means very little.
There is a caveat with using, as he suggests, very short expiry periods: We have a human factor sitting in the middle. Keyring updates in Debian are done approximately once a month, and I do not see the period shortening. That means, only once a month we (currently Jonathan McDowell and myself, and we expect to add Daniel Kahn Gillmor soon) take the full changeset and compile a new keyring that replaces the active one in Debian.
This means that if you have, as Simon suggests, a 100-day validity key, you have to remember to update it at least every 70 days, or you might be locked out during the days it takes us to process it.
I set my expiration period to two years, although I might shorten it to only one. I expect to add checks+notifications before we enable this requirement project-wide (so that Debian servers will mail you when your key is close to expiry); I think that mail can be sent at approximately [expiry date - 90 days] to give you time both to you and to us to act. Probably the optimal expiration periods under such conditions would be between 180 and 365 days.
But, yes, this is by far not yet a ruling, but a point in the discussion. We still have some days of DebConf, and I'll enjoy revising this point. And Simon, even if we correct some bits for these details, I'd like to have your permission to use this fine blog post as part of our documentation!
(And on completely unrelated news: Congratulations to our dear and very much missed friend Bubulle for completely losing his sanity and running for 28 hours and a half straight! He briefly describes this adventure when it was about to start, and we all want him to tell us how it was. Mr. Running French Guy, you are amazing!)
Submitted by gwolf on Tue, 08/19/2014 - 23:10
Summer is cool in Mexico City.
It is cool because, unlike Spring, this is our rainy season — And rains are very predictable. Almost every day we wake up with a gorgeous, clean, blue sky.
Cool, nice temperature, around 15°C. The sun slowly evaporates the rain throughout the morning; when I go out for lunch, the sky is no longer so blue, giving way to a seemingly dirty white/grayish tint. No, it's not our world-famous pollution: It's just yesterday's rain.
Rain starts falling usually between 4 and 7 PM. Sometimes it starts as a light rain, sometimes it starts with all of its thunder, all of its might. But anyway, almost every night, there is a moment of awe, of not believing how much rain we are getting today.
It slowly fades away during the late night. And when I wake up, early next morning, everything is wet and still smells fresh.
Yes, I love our summer, even though it makes shy away from my much enjoyed cycling to work and school. And I love taking some minutes off work, look through the window of my office (located ~70m over the level of our mostly flat city) and watching how different parts of the city have sun or rain; learning to estimate the distance to the clouds, adding it to the direction and guessing which of my friends have which weather.
But I didn't realize our city had so clearly defined micro-climates... (would they really be *micro*-climates?) In fact, it even goes against my knowledge of Mexico City's logic — I always thought Coyoacán, towards the South of the city, got more rain than the Center and North because we are near the mountains, and the dominant air currents go Southwards, "clumping" the clouds by us.
But no, or at least, not this year. Regina (still in the far South — Far because she's too far away from me and I'm too egocentric; she returns home after DebConf) often asks me about the weather, as our friends working nearer the center of the city. According to the photos they post on their $social_media_of_the_day accounts, rains are really heavier there.
Today I heard on the radio accounts of yesterday's chaos after the rain. This evening, at ESIME-Culhuacán, I saw one of the reported fallen trees (of course, I am not sure if it's from yesterday's rain). And the media pushes galleries of images of a city covered in hail... While in Copilco we only had a regular rain, I'd even say a mild one.
This city is bigger than any cloud you can throw at it.
Talks, papers and documents by category
Blog posts by category