|
|
Subscribe / Log in / New account

Brief items

Security

Security quotes of the week

In fact, the introduction of "rich" email formats — in particular HTML email with its pretty fonts, animated icons, and wide array of extraneous adornments — can be reasonably viewed as the key "innovations" that led directly to the modern scourge of spam, phishing attacks, and a wide variety of other email-delivered criminal payloads that routinely ruin innumerable innocent lives.
Lauren Weinstein is not pleased that AMP support is being added to Gmail

Guri and his fellow Ben-Gurion researchers have shown, for instance, that it's possible to trick a fully offline computer into leaking data to another nearby device via the noise its internal fan generates, by changing air temperatures in patterns that the receiving computer can detect with thermal sensors, or even by blinking out a stream of information from a computer hard drive LED to the camera on a quadcopter drone hovering outside a nearby window. In new research published today, the Ben-Gurion team has even shown that they can pull data off a computer protected by not only an air gap, but also a Faraday cage designed to block all radio signals.
Andy Greenberg in Wired

Smart coffee was also a world of hell. The Brewgenie Smart Coffeemaker I ordered first was "smart" in that it had Bluetooth connectivity, so I could use its custom app on my phone to make it run a pot of coffee, but it wasn't compatible with Echo, so I couldn't say, "Alexa, make me coffee." To remedy this, I ordered the Behmor Connected Customizable Temperature Control Coffee Maker which promised Alexa compatibility. I came to regret this while setting up my Eight Sleep Tracker—a sensor layer that went over my mattress that could track sleep, warm the bed, and connect to "any wifi-enabled device in your house." Its instruction manual, along with dire warnings about possibly setting my bed on fire, informed me that it could automatically brew me coffee when it sensed I was waking up ... but only if I had a WeMo coffeemaker.

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.

Kashmir Hill in a cautionary "smart home" tale (worth reading in its entirety)

Comments (none posted)

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.

Comments (none posted)

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."

Comments (10 posted)

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."

Comments (42 posted)

Quotes of the week

Today I debugged an early ENOSPC problem without even adding a printk. The future feels weird.
Chris Mason

When I first started on freedreno, qcom support for upstream kernel was pretty dire (ie. I think serial console support might have worked on some ancient SoC). When I started, the only kernel that I could use to get the gpu running was old downstream msm android kernels (initially 2.6.35, and on later boards 3.4 and 3.10). [...] Linaro and qcom have been working quietly in the background to upstream all the various drivers that something like drm/msm depend on to work (clk, genpd, gpio, i2c, and other lower level platform support). This is awesome to see, and the linaro/qcom developers behind this progress deserve all the thanks. Without much fanfare, snapdragon has gone from a hopeless case (from upstream perspective) to one of the better supported platforms!
Rob Clark

Comments (none posted)

Distributions

Distribution quotes of the week

It is quite common for Debian-based distributions to feature their own tools and packages which do not exist in the official Debian repositories. It seems there is either a barrier or a lack of motivation for developers working on Debian-based projects to get their software included in Debian itself. Which is a shame, because Debian has a lot of children, over 100 active distributions at the time of writing. While all these children use the same package formats, libraries and package managers, they are often prevented from using software developed by their sibling projects.

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.

Jesse Smith

Given that part of our intended audience is geeks, and part of our intention is to attract fresh talent, I'd say it would be fully professional of us to fill a conference booth with cool and crazy, sci-fi / "Inspector Gadget" like Gentoo related stuff. (Has anyone ever tried installing Gentoo on a Dalek?)
Andreas K. Huettel

Automating all generation and updating of runtime and build time [dependencies] would be a good thing to have. Not an easy thing to achieve, of course.

I, for one, would welcome a general AI for automating this. Skynet is worth it if we can get versioned dependencies right every time.

Lars Wirzenius

Comments (none posted)

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."

Comments (16 posted)

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."

Comments (1 posted)

Development quotes of the week

It took 4 long years and to keep community momentum going we had to release even if we did say it would eat your babies.
Jonathan Riddell

When it comes to making money, software developers are an odd bunch. Developers produce code, and code is in high demand. At a glance, it seems obvious that this work pays for itself.

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.

Nadia Eghbal (Thanks to Paul Wise)

Comments (none posted)

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)

Comments (none posted)

Page editor: Jake Edge
Next page: Announcements>>


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds