On 2013-07-03 12:01, Brian May wrote: [...]

I can't think why Facebook would really need all of these. DRAW OVER OTHER APPS looks a little bit scary.

I've seen the Facebook Android App recently started popping up "bubbles" containing a Friend's photo when that Friend tries to chat with you etc., and that overlays other apps and the home screen. I assume that's the rationale behind that one, but there's nothing to say that's the only purpose

These might be required for the app, however do make me nervous:

READ YOUR CONTACTS MODIFY YOUR CONTACTS

Me too. Just another reason I disabled my Facebook Account. This is so Facebook can "offer" to search for your contacts on Facebook, and, presumably, update contact entries with information found about those contacts via Facebook. I'd much prefer to be prompted *when* this access is requested. -- Regards, Matthew Cengia

Quoting Brian May (brian@microcomaustralia.com.au):

Some things look like they might be needed to support features. e.g. GPS for geo-tagging, network access, make phone calls, USB storage (this one is a can of worms), take photos, record audio. Creating accounts is fine too I think.

Apps need to declare all permissions that they might require, even if you never plan to use that feature. Obviously once an app has declared it requires a permission there is nothing stopping it from using that permission maliciously or to breach your privacy.

There there is "READ PHONE STATUS AND IDENTITY" which is often used for advertising. Has a bad reputation, although alternative solutions which don't require this permission may be even worse for privacy (or so I have read).

When I finally get around to seriously investigating CyanogenMod on smartphones, I'll first check whether they adopted the idea -- that I heard was making the rounds -- of enabling the user to promise Android apps all the rights they ask for but then selectively prune those rights any time after installation. According to my understanding, on standard Android, the app's installer asks 'Here's a bunch of permissions this app will need. Are you OK with that y/n?' If you say no, installer exits. No ability to say 'Sure, the app may have everything it asks except READ PHONE STATUS AND IDENTITY, and just go ahead and install it without that one right.' Ah, above was written just before I read...

Older versions of cyanogenmod supported disabling permissions so you can restrict what it can do if you don't like the requested permissions. Not in recent versions unfortunately. There might be alternative apps in the market to do this, haven't checked in ages.

Spineless developers {sigh}. This isn't the first time the CyanogenMod developers have shied away from greater user control. http://review.cyanogenmod.com/#change,5677

Brian May <brian@microcomaustralia.com.au> wrote:

To be fair, it is a weakness in the Android permission model.

Basically the app says "I want this privilege and I expect it to be available." meaning app might crash or do weird things if privilege is not available.

Instead it should be "Please can I have this permission?" and Android can say "Yes" or "No" depending on the user's preference, and app has to handle the result in a graceful way (yes, this could mean throwing up an error message and refusing to run).

Yes, exactly. Probably the closest analogue in (non-Android) Linux installations is PolicyKit under Gnome, and I'm not sure how that works in this regard.

On Wed, Jul 03, 2013 at 01:23:23PM +1000, Brian May wrote:

On 3 July 2013 12:38, Rick Moen <rick@linuxmafia.com> wrote:

...

...

Older versions of cyanogenmod supported disabling permissions so you can restrict what it can do if you don't like the requested permissions. Not in recent versions unfortunately. There might be alternative apps in the market to do this, haven't checked in ages.

Spineless developers {sigh}. This isn't the first time the CyanogenMod

Steve Kondik (aka Cyanogen) has committed Privacy Guard to recent CyanogenMod nightlys. AFAICT the idea of Privacy Guard is to protect against all sorts of promiscuous apps (facebook, g+, games etc.), but in a much simpler to use way than cm7's fine grained model. as a data point, I ran cm7 for a year or two and never used the fine grained permissions. frankly it's a lot of work to understand exactly what all the permissions mean, and to test every app to see what breaks with what combos of revoked permissions. the idea with Privacy Guard is to return null sets (of contacts, call logs, etc.) or coarse data (eg. location) rather than to deny them outright, which can easy break apps and make them crash. the theory is that by doing this it should be plausible to have Privacy Guard on by default most of the time for most people and most apps. ie. it might be something people actually use, and so should be far more effective overall than the cm7 model. in other CyanogenMod news (and again perhaps inspired by recent NSA and Edward Snowden events) Koush is working with Moxie Marlinspike (of RedPhone and TextSecure and (ex-?)whispersystems fame) to bring end-to-end encrypted sms to CyanogenMod as well as other platforms. again, with easy to use & integrated being key design elements. http://www.cyanogenmod.org/blog I've built and run Privacy Guard in my CyanogenMod based ZTE v9 roms and it seems to work (ie. the little shield icon pops up :-) but IMHO it's a few weeks away from being stable enough for me to ship to my users yet. personally I think the CM folks are on roughly the right track and deserve praise for trying to build something folks will use and that will protect them, rather than scorn for not re-implementing all the rarely used bits of cm7. if you really want to go full tin foil hat then I expect the patches are out there to fake IMEI and everything else (or just write them yourself) and it's up to you to do the build for your phone. or simpler, just don't install the facebook app!

To be fair, it is a weakness in the Android permission model.

hmm. personally I think it's just a complex problem (mostly of user education) and no solution is perfect. does any other system handle this in a simpler and clearer and more manageable manner - selinux? unix groups? acls? I don't think so. firefox os was pretty naive about app permissions last time I checked. no idea about apple, ububtu phone os, tizen, or 'doze phone.

Instead it should be "Please can I have this permission?" and Android can say "Yes" or "No" depending on the user's preference, and app has to handle the result in a graceful way (yes, this could mean throwing up an error message and refusing to run).

