freemangordon has quit [Ping timeout: 245 seconds]
freemangordon has joined #neo900
Humpelst1lzchen has joined #neo900
Humpelstilzchen has quit [Ping timeout: 264 seconds]
gurki has quit [Ping timeout: 244 seconds]
Kabouik has quit [Ping timeout: 252 seconds]
ashneo76 has quit [Ping timeout: 265 seconds]
ashneo76 has joined #neo900
ilon has joined #neo900
<ilon>
o/
<ilon>
DocScrutinizer51: Tried to search for it yesterday, but did not find a clear answer: What are the current take on JTAG access?
paulk-collins has joined #neo900
arcean has joined #neo900
sparetire has quit [Quit: sparetire]
Pali has joined #neo900
quatrox has quit [Ping timeout: 245 seconds]
SylvieLorxu has joined #neo900
norly has joined #neo900
<DocScrutinizer05>
ilon: I want to get JTAG available on the testpoints under battery, if feasible.
<DocScrutinizer05>
feasibility depends on number of GPIO we need, and if we can find a GPIO assignment that maybe allows JTAG dual-use
<DocScrutinizer05>
anyway JTAG is important for us on fab QA, not so much for end user who can debrick the device in a number of ways and load own code to CPU/RAM via USB
<DocScrutinizer05>
ICE debugging needs JTAG iirc, so that would be a very useful thing to do with JTAG, beyond the boundary scan in fab
<DocScrutinizer05>
in case you got a lauterbach or similar ICE
<DocScrutinizer05>
on a sidenote about digital video output: it wasn't until yesterday that it occurred to me that mini-HDMI is even a tiny bit smaller than micro-USB and it might be physically possible to get a HDMI jack in/below spacerframe. Alas this might mean that NeoN board doesn't fit into original case that has no mechanical cutouts. IOW all DIY-swap users would need to grab the file or board won't fit
<DocScrutinizer05>
well, actually the quoted 2.8mm height of Micro-HDMI vs only 1.8mm of Micro-USB seem correct, quite amazing I can't really see and feel the difference on a cursory look
<ilon>
DocScrutinizer05: Alright, much as expected then.
<ilon>
DocScrutinizer05: I were looking at ways of CPU-bound encryption (and points of failures for such), and JTAG would be one possible (?) way to defeat it
<DocScrutinizer05>
ooh great! the "headroom" from HDMI-jack rim (front) to rim of HDMI-plug plastic sleeve is a comfortable several millimeters. Which means we could place the (hypothetical so far) jack so "deep" into device that the NeoN board will even fit into unmangled N900 case
<ilon>
DocScrutinizer05: But there are ways to defeat it with the help of DMA and possibly JTAG
<DocScrutinizer05>
hmmm, dunno
<DocScrutinizer05>
to get checked whether you _can_ JTAG-trace ROMBOOT
<DocScrutinizer05>
anyway I take a note to self: "allow for JTAG pad removal)
<DocScrutinizer05>
"
<ilon>
DocScrutinizer05: do you mean cpu cache when you say sram?
<DocScrutinizer05>
there are a 32k or 48, 64k of on-chip SRAM for xloader etc, in OMAP
<ilon>
oh
<DocScrutinizer05>
and ROMBOOT will invariably load xLoader to that RAM during boot
<DocScrutinizer05>
later on that RAM is not really needed anymore, except for stuff like DMA and maybe framebuffers etc
<ilon>
DocScrutinizer05: I dont know if it would be possible to read out sram on the omap
<DocScrutinizer05>
it's for sure not simple, but may or may not work via JTAG
<DocScrutinizer05>
CPU can read SRAM for sure
<ilon>
DocScrutinizer05: i think the reason to implement it entirely in the CPU is to stay compatible no matter what chip
<DocScrutinizer05>
meh, you need to use CPU-specific "registers" anyway
<ilon>
DocScrutinizer05: since (for example armoured) is implemented as a general linux kernel module (wich "mimics" dm-crypt)
<ilon>
DocScrutinizer05: so as its done is to actually implement AES encryption entirely in CPU, and at all times stay clear of RAM to avoid leaking part of / key variables
<ilon>
DocScrutinizer05: problem on ARM (until recently) as i understand it is the lack of AES-NI instruction set
<DocScrutinizer05>
well, I don't see how this shall work in general purpose "compatible" at all, since... all processes run program text that's compiled in a way so CPU *registers* are considered free to use
<DocScrutinizer05>
and task switching "swaps out" the CPU registers to RAM, right?
<DocScrutinizer05>
a task switch will clean out the registers
<ilon>
"with a
<ilon>
mixed set of ARM-specific breakpoint and watchpoint
<ilon>
registers, because those are (1) only accessible from kernel
<ilon>
space, and (2) seldom used by end-users. But unlike the
<ilon>
3debug registers in 64-bit x86 CPUs, they are too small
<ilon>
to hold AES-256 keys. (Note that debug registers can be
<ilon>
written into RAM due to context switching as well, but
<ilon>
we specifically prohibit that by patching respective kernel
<ilon>
routines.)"
<DocScrutinizer05>
yay
<DocScrutinizer05>
ok
<ilon>
There is already a working implementation of this
<ilon>
They also use the NEON multimedia registers as a surrogate stack / heap for the implementation
<DocScrutinizer05>
won't fly, Neon is used
<DocScrutinizer05>
on maemo
<ilon>
DocScrutinizer05: well...
<ilon>
:D
<DocScrutinizer05>
anyway SRAM is available even without any patches to kernel etc
<DocScrutinizer05>
and gets reliably cleared out on boot, when you use low address
<DocScrutinizer05>
ROMBOOT immutably loads xLoader program text to SRAM during very early boot
<DocScrutinizer05>
actually it's the first thing it does, basically, after configuring the hw so that some minimal stuff like regulators work
<DocScrutinizer05>
anyway the correct approach for that problem at large was to use MShield/TrustZone and store the keys to some secure partition of RAM
<DocScrutinizer05>
but that's so secure then that you won't be able to even implement a PoC
<DocScrutinizer05>
;-D
<ilon>
:)
<DocScrutinizer05>
without the proper signature key
<ilon>
well, i generally like the idea to use existing solutions
<ilon>
since i have no time nor experience / expertise to pull off an implementation on my own
<DocScrutinizer05>
this solution exists, see N9 for example
<DocScrutinizer05>
they implemented exactly such secure key storage
<DocScrutinizer05>
and I bet the ARM developers have pondered a lot how to protect MShield even from JTAG attacks
<DocScrutinizer05>
yes, sure
<DocScrutinizer05>
they implement a chain of trust, from ROMBOOT over xLoader/"uBoot" and kernel up to userland
<ilon>
well, if there are good solutions to avoid cold-boot attacks, I'll have a second look at it
<DocScrutinizer05>
but again, this solution is not open to us mere mortals since we lack access to the cert/key to sign any trusted application, so it serves its purpose excellently
<ilon>
And then we're back at tackling the problem of storing encryption keys out of reach for attackers
<DocScrutinizer05>
I think Pali and freemangordon discussed it only a few days ago and freemangordon called in ProtectedApplication
<DocScrutinizer05>
(PA)
<DocScrutinizer05>
also reboot attacks require attacker's ability to boot to an alternative bootloader
<DocScrutinizer05>
which we will provide an option to forbid, in Neo900
<ilon>
If it would be possible to lock the bootloader, i guess that would help
<ilon>
but freezing it and using JTAG could be another vector
<DocScrutinizer05>
when attacker already had hijacked the system so much that it allows them to reflash the bootloader from within, thry also could e.g. run the crypt app under monitor and read out the keys real-time/live
<ilon>
how would the bootloader be locked?
<DocScrutinizer05>
attacker's access to JTAG is very limited, not really feasible with device not going down/unpowered during the process
<ilon>
with local privileges, its always possible to execute code to intercept the enkryption
<DocScrutinizer05>
(BL lock) simply by defining (and kind of hw-locking) the boot sequence via SYSBOOT pins
<ilon>
a hw switch?
<ilon>
would be possible to bypass in such a scenario
<DocScrutinizer05>
for a reboot attack it's invariably necessary to force device into hard reboot while keeping it powered
<DocScrutinizer05>
no, since you can't bypass the switch without powering down and disassembling the device
<ilon>
I think i know too little about encryption and mitigating attacks against it to actually know :)
<DocScrutinizer05>
TBH I also don't see how you want to force an arbitrary android phone into hard reboot
<DocScrutinizer05>
afaik the only way is to press the power button and the OS could intercept that and clean out RAM/registers/whatever before it shits down/reboots
<ilon>
seems rather trivial to do cold-boot attack on a regular android phone
<DocScrutinizer05>
sure, as long as OS doesn't take counter measures
<ilon>
at that point, its not up to the os
<DocScrutinizer05>
it is
<DocScrutinizer05>
no device I know of has a reset button
<DocScrutinizer05>
they all only have a power button and a short press of that one triggers an IRQ only
<ilon>
"11) Then push the battery back and forth very quickly, such that it gets disconnected from the phone for less than 500ms."
<DocScrutinizer05>
even battery takes down system in a finite time, not from now to next CPU instruction
<ilon>
"12) Immediately afterwards (or better already before) hold the power button together with the volume up and volume down buttons."
<ilon>
I think i should try this on my old samsung laying around
<DocScrutinizer05>
meh, that's just a weird way to tell system to shut down. System could clean out several MB of RAM before it's actually forced to reboot
<DocScrutinizer05>
prolly not even needs kernel hacks
<DocScrutinizer05>
there#s a power-down hook for sure
<DocScrutinizer05>
NMI or whatever
<DocScrutinizer05>
on bateery removal the system will happily run on from buffer capacitors for a good fraction of an eternity, from CPU's POV
<DocScrutinizer05>
...while system voltage "slowly" drops and triggers a bat-low/Vsys-low interrupt which the OS could use to clean out stuff
<DocScrutinizer05>
while on a PC with its hw reset button you can't do such thing, on embedded like phones there is no way to do the PC reset
<DocScrutinizer05>
the reboot attack as done on a PC is basically not feasible on embedded
xes has joined #neo900
<DocScrutinizer05>
well, feasible but not invincible like it is on PC
<DocScrutinizer05>
unless you drill holes to the phone and phone's PCB, etc
<DocScrutinizer05>
even then it's more likely to fail than to succeed
Kabouik has joined #neo900
<DocScrutinizer05>
it's just the phone OS like android is doing zilch to defeat such attack
<DocScrutinizer05>
JTAG otoh, yes that could fly
<DocScrutinizer05>
when you could attach JTAG without first removing the battery etc
<DocScrutinizer05>
and even then iirc the OMAP needs a cold reboot to *enable* JTAG
<DocScrutinizer05>
I'm pretty sure you couldn't attach JTAG to a warm system
<DocScrutinizer05>
you're also in ERH? :-)
xes has quit [Ping timeout: 265 seconds]
<ilon>
DocScrutinizer05: sorry, real life's calling :)
<DocScrutinizer05>
np
<ilon>
DocScrutinizer05: thank you for the discussion tho, gave me some good inputs.
<ilon>
DocScrutinizer05: and yes, the ability to perform cold boot attacks on android phones seems to relay heavily upon the way features are implemented.
<DocScrutinizer05>
meh, I stopped that useless approach several years ago
<ilon>
:)
<ilon>
now, semlor
<DocScrutinizer05>
whatever that is
<DocScrutinizer05>
aah ok, you gave explanation already
<ilon>
delicous is what it is
<DocScrutinizer05>
yeah, I also need breakfast meanwhile
che11 has joined #neo900
che11 has quit [Ping timeout: 255 seconds]
paulk-collins has quit [Ping timeout: 265 seconds]
che1 has joined #neo900
paulk-collins has joined #neo900
<DocScrutinizer05>
dos1: ping! please remove >>Don't miss this year's OpenPhoenux Hard & Software Workshop in Munich, Germany on November 29-30.<< - thanks!
<DocScrutinizer05>
it was last year, nit this year
mvaenskae has joined #neo900
phre4k has joined #neo900
freemangordon_ has joined #neo900
<freemangordon_>
Pali: wlancond is closed source ain't? bot n900s here are hitting the same bug, wlancond goes runaway :(
<freemangordon_>
*both
<Pali>
wlancond is open source
<Pali>
and already patched in cssu
<DocScrutinizer05>
runaway?
<Pali>
osso-wlan or similar deb package name
<freemangordon_>
yep, 100% cpu usage
<DocScrutinizer05>
:-o
<freemangordon_>
yep, and device restarts at the end
<DocScrutinizer05>
DUH!
<DocScrutinizer05>
strace?
<freemangordon_>
good it is foss, I'll install debgu symbols and see what happens
<freemangordon_>
after this wlancond uses 100% cpu
<freemangordon_>
*maybe* the reason is too many reconnects, the signal is weak here
<Pali>
" kernel: [24560.471527] wlancond: page allocation failure. order:4, mode:0xc0d0" --> means that allocation for userspace failed
<freemangordon_>
:nod:
<Pali>
bug in wlancond daemon, should not use 100% cpu when some malloc() fails
<freemangordon_>
yep
<freemangordon_>
Feb 21 15:08:26 Nokia-N900 wlancond[1495]: Get scan results failed
<Pali>
I know that it is pretty normal that you cannot allocate 2 or 4MB of memory from malloc() on Nokia N900
<freemangordon_>
~2^4
<infobot>
6
<freemangordon_>
hmm
<freemangordon_>
~16*4096
<infobot>
65536
<freemangordon_>
Pali: ^^^, not that much
<freemangordon_>
also, this is not malloc
<Pali>
how do you know that it is not malloc?
<freemangordon_>
but kmalloc with GFP_ATOMIC
<freemangordon_>
see the backtrace
<freemangordon_>
Feb 21 15:08:26 Nokia-N900 kernel: [24560.471893] [<c0226d74>] (dev_ioctl+0x0/0x788) from [<c0218630>] (sock_ioctl+0x204/0x234)
<freemangordon_>
kernel tries to allocate 64kB of contiguous pages and fails
<freemangordon_>
but wlancond should not have problem with that
<Pali>
some similar __alloc_pages_internal error you can get if you allocate (e.g. statically 2MB of mem) and then call read("/dev/mtdXro", <that2MBarray);
<Pali>
kernel read syscall fails too
raccoon_ has quit [*.net *.split]
GoGi has quit [*.net *.split]
timclassic has quit [*.net *.split]
pigeons has quit [*.net *.split]
timclassic has joined #neo900
pigeons has joined #neo900
pigeons is now known as Guest25216
GoGi has joined #neo900
<freemangordon_>
Pali: alloc_pages fail when the memory is too fragmented
<freemangordon_>
as it tries to allocate contiguous aligned space, iirc
<freemangordon_>
anyway, I'll attach gdb to wlancond and will wait for bug to happen again
<mvaenskae>
pardon, was the FSF not happy with the possibilitz of upgrading the modem?
<Pali>
why you care about FSF?
<Pali>
and those people who are happy with pulseaudio and systemd?
<mvaenskae>
Pali: i need an insane argument against them ;)
<Pali>
you still do not have more then one?
<mvaenskae>
Pali: i needed one which allows me to also shed light on the neo900 once more :D
kolp has joined #neo900
raccoon_ has joined #neo900
MonkeyofDoom has quit [Remote host closed the connection]
MonkeyofDoom has joined #neo900
<mvaenskae>
and mail sent, let's see if i can get some people interested in the neo900 finally :D
<DocScrutinizer05>
peeps, has FSF changed their certification rules, as of http://www.fsf.org/resources/hw/endorsement/criteria ? Particularly >>We want users to be able to upgrade and control the software at as many levels as possible. If and when free software becomes available for use on a certain secondary processor, we will expect certified products to adopt it within a reasonable period of time.<< sounds pretty new to me ;-P
<mvaenskae>
do they have a version history; would be interesting knowing when it was changed and if it has been for some time, why the neo900 project wasn't contacted
<DocScrutinizer05>
>>By way of explanation, a general-purpose facility for installing other programs, with which the choice of programs to install comes directly from the user, is not considered to steer users toward anything in particular. However, the product suggests using the facility to install certain programs, that is steering users towards those programs.<< also is different from what I seem to remember
<DocScrutinizer05>
according to those new cert requerements it might even be possible that FSF now allows the amount of freedom Neo900 offers to users
<DocScrutinizer05>
would need a - however buggy - "open" firmware for the wl125x
<merlin1991>
The null thing is in cssu
<DocScrutinizer05>
I thinjk sth exists
<MonkeyofDoom>
the closed firmware is plenty buggy already ;)
<DocScrutinizer05>
hehe
<DocScrutinizer05>
somebody must have RE'ed the firmware blob for wl12xx, no?
<bencoh>
erm, not sure
<Pali>
are there alternative free firmwares for wl12xx?
<Pali>
will you try to certificate neo900 as free hw according to FSF?
<bencoh>
all I can find thus far is a buch a blobs
<Pali>
I think only atheros wifi cards have open source firmware
<Pali>
(original FW was open sourced)
<mvaenskae>
Pali: i might write stallman an email about the status of the neo900 soonish; i just need to know what exactly is causing trouble as of right now :)
<Pali>
also you can try to certificate device without WIFI support :-)
<Pali>
(if a wl12xx blob is problem)
<Pali>
I think there was only problem with that usb modem...
<bencoh>
with the fact that the firmware could be modified, iirc
<bencoh>
DocScrutinizer05: ^
<Pali>
is wl12xx firmware signed?
<Pali>
if not it can be modified
<mvaenskae>
bencoh: that was the main problem thus far, allowing updateability of the modem :)
<Pali>
it is loaded at system startup
<Pali>
mvaenskae: problem was that modem firmware was able to update? or problem was that firmware was *not* possible to update
<Pali>
?
<mvaenskae>
Pali: as the software on the modem is not FOSS having any mechanism allowing for an update broke the "black box" argument and thereby made it run non-free software
<mvaenskae>
if it has no way to update then stallman is agreeing as seeing it as a sort of hard-wired black box thus not running any non-free software
<Pali>
this is stupid... an any device you can run non free software
<mvaenskae>
exactly
<mvaenskae>
this is beyond stupid
<Pali>
if you *can* update firmware you can load (in future) your own firmware which can be 100% open and free
<Pali>
(if you write it on your own)
<bencoh>
stupid is not enough
<Pali>
I would say that requirment for ability to load/update *any* firmware should sounds good
<Pali>
but to disable updating firmware in FOSS is nonsence
<mvaenskae>
this has been a frustrating part so far but maybe these new "terms" actually allow it
<mvaenskae>
i am interested in the development and as mentioned, depending on time and mood will get in contact with stallman on the matter
<mvaenskae>
gotta help out the project :)
<dos1>
were there really any new terms? it all seems familiar to me actually.
<mvaenskae>
dos1: scroll a bit up on what Doc posted :) it at least sounds as if an updateable modem is allowed
<dos1>
it's not, he was refering to wifi, to which it's much easier to provide some "dummy" FLOSS firmware
<dos1>
with modem it's not really possible
<mvaenskae>
dos1: the modem isn't a secondary processor?
<dos1>
mvaenskae: FSF's definition of "secondary" is "within which software installation is not intended after the user obtains the product"
<dos1>
(it's pretty vague, as it's usually "not intended" to update the firmware anyway, but they do seem to interpret it much wider than I do :P)
<mvaenskae>
dos1: is software installation really intended on a modem with security features such as signed firmware
<mvaenskae>
?
<mvaenskae>
i would say no, not really
<dos1>
mvaenskae: I would say no as well, but FSF has a known history of saying yes to similar questions
<mvaenskae>
dos1: well, it should be cleared up i feel :)
<DocScrutinizer05>
please recheck, they done subtle changes in wording it seems
<dos1>
ok then, to the wayback machine! :)
<DocScrutinizer05>
>>However, there is an exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product<< AND >>We want users to be able to upgrade and control the software at as many levels as possible. If and when free software becomes available for use on a certain secondary processor, we
<DocScrutinizer05>
will expect certified products to adopt it within a reasonable period of time<<
<DocScrutinizer05>
this *clearly* allows modem firmware update
<DocScrutinizer05>
they also seem to have removed a few rough edges about their "website must not point to or direct or inform user to/about non-free software"
<DocScrutinizer05>
>>By way of explanation, a general-purpose facility for installing other programs, with which the choice of programs to install comes directly from the user, is not considered to steer users toward anything in particular<< seems new to me
<dos1>
I remember both of these sentences being there long time ago and I always understood the second one as "if floss alternative to sealed in blackbox becomes available, we expect manufacturer to stop putting it into new devices and use floss alternative instead"
<dos1>
and archive.org says that last sentence was already there in 2012
<bencoh>
"If and when free software becomes available for use on a certain secondary processor, we will expect certified products to adopt it within a reasonable period of time" there's still something I dont quite understand
<bencoh>
does that mean the FSF certifies a hardware+software bundle ?
<bencoh>
meaning neo900 would need to have a board+bsp certified ?
<DocScrutinizer05>
bencoh: exactly
<DocScrutinizer05>
which is kinda nonsensical anxywa
<bencoh>
well ...
<DocScrutinizer05>
anyway since Neo900 doesn't ship with any proper OS/"firmware", we only provide a BSP
<DocScrutinizer05>
plus possibly a number of evidently FOSS and community-based installers for a number of OS
<DocScrutinizer05>
the OS themselves may or may not support some of the subsystems like WLAN, and may do so with importing non-free or REed or FOSS stuff for any needed firmware
<DocScrutinizer05>
anyway the BSP won't come with a FOSS firmware for WLAN. Unless somebody points us to such firmware for wl12xx
<DocScrutinizer05>
we will have to use the blob the WLAN module seller provides to us
<bencoh>
DocScrutinizer05: haha no, I know it's omap3 dsp
<ilon>
DocScrutinizer05: Its an OMAP4 board in the neo900 right? Wich one?
<DocScrutinizer05>
OMAP3 DM3730
<DocScrutinizer05>
OMAP4 for all I know has nasty SiErr that are WONTFIX for OMAP4 and tagged "fixed in OMAP5"
paulk-collins has joined #neo900
<ilon>
DocScrutinizer05: Thank you, and I'm apologize for being lazy and asking you
<DocScrutinizer05>
and OMAP5 is way too far from compatibility with OMAP3430 which been a major design goal for Neo900. Also OMAP5 simply too large to cram it into the Neo900
<ilon>
DocScrutinizer05: Yeah, i recall reading about it way back in the projects early days
<DocScrutinizer05>
STEP2 (next gen Neo900) will probably have OMAP5
<ilon>
(and yes, its now possible to refer to this projects "early days") :D
<DocScrutinizer05>
I guess it's no coincidence but rather related that >>2015-02-22T20:01:01.129784+01:00 localhost kernel: [361983.620898] show_signal_msg: 204 callbacks suppressed<< is following exactly 60s after >>2015-02-22T20:00:01.057658+01:00 localhost systemd[1]: Created slice user-0.slice.<<, the latter prolly been an arbitrary cronjob (in this case snapper, maybe)
<mvaenskae>
DocScrutinizer05: the uptime is too high
<mvaenskae>
it is obviously expecting a reboot every hour because they go so quick :)
<freemangordon_>
mvaenskae: true, but ubuntu 14.04 LTS is supported till 2019. I hope situation to have changed by then
norly has quit [Quit: Leaving.]
<DocScrutinizer05>
could somebody tell me what dang process particularly segfaulted there?
<DocScrutinizer05>
I'm probably partially blind to the info detail that woukd tell me
norly has joined #neo900
<mvaenskae>
i have sadly no idea :(
sparetire has joined #neo900
che1 has quit [Remote host closed the connection]
PeperPots_____ has quit [Read error: Connection reset by peer]
nox- has joined #neo900
mvaenskae has quit [Ping timeout: 264 seconds]
Pali has quit [Ping timeout: 265 seconds]
unclouded has quit [Ping timeout: 265 seconds]
enyc has quit [Ping timeout: 265 seconds]
enyc has joined #neo900
MonkeyofDoom has quit [Remote host closed the connection]
<Oksana>
systemd copied from launchd?.. One Program to Rule Them All?.. Curiouser and curiouser...
* Oksana
really wonders if systemd and launchd are going to have a great stand-off against each other...
<kerio>
Oksana: well, at least launchd does init things
<kerio>
the xinetd and crond stuff is a bit of a stretch but eh
<kerio>
it's still launching processes in response to things
<DocScrutinizer51>
Oksana: how about a new newsletter? dos1 said he doesn't have time to write one, just like rest of core crew. a afilliated newsletter crew would make a lot of sense, and the newsletters were more on user perspective of things
<DocScrutinizer51>
actually the above is not limited to Oksana - everybody is welcome to ontribute. And ask for details to make a story out of it
<Pali>
yes, lennart was inspirated by launchd when he started designing systemd
<Oksana>
Okay, what would it be about? Camera switches were delivered, great? Something about xloader/uBoot need-to-be-changed to work with 1GB-RAM? IR-photodiode - what's up with it?
<kerio>
Pali: then why the fuck didn't he STOP
<DocScrutinizer51>
Oksana: sorry I'm in restaurant, will be available for 'interview' in 1h
<kerio>
launchd has no bootloader
<kerio>
os x logs to text files
<Pali>
yes, launchpad has no bootloader... and lennart is fixing all those errors :D
<kerio>
rofl
<kerio>
the automounter is a separate daemon
<kerio>
and so is the network manager
<kerio>
honestly, launchd isn't that bad
<kerio>
the plist config files are trash tho
<kerio>
xml :s
<Pali>
hahaha XML :D
<kerio>
or a binary format!
<Pali>
that language which should not be edited by text editor
<Oksana>
XML should not be edited by text editor?..
* Oksana
edits XML in text editor, whenever XML has to be edited
<Pali>
yes :-) XML is machine processing language, not human
<Pali>
it should be edited by application specially designed for that XML format
<Pali>
(at least this is what XML people thinks about XML)
* Oksana
why does phrase "should not be edited by text editor" remind me about "let's draw diagrams for this [Time-Turner paradoxes]"?
arcean has quit [Quit: Application terminated!]
<Pali>
"devs: we have one problem... and we will solve it with XML!" and after that they have two problems :D
<kerio>
Pali: wellllll
* Oksana
thinks that there should be a software (internally based on XML) for handling time-turner paradoxes - though I do detest idea of video games, it's the most likely place for such thing to be implemented
<kerio>
os x has both a commandline tool to edit .plist files and a nice graphical editor
<kerio>
:>
<kerio>
JUST SAYIN
<Oksana>
Does this graphical editor never fail? Never mind how long-large, complicated the file may be?
<Pali>
wtf? I got security update for sudo package