Re: [Arm-netbook] systemd nonsense ad-infinitum
On 07/05/2017 01:37 AM, Luke Kenneth Casson Leighton wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > On Wed, Jul 5, 2017 at 1:43 AM, zap wrote: > >> Well, it least you were more civil about it. > zap, phil, et al: i must apologise, the less-than-civil tone is my > fault. i began this thread from a position of frustration and > pissed-off-ness. > > slowly over time however these discussions are helping me to be able > to both understand and vocalise things without the frustration and > pissed-off-ness. > > so i apologise, and at the same time am extremely grateful for > everyone's participation. > > l. Well, I wasn't talking about you that time, but yeah we all need to just calm down and look carefully at what is going on here without eyes of hate. If possible I mean. ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] severe systemd bugs (two of them)
Luke Kenneth Casson Leighton writes: > On Tue, Jul 4, 2017 at 10:42 AM, Elena ``of Valhalla'' ... > the heavy usage of d-bus for the openmoko OS basically was part of > what killed the project. it would not surprise me at all to find that > d-bus is similarly slowing systemd down when compared to other init > systems. The way that d-bus was used in OpenMoko was astonishing, and is really not something one can use to criticise d-bus in general. Not that I'm trying to say that d-bus is particulalry lovely, but what you're doing here is like saying that micrometer screw guages are rubbish becuase you once saw someone using one as a hammer, and they hurt their thumb. The program that ran most of OpenMoko was written on the assumption that it would be very soon replaced by separate components that would all pass messages around via d-bus (a stupid design, given the hardware), then time ran out and that prototype was what shipped. The result being that if one got an incoming call, it would provoke a cascade of (IIRC 7) d-bus interactions that were all being answered by call-backs in the single program that was doing everything. Each one went via a kernel context switch (or two?), dumping the cache, and that meant that it would take at least 5 seconds for the ringer to start ringing after a call came in, a few more seconds to show you the screen with the answer button, a second or two for your mad tapping to be noticed, during which the accelerometer would realise that it needed to swap portrait for landscape (repainting the "cancel" button where the "answer" used to be) and then finally it would process your demented attempts to answer the sodding thing as a call rejection. Marvelous. Enrico Zini worked all that out, and then knocked up a very short script that waited for calls, made the ringer ring, and looked out for a button press on the physical button -- that allowed it to behave quite like a phone with no fuss. If anyone wants an OpenMoko, I have one going cheap :-/ Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
Re: [Arm-netbook] severe systemd bugs (two of them)
On Wed, Jul 5, 2017 at 6:49 PM, Philip Hands wrote: > The program that ran most of OpenMoko was written on the assumption that > it would be very soon replaced by separate components that would all > pass messages around via d-bus ah! 12+ years i'm glad someone remembers. i got the trolltech greenphone, not an openmoko > The result being that if one got an incoming call, it would provoke a > cascade of (IIRC 7) d-bus interactions that were all being answered by > call-backs in the single program that was doing everything. Each one > went via a kernel context switch (or two?), dumping the cache, and that > meant that it would take at least 5 seconds for the ringer to start > ringing after a call came in, a few more seconds to show you the screen > with the answer button, ... which was painted with x11 so that meant many more more context-switches and cache-dumps because x11 is a client-server architecture... > a second or two for your mad tapping to be > noticed, during which the accelerometer would realise that it needed to > swap portrait for landscape (repainting the "cancel" button where the > "answer" used to be) and then finally it would process your demented > attempts to answer the sodding thing as a call rejection. Marvelous. ... didn't you have call-forwarding such that there wasn't enough time to actually answer the call anyway? :) > Enrico Zini worked all that out, and then knocked up a very short script > that waited for calls, made the ringer ring, and looked out for a button > press on the physical button -- that allowed it to behave quite like a > phone with no fuss. dang. *sigh* nokia's low-cost mobile phone OS (symbian?) at least was well-designed (or, designed for purpose). > If anyone wants an OpenMoko, I have one going cheap :-/ ah that would be good to use for the GTA04 motherboard replacement oh wait damnit that didn't go so well, they used a package-on-package TI SoC and DDR sandwich, where the processor was only designed for very specialist mass-volume manufacturing, was made too thin (to save cost) and warps under standard PCB assembly (ovens)... they got something like a SEVENTY SEVEN PERCENT failure rate during a pre-production manufacturing run. http://laforge.gnumonks.org/blog/20170306-gta04-omap3_pop_soldering/ l. ___ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