most apps just die (FC) if they don't get granted full permissions. cheers, robin

On Mon, 8 Jul 2013, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:

It also needs to provide dummy access to any memory cards too -- or at the very least chroot type access to data areas so as to limit every app to only have the possibility to read/write it's own data.

Actually we need permissions on the data store. Now that the use of Android phones as a VFAT USB attached block device has gone away there's no reason not to use a filesystem like Ext4 with POSIX ACLs. Lots of apps get access to all the mass storage of the phone when they really only need one of the following: 1) Access to store their own data (a chroot would do in this case, but it's only one situation). 2) Access to one particular data store - the most common case being an application which only needs access to photos. A chroot wouldn't work for this as it's a fairly standard feature to store photos in two locations. 3) Access to particular files, EG you view a picture in the gallery app and then say that you want to share it via a particular application. Fairly basic ACL use would solve case #1 and #2 if there was a way to specify which application's data is shared (which needs some UI changes). For case #3 you could either copy the file or do a temporary bind mount to avoid having to change ACLs on the entire tree. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

Trent W. Buck <trentbuck@gmail.com> wrote:

Those would be the posix *draft* ACLs that I've never *ever* seen used in practice?

They're used under Debian (and possibly other distributions) to control device access, as I found out. jason@jdc:~$ ls -l /dev/sr0 brw-rw---T+ 1 root cdrom 11, 0 Jul 8 07:15 /dev/sr0 The + indicates the presence of an ACL or other access restriction. Let's investigate. jason@jdc:~$ getfacl /dev/sr0 getfacl: Removing leading '/' from absolute path names # file: dev/sr0 # owner: root # group: cdrom # flags: --t user::rw- user:jason:rw- group::rw- mask::rw- other::--- jason@jdc:~$ Thus user jason is granted read and write permission. If I log in remotely (over ssh) this does not happen, and, as I recall, it's controlled by ConsoleKit.

Robin Humble <rjh+luv@cita.utoronto.ca> wrote:

CyanogenMod folks thought that spoofing a lot and crashing many apps and causing a big app support load risked CM as a whole being blacklisted by app developers. eg. enough apps written as if (CM) exit(1); // too hard to support these tin foil hatters would defeat the whole purpose. I guess it's a fine line to walk when a rom has millions of users - it's large enough to get in trouble.

My problem is with the original security model which lets app developers assume that they don't have to handle "permission denied" conditions appropriately if they declare all of the permissions they want in advance. It would be better to set up an expectation from the outset that certain API calls can result in denials of permission and you had better handle them gracefully if you're an app writer. As I understand it from this discussion, the current approach is to ask the user to grant all permissions that might be needed during installation, and then the app author can simply assume throughout the code that security restrictions won't stand in the way of the actual operations.

Robin Humble wrote:

after all, how many of us write code that checks the return value of close()? how about checking and re-trying short read() and write() calls?

It irritates me to put "or die" after every line, but I tend to do it (I think). I do miss the feature "hey bash, do 'or die' if any command terminates unsuccessfully (except predicates)" in other languages...

google was likely desperate for apps at the beginning. their app store had nothing in it. even now I'm not sure it was the wrong decision to make... apps asking for too many permissions and then abusing them is the real problem. I don't think it's the permissions model itself.

It seems to me that's a knock-on effect of the original design.

if facebook had open protocols then someone else could write a facebook app that didn't steal your phone number even before you'd logged in. perhaps fighting for open protocols is the real solution.

I don't see how you'll make any headway with that, when it directly contradicts their business model.

On 9/07/2013 3:34 AM, Robin Humble wrote:

...

My problem is with the original security model which lets app developers assume that they don't have to handle "permission denied" conditions appropriately if they declare all of the permissions they want in advance.

It would be better to set up an expectation from the outset that certain API calls can result in denials of permission and you had better handle them gracefully if you're an app writer. As I understand it from this discussion, the current approach is to ask the user to grant all permissions that might be needed during installation, and then the app author can simply assume throughout the code that security restrictions won't stand in the way of the actual operations.

I don't know why google did it that way, but I suspect this was a compromise they decided upon to make app development a LOT easier.

Not to mention that the resulting code without the extra checks is going to be smaller. This would have been a concern with early Android devices that were much more memory and storage constrained than is typical today. Regards, Morrie. -- Morrie Wyatt (morrie@mtiqualos.com.au) ----------------------------------------- M.T.I. Qualos Pty. Ltd. 55 Northern Rd. West Heidelberg Vic. 3081 Ph: +61 3 9450 1900 Fax: +61 3 9458 3217 -----------------------------------------

On 9 July 2013 03:34, Robin Humble <rjh+luv@cita.utoronto.ca> wrote:

I don't know why google did it that way, but I suspect this was a compromise they decided upon to make app development a LOT easier.

I would also argue advertising is a big factor. What happens if somebody turns off X permission? How would I be able to do in app advertising any more?

after all, how many of us write code that checks the return value of close()?

Don't need to do this if the language supports exceptions :-) Seriously though, if you don't check the return value of close, especially after a write file operation, your code is buggy and this could result in data lose. google was likely desperate for apps at the beginning. their app store

had nothing in it. even now I'm not sure it was the wrong decision to make... apps asking for too many permissions and then abusing them is the real problem. I don't think it's the permissions model itself.

Don't forget that Google didn't invent Android themselves, they acquired the company that did. So it is not clear where these design decisions were made. -- Brian May <brian@microcomaustralia.com.au>

Hi, On 8/07/2013 9:08 PM, Robin Humble wrote:

