=== tvoss|eod is now known as tvoss === tvoss is now known as tvoss|food === rsalveti_ is now known as rsalveti === tvoss|food is now known as tvoss === udsbotu changed the topic of #ubuntu-uds-client-2 to: Track: Client | Printing Stack with Mobile in Mind | Url: http://summit.ubuntu.com/uds-1303/meeting/21685/client-1303-printing-stack-with-mobile-in-mind/ [13:58] hi everyone. session will start in 3 minutes [13:59] Can someone invite me into the hangout? [14:00] hm, the video isn't on yet, is it? [14:00] I see "starts in a few moments" [14:01] tkamppeter: see orther IRC channel, I pasted you the link [14:01] we still have space free on the hangout if anyone else is interested in joining [14:03] meh @ video, reloading the page throws me out of IRC [14:05] I don't see things to discuss/think about, is there anything to deliberate on while you guys are setting up the video? [14:07] pitti_uds, link for the hangout: https://plus.google.com/hangouts/_/39beb4c0269f04a0f04e218d605e9d67718e3993?authuser=0&hl=en [14:07] just starting now folks! [14:07] tkamppeter: tried, but "hangout ended due to a server error" [14:08] retrying [14:08] same error [14:08] * pitti_uds reloads page to see the live stream [14:09] ok, no live stream, no hangout [14:09] pitti_uds: :( [14:09] I might have missed an answer during reconnect, any question/problem we can think about while you are setting up? [14:09] oh, perhaps I'm not marked as required for this session [14:10] (whatever that means, but I heard it's a prerequisite) [14:10] is this live? I'm getting "This live event will begin in a few minutes" [14:11] IIRC the track lead has to invite folks into the hangouts [14:11] ok, I see Till live now [14:11] same here [14:29] * tsdgeos_uds_ raises hand as poppler maintainer [14:29] tsdgeos_uds_: probably best if you just put your question here (or join the hangout), we'll poke tkamppeter to pick it up [14:30] pitti_uds: not a question, i'm just saying i'm around [14:33] tsdgeos_uds_: did you want to join the session? [14:34] jasoncwarner: i'm listening, not much to say [14:34] systemd in theory allows for on demand startup [14:34] tsdgeos_uds_: besides i think i could join the session, if i press the share icon in the youtube video there's a "hangout" button [14:35] using socket activation [14:35] jasoncwarner: ↑↑ that obviously for you not for me :D [14:35] no i don't have a question :D [14:36] tsdgeos_uds_: ack :) [14:36] tsdgeos_uds_: https://plus.google.com/hangouts/_/39beb4c0269f04a0f04e218d605e9d67718e3993?authuser=0&hl=en [14:36] ok, joining [14:36] ritz: yeah :) but I don't think we'll get that anytime soon [14:37] pitti_uds were we not trying this with upstart ? [14:37] on demand service [14:37] via dbus [14:37] ritz: if it can do it somehow, that'd be great of coures [14:37] ritz, dbus activation != socket activation [14:38] ritz: but that only covers d-bus activation if you try to talk to cups over dbus, not the unix socket [14:38] which is the main way to talk to cups really [14:38] on dbus there's only job notification AFAIK [14:38] QUESTION: would this phone printing stack involve a different set of pkgs than used on desktop, and if so, how would that be managed: a different seed/depends? [14:39] not very familiar with upstart [14:39] kyleN: just fewer seeds presumably; we already have the split in quantal [14:40] ack [14:43] tsdgeos_uds_, Asking in #inkscape to see if I can find some color folks. [14:43] tedg: tx [14:45] The other problem we have is that Mir doesn't have a color management story yet. [14:45] So we might be able to punt a bit on color management. [14:46] I just want to point out that I'm excited about having a real printing stack on a mobile device. Hate not having it on Android. This really could be a practical differentiator. [14:47] tsdgeos_uds_, I was sent this: http://www.oyranos.org/wiki/index.php?title=Test_Images#PDF [14:49] larsu, Can you add a work item for design to help with the dialog? jnicktait [14:50] larsu, pitti_uds, it wouldn't be an issue if you guys would stop using a stupid size like A4! US Letter! ;-) [14:54] tedg: done. thanks === udsbotu changed the topic of #ubuntu-uds-client-2 to: Track: Client | Discuss and plan our webkit maintenance strategy | Url: http://summit.ubuntu.com/uds-1303/meeting/21647/client-1303-webkit-maintenance/ [14:56] helloww [15:01] Hi hi [15:01] = chad miller [15:01] hi everyone... [15:01] session will begin in a minute [15:01] does anyone want to participate on hangout? [15:02] someone is having mic probs [15:02] qengho , you seem like you would like to hangout ;) [15:02] jasoncwarner_UDS: Yes, I do. [15:02] showing up on hangout doesn't automatically mean you get work items [15:02] :) [15:03] mdeslaur: In fact, if one can't talk, one is more likely to just be assigned them. :) [15:03] you know, I only use this like 10 times a week [15:03] We are currently experiencing technical difficulties. Your call is important to us. Please stay on the line. [15:03] What's the hangout url? [15:04] ok. [15:04] xnox and qengho https://plus.google.com/hangouts/_/87858bba77dc51229f080c9df9b930418b03173a?authuser=0&hl=en [15:04] jasoncwarner_UDS: hehe and everyone joins now =) [15:04] * Laney will actually [15:06] \o/ [15:06] mdeslaur: everything is in the etherpad [15:10] NOISE [15:11] Laney: ok. [15:11] :-) [15:12] mdeslaur: they did it already [15:12] mdeslaur: it's qt5 only now [15:14] mdeslaur: I have a proposal in etherad [15:14] etherpad [15:15] * jdstrand has no volume controls at all [15:16] * jdstrand shakes fist at computer [15:17] Yes, we heard something. [15:17] Perfect. [15:17] Are you running Skype also? [15:18] jdstrand: you might need http://blog.didrocks.fr/post/Getting-sound-working-during-a-hangout-in-raring [15:18] kyleN, the phone printing stack does not inviolve different packages, I will simply split binary packages to allow the desired small-footprint stack. [15:20] If neither KDE and Gnome have resources to keep backporting patches, why do you think Ubuntu will? :-/ [15:23] vrruiz: if we're going to use a webkit engine in our sdk and our browser, we have no choice [15:24] why not base on QtWebkit, since it's the one most relevant for our developers? [15:24] mardy: nobody is backporting security features to qtwebkit [15:25] I suspect we'll be using the qtwebkit bindings though [15:25] mdeslaur: I mean, you would :-) [15:25] s/features/fixes/ [15:25] yes, we could possibly be the ones maintaining qtwebkit [15:26] we're not implying we wouldn't be doing this upstream [15:26] I like jdstrand's proposal, pulling from APPL and our maintainence of minor patches atop them. [15:26] mdeslaur: But AFAIK, one of your arguments to need a webkit engine is that other projects have resource problems. Isn't easier to collaborate with them? [15:27] xnox raised a valid point, backporting the bindings might not be a small effort; that's why basing on QtWebKit would reduce this effort a bit [15:27] vrruiz: sure, if upstream projects are ready to completely freeze the API, no problem [15:35] There are other companies that will be using QtWebkit on the mobile-like platforms. [15:36] Would be nice to share the cost of webkit maintenance. [15:36] Blackberry is using Qt in BB 10 [15:37] convince Opera to use QtWebKit ;-) [15:37] mardy, ahah [15:38] xnox: +1 [15:39] mardy: Aren't they actually using Chromium? [15:40] vrruiz: yes, they are [15:41] mdeslaur: especially with WebKit2, things are changing a lot [15:42] mdeslaur: on the bright side, it seems that Qt bindings are using more and more the C bindings [15:42] jdstrand: it's in continuous development [15:42] jdstrand, I think so yeah [15:42] (that's not to say that's unstable) [15:42] 10 seconds + thinking + typing delay. [15:43] WK2 is used on 2011 Nokia N9, quite stable and nice (no doubt was a lot of work back then) [15:44] jasoncwarner_UDS: FWIW, the Lower Third hangout app on the left is indeed dead, and it's [15:44] it will be interesting to know if apple are making API changes that will make the rebasing difficult [15:44] moved into the Hangout Toolbox app. [15:44] what excellent timing [15:44] heh [15:44] bye [15:45] Laney: we're that good :) [15:45] Laney: possibly...I don't think they care too much about breaking stuff that may impact other bindings then their own [15:45] right, back to debugging jit code ;) [15:45] chrisccoulson: Ugh. Still? [15:45] indeed === udsbotu changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/client-2/ - http://ubottu.com/uds-logs/%23ubuntu-uds-client-2.log [15:45] chrisccoulson: How can I help? [15:46] qengho, yeah, i've located the exact instruction where it all goes wrong, but just trying to figure out what the jit is actually doing [15:46] which is interesting ;) [15:46] chrisccoulson, ff on arm? [15:46] alex_abreu, no, chromium [15:46] ff works fine on arm btw ;) [15:46] chrisccoulson, oh interesting ... any lp bug on that? [15:47] chrisccoulson: I remember some mention of a security bug WRT the JIT and memory contexts. I wonder if it's related. [15:47] alex_abreu, not yet [15:47] qengho, ah, interesting [15:47] tvoss: bah geoclue conflicts with update process session; I'll go to update process, but can join geoclue mid-way if that's helpful [15:48] the jit is disabled on the webkitgtk arm build due to bug [15:48] buh [15:48] due to https://bugs.webkit.org/show_bug.cgi?id=85076 [15:48] bugs.webkit.org bug 85076 in JavaScriptCore "ARM JIT causes segmentation fault on javascript-heavy pages" [Normal,Unconfirmed] - Assigned to webkit-unassigned@lists.webkit.org [15:48] Laney, this is v8 though ;) [15:48] (not JSC) [15:49] lool, cool, thank you [15:49] fair enough === udsbotu changed the topic of #ubuntu-uds-client-2 to: Track: Client | Location Service - Geoclue vs whole cloth | Url: http://summit.ubuntu.com/uds-1303/meeting/21614/client-1303-location-service/ [15:51] chrisccoulson, any st/dissasembly? is it something GC related? [15:51] alex_abreu, no, it's not GC related [15:57] session will start in 3 minutes [16:01] hi folks...have spots open for those interested in joining the hangout [16:01] https://plus.google.com/hangouts/_/0ec0ef5db83f0a1952bc68dfb0337d646e9d288d?authuser=0&hl=en [16:11] I'm familiar with geoclue [16:12] mkay [16:13] I mean, rather than rewriting lots of stuff, let's fix and provide fixes upstream [16:14] cyphermox: is there a chance we could assume control of the existing project? [16:14] possibly I don't know [16:15] last I checked it didn't seem super active [16:15] but then again, maybe it also largely works and that's why it's not being a flurry of commits [16:15] who is the last maintainer-type person? [16:15] the description of the session says it's pretty much dead [16:15] IIRC, the old maintainer offered it for adoption, no takers [16:15] so let's adopt it? [16:16] Cheesehead: got a citation for that? [16:16] We can cache apt data and fake it / provide that those core packages are available. [16:16] hadess might have been the last maintainer? [16:16] desrt: Sorry, old memory. Perhaps an old mailing list. [16:16] daniel was in contact with the last maintainer [16:17] so my point was that we can definitely improve on any things that don't work when they already have most of what we need, rather than rewriting a whole lot of stuff from scratch and running into the same issues the original project probably ran into many times [16:18] whether that means adopting the project or whatever else is fine [16:18] larsu: could you add lower third? [16:18] tvoss: ^ [16:18] lower third? [16:19] larsu: hangout toolbox app, installable from the left bar [16:19] larsu: only works in chromium though [16:19] cyphermox, I tried, but it's shown on the upper tird :) [16:19] tvoss: oh, so it is! [16:19] I briefly saw it [16:20] cyphermox, weird though [16:20] yes, totally agree it can / needs to be improved [16:21] 11:19 < hadess> desrt, by a newer version, i have some apis scribbled on pieces of paper (notes on my computer) [16:21] 11:19 < hadess> desrt, less moving parts, stuff that works [16:21] 11:19 <@desrt> hadess: canonical wants to do the same [16:21] 11:20 < hadess> desrt, satabdi has been working on ip geolocation, and (rev)geocoding in geocode-glib [16:21] 11:20 <@desrt> hadess: so do you plan to torch the current codebase? [16:21] 11:20 <@desrt> hadess: and what is your timeline? [16:21] 11:20 < hadess> desrt, yep, it's pretty clear it's not usable [16:21] 11:20 < hadess> desrt, timeline is "when i have time" [16:21] FYI [16:21] looks like the reason upstream is dead is because upstream thinks that the current codebase is not worth it [16:21] tvoss: that's a good point [16:22] 11:21 < hadess> (it's been pushed back at least 2 cycles already because of no time) [16:22] tvoss: I'm curious if we can't write a test suite for what we have right now, and spend less time than rewriting all; then refactor, fix tests, etc... you know how it goes ;) [16:23] esp. for a project relatively as isolated/self contained as geoclue [16:23] it *is* a complex decision on that end, though, definitely [16:23] yeah [16:24] basically, very rough tests to check the exisitng impl, refactor, make the tests good, refactor, repeat [16:24] at least making sure we don't introduce regressions [16:25] interesting [16:25] I've coded a bit with the geoclue stuff and the code... was... ugly/messy I guess, so don't take my intervention as saying "no we should absolutely not do a rewrite" [16:26] there is going to be a rewrite one way or another, it seems [16:26] desrt: in terms of majorly overhauling the code base, yeah ;) [16:26] imho we should try to share the component, though [16:26] so there already is code... [16:27] from a practical standpoint, writing it in c++ for Qt is a good way to ensure that we're the only ones who will ever use it [16:27] desrt: can you pull hadess here? [16:27] i tried. he's not interested :) [16:27] his input may be useful [16:27] oh ;) [16:27] * desrt tries again [16:28] we can help with the "lack of time" [16:28] indeed [16:28] he has notes on the new design... i asked if he could publish them somewhere [16:28] hadess: hey. welcome. [16:28] assuming we can spend time writing the code from the api he designs [16:28] desrt, they're more "nice to haves" [16:28] hey hadess, thanks for coming [16:28] tvoss: +1 [16:29] hadess, hey, thx for being with us [16:29] desrt, including things that aren't currently possible, such as authorisation and sandboxing [16:29] hadess: want to join the session? [16:29] desrt as well? [16:29] https://plus.google.com/hangouts/_/0ec0ef5db83f0a1952bc68dfb0337d646e9d288d?authuser=0&hl=en [16:29] jasoncwarner_UDS: i don't have the google hangout plugin, nor h264 video support :( [16:30] no thanks [16:30] desrt: what year is it where you live? ;) [16:30] haha [16:30] hadess: no worries [16:30] thanks for joining the irc [16:30] hadess: so part of why you're stalled is missing infra from other places too? [16:31] or would it be possible to push ahead on the new design without these things in place, keeping in mind that we want to add support later? [16:31] desrt, i think it would be almost impossible to retrofit [16:31] right. we're talking rewrite already [16:31] but if canonical is already thinking of doing a rewrite, we may as well pool resources [16:31] I have some interest in location services for wifi stuff .. for instance getting proper updates of regulatory domains, as it has been planned for a long while [16:33] do we need much of that provider description? [16:33] the target is 1) ip geocoding (code is in geocode-glib) 2) wifi geocoding (code will be in geocode-glib) 3) gps through cellular [16:33] hadess: cool [16:34] if canonical want to help, adding support for more modems in ModemManager, and adding support for GPS-A is probably much harder than writing a shim on top of all that [16:35] hadess: do you mean you're writing GPS-A support? [16:35] cyphermox, no, that somebody should [16:35] ack [16:36] I think there's some of it in progress [16:36] hadess: what's the plan for how the data gets from modemmanager to apps? [16:36] desrt: modem location support is provided via a dbus interface from MM [16:36] desrt, a small dbus service, the api is pretty much that of core location [16:37] hadess: and this does the wifi/ip-based ones as well? [16:37] desrt, it would, yes [16:37] so this is the to-be-written [16:37] desrt, "give me my location" and it would choose the way to access it based on accuracy required [16:37] yeah [16:37] yeah [16:38] the main difference here is that it's just one simple process instead of a gaggle of providers [16:38] yes, and without support for stand-alone gpses either [16:38] tragic :p [16:38] omg [16:39] hadess: then your concern moves to how to prevent unworthy apps from hitting this dbus interface [16:39] i assume it's meant to be a system service [16:44] totally agree, syncing with hadess, comparing requirements/plans [16:46] desrt, i don't think it needs to be a system service [16:47] hadess: so any user would have to be able to read data out of modemmanager then [16:48] ditto things like wifi AP mac addresses (that's how wifi-based geocode works, right?)? [16:48] desrt, the way things work right now, yes, but that's the same trying to configure your wwan broadband right now [16:49] hadess: almost starts to seem like we don't need a service at all, then? [16:49] it doesn't need to run as a system service, but if it runs as a session service, it needs to be special [16:49] why not just have a library do the work in app context? [16:49] do we consider location infromation privileged? [16:49] dcbw: yes. we ought to. [16:49] eg, how do we gate access to it? [16:49] desrt, because that would make it impossible to sandbox [16:49] in that case, normal users shouldn't be able to ask ModemManager for location info [16:49] dcbw: this goes to the larger sandboxing question [16:50] hadess: you could sandbox at the mechanism level [16:50] hadess: no access to modemmanager data, for example [16:50] we already have PolicyKit support for location stuff in MM [16:50] we just don't turn it on by default [16:50] but that's not really a model we want these days [16:50] that's why i thought you wanted to make it a system service.... then only root-owned processes (or whatever it runs as) get access to MM [16:50] it should be remembered on a per-app basis instead of a global PK dialog [16:50] desrt, a separate service would also take care of power management [16:51] interesting. [16:51] desrt, no point calling doing network calls if you have a good enough data from the modem for another app for example [16:52] who is the one on the canonical side who has time to work on this? [16:54] desrt: looks like daniel === udsbotu changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/client-2/ - http://ubottu.com/uds-logs/%23ubuntu-uds-client-2.log === udsbotu changed the topic of #ubuntu-uds-client-2 to: Track: Client | Converged network stack | Url: http://summit.ubuntu.com/uds-1303/meeting/21673/client-1303-converged-network-stack/ [18:08] Hi everyone, session will start in about 6 minutes. [18:11] session starting in 4 mn [18:13] hey everyone [18:15] lool: could you announce when the session goes live please [18:15] zyga-uds, it's live now [18:15] zyga-uds: it is, reload, reload [18:16] sucky youtube widget [18:16] lool: awe_: can we dynamically request NM to rescan for aps? [18:16] rsalveti: already present [18:16] awesome [18:16] rsalveti: there's a Scan method in 0.9.8 [18:16] QUESTION: will the converged stack affect testing or certification performed on non-touch/mobile systems [18:18] anyone got a hangout link for the chat? [18:18] NM is 3.9 MB RSS, even dhclient is 3.0 [18:18] that doesn't seem terribly much? [18:18] pitti_uds: nm-applet is the real hog [18:18] root 1371 0.0 0.0 205176 3020 pts/0 S+ 06:47 0:00 sudo src/.libs/NetworkManager --no-daemon [18:19] aye [18:19] dcbw 1191 0.0 0.5 710736 19464 ? Sl 06:46 0:08 nm-applet [18:19] vUDS needs a conflict resoultion protocol for the speakers to agree upon to minimize collision lag [18:19] nobody's denying that nm-applet needs a diet:) [18:19] I also mentioned I'd look at how we can reduce both [18:19] dcbw: want to join the hangout? https://plus.google.com/hangouts/_/e852387d7e4db65b443695b981fc9ad4431aaed1?authuser=0&hl=en [18:19] pitti_uds, it's not... it was just one criteria that we wanted to measure [18:19] 14.4mb as shown by ps_mem.py [18:19] thanks [18:19] awe_: right, thanks [18:19] agreed about nm-applet [18:19] does modem-manager handle... oh never mind, it'll go away [18:20] hey dcbw...long time! [18:20] pitti_uds: if you want to join the hangout as well, feel free! [18:20] modemmanager is a pain -- it opens all tty devices checking if that's a modem, that can be a problem on a phone that may have stuff like gps on a tty [18:20] lool: ^^ [18:20] dcbw, your typing steals the video focus [18:20] awe_: yo :) [18:20] hey dcbw, thanks for showing up [18:20] dcbw, better mute if you dont speak [18:20] qwebirc105673: not enough to contribute, I'm afraid [18:20] zyga-uds: but I'd say that's more of a bug [18:20] it is indeed annoying [18:21] rsalveti: no, it has to try otherwise it'd require some manifests to idenitify modems, right? [18:21] ogra_: yeah, muted already [18:21] :) [18:21] rsalveti: it's a problem whenever you have a serial port showing, up, mm will try talking to it [18:21] right, that's why I said it'd be more of a bug for me [18:21] because I don't think this is the desired behavior [18:21] we did just add ModemManager1 support, so that's a good patch to look at [18:22] it breaks everyone that needs to use serial based devices [18:22] that basically adds a completely new MM backend [18:22] rsalveti: I don't see a fix for that that would not break modem support for virtually everyone [18:22] rsalveti: even if you only look at 3G modems [18:22] rsalveti: I agree on that [18:22] rsalveti: one thing I tried to do to fix that [18:22] rsalveti: is to blacklist certain ttys in udev rules [18:22] rsalveti: and I got that to work for my development boards and generic serial-usb dongles [18:23] rsalveti: if you want I can share that [18:23] rsalveti: there's a similar problem with random usb devices being probed by mtp client to see if they are a storage device [18:23] rsalveti: that crashes bootloaders for me [18:24] zyga-uds: I think we have a bug opened for that [18:24] let me try to find it [18:24] rsalveti: cool, I'm interested in fixing that [18:24] rsalveti: in the end the rules for mtp and modem manager need patching [18:24] rsalveti: then the system is generic enough to have per-package rules that blacklist a device [18:24] zyga-uds: rsalveti: there's some stuff changing on that level, but can we keep it around what is being discussed on the hangout to not get all mixed up [18:24] ok [18:25] you're obviously welcome to bring things up, ping me if you feel your questions are being ignored [18:25] awe_: we also want rild support [18:26] cyphermox: no, I guess those are implementation bugs/details [18:26] if it doesnt have voice support it wont [18:26] zyga-uds: yeah, need to take a better look at that, but I know we have a bug :-) [18:26] pass cert [18:26] doubtful that ofono was any more certified though... holtmann do you know? [18:26] ChickenCutlass, I'll get there [18:26] We went throughout GCF certification with oFono. [18:26] You guys need to think about SIM Toolkit support. [18:26] cyphermox: it has been certified for GCF [18:26] ack [18:26] That is the first thing that is going to be asked. [18:26] thanks [18:27] lool: do we consider a situation where the vendor might replace the telephony stack, is that something they do on android today? [18:27] stgraber: esp. leverage all the work we've done and simplify convergence [18:28] stgraber: that sounds good [18:28] zyga-uds: they'd have to pass certification again [18:28] ah, yes the caps bits [18:28] zyga-uds: they do that today , yes [18:28] awe_: I'm preparing MM1 on a PPA [18:29] https://launchpad.net/~network-manager/+archive/modemmanager-next (incomplete) [18:29] does modem manager work with rild? [18:29] awe ^ [18:29] no [18:29] no, it doesn't [18:29] a rild connector would be nice to have [18:29] victorp_: I wonder how that changes our side, if they switch from vanilla android to say, qualcomm android telephony, does that change the interface as seen from the system? [18:29] zyga-uds: probably not [18:29] victorp_, voice support @ the high-level API is the big missing piece [18:29] as they would have to change RIL [18:29] Guhttps://git.kernel.org/cgit/network/ofono/ofono.git/tree/doc/certification.txt [18:30] if this was added to mm, we could add rild support to mm [18:30] https://git.kernel.org/cgit/network/ofono/ofono.git/tree/doc/usat-certification-status.txt [18:30] holtmann: thanks [18:30] zyga-uds: they can replace the implementation, but the interface would be the same [18:30] but it's fairly large piece of code that's missing [18:31] ConnMan comes with a built-in DHCP client. [18:31] holtmann, hey dude... long time [18:31] awe_: and crucial [18:31] he is hiding :) [18:31] ConnMan has its own DHCP client and server. [18:31] holtmann: yeah, we mean how hard could it be to make it use an external client again? [18:31] holtmann, that's what we're talking about... there's some concern about the builtin dhcp client [18:31] It is by magnitudes faster than external clients. [18:31] See my presentation at LinuxCon Vancouver a few years ago. [18:31] awe_: not sure is in the scope of this session but will be nice to talk about SIP support [18:32] * awe_ screams [18:32] holtmann: would it be possible to implement this in dhclient? [18:32] holtmann: we wouldn't want to have to support 2 DHCP clients [18:33] ConnMan DHCP had a 80% speed increase in corporate or public networks. [18:33] The internal DHCP client in ConnMan also reduces the memory footprint. [18:33] holtmann: due to the arp tricks? [18:33] As I said, the numbers where in my LinuxCon talks. [18:33]