IRC log for #edev on 20091130

01:11.40*** join/#edev SpeedEvil (n=user@tor/regular/SpeedEvil)
01:14.47MirellOkay, "wait" in bash is nice.
01:21.27*** join/#edev calculus (n=calculus@gentoo/user/calculus)
01:51.35*** join/#edev linac (n=lin@113.106.217.121)
01:55.33*** join/#edev prpplague^2 (n=dave123_@ppp-70-242-116-135.dsl.rcsntx.swbell.net)
01:55.43prpplague^2ho ho ho
01:58.17davidc__Merry Fishmas!
02:05.12MirellIndeed.
03:52.56*** join/#edev geep (n=JoeBelow@bas21-toronto12-1242364375.dsl.bell.ca)
04:43.05*** join/#edev PureSine (n=chatzill@87.247.172.139)
04:44.47monkey_hey prpplague^2
04:44.54monkey_Mirell:
04:46.58Mirellmonkey_:
05:23.27MonMothaanybody done any Android hacking, or is that sufficiently off-topic for here? :)
05:36.35MirellThat's way to close to what this channel is supposed to be for.
05:37.48*** join/#edev SandGorgon (n=OmNomNom@122.160.41.129)
05:44.12MonMothaah, well, then forget it :)
05:44.26MonMothaI'm looking for a phone to actually use (gasp!), but I'd like to be able to hack it if it's not behaving
05:44.40MonMothaAndroid is a good option for that, but I'm having trouble finding a suitable handset
05:44.48MonMothaHTC Hero would be good if it had a darned keyboard
05:45.00MonMothaSamsung Moment isn't very hackable and of questionable hardware quality
05:45.08MonMothaHTC Touch Pro 2 would be great if it didn't run WinCE
05:47.49ZeZumake it run linux
05:49.07ZeZuWinCE has to be pretty hackable,  probably a million exploits to take them over where you ought to be able to easily figure out the addressing
05:49.24ZeZuthem = winCE/arm devices
05:51.35MonMothaoh, there's an effort to make Android run on the Touch Pro 2
05:51.41MonMothathe original Touch Pro apparently has a very usable port
05:51.51MonMothastill booting from within WinCE, though
05:52.01MonMothaHaRET is wonderful :)
05:53.43ZeZunot familiar with it, but booting from within WinCE is ok as long as its not running "under" WinCE
05:53.57MonMothano, it just basically uses WinCE as a bootloader :)
05:53.59ZeZucould be a bit slow to boot though i guess
05:54.02ZeZuright
05:54.06ZeZuthats ok-ish
05:54.07ZeZu:)
05:54.31MonMothawell, you don't boot the darned thing very often
05:54.35MonMothaat least hopefully
05:55.39ZeZuhehe
05:55.57ZeZuI've still not played with android at all
05:56.06MonMothait's barely Linux as you know it
05:56.12MonMothathe userspace is very, very different
05:56.55ZeZuright, the linux userspace doesn't even exist, its just linux kernel running java with userspace underneath that from what i understand
05:57.02ZeZuwhich is so very ...ewwwww
05:59.00MonMothapretty much
05:59.23ZeZuthus why i've not bothered
05:59.41MonMothaI'd like an N900, but there's no CDMA2000 version
06:01.01ZeZuI dont even mess with half of the phones,  I'd think about it now that t-mo has the unlimited plan,  but i'm broke as hell atm so thats a no og
06:01.03ZeZugo*
06:01.35ZeZuverizon can kiss my ass :)
06:03.09MonMothaactually, I'm on Sprint
06:03.23MonMothathe other CDMA2000 carrier
06:03.49MonMothaand I agree with your general assessment of Verizon, though I'd prefer they not get anywhere near my ass considering what they've done to others'
06:04.56ZeZuhaha
06:04.58ZeZuso true
06:05.08ZeZui'm on sprint/boost
06:05.18ZeZu$50/unlimited everything
06:05.39ZeZuI can only use a phone if its got a sim card slot and uses their crap
06:05.45ZeZuCDMA2000 is it ?
06:06.10MonMothaif it's using SIMs, then it's GSM or WCDMA (the successor to GSM)
06:06.29MonMothaCDMA2000 supports something like a SIM (though they call it something else), but neither Verizon nor Sprint use them
06:06.56MonMothaGSM is by far the most common mobile phone standard in the world
06:07.22MonMothaCDMA2000 is something Quallcomm came up with in the late 90s and is really only used in North America for the most part
06:07.38ZeZuQuallcom is nasty
06:07.47MonMothaGSM is actually a TDMA type standard, but the successor WCDMA is CDMA based (hence the name)
06:07.48ZeZuanything that i've ever seen from them, is just crap
06:07.56MonMothaeh, their air interfaces aren't bad
06:08.07MonMothaI'm not fond of the CPU they put out that EVERYBODY uses
06:08.08ZeZutheir new snapdragon chipset isn't all its cut out to be either
06:08.10MonMothaTI OMAP seems better
06:08.17ZeZuyes
06:08.22ZeZuomap is deff. better
06:08.41MonMothaI suspect there are "agreements" in place that if you want to use their chips for CDMA2000 (which you have to due to patents), they probably make you use their CPUs
06:09.19MonMothaThere's one 528MHz ARM11 that everybody uses.  It's "OK" at best from what I've gathered.
06:10.01ZeZuyea
06:10.12ZeZuas long as you dont have to work with brew,  the mess is OK
06:10.25ZeZuif you have to use brew, you might as well laugh it off and stay well away
06:10.42MonMothaheh
06:11.22ZeZuI have some lame Zeebo console here, and its _all_ brew v4
06:11.30ZeZuIt collects dust, and its not even released yet
06:11.33ZeZui should sell it
07:48.04rektideI understand LTE is trying to have a more unified packet layer
07:48.47rektidev. today, where UTMS and HSDPA &c &c kind of form their own separate layer
08:07.22*** join/#edev keesj (n=keesj@ip49-193-210-87.adsl2.static.versatel.nl)
08:09.07MonMotharektide: yeah, something along those lines
08:09.20MonMothathe current air interfaces are pretty heavily "stream" oriented
08:09.45MonMothathat's great when almost all your traffic is voice, but it gets really inefficient when you have a lot of bursty data users
08:10.01rektideit'll be interesting to see how the spec works to prevent saturation
08:10.15rektidecertainly my biggest frustration with Wifi is that theres no way to demand CTS
08:10.30rektidethe hidden sender problem really makes any decent sized wifi net collapse... badly
08:12.07MonMothayes
08:12.33MonMothait almost seems like there should be a subchannel reserved for RTS/CTS
08:12.38MonMothaand then it should be required
08:12.40*** join/#edev tsjsieb (n=tsjsieb@dejongbeheer.nl)
08:13.05MonMothayou still only need one transmitter, though then the AP has to be able to both send and receive at the same time, which requires some VERY good filters
08:24.43*** join/#edev hw_ (n=hw@p578b3905.dip0.t-ipconnect.de)
08:32.33rektidethe reseved RTS/CTS space would be good
08:32.52rektidei think things would be a whole lot better if an AP could declare CTS mandatory
08:41.06*** join/#edev likewise (n=chatzill@82-171-51-231.ip.telfort.nl)
08:48.27*** join/#edev JoeLlama (n=snork@206.169.63.10)
09:23.20*** join/#edev JoeLlama (n=snork@206.169.63.10)
09:57.00SpeedEvilYou can't do that anyway.
09:57.20SpeedEvilUnless you have a managed net where each station has a timeslot
09:57.54SpeedEvilAnd also where there are no distant nodes that can't be picked up when they transmit.
09:58.23SpeedEvilBecause you can't discern a distant transmitting node from noise.
09:59.08SpeedEvilthe major reason cellphones work so well is that there is one dictatorial authority per cell - the tower.
10:04.30*** join/#edev florian_kc (n=fuchs@Maemo/community/contributor/florian)
10:10.06*** join/#edev olivdt (n=x@modemcable206.214-57-74.mc.videotron.ca)
11:24.54*** join/#edev pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB)
12:29.25*** join/#edev gustavoz (n=gustavoz@201.253.203.56)
13:04.54*** join/#edev PureSine (n=PureSine@87.247.172.139)
13:12.21*** join/#edev Crofton|work (n=balister@pool-71-171-31-89.nwrknj.east.verizon.net)
13:17.59*** join/#edev PureSine_ (n=chatzill@87.247.172.139)
13:34.56*** join/#edev keesj (n=keesj@ip49-193-210-87.adsl2.static.versatel.nl)
13:40.01*** join/#edev likewise (n=chatzill@82-171-51-231.ip.telfort.nl)
13:52.16*** join/#edev ncopa (n=ncopa@220.173.34.95.customer.cdi.no)
14:22.42*** join/#edev gustavoz (n=gustavoz@host248.201-252-31.telecom.net.ar)
14:26.46*** join/#edev GPSFan (n=kenm@64.92.145.112)
14:26.47*** mode/#edev [+o GPSFan] by ChanServ
14:34.22*** join/#edev kergoth (n=kergoth@nat/montavista/x-nqtorpgdqxhpyrev)
14:48.27MirellExcept when the tower changes?
15:25.22*** join/#edev PureSine (n=PureSine@87.247.172.139)
15:45.58ncopahi
15:46.11ncopahow can i enable -j12 in firmware linux?
15:47.46ncopaCPUS
15:48.19Mirellncopa: The CPUs stuff should be dynamically set, but you can add CPUS=12 in the config file
15:48.29ncopathats what i did
15:48.48ncopamy eight horses got some work now :)
15:49.16MirellNeeeeeee.
15:49.48ncopahumm
15:49.49ncopas/intl'
15:49.50ncopa"SED libgnuintl.h "
15:49.50ncopa/bin/sh: SED libgnuintl.h : not found
15:49.50ncopamake[2]: *** [libgnuintl.h] Error 127
15:50.37MirellLooks like your package depends on internationalization crap.
15:51.06ncopayes
15:51.09ncopaseems so yes
15:51.21ncopai build in a busybox/uclibc env
15:51.32ncopai wonder if i can disable e2fsprogs
15:53.03ncopai inserted an 'exit 0' in host-tools.sh
16:00.16Mirellncopa: Why do you want disable e2fsprogs?
16:00.58ncopait failed to build due to some internationalization crap
16:00.58ncopai dont think i need it
16:01.04ncopaim only interested in a native uclibc-nptl toolchain
16:01.17ncopawhich i can chroot into
16:01.22MirellOh, so your *host* system is uClibc based.
16:01.24MirellInteresting.
16:01.29ncopayes
16:01.32ncopaits alpine linux
16:01.33MirellYah, you can just comment/remove the e2fsprog lines.
16:01.52MirellAnd probably poke landley on the mailing list about that dependency.
16:02.14ncopaim working on uclibc with nptl for my alpine linux distro
16:03.28ncopaseems like i need to bootstrap the toolchain from scratch
16:04.43MirellEh?
16:29.52ncopai already have a native uclibc toolchain
16:29.55ncopawith linuxthreads
16:30.05ncopai want to switch to nptl
16:30.16ncopabut they are not abi compatible
16:33.22MirellAh, yah.
16:41.14ncopahum
16:41.22ncopamy hostcc seems to segfault
16:48.10MirellDas ist nicht gut.
16:49.20*** join/#edev JoeLlama (n=snork@206.169.63.10)
16:57.11*** join/#edev PureSine (n=PureSine@87.247.172.139)
17:47.18*** join/#edev dfarnsworth (n=dfarnswo@nat/montavista/x-lawzzmnatmzfsksb)
18:06.09*** join/#edev RemoteSine (n=chatzill@87.247.172.139)
18:34.10*** join/#edev eox425 (n=root@213.133.177.11)
18:36.46*** join/#edev Redhatter (n=vk4msl@2001:388:f000:0:0:0:0:71)
19:12.51*** join/#edev roxfan (i=dunno@139.220-240-81.adsl-dyn.isp.belgacom.be)
19:14.43*** join/#edev brolin (n=brolin@nat36.udea.edu.co)
19:21.16*** join/#edev florian (n=fuchs@Maemo/community/contributor/florian)
20:30.36*** join/#edev archae0pteryx (n=snewman@207.47.42.130.static.nextweb.net)
20:58.26*** join/#edev PureSine (n=PureSine@87.247.172.139)
21:46.47Mirellls
21:46.50MirellGah.
21:50.11MonMothahum, looking for a hackable A/B/G/N WAP that doesn't cost an arm and a leg
21:50.31MonMothaalternately, not hackable but supports 802.1af and 802.1q
22:09.07SpeedEvilq?
22:09.14SpeedEvilneeds to keep up.
22:56.13MonMotha802.1q is tagged vlans
22:56.32MonMothaand I may mean 802.3af.  Whatever the PoE standard is.
22:57.05MonMothaI also need WPA2 preferably "enterprise" support (I can run my own RADIUS server)
23:04.23SpeedEvilah
23:04.58SpeedEvilI wanted to find out how long and how many packets the powersave intervals were minimum on routers.
23:05.18SpeedEvilI started reading the standard, but my head exploded at about the 7th level of indirection.
23:05.39SpeedEvil(I wanted to see if it was plausible to sleep for 60s, and wake for 5)
23:06.17MonMothaI generally expect my routers to forward things immediately...
23:09.42SpeedEvilyeah - the powersaving thing can be useful.
23:10.50SpeedEvilMy laptop is at the moment suspending and resuming the wireless card several times a second, and using a moderately small fraction of its always on power.
23:11.03MonMothaoh, that
23:11.15MonMothaI thought you meant actually suspending like a consumer router appliance
23:11.37SpeedEvilhowever - it'd be useful in some circumstances if you could have the connected device suspend for much longer periods.
23:12.00MonMothawell, you can do that, but you'll miss anything that shows up during that interval until you turn the receiver back on and "hear" it
23:12.09MonMothaunfortunately, the receiver consumes a non-trivial amount of power
23:12.19SpeedEvilThat's the point of the router supporting it too.
23:12.22MirellWake-On-LAN wireless!
23:12.30SpeedEvilIt doesn't miss anything, but queues the packet.
23:12.40SpeedEvilthe whole radio is off for large portions of the time.
23:13.02MonMotharight, but that'll still give you very high latency
23:13.12MonMothaand it would also require a lot of RAM on the AP
23:14.59SpeedEvilIf my laptop is sitting in the corner, not plugged in, I don't actually care that IRC/SMTP/... packets sometimes get delayed by under the timeout period.
23:15.06SpeedEviland yes, sometimes
23:15.25MonMotha60s is enough that some things will time out, though
23:15.54SpeedEvilyes.
23:15.55MonMothaI'm not sure what off 60/on 5 buys you over off 6/on 0.5 for example
23:16.03MonMothaor even off 0.6/on 0.05
23:16.12MonMothathere's some overhead in the state transition, but it's pretty quick
23:16.29SpeedEvilyou can't do suspend and resume to RAM in 0.5s on normal hardware that's not designed for it.
23:16.41MonMothaoh, you're attempting to actually STR the whole machine?
23:17.08MonMothathis seems like a good candidate for a separate application processor that's much lower power to handle "always on" networking applications such as chat
23:17.18SpeedEvilyes. and yes, of course it would be good.
23:17.24SpeedEvilBut that required hardware.
23:17.28MonMothathat's how mobile phones work these days.  The RF processor stays somewhat alive and can wake the application processor any time
23:17.29SpeedEvilrequires
23:17.51MonMothahowever, just do it.  TCP will retry
23:18.23MonMothano consumer grade AP has enough RAM to seriously do what you propose, though
23:18.34MonMothamost of those things have like 8 or 16MB of RAM
23:18.50MonMotha1/2 to 3/4 of which is consumed just to run the OS
23:18.50SpeedEvilTCP will retry.
23:19.09SpeedEvilhowever, exponential backoffs will kill you in the face of no packet queuing.
23:19.19MonMothayes
23:19.29MonMothabut you can't have packet queuing without some serious hardware
23:19.58SpeedEvilThis solution would at most typically put a window size of data in the queue per 60s - so it's not typically huge.
23:20.05MonMothathere is wake on WLAN.  You could possibly use that
23:20.27MonMothaSTR the machine and have the AP/router send a wake on WLAN packet whenever there's data or the queue gets full
23:20.32SpeedEvilI think the only realistic solution is actually a userspace vpn thingy with queue
23:20.45MonMothathat requires keeping the RF receiver active, but that won't kill you as badly as keeping the whole laptop up
23:21.02MonMothayou may be able to pull this off using the Linux traffic control stuff
23:21.15MonMothait's got some pretty advanced queuing stuff, but I don't know how it interacts with the 802.11 MAC
23:21.53SpeedEvilYeah - problem is that none of that is actually supported typically, even if the hardware will actually do that.
23:22.10MonMothaall you need is to hold the packet in the queue until there's a MAC level acknowledgement
23:22.33MonMotharetry one packet (the head of the queue) every 1s or so until you get to send a MAC level ack, then flush the queue
23:22.34SpeedEvilI was looking for a fairly generic solution, that would work on most laptops that would suspend and resume from RAM rapidly.
23:23.17MonMothaI don't think there's already support for such a queue in the tc stuff in linux, you could probably add it if you can get notification of the 802.11 MAC level ACKs
23:26.35SpeedEvilI need to look at it again, yeah, that would be a reasonable starting point

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.