maybe Open PDroid is for you http://forum.xda-developers.com/showthread.php?p=36678558 I haven't tried it, but it seems to have plenty of fine grained options. I expect there are other options out there too.

Yes, I think that would be a great option -- particularly if I wanted to root my phone, which I don't right now; and even better if I wanted to build my own ROM, which I probably don't have the skill and definitely don't have the time to do.

CyanogenMod folks thought that spoofing a lot and crashing many apps and causing a big app support load risked CM as a whole being blacklisted by app developers. eg. enough apps written as if (CM) exit(1); // too hard to support these tin foil hatters would defeat the whole purpose. I guess it's a fine line to walk when a rom has millions of users - it's large enough to get in trouble.

Yes, I can understand that. But if an app is going to ban all CM builds then that app probably isn't worth having.

the PrivacyGuard method of returning null sets (eg. no contacts, no sms's sent/recv'd) should be low disruption to apps as is a legit state that a phone could be in.

Sure.

having said that, I would kinda like to see a separate 'privacy' control for fine gps location though as I don't mind some apps (eg. bushfire) knowing exactly where I am on a map, but they still have no right to read or send sms's for me.

It might be very worthwhile to be able to send an SMS in an emergency situation .... some apps need to be more trusted than others? As I understand it, some bad apps come out of Google play store after having been good apps for a period of time.... they turned into bad apps by sliding under the radar.

...

It also needs to provide dummy access to any memory cards too -- or at the very least chroot type access to data areas so as to limit every app to only have the possibility to read/write it's own data.

CyanogenMod (or maybe even standard Android) already has: Settings -> Developer options -> Protect SD card "Apps must request permission to read SD card"

That is available in my stock S3 4.1.2 ROM.

which isn't great as it's not limiting them to one sdcard directory or anything, but OTOH if you have a photo editing app of some sort then you actually want it to be able to read your directories full of photos...

You are right, but what if a photo editing app wanted to upload ALL your photos or thumbnails to start with? It could easily still overreach significantly -- even if you do want to use it on one or two photos (or more, selectively).

at least a bunch of them are open source (mostly) so anyone can write patches and ship their own.

Anyone with enough time and other resources, as well as all the /right/ skills. The biggest problem with Google and this transfers down to Android, is that there are too many younger people whom don't seem to think twice about sharing their entire lives online in fb, twitter or anywhere else. Google's Buzz made assumptions that just because you communicated with someone, actually anyone, then you must be happy with the idea of linking them up as friends whom can see everything you do in Buzz .... glad that product died, not so glad Wave died, but that's the way of Google, you never know what will last and what will die. Cheers A.

Robin Humble wrote:

or simpler, just don't install the facebook app!

The last time I gave a full-on privacy rant to a bunch of normal people, they looked at me and went "so what do we do?" And I said "well a simple, easy and effective start is to boycott facebook." Then there was an awkward silence and you could see them thinking "facebook is worth more than my privacy." Sigh.

On 9/07/2013 4:18 PM, Rick Moen wrote:

Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):

...

[2] http://twit.tv/show/security-now/404 -- How Facebook Monetizes (May 15 2013)

One's faith in this as a credible source of information is somewhat impaired by their citation of third-rater IT drone Steve Gibson, of all people, as 'the security master'.

It may not be the best source, by a long way, but it is a source that often has /some/ gems. Steve Gibson often says things that infuriate me because I just plain know he is wrong, but on the whole, he isn't that bad.

Anyway, the only surprise in this subject would be the notion that anyone might be unaware that Facebook are selling its users as product, which they are most certainly doing, indeed. It suffices to visit any Facebook page and check using NoScript to see the array of tracking methods they throw at people, and that aspire to track even logged-out users.

Yes, and with the shadow profiles, they will link up ALL the email addresses that they can find for you from whatever source gives them up willingly (even if naively willing).

Additionally, one might point out that the smartphone market's whole 'start with a pproprietary, vendor-controlled OS, then install and run a variety of untrustworthy codebases from nowhere-in-particular' user culture is essentially hopeless, i.e., there is -no- prospect for reasonable security, having thrown that away at the beginning. And that's not including their other obvious data-mining measures.

Yes, I think you are right there; such a pity ... but I'm not going to resort to my old Palm VX any time soon.

The core of my computing centres around the Debian server in my garage (the linuxmafia.com box), which is a fine platform with a readily understandable and controllable security model and which I can rely upon to work for me and not three-letter spook agencies.

;)

[1] Although it's an opaque proprietary OS, PalmOS as implemented on classic PDAs like my Palm TX is a single-tasking, standalone OS, hence it has a simple, readily understood threat model. The killer app in my opinion is Martin B. Pool's Keyring, http://gnukeyring.sourceforge.net, an open-soruce 3DES datastore for security tokens. I keep anything and everything security-sensitive there, airgapped from all networks.

Now known as just Keyring for Palm OS, they've dropped GNU in the name, but the SF link still needs it; it would be good if it redirected to: http://keyring.sourceforge.net - oh well. I don't trust 3DES and 112 bits doesn't seem enough for my liking, that's only really 2DES anyway. It also looks like your password is crackable against the MD5 hash.... where the 32 bit random salt comes in seems quite unclear to me from the description. KeePass and TrueCrypt are what I use (for now), both seem much more secure than Keyring for Palm OS, albeit I don't use it with an airgapped device. Cheers A.

Rick Moen <rick@linuxmafia.com> wrote:

Anyway, the only surprise in this subject would be the notion that anyone might be unaware that Facebook are selling its users as product, which they are most certainly doing, indeed. It suffices to visit any Facebook page and check using NoScript to see the array of tracking methods they throw at people, and that aspire to track even logged-out users.

