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.
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.
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:
- sid / jessie (unstable / testing)
- wheezy (stable)
- squeeze-backports (oldstable)
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):
- Oct 16 15:22:21 lafa suhosin: ALERT - configured request variable
- total name length limit exceeded - dropped variable 'name[0; INSERT INTO
- `menu_router` (`path`, `load_functions`, `to_arg_functions`, `description`,
- `access_callback`, `access_arguments`) VALUES ('deheky', '', '', 'deheky',
- );;# ]' (attacker '126.96.36.199', file '/usr/share/drupal7/index.php')
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:
- Oct 17 10:26:04 lafa suhosin: ALERT - configured request variable
- name length limit exceeded - dropped variable
- (attacker '188.8.131.52', file '/usr/share/drupal7/index.php')
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.
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.
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.
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:
- Diego's own account on the matter in Compartir no es delito
- Why are we prosecuting students for sharing knowledge? (Timothy Vollmer, on Creative Commons' weblog)
- Science is not a crime (David R. Koepsell, Center for Inquiry)
- Fuller story on the EFF
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:
- 0 gwolf@mosca『9』~/Download/banana$ ls -hl bananian-latest.zip \
- > Lubuntu_For_BananaPi_v3.1.1.tgz Raspbian_For_BananaPi_v3.1.tgz \
- > Scratch_For_BananaPi_v1.0.tgz
- -rw-r--r-- 1 gwolf gwolf 222M Sep 25 09:52 bananian-latest.zip
- -rw-r--r-- 1 gwolf gwolf 823M Sep 25 10:02 Lubuntu_For_BananaPi_v3.1.1.tgz
- -rw-r--r-- 1 gwolf gwolf 1.3G Sep 25 10:01 Raspbian_For_BananaPi_v3.1.tgz
- -rw-r--r-- 1 gwolf gwolf 1.2G Sep 25 10:05 Scratch_For_BananaPi_v1.0.tgz
Now... that is quite an odd way to distribute image files! Specially when looking at their contents:
- 0 gwolf@mosca『14』~/Download/banana$ unzip -l bananian-latest.zip
- Archive: bananian-latest.zip
- Length Date Time Name
- --------- ---------- ----- ----
- 2032664576 2014-09-17 15:29 bananian-1409.img
- --------- -------
- 2032664576 1 file
- 0 gwolf@mosca『15』~/Download/banana$ for i in Lubuntu_For_BananaPi_v3.1.1.tgz \
- > Raspbian_For_BananaPi_v3.1.tgz Scratch_For_BananaPi_v1.0.tgz
- > do tar tzvf $i; done
- -rw-rw-r-- bananapi/bananapi 3670016000 2014-08-06 03:45 Lubuntu_1404_For_BananaPi_v3_1_1.img
- -rwxrwxr-x bananapi/bananapi 3670016000 2014-08-08 04:30 Raspbian_For_BananaPi_v3_1.img
- -rw------- bananapi/bananapi 3980394496 2014-05-27 01:54 Scratch_For_BananaPi_v1_0.img
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,
- 0 gwolf@mosca『7』~/Download/banana$ tar xzf Lubuntu_For_BananaPi_v3.1.1.tgz
- 0 gwolf@mosca『8』~/Download/banana$ xz Lubuntu_1404_For_BananaPi_v3_1_1.img
- 0 gwolf@mosca『9』~/Download/banana$ ls -hl Lubun*
- -rw-r--r-- 1 gwolf gwolf 606M Aug 6 03:45 Lubuntu_1404_For_BananaPi_v3_1_1.img.xz
- -rw-r--r-- 1 gwolf gwolf 823M Sep 25 10:02 Lubuntu_For_BananaPi_v3.1.1.tgz
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:
- 0 gwolf@mosca『8』~/Download/banana$ dd if=<(xzcat bananian-1409.img.xz) of=/dev/sdd
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:
- $ xzcat bananian-1409.img.xz | dd of=/dev/sdd
That allows for less piping to be done on the kernel, and is portable between different shells. Also, a possibility would be:
- $ xzcat bananian-1409.img.xz > /dev/sdd
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):
- $ dd if=<(unzip -p bananian-latest.zip) of=/dev/sdd
- $ dd if=<(tar -xOf Lubuntu_For_BananaPi_v3.1.1.tgz) of=/dev/sdd
And a commenter by IRC suggests:
- $ paxtar -xOaf Raspbian_For_BananaPi_v3.1.tgz Raspbian_For_BananaPi_v3_1.img | sudo dd bs=262144 of=/dev/…
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!
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!
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!)
I still consider myself a newbie teacher. I'm just starting my fourth semester. And yes, I really enjoy it.
Now, how did I come to teaching? Well, my training has been mostly on stages for different conferences. More technical, more social, whatever — I have been giving ~10 talks a year for ~15 years, and I must have learnt something from that.
Some good things, some bad habits.
When giving presentations, a most usual technique is to prepare a set of slides to follow/support the ideas. And yes, that's what I did for my classes: Since my first semester, I prepared a nice set of slides, thematically split in 17 files, with ~30 to ~110 pages each (yes, huge variation). Given the course spans 32 classes (72 hours, 2¼ hours per class), each slide lasts for about two classes.
But, yes, this tends to make the class much less dynamic, much more scripted, rigid, and... Boring. From my feedback, I understand the students don't think I am a bad teacher, but still, I want to improve!
So, today I was to give the introduction to memory management. Easy topic, with few diagrams and numbers, mostly talking about the intuitive parts of a set of functions. I started scribbling and shortening the main points on a piece of paper (yes, the one on the picture). I am sure I can get down to more reduction — But this does feel like an improvement!
The class was quite successful. I didn't present the 100% of the material (which is one of the reasons I cling to my presentations — I don't want to skip important material), and at some point I do feel I was a bit going in circles. However, Operating Systems is a very intuitive subject, and getting the students to sketch by themselves the answers that describe the working of real operating systems was a very pleasant experience!
Of course, when I use my slides I do try to make it as interactive and collaborative as possible. But it is often unfeasible when I'm following a script. Today I was able to go around with the group's questions, find my way back to the outline I prepared.
I don't think I'll completely abandon my slides, specially for some subjects which include many diagrams or pictures. But I'll try to have this alternative closer to my mind.
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.
Yes, I've been bragging about the Operating Systems book all over... Today, a colleague handed me a phone call from somebody at Editorial Patria, a well known educational editorial in Mexico. They are looking for material similar to what I wrote, but need the material to be enfocado a competencias — Focused on skills, a pedagogic fashion.
I was more than interested, of course. As it currently stands, I am very happy that our book is being used already at three universities in three countries (by the different authors) and have heard other people saying they would recommend it, and of course I'm interested in making our work have as big an impact as possible. Of course, we'd have to modify several aspects of the book to cater to the skills focus... But it would be great to have the book available at commercial bookstores. After all, university editions are never as widely circulated as commercial ones.
I had just one hard request to accept this: Our work must be distributed under a free licensing. Explicitly allow book photocopies and electronic distribution (didn't get into the "and modification" part, but I would eventually get there ;-) )
And... Of course, the negotiation immediately fell down. Editorials, this person says, live from selling individual books. She says she was turned down by another university professor and for another subject this same week.
So, yes, I took the opportunity to explain things as I (and the people that think as I do — Fortunately, not so few) see them. Yes, of course, editorials have to make a living. But text books are often photocopied as it is. Who buys a book? Whoever needs it. On one hand, if somebody will be using a book throughout a semester and it's reasonably priced (say, up to 3×cost of photocopies), they will probably buy it because it just works better (it is more comfortable to use and nicer to read).
If a teacher likes the explanation for a particular topic, it should be completely legal for him to distribute photocopies (or digital copies) of the specific material — And quite probably, among the students, more than one will end up appreciating the material enough to go look for the book in the library. And, as I have done throughout my life, if I read (in copies, electronically or in a library) a book I like... Quite probably I will go buy it.
So... Of course, she insisted it was against their corporate policy. I insisted on my explanation. I hope they meet many stubborn teachers refusing to distribute books under a non-free licensing. I hope I contributed to making a dent in an industry that must change. Yes, a very very small dent, but one that helps them break free from their obsolete mindset ;-)
(But yes, I don't know how long I will regret not being part of their very nice catalog of science and engineering books) ;-) )
Today I finally submitted our book, Fundamentos de Sistemas Operativos, for the Editorial Department of our institute. Of course, I'm not naïve enough to assume there won't be a heavy editorial phase, but I'm more than eager to dive into it... And have the book printed in maybe two months time!
Of course, this book is to be published under a free license (CC-BY-SA). And I'm talking with the coauthors, we are about to push the Git repository to a public location, as we believe the source for the text and figures can also be of interest to others.
The book itself (as I've already boasted about here :-} ) is available (somewhat as a preprint) for download.
[update] Talked it over with the coauthors, and we finally have a public repository! Clone it from:
A long time ago, I did some (quite minor!) work on natural language parsing. Most of what I got was the very basic rudiments on what needs to be done to begin with. But I like reading some texts on the subject every now and then.
I am also a member of the ACM — Association for Computing Machinery. Most of you will be familiar with it, it's one of the main scholarly associations for the field of computing. One of the basic perks of being an ACM member is the subscription to a very nice magazine, Communications of the ACM. And, of course, although I enjoy the physical magazine, I like reading some columns and articles as they appear along the month using the RSS feeds. They also often contain pointers to interesting reads on other media — As happened today. I found quite a nice article, I think, worth sharing with whoever thinks I have interesting things to say.
They published a very short blurb titled The Fasinatng … Frustrating … Fascinating History of Autocorrect. I was somewhat skeptical reading it links to an identically named article, published in Wired. But gave it a shot, anyway...
The article follows a style that's often abused and not very amusing, but I think was quite well done: The commented interview. Rather than just drily following through an interview, the writer tells us a story about that interview. And this is the story of Gideon Lewis-Kraus interviewing Dean Hachamovitch, the creator of the much hated (but very much needed) autocorrect feature that appeared originally in Microsoft Word.
The story of Hachamovitch's work (and its derivations, to the much maligned phone input predictors) over the last twenty-something years is very light to read, very easy to enjoy. I hope you find it as interesting as I did.