<j4s0nmchr1st0s>
DocScrutinizer05: 11 yr old bug still not fixed?
<DocScrutinizer05>
I do't know if it's fixed
<DocScrutinizer05>
I just stumbled over that 11 y old bug report of mine
<j4s0nmchr1st0s>
yes, I recall making reports that were never taken care of usually about security
jonwil has joined #neo900
<jonwil>
hi
<j4s0nmchr1st0s>
hi
<j4s0nmchr1st0s>
jonwil: What is going on>
<jonwil>
still fiddling with PulseAudio
<jonwil>
and still fiddling with the browser stuff
<j4s0nmchr1st0s>
On the phone?
<jonwil>
yes
<j4s0nmchr1st0s>
A prototype or is it now sold?
<jonwil>
no, not the Neo900, just software work
<jonwil>
but to support the phone :)
<jonwil>
both N900 and Neo900
<j4s0nmchr1st0s>
Doesn't pulse introduce latency?
<jonwil>
you obviously know nothing about the N900 or Neo900 otherwise you would know where PulseAudio fits into all this
<j4s0nmchr1st0s>
Nothing more than a quick look at the page.
<j4s0nmchr1st0s>
There are thousands of current phone models.
<jonwil>
but the only ones relavent to this channel are the N900 and Neo900
<freemangordon>
jonwil: hi!
<freemangordon>
jonwil: the last time I tried, building upstream mozilla in SB worked, as is the resulting bunary
<freemangordon>
like snail, as you can imagine, but still
<freemangordon>
building like "desktop build"
<kerio>
freemangordon: pls build the latest firefox :3
<freemangordon>
what for?
<freemangordon>
the UI is so bloated that it is simply unusable
<kerio>
:(
<freemangordon>
the only thing I can think of that can make upstream gecko/embedlite usable on n900 is to somehow teach https://projects.gnome.org/gtkglext/ to use gles
<Wizzup>
I guess I am reposting stuff you already know
<jonwil>
Basically we have 3 things we need to care about re the browser. The first is the interface between the browser engine and the things that use it. With the exception of nokia-maps, everything else uses browser-neteal to talk to tablet-browser-daemon so we just need to expose the same dbus interface as stock tablet-browser-daemon.
<Wizzup>
dbus wrappers should be trivial though right? :)
<jonwil>
well tablet-browser-daemon is FOSS as is basically everything it pulls in
<jonwil>
so we are good on that
<jonwil>
browser-neteal is also FOSS
* Wizzup
is now wondering why exactly it needed dbus, but whatever :D
<jonwil>
It uses dbus as an inter-process-communication method
<jonwil>
to talk between the browser daemon (tablet-browser-daemon aka browserd) and the things that use it (briwser-ui etc)
<Wizzup>
The whole embedlite thing, does that use a recent xulrunner?/gecko?
<Wizzup>
jonwil: I see
* Wizzup
would love to help out coding and stuff btw, but my free time looks very limited
<jonwil>
The second issue is the plugins. For Flash we just need to make sure the npapi interface is ABI compatible between current browser engine and new browser engine (making the necessary changes to new-browser-engine to make that happen)
<jonwil>
same thing for tablet-browser-default-plugin and tablet-browser-mediaplayer-plugin
<jonwil>
microb-geolocation will probably need forward porting as its more closely linked to actual Gecko APIs
<jonwil>
its FOSS so we can do that
<jonwil>
Not sure what libssoautologin is for but that will possibly need to be cloned and forward ported
<jonwil>
and something will need doing about Nokia Maps
<jonwil>
The third issue we need to care about is all the maemo specific functionality in microb that isn't in modern Gecko. e.g. stuff related to network connectivity via various maemo libs (to name one thing I know of)
<jonwil>
Hence the need to find all the bugs in Mozilla bugzilla related to removing that functionality or otherwise changing it in ways that need to be undone to work on Maemo
<Wizzup>
alopex is quite neat..
<Wizzup>
just tried it
<jonwil>
being able to talk to romaxa (guy who did work on microb/gecko back in the day and may know some things) or other guys who know stuff about gecko/microb would also help
<jonwil>
but getting in contact with romaxa seems impossible
arcean has joined #neo900
* jonwil
is getting nowhere with this pulseaudio stuff
<freemangordon>
jonwil: what is the problem?
<jonwil>
Getting stuck trying to figure out the rest of this massive userdata structure
<freemangordon>
oh, I see
<DocScrutinizer05>
morning
Pali has joined #neo900
* DocScrutinizer05
just glares at "Errors (506); Warnings (842)" :-S
<DocScrutinizer05>
ERC
<DocScrutinizer05>
well, that's what you get in eagle for placing a eMMC and a SoC on a sheet and simply not connecting them
<jonwil>
still no luck getting in touch with romaxa either :P
<DocScrutinizer05>
air pumping: PETRA 20 mm^3; TINY 27mm^3
<DocScrutinizer05>
dimensions: TINY 8x12x2.5; PETRA 8x12x2.0
<DocScrutinizer05>
PETRA: 32 Ohms; TINY: 8 Ohms
<DocScrutinizer05>
freemangordon: some of the specs for TINY from http://www.digikey.com/Web Export/Supplier Content/Knowles_423/PDF/knowles-pi-mic-receiver-speaker-portfolio.pdf?redirected=1 might help with XPROT, they may show up in (converted, derived) constants there
<DocScrutinizer05>
others may - and will - show up in EQ
<DocScrutinizer05>
digikey only knows of knowles PETRA for speakers 12x8
<DocScrutinizer05>
I kinda doubt any other manufacturer sold a (at least mechanically) compatible 12x8 speaker
<DocScrutinizer05>
but I'd love to get proven wrong ;-)
<DocScrutinizer05>
we have a 2.8mm headroom which N900 couldn't dream of, where we *could* place larger than 12x8 speakers of max height: 2.8mm *if* we cut huge windows into LOWER PCB *and* find a way to connect those new speakers to the cavity/tube where TINY been in case
<DocScrutinizer05>
sealed connection
<DocScrutinizer05>
IOW even when the transducer is larger than 12x8, it must have a membrane aperture (or backside pot vent) of no larger than 12x8
<DocScrutinizer05>
and tuning that new acoustic system will be a nightmare
<DocScrutinizer05>
quite possibly the then empty cavity of 12x8x2.5mm will create a nasty resonance peak together with the membrane Q and the tube from cavity to free air
<DocScrutinizer05>
oooh, the effective cavity will be quite different than 12x8x2.5, since the case creates backside resonance volume for the TINYs
<DocScrutinizer05>
quite a bit of it, and it would connect to the "front" volume of a new oversized speaker's membrane
<DocScrutinizer05>
um nope, scratch that. The resonance chamber volume connects to front of TINY as well
<DocScrutinizer05>
weird
<DocScrutinizer05>
backside (pot) volume is actually 'tiny'', barely more than the pot itself plus a maybe 0.5mm layer of empty space from backside of speaker to PCB
<wpwrak>
hmm yes, digi-key looks pretty bleak. they have PUI and knowles. we already know that knowles doesn't have what we want, and pui only has 13 x 13 x 4 mm. probably quite the ghetto blasters :)
<DocScrutinizer05>
stay tuned for photos
<DocScrutinizer05>
some surprising funny stuff involving a solder wire
<DocScrutinizer05>
and it even shows that the acoustic design (resonance volumes) won't change that much when placing an e.g. Knowles GRAND on the seal that formerly sealed backside volume of TINY to PCB
<DocScrutinizer05>
*might* be feasible
<wpwrak>
what do the photos show ? a) they all seem to have the same content, b) did you find some alternative speakers and they are in the case ?
<DocScrutinizer05>
main problem (besides real estate eaten by speaker on LOWER bottom and top side for window, plus on UPPER bottom side for placing speakers) is the size of membrane plus fixture of GRAND that doesn't exactly fit to the outer seal of the chamber
<DocScrutinizer05>
wpwrak: it shows the cavity in case where the speaker usually lives
<wpwrak>
ah, okay. so we still need to find something to put inside :)
<DocScrutinizer05>
the inner torn-apart foam seal is where the TINY been glued to
<DocScrutinizer05>
the outer seal seals the backside volume of TINY to PCB
<DocScrutinizer05>
((put inside) yes, for that we'd need some 12x8x(<)2.5 transducer
<DocScrutinizer05>
which might be hard to find
<DocScrutinizer05>
unless we could source TINY
<DocScrutinizer05>
see my weird idea as of >><DocScrutinizer05> we have a 2.8mm headroom which N900 couldn't dream of, where we *could* place larger than 12x8 speakers of max height: 2.8mm *if* we cut huge windows into LOWER PCB *and* find a way to connect those new speakers to the cavity/tube where TINY been in case<<
<wpwrak>
(cavity size) my measurements tell me about 12.6 x 8.9 mm. so not a lot of slack
<DocScrutinizer05>
that's the backside "volume", yes
<DocScrutinizer05>
pretty hopeless to find a replacement for TINY, in my book
<wpwrak>
ask knowles ?
<DocScrutinizer05>
sure
<DocScrutinizer05>
but yiu know how that usually works
<DocScrutinizer05>
particularly when asking for a maybe 1000 or 2000 units
<DocScrutinizer05>
knowles CR dude <thinking>How many?? 2k?! Let's see: 11ct/unit win margin, that's 0.11*2000 = 220 bucks, now how much is my employer paying for me per hour...?</thinking>
<wpwrak>
depends a lot. some companies are nice, some aren't.
<DocScrutinizer05>
anyway what do you think of my weird (but brilliant as usual ;-P) idea?
<DocScrutinizer05>
use seals between UPPER and LOWER to form a hermetic backside chamber
<DocScrutinizer05>
use a seal on bottom side of LOWER to seal transducer to that "chamber"
<DocScrutinizer05>
the outer seal of original chamber (12.6 x 8.9 mm inner size, according to you), would _almost_ fit to front side of GRAND
<DocScrutinizer05>
membrane size (incl membrane suspension) of GRAND: 15.6x10.6
<DocScrutinizer05>
total height of GRAND: 2.5mm
<DocScrutinizer05>
+0.3mm for membrane overshot
<DocScrutinizer05>
overshoot
che1 has quit [Ping timeout: 256 seconds]
paulk has joined #neo900
paulk-collins has joined #neo900
paulk has quit [Remote host closed the connection]
paulk-aldrin has joined #neo900
che1 has joined #neo900
<DocScrutinizer05>
outer size of outer seal: 10.9x15.7mm
<DocScrutinizer05>
so it actually kinda "fits"
<DocScrutinizer05>
distance between LOWER and UPPER: 2mm. Plus thickness of UPPER PCB: 0.8mm = 2.8mm = height of GRAND (2.5mm) + overshoot (0.3mm)
<DocScrutinizer05>
s/UPPER/LOWER/
<DocScrutinizer05>
some additional seal glued to bottom side LOWER will improve the sealing between front side of GRAND membrane (aka window in LOWER) and chamber in case. The ~0.1mm overlapping between PCB and outer seal on chamber is a tad on the too low side
<DocScrutinizer05>
0.1 resp 0.3
<DocScrutinizer05>
15.6x10.6 vs 15.7x10.9mm
<DocScrutinizer05>
GRAND is *much* stronger than TINY :-)
paulk-aldrin has quit [Quit: Quitte]
paulk-collins has quit [Remote host closed the connection]
<DocScrutinizer05>
slyon is too optimistic regarding "soon they will present their current sttae device at OHSW14", we're late for that
<DocScrutinizer05>
a pity but what can we do? proto_V2 will not appear before end of year
<DocScrutinizer05>
and again the usual stereotypes like "resistive touchscreen? total dealbreaker" and "USD1000? are they mad?"
<DocScrutinizer05>
and the usual noise about baseband firmware, despite we really elaborated on that topic by now
<DocScrutinizer05>
dos1: seems your complete talk (plus some hours more) could easily get filled with elaborating on "how secure can a mobile phone get today? and how?"
<DocScrutinizer05>
starting at shared RAM / SoC with integrated modem, then separation of modem, FSF/RMS' take on "everything with firmware not updateable is no software", why we nevertheless think update is a good thing, why even non-update-option policy is _not_ making modem any more secure, short excursion to script kiddies messing on baseband firmware to implement "1337 phne2phone walkietalkie" and thus taking down whole cells" (potentially if they
<DocScrutinizer05>
were able to mess with FW), then explaining our approach of considering everything with closed blob firmware as EVIL[TM] and engineering around it in a way as if it was as evil as it gets, and how this _guarantees_ that a huge number of attack vectors (actually all valid and feasible ones we can think of so far) are dealt with by our approach
astr has quit [Ping timeout: 264 seconds]
<DocScrutinizer05>
"valid" here means: (for example) we cannot deal with OTA "wiretapping" since we cannot implement our own better encryption for baseband GSM voice, so any concerns regarding that are not in the scope of a secure phone hardware, thus not valid. We however will allow/support GSM voice encryption in a secure way, as already done by several apps (in a less secure way than possible on Neo900) and dongles
<DocScrutinizer05>
other example: we cannot implement a SPI firewall into the GSM antenna wire to filter/block OTA update of modem firmware (even though it's unlikely that the modem will allow that - we nevertheless consider the modem being "rogue")
<DocScrutinizer05>
but we can make sure there's no data traffic of several dozens of megabyte when the linux system isn't expecting any such data traffic, and thus we can abort any such OTA update (unless we are doing bulk data downloads by a valid app like browser or whatever concurrently)
<DocScrutinizer05>
any OTA update won't have means to synchronize it to valid user data download, so any such update would get exposed and discovered pretty soonish, usually
<kerio>
DocScrutinizer05: how are cells so fragile, tho
<DocScrutinizer05>
again, we don't worry too much about OTA update since we already consider modem rogue, to start with
<kerio>
DocScrutinizer05: how much storage does the modem even have?
<DocScrutinizer05>
kerio: why is your average WLAN so riddled by interference and disruptions?
<DocScrutinizer05>
(storage) how should I know?
<kerio>
i dunno, i just bump up the tx power on mine :3
<DocScrutinizer05>
(bump up) exactly the pattern that kills whole cells
<kerio>
i thought that linux fed the modem its firmware on boot
astr has joined #neo900
<kerio>
appropriately signed, w/ever
<DocScrutinizer05>
nope!!
<kerio>
doesn't that happen for stuff like wifi cards
<kerio>
?
<DocScrutinizer05>
yes
<kerio>
the reason you have to install b43-firmware for broadcom devices on stallmann-y distros
<DocScrutinizer05>
but WLAN firmware is about 3 to 5 magnitudes smaller
<DocScrutinizer05>
compared to the complete GSM/UMTS/LTE stack incl all supplementary stuff like SIM talk and AT chatter and audio DSP and whatnot, WLAN is a lame joke of simplicity
<DocScrutinizer05>
>>From what I've heard, every phone with data capabilities (every phone) has another embedded system-on-a-chip that your android, or whatever runs your phone that you interface with, is slaved to. << "moistmoistrevolution [score hidden] 19 minutes ago "
<DocScrutinizer05>
BZZZZZ wrooooong!
kolp has joined #neo900
<enyc>
DocScrutinizer05: =)) and how much of that 'stuff' needs changing to connect modem over USB instead of [whatever shared memory bus]
<DocScrutinizer05>
at least the last 3 words "is slaved to"
<DocScrutinizer05>
enyc: huh? on Neo900 this IS already done
<enyc>
DocScrutinizer05: nodsnods, but was this done specificalyl for neo900 ?? doesn't that depend upon the software distro/version ? or all in a shared kernel that we get them to all use?
<bencoh>
we just take a usb modem .... and use a usb driver
<enyc>
bencoh: aha, ok! -- so didn't need to redesign that part of intreface/softawer to not make such shared-memory-assumpitons, [ok] that makes sense1
<DocScrutinizer05>
how's hw design depending on OS? isn't it the other way around?
<bencoh>
DocScrutinizer05: hmm btw, do you actually have FOSS drivers ?
<bencoh>
s/you/we/
<DocScrutinizer05>
for what?
<bencoh>
modem
<kerio>
isn't it a serial usb
<kerio>
?
<bencoh>
(and voice controle)
<bencoh>
I dunnno ... is it pure AT ?
<dos1>
bencoh: it even already works with fsogsmd
<bencoh>
wow, impressive :)
<dos1>
bencoh: I have used it a few times as data dongle for my laptop ;)
che1 has quit [Ping timeout: 260 seconds]
<dos1>
plus did some test calls and smses as well (no audio yet, but that won't be any problem on future boards, it's standard pcm)
<DocScrutinizer05>
and no, PCM is via dedicated line
<bencoh>
DocScrutinizer05: you know I wasnt talking about just data ;)
<dos1>
bencoh: nope, separate lines connected to audio codec
<kerio>
most if not all USB UMTS dongs are some magic initialisation procedure and then just a standard usb serial connection for AT commands
<dos1>
which is btw controlled by CPU, so that's CPU who decides if modem have access to microphone etc., not the modem itself
<DocScrutinizer05>
"mgic" like in "ATD**99#" ?
<bencoh>
hmm, okay
<kerio>
the initialisation procedure is just to make the damn "driver disc" disappear
<kerio>
DocScrutinizer05: no, usb eject
<dos1>
it was the same way on neo freerunner and gta04
<DocScrutinizer05>
aah, that one
<enyc>
kerio: yes i rememabal all that =)).
<enyc>
kerio: ozerocdoff of something like that
<dos1>
kerio: PHS8 is saner in this regard - after all, it's meant to be embedded in other devices, so no need for "driver disc" :)
<DocScrutinizer05>
it's even same (PCM to codec) on N900
<DocScrutinizer05>
;-)
<kerio>
yeah i'd really hope so
<kerio>
it would be silly to have an embedded usb modem that provides a virtual cdrom
<bencoh>
:))
<dos1>
it does have a few distinct modes of operation - you can have two AT channels, NMEA channel and QMI (propertary protocol, but with existing free implementation libqmi-glib) channel, and you can configure them in several ways
<dos1>
like "first AT channel on UART, the rest on USB", or "everything on USB", or "only NMEA on UART, everything else off" etc
<bencoh>
qmi ? qualcomm protocol ?
<dos1>
hmm, the last one actually might not be true... that would be deadlock, so s/NMEA/AT/ :)
<DocScrutinizer05>
hehe
<dos1>
bencoh: yup
kolp_ has quit [Ping timeout: 255 seconds]
<dos1>
my neo900 protoboard (the same Nikolaus showed on last OHSW) even works with plain networkmanager, as it supports qmi
<bencoh>
funny they decide to implement it
<dos1>
bencoh: there's some qualcomm chipset inside the modem
<bencoh>
oh, okay
<kerio>
well, networkmanager > icd i guess
<DocScrutinizer05>
yeah
<DocScrutinizer05>
sure
<kerio>
no?
<DocScrutinizer05>
yes
<DocScrutinizer05>
I think NM talks AT to USB dongles
<DocScrutinizer05>
our modem would moszt likely ENUM as tty_acm or sth like that
<DocScrutinizer05>
speaking AT
<DocScrutinizer05>
for other protocols you have to switch protocol by AT command I guess
<DocScrutinizer05>
might be sticky though
<DocScrutinizer05>
anyway, what been the question? aaah >><bencoh> DocScrutinizer05: hmm btw, do you actually have FOSS drivers ?<< We don't need any special drivers
<DocScrutinizer05>
and we wouldn't have any such special drivers when we would need them, since we're not entitled for receiving them
kolp has joined #neo900
<bencoh>
:)
<DocScrutinizer05>
that's why we call the device "open hardware"
<DocScrutinizer05>
one of the reasons why we do this
* DocScrutinizer05
feels like repeating himself
kolp_ has quit [Ping timeout: 255 seconds]
<kerio>
DocScrutinizer05: yeah but do you have drivers
<kerio>
?
<DocScrutinizer05>
I'm using bus and tram
<DocScrutinizer05>
they have drivers
<kerio>
not necessarily!
<DocScrutinizer05>
except our new U3
<kerio>
there's driverless subways
kolp has quit [Disconnected by services]
kolp_ has joined #neo900
<DocScrutinizer05>
yes, I know, based on technology I helped developing
<kerio>
the smallest little piece of the C line in rome had its inauguration yesterday
kolp_ has quit [Read error: Connection reset by peer]
<DocScrutinizer05>
I wonder when people will learn that additional hardware needed for improved security also causes additional cost
<DocScrutinizer05>
(the above actually even applies to metro as well ;-D )
<DocScrutinizer05>
but been meant for those "wut? a 1000 bucks?" whiners
<Pali>
network manager does not have support for modems (AT or whatever)
<Pali>
it use another piece of daemon which using modems
<DocScrutinizer05>
mhm, possible
<dos1>
right, it's called ModemManager
<Pali>
either modemtmanager
<Pali>
or ofono
<DocScrutinizer05>
lol, ofono
<DocScrutinizer05>
now I see where from that damn phonet kernel module comes
<Pali>
phonet comes from nokia
<Pali>
also AF_PHONET socket
<DocScrutinizer05>
sure, but Nokia doesn't push kernel modules onto my PC
<Pali>
no, they pushed too :-) in standard linux distribution kernels you could see phonet.ko
<Pali>
also usb phonet gadget
<DocScrutinizer05>
and that module wouldn't make it into each and every standard distro installation when there wasn't something *using* it
<Pali>
basically usb phonet driver is using phonet
<Pali>
and if you connet n900 in pcsuite mode into computer it export via usb phonet stack
<Pali>
and desktop linux kernel with load phonet driver for that usb connection
<Pali>
and then you can see phonet0 network interface
<Pali>
and you can use AF_PHONET socket on phonet0
<DocScrutinizer05>
yes, and that's exactly complete bullshit since I have no app ever wanting to use that crap
<Pali>
or you can start ofono on desktop and it will talk to nokia n900 modem via phonet0 via usb
<dos1>
I think some symbian phones exported phonet interface via usb as well
<Pali>
yes, there are no apps (except ofono) which can use that phonet stack
<DocScrutinizer05>
ofono is an APP?
<Pali>
it is daemon which export dbus-api
<DocScrutinizer05>
ohmy
<Pali>
and ofono has cmdline applications which using ofono dbus api
<dos1>
fsogsmd has some unfinished support for phonet
<Pali>
so basically there are some applications which can use them
<DocScrutinizer05>
nothing called ofono or similar known on my distro
<Pali>
and I forgot, there *is* telepathy-ring and connman which can use ofono
<Pali>
so you can start telepathy-ring in your telepathy application (e.g kde-telepathy or empathy) and if you have ofono installed, you can start voice calls
<Pali>
or send/receive sms
<DocScrutinizer05>
wow, geoclue-gsmloc has "ofono" in description text
<Pali>
I have ubuntu 12.04 LTS (2 years old ubuntu) and it has ofono package
<DocScrutinizer05>
e_dbus depends on libeofono.so.1()(64bit)
<Pali>
ah... nokia flasher was unable to flash n900 when cdc_phonet was loaded... right?
<DocScrutinizer05>
yep
<Pali>
probably they did not hear about function usb_detach_kernel_driver_np() :D
<DocScrutinizer05>
probably they didn't
<DocScrutinizer05>
neither did I ;)
<Pali>
it is libusb function
<Pali>
use use libusb for communication with usb devices from userspace
<DocScrutinizer05>
and what stops udev or whatever from loading the driver again, as soon as you plug in N900?
<Pali>
and you need to open usb device (it returns handle), then you need to detach kernel driver on specified handle and after that you can send/receive data via usb
<Pali>
kernel stops it
<DocScrutinizer05>
why?
<Pali>
because you lock bus from userspace
<DocScrutinizer05>
well, only when you never quit the flasher, right?
<Pali>
if driver is modprobed again it cannot alloc device
<Pali>
yes, when you quit flasher, userspace will drop lock
<Pali>
and kernel can bind driver again
<DocScrutinizer05>
exactly that happens on usual PC
<Pali>
but you can again open usb device from userspace and tell kernel to detach kernel driver
<DocScrutinizer05>
you do a modprobe -r cdc_phonet, you flash COMBINED, and after that you fail on flashing VANILLA
<DocScrutinizer05>
since cdc_phonet is loaded again
<DocScrutinizer05>
yeah, should work
<Pali>
yes, but once you flash combined usb device is disconnected and connected again
<DocScrutinizer05>
well, I hope 0xFFFF is fixing that issue :-)
<Pali>
and you need to open device again and again need to detach kernel driver
<Pali>
0xFFFF should have fixed this logic
<DocScrutinizer05>
great! :-)
<Pali>
at least on my machine I have loaded that cdc_phonet driver and I can use 0xFFFF without problem
<Pali>
I could imagine only problem on slow machines, where detaching kernel driver takes more time then n900 flasher timeout
<Pali>
but for that pressing U key hack can be used
<DocScrutinizer05>
err, the recommended procedure is to first start flasher, only _then_ plug in N900
<Pali>
yes
<DocScrutinizer05>
but yeah, when you script all that, with two consecutive flasher invocations, you might run into race condition
<DocScrutinizer05>
(scriptinmg the stuff is what I just am about to complete)
kolp has joined #neo900
<Pali>
I can try to test what happen... but I think only one instance will be able to open/claim usb device
<DocScrutinizer05>
evidently flasher cannot open USB when cdc_phonet locked it
<DocScrutinizer05>
or maybe just cannot use it, open() might still work, dunno
<DocScrutinizer05>
anybody ever heard about a shell option (NOCLOBBER?) that causes a ">>" redirection to fail if the file doesn't exist and a ">" redir to fail when the file already exists?
<nox->
yeah thats a useful thing
<nox->
setopt noclobber with zsh
<DocScrutinizer05>
seems it's lacking one of both properties I mentioned above
<DocScrutinizer05>
aaah, in zsh, that's maybe why I can't find it in bash
<nox->
yeah dunno about bash
<DocScrutinizer05>
in bash it seems it'seither lacking the ">>" or the ">" function, can't remember which of both
<nox->
well not warning about >> is less harmful
<nox->
than the other
<DocScrutinizer05>
>> -C If set, disallow existing regular files to be overwritten by redirection of output. <<
<DocScrutinizer05>
:-/
b1101 has joined #neo900
<DocScrutinizer05>
ohnoes! a bug!
<DocScrutinizer05>
;-P
jonwil has joined #neo900
<jonwil>
hi
b1101 has quit [Quit: b1101]
<DocScrutinizer05>
jonwil: hi!
<freemangordon>
jonwil: hi!
<jonwil>
saw your latest xprot work, looking good
<freemangordon>
just pushed a bugfix
<freemangordon>
:)
<jonwil>
how much is left for xprot?
<freemangordon>
about half?
<freemangordon>
or less
<jonwil>
ok
<jonwil>
still getting nowhere with any of the things I am doing...
<Pali>
consolekit is bad... but better then systemd
<Pali>
"The 63 threads issue has been resolved if the Linux kernel has support for the notification required."
<Pali>
finally!
<Oksana>
Shouldn't it be possible to measure exactly how much data apps want to get, and how much data arrives over air, and still abort OTA if too much data arrives over air? Sure, apps will complain about Internet interruption, but they should be able to handle it. <quote> unless we are doing bulk data downloads by a valid app like browser or whatever concurrently
<Oksana>
Good morning
<DocScrutinizer05>
Oksana: how would you check how much data exactly is received OTA?
<ds2>
watch the counters on ppp0 or iptables?
<Oksana>
Hmm... What would the modem-monitor know about data being received OTA?
<ds2>
oh really over the air...n/m
<DocScrutinizer05>
only a rough estimation based on total RF activity
<Oksana>
The real problem would be if the modem took "valid data", added "modem update" and compressed the sum so that it would weigh about as much as the "valid data" by itself.
<DocScrutinizer05>
he only valid way is to temporarily stop app data RX (for sth like 2 seconds) and see if there's still RF activity that looks like inbound data
<Oksana>
Yes :-) That's the paranoid way of checking if "update" tries to sneak in together with "valid data".
<DocScrutinizer05>
modem doesn't even offer a tally about data volume received, and even if it did, who gives warranty that OTA update shows up there
Svetlana has quit [Remote host closed the connection]
che1 has joined #neo900
Svetlana has joined #neo900
<DocScrutinizer05>
of course you also could try to check what's the theoretical bandwidth available and then frown when you don't see that bandwidth delivered on your user data. That however assumes that there's no other bottleneck in the intarnets
<Oksana>
If "update" wanted to hide, it would be simple for modem to 'notify' the "update-source" when modem notices large flow of "valid data" through itself <quote> any OTA update won't have means to synchronize it to valid user data download
<Oksana>
"Theoretical bandwidth" is difficult to estimate when it depends on strength of signal.
<Oksana>
Any news from Gerry?
<DocScrutinizer05>
but honestly, most safe way is to never have data download bursts of longer than - say - 3 seconds. Take a break of at least 3 seconds after that and check for RF going into a state that's in line with expectations for "no data traffic"
<DocScrutinizer05>
I'd tell when there were any news
<DocScrutinizer05>
you don't need to poll. Polling is evil
<DocScrutinizer05>
;-)
<Oksana>
Chargers are moving like a snail... Or a grasshopper. They were in the same city, and now they are far away. Why? Asking the post; they will reply within two days (hopefully)
<DocScrutinizer05>
I work event triggered here
<Oksana>
:-)
<j4s0nmchr1st0s>
Oksana!
<Oksana>
j4s0nmchr1st0s!
<DocScrutinizer05>
please!
<Oksana>
What's the question?
<j4s0nmchr1st0s>
Oksana: I was asking where you were.
<j4s0nmchr1st0s>
Oksana did you move out of L.A. ?
<Oksana>
So, sorting patches into categories: harmless UI for usability (which still work as-is in newest Gecko), patches which were integrated into Mozilla-latest already (thus, not needed any more), and patches which need to be done differently because latest-Gecko is different.