It should also be obvious, given that they don't charge their users directly for services, that there isn't much they could sell other than access to and information about said users for advertising purposes. There's a well known quote to the effect that, if you aren't paying for the product, then you are the product.

I just had a reminder of how huge a percentage of people simply fail to engage, at a fundamental level, with the basics of Internet security. My acquaintance James Redekop, who works as a veteran coder at an Internet firm in Ontario, said on a mailing list that he was unable to follow a link to an article on cincinnati.com because the site told him he'd reached his quota for gratis articles for the month. I thought, wait, what? That means.... Quoting James H.G. Redekop (james.hg.redekop@gmail.com):

On Tue, Jul 9, 2013 at 8:40 AM, Garrison Hilliard <garrison.hilliard@gmail.com> wrote:

...

Not too rainy in Cin. city, but...

http://nky.cincinnati.com/proart/ab/20130708/news0103/307080034/a-month-s-worth-rain-fell-one-week?odyssey=mod|newswell|img|frontpage|p&pagerestricted=1

Apparently, my free trial to this website I've never visited before has expired, so I can't read the article.

d00d, as always, it's a Javascript function. You're not using NoScript yet? I was stunned because James of all people should have long ago figured out _why_ something like NoScript is necessary. But then I was stunned a second time by his explanation of why he was doing without it: Quoting James H.G. Redekop (james.hg.redekop@gmail.com):

I'm at work, where I work on a cloud-based application which uses JavaScript, so I haven't bothered to install it here.

You've possibly made the error of assuming the name 'NoScript' means that it disables Javascript? I continue to be amazed how many people make that erroneous assumption.[1] I use it at work, and $FIRM has dozens of sites on which I need to be able to automatically run the served Javascript. So, that's what I have NoScript do for all such sites. [1] Put simply, NoScript _inverts_ Web browsers' default behaviour of being willing to run any JavaScript snippet on any page from any FQDN, by making that become default-no. On a per-site basis, you choose which FQDNs' snippets to enable either temporarily or permanently from then on. You also can (and should) tweak permitted Javascript behaviour in NoScript's preferences, which is a key advantage because the Javascript language is dangerously and horrifically overfeatured. You are warned that there is a learning curve in getting used to NoScript, and it's important to know how to use its overrides for difficult cases. The payoff is much better security and browser performance, there are far fewer instances of bombing out of memory, there is far lower RAM usage, there is much less junk on pages, video clips become optionally playable objects rather than autorunning irritations, and many paywalls like NY Times's and cincinnati.com's simply go away completely. (AdBlock Plus is a highly recommended companion measure.) In other words, James had failed to even investigate NoScript, never looking beyond its _name_, and assuming (in error) based solely on that name that it simply disables Javascript in some blanket fashion -- without taking even a few seconds to check. (Aside: Why would anyone write a Firefox extension merely to disable Javascript, anyway? That doesn't even make a tiny bit of sense.) The larger picture: Installing and tweaking add-on moficiations to basic software requires taking initiative, and I notice that hardly anyone ever does. In Feb. 2011, I gave a talk at Silicon Valley Linux User group called 'The Wild, Wild Web: Web Browser Security, Performance, and Privacy' (for which notes and slides are online), and made the point that Javascript is _the_ keystone technology one must wrestle back under user control if one hopes to enjoy reasonable security, performance, stability, and privacy. Thus the extreme need for NoScript or something like it. Even though, yes, using it does require you to get off your ass and do something on your own initiative rather than being a passive consumer. Near the end of my talk, I asked for an honest show of hands: 'Seriously now, and I would appreciate an honest answer and will take no offence at same, how many of you will serious consider any significant portion of the recommendations I'm making here today?' Out of a room of about 50-60 members of the audience, I think one hand went up. I thanked them for their refreshing honesty -- but was a bit appalled at the near-total disconnect between people understanding the problem and being willing to lift a finger to take corrective (but non-default) measures to deal with it. The even larger picture: I've notice that the rot has set in pretty deeply of people 'trying Linux' but never even considering doing anything non-default. We've now had about a decade's worth of participants for whom 'installing Linux' is just booting a distro installer and hitting the spacebar repeatedly with their foreheads until completion, who are utterly helpless to deal intelligently with driver and configuration issues, and who don't even really understand anything about their chosen distros, either. I started to realise the magnitude of the problem when I encountered people installing DamnSmallLinux on P4 boxes with 512 MB or 1GB RAM because they seriously thought nothing more complex _could_ work. And why did they think this? They attempted to boot the live-CD image of (say) Ubuntu to run the graphical installer on top of that, it choked on the extreme RAM shortage, and they concluded that installation was impossible. Or the installer completed but then was 'slow' and they couldn't even start to figure out how to decide what to run and not run, because the very concept of doing so was alien. I saw this problem when I asked such people about the process list. Blank expression. 'Process list. You know, the process list. ps and all that.' Complete and total non-comprehension. 'Wait, this is an open-source OS. The very basic idea, the raison d'etre, is to enable _you_ to decide for _yourself_ what to run and not to run. Are you telling me you have never even considered figuring out what is running and deciding for yourself what you want?' Yes, that's overwhelmingly the case. And these people actually _argue_ with me. DamnSmallLinux is The Right Thing because they can boot into the installer and hit the spacebar with their foreheads repeatedly and arrive at a (feeble, limited) Linux installation. Therefore, it's the right choice, say they. Wow. Just wow.

Rick Moen <rick@linuxmafia.com> wrote: [A good candidate for the "mailing list post of the year award", if there were one.]

I started to realise the magnitude of the problem when I encountered people installing DamnSmallLinux on P4 boxes with 512 MB or 1GB RAM because they seriously thought nothing more complex _could_ work. And why did they think this? They attempted to boot the live-CD image of (say) Ubuntu to run the graphical installer on top of that, it choked on the extreme RAM shortage, and they concluded that installation was impossible. Or the installer completed but then was 'slow' and they couldn't even start to figure out how to decide what to run and not run, because the very concept of doing so was alien.

There's another problem: consider a recent distribution of Linux with, for example, GNOME installed. It has long since past the point at which, not being a GNOME insider, I know what all of the processes do, what the components are and how they interact. When I'm running a straightforward console session I can read a process listing and understand what's running and, just as importantly, why I'm running it. Graphical desktop environments take the level of complexity up enormously, and it isn't simply process-related: read ~/.xsession-errors and consider all of the messages from components one didn't even know existed. One is then faced with the practical question: against which package to submit a bug report. At some point the level of complexity really will have to be reduced to make everything easier to administer and easier to debug. I think those who run simple window managers rather than "desktop environments" are well justified in doing so. For accessibility reasons, this isn't an option for me; it's best to run the accessibility infrastructure, when I do need an X environment, in GNOME (for which it was written).

Trent W. Buck <trentbuck@gmail.com> wrote:

Har har. That's like saying entropy will go down.

Maybe.

...

I think those who run simple window managers rather than "desktop environments" are well justified in doing so. For accessibility reasons, this isn't an option for me; it's best to run the accessibility infrastructure, when I do need an X environment, in GNOME (for which it was written).

Pity you can't just do everything in emacspeak :-/

Mostly, I can (either that or a console session). Web sites requiring HTML 5, DOM and associated APIs are the main exception at the moment. LibreOffice is installed but I mostly run it with --headless on the command line to perform file format conversions. I occasionally test the accessibility features of the UI and report bugs; it's like an ensurance policy - I hope I don't have to use it, but it's important for it to be there in case I do. LaTeX, HTML and other markup formats serve my writing needs well. The only situation in which I would need the LibreOffice UI is a collaborative editing cycle with word processor users, i.e., requiring conversion in both directions with preservation of the formatting. At the moment, this isn't the kind of work I do.

Brian May wrote:

Programs shouldn't even be recording all of the stuff in ~/.xsession-errors

As Russell pointed out, that's just where X's stderr (and stdout, I think) goes.

Just noticed mine is filling up fast with the following error. I think I might have to investigate this. Not really sure what is running amixer though (I use awesome, so no, not gome/kde stuff)

I filled /home a couple of times due to .xsession-errors. I found on Debian, chmod -w'ing it causes it to fill /tmp instead (and for me that's a tmpfs and I reboot regularly, so it neatly sidesteps the issue). Doesn't work on Ubuntu, though.

