On 2013-07-03 12:01, Brian May wrote: [...] 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 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(a)microcomaustralia.com.au): 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... 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(a)microcomaustralia.com.au> wrote: 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: 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! 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. most apps just die (FC) if they don't get granted full permissions. cheers, robin

On Mon, 8 Jul 2013, Andrew McGlashan <andrew.mcglashan(a)affinityvision.com.au> wrote: 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(a)gmail.com> wrote: 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(a)cita.utoronto.ca> 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.

Robin Humble wrote: 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... It seems to me that's a knock-on effect of the original design. 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: 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(a)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(a)cita.utoronto.ca> wrote: 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? 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 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(a)microcomaustralia.com.au>

Hi, On 8/07/2013 9:08 PM, Robin Humble wrote: 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. Yes, I can understand that. But if an app is going to ban all CM builds then that app probably isn't worth having. Sure. 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. That is available in my stock S3 4.1.2 ROM. 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). 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: 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: 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. 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). 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. ;) 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(a)linuxmafia.com> wrote: 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(a)gmail.com): 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(a)gmail.com): 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(a)linuxmafia.com> wrote: [A good candidate for the "mailing list post of the year award", if there were one.] 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(a)gmail.com> wrote: Maybe. 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: As Russell pointed out, that's just where X's stderr (and stdout, I think) goes. 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(a)jasonjgw.net): /me bows, pretends to humility. 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(a)linuxmafia.com we know who the enemy is. --- Steven Brust McQ! (4x80)

Quoting Trent W. Buck (trentbuck(a)gmail.com): 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. 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(a)gmail.com): Tusen takk! (Er, thank you very much.)

Tim Connors wrote: 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.] 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(a)rather.puzzling.org): (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(a)gmail.com): Forgot, sorry! 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: 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: 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: 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: 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. 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(a)taz.net.au> BOFH excuse #329: Server depressed, needs Prozac

Craig Sanders 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 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: 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 &lt;jason(a)jasonjgw.net&gt; wrote: 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 &lt;cas(a)taz.net.au&gt; wrote: 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 &lt;jason(a)jasonjgw.net&gt; wrote: 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: 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 &lt;cas(a)taz.net.au&gt; wrote: 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 &lt;trentbuck(a)gmail.com&gt; wrote: 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: 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.