04:15 <DocScrutinizer05> viric: have you ever seen RMS happy?

04:16 <DocScrutinizer05> ooh, larsc said that already ;-P

04:19 <DocScrutinizer05> actually I again did the mistake to read backsroll top-down instead of bottom up

04:19 <DocScrutinizer05> seem the letters RMS and happy in one line trigger reactions in about everybody

04:22 <DocScrutinizer05> (battery) as long as standby times of a laptop under linux are shorter than under (even!) windows, you know sth is terribly fsckd up in linux regarding power management.

04:25 <roh> DocScrutinizer05: maybe its because people get stuff done with their linux and idling while showing a hourglass simply needs less power ;)

04:25 <DocScrutinizer05> possible, but not really in line with what you see

04:28 <DocScrutinizer05> it's rather that windows (like android) simply doesn't care about stuff like layering violations and instead implements whatever botch needed to make stuff work and forbid userland to do nasty things, while linux is a proper OS that allows userland to do whatever idiocy they like and system doesn't do anything to stop the fallout

04:29 <DocScrutinizer05> so when OS allows background busy waiting then ineevitably some stupid app coders will use that feature

04:30 <DocScrutinizer05> and on linux not even device drivers are remarkably saner than apps, regarding that

04:31 <DocScrutinizer05> at least some of them

04:32 <DocScrutinizer05> since linux wants to be compatible to every crappy hw you could imagine, which often implies not exploiting available power saving measures

04:32 <DocScrutinizer05> even by design (like API)

04:33 <DocScrutinizer05> e.g.: when you design a universal accelerometer API, you just can do poll basically. For sure you can't rely on advanced "embedded intelligence" of the accelerometer chip that's not to be found on next random chip in next platform

04:36 <DocScrutinizer05> on windows it's simple: you have no driver at all but rather some closed source userland app that talks to peripheral, and a manufacturer ships both hw & sw in a bundle

04:38 <DocScrutinizer05> of course this is a tad pithy now, but the basic idea is right I think

04:39 <DocScrutinizer05> I had a lot of similar discussions lately, about "upstream" kernel vs Nokia N900 specific kernel

04:40 <DocScrutinizer05> I still don't see any other kernel come into vicinity of maemo-2.6.28 when it comes to powersaving on N900

04:41 <DocScrutinizer05> since they all despise the Nokia "proprietary" though FOSS/GPL kernel hacks

04:42 <DocScrutinizer05> upstream rjects them since it doesn't meet their policies and rules on how software should look

04:52 <DocScrutinizer05> pardon my french, should chill out a bit

05:04 <kyak> your direction of thinking makes sense

05:25 <DocScrutinizer05> thanks

06:47 <wpwrak> hmm, does my memory betray me, or was it the case that once upon a time, in C, when having an array char a[10]; the expressions a and &a were equivalent ? (this is not the case now)

06:53 <ysionneau> I think so , it used to be at least

06:59 <kyak> i think a, &a and &a[0] are equivalent

06:59 <kyak> wpwrak: are you saying it's no longer the case?

07:07 <wpwrak> at least gcc says they're incompatible

07:08 <wpwrak> also clang dislikes it

07:09 <wpwrak> the value generated is the same, though

07:56 <whitequark> I think it's called decay

07:58 <viric> wpwrak: I remember that being part of K&R even

08:00 <whitequark> http://c0x.coding-guidelines.com/6.3.2.1.html#729

08:16 <wpwrak> the case that causes problems is &array. e.g., if i have int a[10]; then &a is "int (*)[10]" (not to be confused with "int *[10]") and considered by gcc and llvm to be incompatible with a mere "int *"

15:26 <kristianpaul> cool https://en.wikipedia.org/wiki/Software_GNSS_receiver#Comparison_of_implementations

17:14 <qi-bot> [commit] Werner Almesberger: fab/prettygerbv: update for new file names; add option -y for vertical stacking (master) http://qi-hw.com/p/eda-tools/53d6e1d