Quoting Jason White (jason@jasonjgw.net):

Rick Moen <rick@linuxmafia.com> wrote: [A good candidate for the "mailing list post of the year award", if there were one.]

/me bows, pretends to humility.

At some point the level of complexity really will have to be reduced to make everything easier to administer and easier to debug. I think those who run simple window managers rather than "desktop environments" are well justified in doing so.

Oh, I'm one of them, at that. Hand me, say, a default Debian installation with a DE to be my own, and the very first thing I'm likely to do, even before whittling down the rest of the startup processes, is cd /etc/alternatives mv x-session-manager x-session-manager.disabled That saws the legs out from under the DE. Then, because I'm a retrograde refugee from NeXTSTep: apt-get install wmaker wmaker-data update-alternatives --config x-window-manager -- Cheers, Snowden is accused of giving information to "the enemy". Rick Moen He gave information to the American people. Well, now rick@linuxmafia.com we know who the enemy is. --- Steven Brust McQ! (4x80)

Quoting Trent W. Buck (trentbuck@gmail.com):

That shouldn't be necessary. ?dm should run .xsession by default, if there is one.

Be that as it may, I found out accidentally one day that disabling X11 session management very efficiently prevents an installed and configured DE from loading at all, i.e., absolutely nothing except for the configured window manager runs at X startup time. That may not be the right way to defang a DE, but it happens to work very well.

I guess, but I'd have thought it easier to

cd echo wmaker >.xsession chmod +x .xsession

Point taken about .xsession -- which obviously I'm going to have to look up and understand yet again. Back in dinosaur days, when I was dissembling the X infrastructure of early Slackware and Red Hat Linux boxen, I traced all of that ghod-awful maze of conffiles until, for one glorious moment, I held it all in my head, in all of its hideous glory. And was well and truly revolted. And then the moment passed, and I've forgotten much of it, rather like the mostly-recovered protegonist of an H.P. Lovecraft short story.

Quoting Trent W. Buck (trentbuck@gmail.com):

FYI, I took notes last time, top of my http://cyber.com.au/~twb/.xsession.

Tusen takk! (Er, thank you very much.)

Tim Connors wrote:

I like the twb-loop. I had been running fvwm for 5 years without a crash.

Ah, well, that was back in the days when ratpoison actually crashed a lot, and when I was actually patching in new features. Hasn't been an issue for me for at least five years. http://cyber.com.au/~twb/.bin/twb-loop As you can see, it's gratuitously complicated. Nowadays, I live in the tty most of the time, except for the odd thing like "xinit /usr/bin/epdfview tmp.pdf" or "xinit /usr/bin/midori URL" which don't run a WM at all. [Yes, I know I can view PDFs on the tty by rasterizing them. I'm not hardcore enough for that. I used to recompile against fbgtk, but that was buggy and shit and it has probably been dead for half a decade.]

