Re: [Sugar-devel] Clocks on XOs
El Fri, 02-07-2010 a las 20:15 -0700, Hal Murray escribió: Is that one of the old XOs that had troubles with the tiny battery feeding the TOY/RTC clock when the main battery and wall power are both disconnected? I forget the details, but I think there was a problem with the battery holder. Likely so, but the software should be able to compensate for it. After discussing it on IRC, it seems that olpc-update-query should automatically update the clock from the OATS server. NetworkManager used to call ntpdate when it setup a connection. Was that an OLPC addition? We figured out that the ntp package has never been present on the XO images. I think this area gets tangled up with security and lease checking. Do we want/need two separate modes, one for the secure case and another for developers without a school server? Maybe. We discussed the security implications of using unauthenticated ntp on XOs with anti-theft enabled yesterday on IRC. The concern is that a clever thief could setup a LAN with DHCP, DNS and NTP to set a date in te past and thus subvert the leases expiration scheme. However, with root access on the laptop, one does not need to bother so much: they could simply change the time from the console or, better, in /etc/rc.local. There's no way to practical way to implement effective anti-theft without taking away root from the user. And once we take away root access, we've also taken away olpc's principle #1: child ownership. What are the school servers doing to keep their clocks reasonable? They're using ntp, with the Fedora pool of ntp servers. Why aren't we using ntp? ntp is probably overkill for XOs. Besides, who would want to give up that much ram? On top of that, ntpd doesn't get along with power saving mode. Wow, 2MB of RSS! I had no idea ntp was such a hog. Aside from quirks like this one, is time on the XO normally good enough? I would have to check... -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
MANIFEST pointlessness
El Fri, 02-07-2010 a las 15:54 +1000, James Cameron escribió: A fascinating meaning of the word MANIFEST that I had not previously encountered. That sounds like an INVENTORY. What's the point of a file that is automatically generated? None, this is why I removed it. IIRC, the original plan was to make the MANIFEST contain hashes, so it could be used for integrity checking and to update activities by downloading only deltas. In 3 years, nobody ever got around to implement any of these advanced features... And in case anyone ever did, the current MANIFEST format would have to be redesigned anyway. To simplify the life of activity authors, we should simply remove any mention of it from the documentation and maybe teach setup.py to generate bundles out of git ls-files. Meanwhile, SoaS, USR and the new ARM-based XO laptop are pressing hard for switching from xo bundles to a full-featured packaging system, which would also solve the problem that the MANIFEST was supposed to address. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Clocks on XOs
El Sat, 03-07-2010 a las 09:54 -0400, Bernie Innocenti escribió: Likely so, but the software should be able to compensate for it. After discussing it on IRC, it seems that olpc-update-query should automatically update the clock from the OATS server. I checked: olpc-update-query only sets the clock if it's off by more than 24hours, so it cannot serve as a replacement for ntpdate. Besides, I can't find where NetworkManager would be running ntpdate... The most logical place would be /etc/NetworkManager/dispatcher.d, but there's nothing. The ntp packate drops a script in /etc/dhcp/dhclient.d, but it seems to kick into action only if the dhcp server provides an ntp server option. My conclusion: currently there's no straight-forward way to set the clock on the XO (even when we don't care about the time hijacking scenario). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
NetworkManager time sync
Dan, we don't have any way to synchronize the clock on the XO... I'd rather avoid running ntp all the time as it wastes 2MB of RSS. Does NetworkManager provide a service to automatically call ntpdate when the interface goes up? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] UI experiments: pop-up menus and hot corners
some current (ongoing) future design changes will remove this issue completely with a full screen screen dialogue for deciding new/resume. One click on a home view activity displays a gallery/journal like display of past work or a new blank template My observation - on the XO, there is a VERY perceptible time lag between when the user makes a click (on an existing screen) and when the replacement screen gets presented to that user. [It would not be so bad if the cursor changed shape to indicate the system is working on your input -- but as it is, the XO display might freeze, or even switch (temporarily) to a completely unrelated session -- and the user must mentally refrain (for up to a number of seconds) from doing anything while waiting to see whether the expected screen will/will_not be shown. [This time lapse in preparing a new full screen display on the XO seems to be worse with metacity than with matchbox. For instance, with Paraguay's sugar 0.88 builds, the activity being launched screen sometimes never gets to pulse -- apparently, to get it shown might take as long as it does to prepare the actual activity session's screen !!] A major advantage of the menu (palette) on the XO is that as soon as the user clicks within that menu, the menu itself vanishes. This gives the user IMMEDIATE visual feedback that the system is working on your input - and removes the what is it doing? doubt from the user's mind. Thanks, mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] UI experiments: pop-up menus and hot corners
Hi Mikus, On 4 Jul 2010, at 04:32, Mikus Grinbergs wrote: some current (ongoing) future design changes will remove this issue completely with a full screen screen dialogue for deciding new/resume. One click on a home view activity displays a gallery/journal like display of past work or a new blank template My observation - on the XO, there is a VERY perceptible time lag between when the user makes a click (on an existing screen) and when the replacement screen gets presented to that user. [It would not be so bad if the cursor changed shape to indicate the system is working on your input -- but as it is, the XO display might freeze, or even switch (temporarily) to a completely unrelated session -- and the user must mentally refrain (for up to a number of seconds) from doing anything while waiting to see whether the expected screen will/will_not be shown. [This time lapse in preparing a new full screen display on the XO seems to be worse with metacity than with matchbox. For instance, with Paraguay's sugar 0.88 builds, the activity being launched screen sometimes never gets to pulse -- apparently, to get it shown might take as long as it does to prepare the actual activity session's screen !!] A major advantage of the menu (palette) on the XO is that as soon as the user clicks within that menu, the menu itself vanishes. This gives the user IMMEDIATE visual feedback that the system is working on your input - and removes the what is it doing? doubt from the user's mind. I do feel the pain... But the fullscreen dialogue should do no more than the current hover palette, there is no excuse for its code to being perceptibility slower. It's not starting up the activity or triggering an enema of module imports and dbus messages, it's just showing a full screen 'new or resume past instance' UI, with pretty much just the same content as the current 'weight and then fight with the cursor' mini palette. The down side is that every activity start would be then be two clicks, one to bring up the large dialogue (I like to think of it as a one page gallery), and one for new or resume choice... But that was partly the point, no one here could agree on a new or resume default behaviour, so there needs to be an extra user end decision, just to settle the UI feud and allow us move on, to more gainful tasks. Regards, --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] UI experiments: pop-up menus and hot corners
The down side is that every activity start would be then be two clicks, one to bring up the large dialogue (I like to think of it as a one page gallery), and one for new or resume choice... But that was partly the point, no one here could agree on a new or resume default behaviour, so there needs to be an extra user end decision, just to settle the UI feud and allow us move on, to more gainful tasks. If the user needs to choose case-by-case whether to launch new or resume, if he wants to resume he can go to Journal (one click) and launch from there (second click) -- whereas if he wants to launch new he can go to Home, hover, and (one click) 'Start' in the existing palette. For those users who consistently resume all the time, provide a setting within the control panel to override the directly_on_Home_icon first-click behavior (perform launch new vs. show menu of resumes). If frame behavior can be specified by user, so should home behavior. My $.02 mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
