Brief items
Security
Security quotes of the week
I refused to order a third coffee maker for my smart home.
I made do with the Behmor, which makes incredible coffee but had a prickly relationship with Alexa. Each morning, my husband and I begged Alexa to put the coffee on. She would only react to a very specific phrasing of the request and then would only do so sometimes.
Kernel development
Kernel release status
The current development kernel is 4.16-rc1, released on February 11. Linus said: "I don't want to jinx anything, but things certainly look a lot better than with 4.15. We have no (known) nasty surprises pending, and there were no huge issues during the merge window. Fingers crossed that this stays fairly calm and sane."
Stable updates: 4.15.3, 4.14.19, and 4.9.81 were released on February 13.
Gettys: The Blind Men and the Elephant
Jim Gettys provides an extensive look at the FQ_CoDel queue-management algorithm as a big piece of the solution to bufferbloat problems. "Simple 'request/response' or time based protocols are preferentially scheduled relative to bulk data transport. This means that your VOIP packets, your TCP handshakes, cryptographic associations, your button press in your game, your DHCP or other basic network protocols all get preferential service without the complexity of extensive packet classification, even under very heavy load of other ongoing flows. Your phone call can work well despite large downloads or video use."
Wielaard: dtrace for linux; Oracle does the right thing
Mark Wielaard writes about the recently discovered relicensing of the dtrace dynamic tracing subsystem under the GPL. "Thank you Oracle for making everyone’s life easier by waving your magic relicensing wand! Now there is lots of hard work to do to actually properly integrate this. And I am sure there are a lot of technical hurdles when trying to get this upstreamed into the mainline kernel. But that is just hard work. Which we can now start collaborating on in earnest."
Quotes of the week
Distributions
Distribution quotes of the week
I suspect part of the problem is developers are already busy enough working on their own software and do not feel they have time to upload their packages to Debian. Perhaps there is not much motivation either. Developers make software for their distribution's users and probably do not see much benefit in spreading their work to other Debian-based projects. There may even be a sense of friendly competition between sibling projects which reduces the motivation to share packages.
Another hurdle to sharing packages though is, I think, the process involved in getting software into Debian's official repositories.
I, for one, would welcome a general AI for automating this. Skynet is worth it if we can get versioned dependencies right every time.
Development
Containers Will Not Fix Your Broken Culture (and Other Hard Truths) (ACMQueue)
In ACMQueue magazine, Bridget Kromhout writes about containers and why they are not the solution to every problem. The article is subtitled: "Complex socio-technical systems are hard; film at 11." "Don't get me wrong—containers are delightful! But let's be real: we're unlikely to solve the vast majority of problems in a given organization via the judicious application of kernel features. If you have contention between your ops team and your dev team(s)—and maybe they're all facing off with some ill-considered DevOps silo inexplicably stuck between them—then cgroups and namespaces won't have a prayer of solving that. Development teams love the idea of shipping their dependencies bundled with their apps, imagining limitless portability. Someone in security is weeping for the unpatched CVEs, but feature velocity is so desirable that security's pleas go unheard. Platform operators are happy (well, less surly) knowing they can upgrade the underlying infrastructure without affecting the dependencies for any applications, until they realize the heavyweight app containers shipping a full operating system aren't being maintained at all."
Tromey: JIT Compilation for Emacs
On his blog, Tom Tromey looks at just-in-time (JIT) compilation for Emacs and what he has done differently in his implementation from what was done in earlier efforts. He also looks at potential enhancements to his JIT: "Calling a function in Emacs Lisp is quite expensive. A call from the JIT requires marshalling the arguments into an array, then calling Ffuncall; which then might dispatch to a C function (a “subr”), the bytecode interpreter, or the ordinary interpreter. In some cases this may require allocation. This overhead applies to nearly every call — but the C implementation of Emacs is free to call various primitive functions directly, without using Ffuncall to indirect through some Lisp symbol. Now, these direct calls aren’t without a cost: they prevent the modification of some functions from Lisp. Sometimes this is a pain (it might be handy to hack on load from Lisp), but in many cases it is unimportant. So, one idea for the JIT is to keep a list of such functions and then emit direct calls rather than indirect ones."
Development quotes of the week
But when a developer produces code of their own choosing, they quickly find that while their code-writing skills have market value, their output (the code they write) has none.
Miscellaneous
Preining: In memoriam Staszek Wawrykiewicz
Norbert Preining reports the sad news that Staszek Wawrykiewicz has died. "Staszek was an active member of the Polish TeX community, and an incredibly valuable TeX Live Team member. His insistence and perseverance have saved TeX Live from many disasters and bugs. Although I have been in contact with Staszek over the TeX Live mailing lists since some years, I met him in person for the first time on my first ever BachoTeX, the EuroBachoTeX 2007. His friendliness, openness to all new things, his inquisitiveness, all took a great place in my heart." (Thanks to Paul Wise)
Page editor: Jake Edge
Next page:
Announcements>>