Anyway, my fvwm has been run under a loop ever since, which has actually proved more useful than you might otherwise guess, because X clients (particularly skinned multimedia clients, surprise surprise) are doing stupider and stupider things. xine in particular likes to set the WM into a 100% loop somehow, once it tries to pop up a scrollbox in its godawful 1987 style default theme.

My favourite was ratpoison + xgo. xgo says "I must be in a square window" and it hasn't heard of this whole "WM" concept, so it resizes itself. And ratpoison says "windows are tiled, goddammit" and maximizes the window. Rinse & repeat, at 100% CPU.

Quoting Tim Connors (tconnors@rather.puzzling.org):

I like the twb-loop.

(Please pardon me a moment, Tim, while I talk over your virtual shoulder.) Trent, I hope you know that proclaiming that a work is 'placed in the Public Domain' is problematic and has indeterminate effects[1] that may depend on the jurisdiction. And that you can achieve literally all of what you want to achieve -- without the feeling of ideological purity but also without the legal problems -- but just saying: Copyright (C) 2013 Trent W. Buck. You may do whatever you want with this work. You'd be doing a huge favour to anyone who might be tempted to include your script into a larger work -- and an even bigger favour to other coders who might be tempted to follow your example for a more-complex work where this sort of legal error can have more-drastic consequences. And yes, I do give this advice to pretty much everyone in the open-source community I see perpetuating this lurking threat to those doing code reuse. [1] Judges might rule it to have the intended effect, to have no effect and be void, to create a perpetual licence for unrestricted use, or possibly other outcomes -- differently for each jurisdiction. There is in general throughout the Berne Convention world, which I believe is now all countries, no mechanism for copyright owners to completely eradicate their copyright titles, and it's specifically known in certain jurisdictions including the UK that this ploy does not work at all.

Quoting Trent W. Buck (trentbuck@gmail.com):

I haven't touched that code since we last had that discussion.

Forgot, sorry!

If any of my shitty little scripts are notable and noteworthy enough to be worth stealing AND to be covered by copyright, someone can write and ask me to issue a license, and I will.

Fair enough. Also not too difficult to independently write a replacement, for that matter. Sorry to have bothered you on something you had already pondered.

Tim Connors wrote:

I remember the good old days when you could chuck scripts in /etc/pm.d or something similar to get it to do things prior and aft suspend. Hah! I hadn't figured out how to do it again as of about 2 years ago. And it's probably gotten worse since. It sounded to me like a DE wasn't optional for that to pretend to work.

FTR, acpi-support and acpi-support-base provide the default policy for this... but by default, they say something like "if there's an X session, and it's not locked, and gnome-power-manager or kwhatever is running, then DO NOTHING AND ASSUME THEY WILL". The code that actually *does* the workarounds is pm-utils or so; the ACTUAL suspending is usually done by that echoing "mem" or "disk" or "mem disk" into /sys/something, which makes the kernel do the basic suspending. Doing things around AC insert/remove is plain acpid & /etc/acpi/events. That's as at sid around twelve months ago, when I last looked through it. The detection code made me a big queasy. Ah, glancing at the source, it looks like it also/instead now checks for upowerd. Remember hal, that everyone hated? AFAICT the parts that didn't move into udev, got rebranded as "upower" and "udisks" and are just as terrible as before, and made by the same people. Oh yeah, here's the code in debian/patches/policy-funcs.diff and lib/policy-funcs (acpi-support package). Yuk. Don't read this without a stiff drink handy.

Craig Sanders wrote:

On Tue, Jul 09, 2013 at 12:41:47PM -0700, Rick Moen wrote:

...

And these people actually _argue_ with me. DamnSmallLinux is The Right Thing because they can boot into the installer and hit the spacebar with their foreheads repeatedly and arrive at a (feeble, limited) Linux installation. Therefore, it's the right choice, say they.

Ah, okay. That explains something I'd never really got before - "what's the point of DamnSmallLinux and other tiny-distros when a debian base install is also tiny but gives you instant apt-get access to tens of thousands of extra programs already packaged as well as a dev team of over 1000 people, many of them first-rank experts in their fields?".

it's just perception and marketing.

Last time I did a PXE install of debian 6 into qemu, it needed 192MB instead of the default 128MB of RAM (possibly somewhere between those two), or some packages were not completely unpacked (which completely floored me, because the install CLAIMED to finish just fine). Once installed with 192MB, it booted fine with 128MB. The smallest I've gotten a rootfs + kernel + ramdisk for minimal Debian, is 49MB, or 23MB with a localyesconfig kernel. And that was using squashfs, so you'd need more RAM to actually run it. I think there *is* a gap between the smallest thing you can reasonably run Debian on -- about 128MB nonvolatile / 128MB volatile -- and your typical OpenWRT target (4 to 16MB nonvolatile / 8 to 32MB volatile). But I don't know you can buy devices in that range, and I don't think DSL targets it.

Craig Sanders wrote:

you can't brick a PC, either (although SecureBoot and UEFI is fixing that bug). configurung and upgrading a PC, and generally working on it is a lot less hassle than tiny embedded devices.

FWIW, you can't brick a WNDR3800 or a tegra2 either (for example). Enough of their bootloader is in ROM that you can boot an installer even if you brick the eMMC.

On Fri, Jul 12, 2013 at 08:37:56PM +1000, Andrew McGlashan wrote:

On 12/07/2013 4:45 PM, Craig Sanders wrote:

...

