Quotes of the week [LWN.net]

There _are_ things we can do though. Detect a write to the old file and emit a WARN_ON_ONCE("you suck"). Wait a year, turn it into WARN_ON("you really suck"). Wait a year, then remove it.

-- Feature deprecation Andrew Morton style

The post-Google standard company perks - free food, on-site exercise classes, company shuttles - make it trivial to speak only to fellow employees in daily life. If you spend all day with your co-workers, socialize only with your co-workers, and then come home and eat dinner with - you guessed it - your co-worker, you might go several years without hearing the words, "Run Solaris on my desktop? Are you f-ing kidding me?"

--- Valerie Aurora

Everybody takes it for granted to run megabytes of proprietary object code, without any memory protection, attached to an insecure public network (GSM). Who would do that with his PC on the Internet, without a packet filter, application level gateways and a constant flow of security updates of the software? Yet billions of people do that with their phones all the time.

-- Harald Welte

(Log in to post comments)

WOW! But... what's the point?

Posted Feb 18, 2010 9:46 UTC (Thu) by khim (subscriber, #9252) [Link]

The whole story about "megabytes of proprietary object code, without any memory protection, attached to an insecure public network" just makes me wonder: what this is all about? Do you want to become a global wireless provider or not? If not, then you'll be trusting megabytes of code running on "insecure public network" anyway, so much easier to treat all this GSM stuff in the same way human body treats the contents of it's digestive tract: as something you don't trust and don't own. Yes, it's inside of the device you've bought, but it's not part of that device! Rather it's part of GSM network and so can not be trusted fully. Most hardware treat it this way - by running it on it's own piece of silicon, no less!

WOW! But... what's the point?

Posted Feb 18, 2010 12:03 UTC (Thu) by Tobu (subscriber, #24111) [Link]

The base station side of GSM already is already supported by free-software with OpenBTS. Obviously the rest of the network is well covered with things like FreeRadius, LDAP, carrier grade linux

WOW! But... what's the point?

Posted Feb 18, 2010 19:52 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

quote:
Obviously the rest of the network is well covered with things like FreeRadius, LDAP, carrier grade linux

this is incorrect, Harold has been working hard (and publicly) in this area, and there are still a lot of things in the network that he does not have working yet. the list is getting smaller, but it's far from 'obviously well covered'

WOW! But... what's the point?

Posted Feb 18, 2010 20:49 UTC (Thu) by martinfick (subscriber, #4455) [Link]

The network is assumed hostile even when you connect with your PC, so we shouldn't care much what is running on the telco providers side. But, stuff that runs on your device, surely this should be a concern. And, just because sometimes it is on a different piece of silicon does not mean that it can't access the same memory as your application CPU and read all of your private data without you or even your operating system being aware of it!

It would be nice if the GSM stack on your phone could be considered untrustworthy the way a separate external modem could (encrypt your data before it even reachs the modem), but that is not enough when the modem can access your memory.

"... then remove it"

Posted Feb 18, 2010 19:39 UTC (Thu) by anton (guest, #25547) [Link]

Remove a feature after only two years of warnings? Great! Throw away your two-year old (infant) binaries! And I used counter claims of Linux binary incompatibility, but maybe I was wrong. Wait, for this kind of stuff just recompiling is not enough, you also have to change the source code. Even greater!

This week I was burned because the Debian 2.6.30-bpo.1-amd64 kernel follows the Linus kernel in making relatime the default. I did not find a way to fix that on Debian Lenny. Apparently one can do it with a mount option strictatime, but the mount coming with Debian Lenny rejected this mount option. And of course everybody else who uses a new kernel on an old userland is affected in the same way, too. Although I guess those who don't follow LWN would have even more trouble than I did to find out why the atime is wrong.

Maybe it's time to shop around for a new kernel.

"... then remove it"

Posted Feb 19, 2010 9:07 UTC (Fri) by iq-0 (subscriber, #36655) [Link]

You are falling over backwards compatibility in the kernel yet you come up with a problem in upwards compatibility in the utils. Perhaps supplying 'atime' would restore your wanted behavior?

But it will take some time before people finally realize that some parts of your system are very much related to your kernel while most parts aren't. Perhaps than we can move to a saner relation between kernel configuration interfaces and the supported set of tools. And then we can derive deprecation of interfaces to perhaps the toolset shipped with all major distribution releases that are current in the N-years before this kernel.

Non-configuration related interfaces should of course be set in stone, so I don't ever have to patch nethack :-)

"... then remove it"

Posted Feb 19, 2010 10:39 UTC (Fri) by nix (subscriber, #2304) [Link]

Unfortunately oom_adj is not a feature that only system admin tools tightly coupled to the kernel uses. *KDE* uses it, for godsakes: if oom_adj = -17 becomes 'just below midway', then people will find their KDE 3.5 systems (slightly old but still in wide use) suddenly imploding.

User desktop apps use this. It should stay, even if it *is* horrible (on which I think we are all agreed). At the very least -17 must retain its existing meaning: I doubt many non-sysadmin tools use the other values (as they don't have much useful meaning).

"... then remove it"

Posted Feb 19, 2010 17:50 UTC (Fri) by anton (guest, #25547) [Link]

You are falling over backwards compatibility in the kernel yet you come up with a problem in upwards compatibility in the utils.

I see it as a problem in backwards compatibility in the kernel. They are two sides of the same medal; however, it's much easer to be backwards compatible with existing software than to be forward compatible with unannounced changes in future software. How should mount have known that there would be a "strictatime" mount option?

Perhaps supplying 'atime' would restore your wanted behavior?

It doesn't:

smaug:~# grep /usr/local /proc/mounts
/dev/md3 /usr/local ext3 rw,relatime,errors=continue,barrier=1,data=ordered 0 0
smaug:~# mount -o remount,atime /usr/local
smaug:~# grep /usr/local /proc/mounts
/dev/md3 /usr/local ext3 rw,relatime,errors=continue,barrier=1,data=ordered 0 0

That's because the kernel people made relatime the default for atime, instead of the saner approach of making it another alternative to atime and noatime.

As for a saner way for dealing with changes in /proc, /sys etc., I have been thinking for some time that it would be a good idea if the kernel came with some userland libraries and/or tools that accesses this stuff and can therefore adapt to changes there. E.g., in the mount case maybe the kernel should come with a library that translates mount options; of course, that would not help for a statically linked mount, but it's better than the current situation where even a dynamically linked mount cannot do the new stuff.

In the old days, I used to be able to run a new kernel on a system that was several years old, without fear of breaking anything. Nowadays, there's always something in userland that needs to be adapted: udev, mount, the X server or things I probably don't even know about.

But then, if the kernel included some userland for this stuff, maybe the kernel people would do bad stuff like turning off proper atime handling even more readily than they do now.

"... then remove it"

Posted Feb 23, 2010 11:35 UTC (Tue) by nye (guest, #51576) [Link]

I don't recall the exact invocation, but I believe you can set strict atime as a filesystem option using tune2fs - though I don't see why anyone would want to.