you probably can't even find them second hand any more and why would you bother even if you could find them? it's not at all difficult to find P4s and better being given away for free or just thrown out, they're considered obsolete junk (but considerably better "junk" than the 40Mhz 386 machines with 4MB - megabytes, not gigabytes - RAM that I was running SLS and then debian on in 93 and 94).

P4 is overkill and a power hog compared to many newer processors, ATOM, cough ... ARM or AMD, there are plenty of low power units now that are very cheap and not limited too much (especially by RAM).

true, but people tend to re-purpose old machines for DamnSmallLinux and other tiny-distros. a new system might save on power, but even putting together a cheap new system (case & power-supply, cpu, motherboard, disk, and ram) will set you back at least $200. it takes several years worth of electricity savings to make up the difference between free and $200. just quickly looking at MSY's price list, the cheapest headless system I could put together would be: GT-DF1 case + power-supply $35 AMD A4-5300 CPU $54 AsRock FM2A55M-DGS m/b $58 2GB DDR-3 1333 RAM $20 Seagate SATA3 500GB $58 ---- $225 ---- that would make a decent little router/firewall/proxy-server/etc. add a few more drives and it could be a "NAS" too. Alternatively, using a Sempron LE-145 CPU and motherboard would be $195, but you'd have to add another $25-$30 for a cheap video card so it would cost about the same. the A4-5300 is a much better CPU than the Sempron, so the only real advantage to the sempron is that it can be upgraded to any AM3+ CPU, whereas the upgrade path for the A4-5300 is via the FM2 CPU socket. add another $150 or so if you want a cheap LCD screen, keyboard and mouse too. from bitter experience I am biased against cheap power supplies (they often die within months) and cheap cases (they shred your hands with rough cut metal edges while installing components), $35 for a case and power-supply sounds way too cheap. I'd prefer to spend at least $60 or $80 on a brand-name case + PSU, so the total would be closer to $250 or $300.

Heck, even the HP N54L can be had for a very reasonable price and it can take 4x HDDs if you want them -- otherwise using very little power.

they're in a much nicer case than the GT-DF1 above, and have a low-power CPU but the cheapest I can find them is $299 (or $279 for the N40L)...30% more than the cheap system above and again a lot more than free, and doesn't include any disk drives. OTOH, the HP microserver doesn't require any assembly except installing the drives, there's something to be said for that. the downside is that appliances aren't really upgradable or repairable and parts can be hard to find - if it dies out of warranty, buy a complete new replacement. a clone PC can be easily upgraded and individual components replaced if they die. if the environmental cost is a concern then the embedded energy costs of disposal and replacement are far higher than that of repair and upgrade. As for performance, the A4-5300 is significantly more powerful (and includes a radeon 7480D GPU, nice for video playback or transcodes) than the Turion II N45L in the HP, but uses up to 65W rather than 25W, although at idle it only uses about 36W or even less if you under-clock or under-volt it. http://www.cpu-world.com/Compare/388/AMD_A4-Series_A4-5300_vs_AMD_Turion_II_... The ASRock motherboard is also nicer than the HP N45L - it has 6 SATA2 ports, 10 USB 2.0 ports, and theoretically takes up to 32GB RAM (but only has 2 DIMM sockets and 16GB sticks are hard to find, so practically only 16GB RAM). spend a little more (maybe $10 or $20) to get a slightly better model m/b and you get built-in SATA3 and USB3 and maybe 4 DIMM sockets rather than two. craig -- craig sanders <cas@taz.net.au> BOFH excuse #329: Server depressed, needs Prozac

Craig Sanders wrote:

your comments, btw, are a large part of the reason why I give up disappointed every time I look into the idea of using an openwrt-capable device rather than a generic PC. they're very limited, and quite expensive for what you get (a PC to do the same job can be had for free). about the only thing I really want a *wrt device for is so I can have the ADSL line directly controlled by Linux (rather than bridging pppoe), but I can't find one with supported ADSL that isn't either tagged as experimental WIP, or comes with stuff I don't want/need (wifi/NAS/print-server), or doesn't have Gb ethernet.

Currently MSY has Netgear WNDR3700 for A$99. It has a 5*gigE programmable switch, 11n wifi, 16MB/64MB, and excellent OpenWRT support. If those are things you want, IMO it's easily worth the price. If you don't want those things, >shrug<. I concede the lack of open ADSL drivers is very annoying. OpenWRT and "appliance" hardware both deal cleanly with lossy power, which avoids needing a UPS if $customer has no other servers. It probably reduces electricity bill, though I doubt it'd be enough to offset the $99 vs. free over a (say) five-year life cycle.

On 13/07/2013 9:53 AM, Jason White wrote:

Trent W. Buck <trentbuck@gmail.com> wrote:

...

Currently MSY has Netgear WNDR3700 for A$99. It has a 5*gigE programmable switch, 11n wifi, 16MB/64MB, and excellent OpenWRT support.

When are we likely to see devices with excellent OpenWRT support (open drivers) that can serve as an 802.11AC access point?

I would be more inclined to use a gigabit device and then a separate AP with whatever radio and antenna suits. https://en.wikipedia.org/wiki/IEEE_802.11#802.11ad Cheers A.

On Sat, 13 Jul 2013, Jason White <jason@jasonjgw.net> wrote:

Trent W. Buck <trentbuck@gmail.com> wrote:

...

Currently MSY has Netgear WNDR3700 for A$99. It has a 5*gigE programmable switch, 11n wifi, 16MB/64MB, and excellent OpenWRT support.

When are we likely to see devices with excellent OpenWRT support (open drivers) that can serve as an 802.11AC access point?

To be more specific about this, I'm using a Traverse Technologies ADSL card for my Internet connection, installed in a desktop machine. When I enter the mobile phone market, I'll need a wireless access point (at the moment, I don't, since all of the devices are within a metre of each other and a Gigabit Ethernet switch solves the connectivity problem well). Newer phones have 802.11AC, so it's worth waiting a while and investing in a suitable access point (presumably, an OpenWRT device or perhaps a PCI-Express card if there is such a product compatible with recent kernels).

Why do you need such speed on a phone? I've recently started watching TV on my Galaxy Note 2. Uploading the large MP4 files of TV shows isn't a problem with typical wireless speeds (I can upload them faster than watching them). When your device only has 16G of storage you can't take full advantage of high speed transfers unless you are going to upload a new 16G data set every day or something. On Sat, 13 Jul 2013, Craig Sanders <cas@taz.net.au> wrote:

for anyone else though, it's a bit like whinging about petrol prices going up 2 or 5 or even 20 cents per litre - WGAF? even with an enormous rise of 20 cents that adds up to a completely underwhelming $8 on an average 40 litre tank. for the more common 2 cent fluctuations, it's 80 cents.

Every year my parents buy a book of discount vouchers (such things are very popular among retirees). That discount book allows them to order Woolworths gift cards at a 5% discount. So I get 5% discount on my groceries and petrol and then get ther 4c/L petrol discount because of spending more than $30 on groceries. Hardly anyone seems to do that so I guess they don't really want the 5% discount. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

On Sat, 13 Jul 2013, Jason White <jason@jasonjgw.net> wrote:

Russell Coker <russell@coker.com.au> wrote:

...

Why do you need such speed on a phone?

I don't. However, the phone won't be the last 802.11ac device here; the next laptop will support it as well, whenever that's purchased, and it might not always be within range of Ethernet cables.

Thus the thought was: consider an 802.11ac access point and avoid the upgrade later on.

I suppose the backups and dist-upgrades can afford to be on Ethernet, but I tend to be of the "buy hardware that meets the latest standards and hold onto it until there's a real need to upgrade" school.

I'm in favor of getting something cheap that does the job and not upgrading it until necessary. I'm using 100baseT networking which is fast enough for my use. It's a lot faster than my ADSL2+ link and faster than the NBN will be. It's a bottleneck for backups but they can just run for as long as it takes. My home wifi does "up to 54Mb/s" (802.11a/g I guess) and my phone reports it as having a connection speed of 18Mb/s. The lowest FTP transfer rate to my phone on that link is about 560KB/s (5Mb/s). That's enough to transfer a 40 minute TV episode in 10 minutes, it's good enough. 560KB/s also compares well to the maximum transfer rate I get from the Internode mirror which usually gives a maximum speed of about 800KB/s. So I don't think Wifi would limit me in dist-upgrade type operations. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

Jason White wrote:

When are we likely to see devices with excellent OpenWRT support (open drivers) that can serve as an 802.11AC access point?

NFI, recommend you ask #openwrt on Freenode. I run WNDR3700 and 1043NDs on their recommendations, AFAIK they speak 802.11n. I'm using them as APs without installing any extra blobs, but that might just mean non-DFSG blobs are built into the stock OpenWRT firmware.

Craig Sanders <cas@taz.net.au> wrote:

On Fri, Jul 12, 2013 at 11:45:18PM +1000, Trent W. Buck wrote:

...

Currently MSY has Netgear WNDR3700 for A$99. It has a 5*gigE programmable switch, 11n wifi, 16MB/64MB, and excellent OpenWRT support. If those are things you want, IMO it's easily worth the price. If you don't want those things, >shrug<.

i get to this point and think "excellent, that'll do"

...

I concede the lack of open ADSL drivers is very annoying.

and then i get to this sticking point and realise, "no, it won't".

without an ADSL driver, I'm still going to have to have an ADSL modem as well as a router, which defeats the entire purpose (of merging modem + router/firewall and wifi into one little unit) for me. and then i remember that 64MB RAM wont be enough to run an authoritative nameserver (which has to be on my gateway's IP address of 203.16.167.1) and it certainly wont be enough for squid.

Probably expensive, but traverse Technologies offer ADSL modem/router boxes now with Gigabit ports. From memory, you could add a wireless card. I don't know how much RAM. The ADSL driver is in the mainline kernel.

Trent W. Buck <trentbuck@gmail.com> wrote:

I have no experience with traverse's complete device offerings (IIRC they're called "ALIX" or something). I assume they're just something like a soekris net5501 + one of their DSL cards, in a custom SFF case.

I think they're a custom board with ADSL included (using the same drivers as the Solos PCI cards). http://www.traverse.com.au/images/stories/downloads/datasheet.pdf

Russell Coker wrote:

On Fri, 12 Jul 2013, "Trent W. Buck" <trentbuck@gmail.com> wrote:

...

The smallest I've gotten a rootfs + kernel + ramdisk for minimal Debian, is 49MB, or 23MB with a localyesconfig kernel. And that was using squashfs, so you'd need more RAM to actually run it.

http://etbe.coker.com.au/2008/05/22/xen-and-swap/

In 2008 I found that a default Debian initrd produced on a system with LVM needed 30M of RAM to boot. Getting a virtual machine to boot with 13M of RAM took as much effort as I was prepared to invest in that project.

Note that my numbers above are for the non-volatile storage, i.e. the root filesystem. I was trying to reduce its size because (some of) my PXE clients download their entire OS into RAM at boot, so they don't care if TFTP server dies. A smaller rootfs means it boots faster.