Re: [sugar] XO identity shared via Browse
On Dec 4, 2008, at 4:59 PM, Sebastian Silva wrote: I looked this up. Actually, his only argument that I could find it suposedly makes phishing easier. I must really disagree. Can we please not duke out the issues with OpenID on this particular list? Go argue with Kim Cameron at http://idcorner.org/2007/08/22/the-problems-with-openid/ or something. I originally envisioned a potential use for OpenID within the XO security model in minimizing the number of passwords that needed to be remembered by the kids. I was thinking of strong, automatic OOB authentication to the IdP on the XS as a slightly lesser evil than a browser plugin storing the passwords, as the latter is potentially harder to back up, restore, etc. But I've come around since then -- an XS IdP will probably mean people expect to be able to use their OpenID from anywhere, including e.g. internet cafe machines that are not their XOs, in which case the strong OOB authentication to the IdP would be absent, thus we're back down to a password, thus we go down the rabbit hole of stupidity that I was trying to avoid in the first place. For authenticating the XO to just the XS, OpenID seems downright idiotic, and I'm actually in disbelief about hearing genuine suggestions for OpenID over Jabber. Or, in fact, anything else over Jabber. For those just tuning in, the whole story of Jabber on the XO has basically been colorfully fucked, as has that of the entire collaboration stack. I suggest further proposals of actually using Jabber for anything wait until the basic XO implementation gets to the point where IRC was 20 years ago -- namely, working. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Sugar-devel] XO identity shared via Browse
On Dec 4, 2008, at 11:34 PM, Robert McQueen wrote: I really don't think these kind of comments are productive for anyone. How not? You just wrote a long e-mail explaining *why* things are fucked, not in the least disputing my claim that they are, indeed, fucked. I'm not sure why you felt you needed to defend yourself, as I couldn't care less about dispensing blame. Nonetheless, until all the problems are resolved and there's hard stability data from the field, relying on important (especially security!) services running on top of the collaboration stack is idiotic and indefensible. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Sugar-devel] XO identity shared via Browse
On Dec 5, 2008, at 12:09 AM, Martin Dengler wrote: Because it's hard to distinguish gratuitous/personal attacks from a tough-love I gave a concrete suggestion about a particular use case (XO/XS authentication) -- namely, to stay the hell away from a hard dependency on a stack that's been, without any doubt or question, extremely problematic to get to work even for its very basic purpose. I don't see how this is either gratuitous or personal. I would love to see the reponse if someone from sugarlabs were to send an email saying Bitfrost has a long, colourful history of being fucking ineffective and its implementation has a number of holes You're confusing Bitfrost and Rainbow. I spent almost no time on the latter, and not by choice; how my time was allocated for a good chunk of my OLPC tenure agitated me greatly and was no small element in my decision to depart, which is entirely off-topic for the present discussion. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] OLPC + Sugar
On Nov 27, 2008, at 2:17 AM, Michael Stone wrote: OLPC remains incredibly excited by Sugar and looks forward to a long and productive working relationship with all the other people who share this excitement. Earlier this year, Nicholas informed both Walter and me that his plan was to terminate all OLPC involvement with Sugar within a year, and push off its stewardship to an organization that wouldn't be receiving OLPC funding. Since, to my knowledge, other OLPC people were not involved in _that_ decision, it's hard to divine whether your statement in this matter -- or, in fact, a statement made by anyone but Nicholas -- carries any weight whatsoever. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] sugar-devel mailing list
On Nov 17, 2008, at 10:59 PM, David Farning wrote: The Sugar developers have started a upstream list for sugar development issues that are not OLPC specific. If you are interested, please feel free to join. Namely, sugar-devel: http://lists.sugarlabs.org/listinfo/sugar-devel A full feed of Sugar Labs bug mail is now also available: http://lists.sugarlabs.org/listinfo/bugs -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] World readable documentation for Chandler rearchitecture
On Oct 22, 2008, at 11:39 AM, C. Scott Ananian wrote: I notice that, at the moment, there are lots of references to 'trellis'; I'd love to see some documentation about the exact what, why, and how of this. Trellis is Philip Eby's simplified, pseudo-STM based async processing system for Python: http://pypi.python.org/pypi/Trellis -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Viewing PDFs from Browse
On Oct 11, 2008, at 11:04 AM, Walter Bender wrote: Does it even make sense to make annotation tools for PDF as a general concept? Why try to distort a proprietary, read-only data format into something it isn't. PDF is not proprietary. PDF/X-1 became an ANSI standard as early as '99, PDF/X-1a became ISO 15930-1 in '01, PDF/X-3 became ISO 15930-3 in '02, PDF/A became ISO 19005-1 in '05, and finally, PDF 1.7 became ISO 32000 earlier this year. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Tagged Journal Proposal
On Sep 23, 2008, at 2:05 PM, C. Scott Ananian wrote: A hand-drawn proposal for what a Journal supporting directory traversal as well as tag space exploration is in the attached PDF. Discussion welcome! FWIW, I made several impassioned proposals for these features -- in fact, with some visual resemblance to your own -- on the Pentagram whiteboards, but the Pentagram folks were opposed on account of excess complexity. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] LiveCD LiveUSB
On Sep 1, 2008, at 5:40 PM, David Farning wrote: Sounds reasonable. Where should I upload the images? Will it be you, Jani or Morgan uploading? Whoever it is should send me their pubkey and desired username off-list. Another organization is in the process of taking over hosting downloads.sugarlabs.org for us, but I can create a temporary account for someone in the meantime. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] LiveCD LiveUSB
On Sep 1, 2008, at 10:25 PM, Sameer Verma wrote: We should also put it up via torrent. Why? We have plenty enough bandwidth to satisfy demand over plain HTTP. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] LiveCD LiveUSB
On Sep 2, 2008, at 8:59 AM, Martin Dengler wrote: Notwithstanding, is there a reason to discourage it (admin overhead, for example)? I wasn't trying to discourage it, but to understand it -- I personally never use torrents when a fast HTTP download is available. Anyway, it sounds like there are at least a few people who prefer torrents, so there's no reason not to set some up. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] LiveCD LiveUSB
On Sep 1, 2008, at 5:23 PM, David Farning wrote: I am a bit reluctant to host them at Sugar Labs. We are pushing to brand Sugar as distribution agnostic. So, distributing a Ubuntu based live cd and live USB seems a bit disingenuous. No, it would be disingenuous if we also refused to host _other_ live CDs. Precisely because we're distro agnostic, we should provide resources to all those interested in making Sugar more widely available. I am happy to have a 'unofficial' or 'contrib' directory in the download tree to indicate SugarLabs didn't produce the images. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] LiveCD LiveUSB
On Aug 31, 2008, at 7:42 AM, Jani Monoses wrote: I do not know where ISOs could be hosted though. SugarLabs can host them. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
On Jul 22, 2008, at 7:49 PM, Michael Stone wrote: Python lacks support for loading data without unmarshalling it from bytestreams. Can you clarify what specifically you mean with this point? -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] ssl authentication [was (another) WebKit port of Browse]
On Jul 12, 2008, at 11:59 PM, Dirk-Willem van Gulik wrote: Which IDMR - the sun one with all the usual/heavily standardized industry protocols - or something OLPC specific ? It's not a protocol, just a small Python script that does some XML-RPC nonsense from what I recall. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] ssl authentication [was (another) WebKit port of Browse]
On Jul 8, 2008, at 2:46 PM, Carol Lerche wrote: I am puzzled about the PKI infrastructure you envision. I envision having a private certificate authority that runs on the teacher's XO and keeps its keystore on a USB thumb drive. To summarize for those who haven't heard me rant about this in person: actual PKI is almost never the answer. It is a question, and the answer is hell, no. While you may believe the setup you have in mind is easy and uncomplicated, the odds are *overwhelmingly*, **super-stunningly** stacked against you to make PKI work the way you want in production. The fact that TLS client certs, in particular, have zero commercial end-user deployment uptake, should tell you something. I cannot recommend more strongly to stay the bloody hell away from the entire real PKI/X.509/CAs morass. A solution based on e.g. SSH and key continuity is, while certainly less traditional, enormously likely to work out better in practice. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Fwd: Autonomous system for Sugar development....
On Jun 6, 2008, at 9:04 PM, Jim Gettys wrote: The community itself needs to decide on a set of people who are the group of sysadmin people for Sugar's possible move to be something all are comfortable about. Please don't top post, and please do quote relevant sections of original e-mails when replying. I don't know what the above statement is referencing, since I never made any claims about who should choose, or act as, the SugarLabs sysadmins. And for more to contribute in the sysadmin area, the system administration needs to have redundancy, and actually get documented and communicated. Single points of failure is not an option to us at this date. A single point of failure was never an 'option'; at OLPC, it was a reality due to organizational failings. No reasonable open source community will make those kinds of mistakes. I've offered hardware, bandwidth and root to a small group of trusted SugarLabs people. I'll leave scheduling meetings and discussing it with OLPC to people who have the patience. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] New multilingual dictionary activity
On Mar 10, 2008, at 7:26 PM, Jameson Chema Quinn wrote: For the XO, it would be great if dictionaries were *not* constant databases. Where's the issue? You make the existing corpus a constant database, and provide user modifications and additions as a tiny, human-readable overlay file that's consulted first on lookups. It hardly strikes me as a worthwhile goal to make the user modifications on a fraction of a percent of the corpus be in-place at the expense of slowing down all queries noticeably. Is there some use case that demands this mode of operation? -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] New multilingual dictionary activity
On Mar 9, 2008, at 9:33 PM, Chris Ball wrote: * Could use a trie instead of just using Python dicts; it's a little slow on the XO. Any other suggestions? Since dictionaries are constant databases, you might convert them into djb's CDB database which at least at one point had Python bindings. That'll give you a constant two-seek word lookup at the expense of fuzzy matching and incremental search. However, if you're using straight python dicts, you probably don't have either of those now; I haven't looked at the code. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Speeding up activity launches.
On Mar 4, 2008, at 8:39 PM, Chris Ball wrote: I think having something working will be the only thing that motivates resourcing any security work that's needed alongside it. +1. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Disconnected backups.
On Feb 19, 2008, at 3:32 PM, Jameson Chema Quinn wrote: That's a separate issue - at the simplest, you just store the encryption key on the first backup and only manually thereafter; a more complicated scheme, for implementing later, would break it into 5 parts of which any 3 would suffice, and store the same 2 parts on all the backups Collaborative erasure-coded backups are not a good idea for devices with very limited storage, except in special cases. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] python activities startup
Hi Jukka, On Feb 6, 2008, at 11:13 AM, Klaus Weidner wrote: Would it be feasible/helpful to use the uncore approach used by Emacs? - launch Python interpreter, load and initialize modules - force the interpreter to dump core - convert the core file to an executable file that has all the modules loaded and initialized already - activities use this preloaded executable instead of the plain python interpreter per this thread: http://lists.laptop.org/pipermail/sugar/2008-February/004252.html we're looking into startup-time optimizations for Python on OLPC XO laptops. We had discussed this in the past at some length, and I recall you mentioning you had folks working on something similar. Did your effort get anywhere? Any notes to share? Thanks! Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] On Matploblib for the XO
Hi Fernando, John, I wanted to restart the discussion around Matplotlib, IPython, and the entire scientific/mathematical environment idea on OLPC laptops. I responded to the mail below previously, but I'm not sure what happened after that. Arjun Sarwal, who is the author of the Measure activity that I demonstrated at SciPy, has recently been looking into plotting libraries for the XO, and (understandably) Matplotlib caught his eye. Arjun and others -- I'm forwarding Fernando's original e-mail below for your reference. I am in full support of the Matplotlib/sympy/IPython combo getting up and running on the XO, on the way to an awesome complete sci/math environment. I hope Fernando and John will still consider giving us a hand. Thanks! Cheers, Ivan. On Aug 19, 2007, at 10:38 PM, Fernando Perez wrote: In order to estimate the sizes one could expect to see with a matplotlib build for the OLPC, I tried to build it with only the GTK Cairo backend (though AGG still needs to be built for internal use, since it's everywhere) and then added GTKAgg as well. These were the sizes I got: tlon[build] d *.tgz /home/installers/src/scipy/matplotlib/build -rw-r--r-- 1 fperez 4674627 2007-08-19 19:43 mpl_cairo_only.tgz -rw-r--r-- 1 fperez 121 2007-08-19 20:25 mpl_with_gtkagg.tgz However, the Cairo backend is still not very mature and doesn't perform very well; in particular it lacks proper transparency support, so using GTK+Agg might be a better alternative. These sizes are what I got from doing a build and quickly removing some obvious things (as well as deactivating support for Qt, Tk and WX). It's quite likely that John might suggest how to trim it further, I was afraid of cutting things I shouldn't so I went in conservatively. John will correct me if I'm wrong, but I think that since you already ship a real GTK, the GTKAgg backend should work just fine. Agg is very fast, has extremely high quality, and the GTKAgg backend is probably the most mature and widely tested one of all. If 5.5 MB is an acceptable size for you, here are the numbers for the other pieces of the puzzle. For IPython: -rw-r--r-- 1 fperez 713456 2007-08-19 21:18 ipython_installed_nodocs.tgz -rw-r--r-- 1 fperez 808717 2007-08-19 21:16 ipython_installed.tgz IPython comes in at a bit under 1MB, keeping the source and HTML manual but removing the PDF docs. Removing the HTML manual saves about 100k. As for sympy, I just installed it and tarred it: -rw-r--r-- 1 fperez 1686428 2007-08-19 21:21 sympy_installed.tgz I'm not familiar enough with it to know what can be cut out, though I know their 3d plotting is OpenGL based, so that can probably go. You'd need to get the sympy team involved, though Ondrej sounded enthusiastic when I spoke with him. So it looks like the ipython/matplotlib/sympy combo would cost you around 8MB total. That's not counting numpy, but you told me you'd already decided to include that for other reasons (matplotlib can't run without numpy, nor can one do many key numerical operations without it at reasonable speeds). One final question: have you run any numpy code on the olpc to get an idea for its floating-point performance? Here are a couple of reference points and an easy way to get some timing info: On my 5 1/2 year old laptop, a Pentium-III at 1.13 GHz with only SSE (no SSE2) instructions, a typical test time for numpy is: maqroll[~] time python -c import numpy;numpy.test(10) /dev/null 3.484u 0.196s 0:03.73 98.3% 0+0k 0+0io 0pf+0w On my desktop, a dual-core Athlon 4400 (2.2GHz clock): tlon[~/tmp] time python -c import numpy;numpy.test(10) /dev/ null 1.420u 0.144s 0:01.56 100.0%0+0k 0+0io 0pf+0w My laptop is perfectly usable as a matplotlib/numpy computing environment at these speed, and you could probably take a factor of 4 hit on performance and still be OK for the numerics. The graphics may get a little unpleasant if your box is much more than 2-4 times slower than my laptop, I suspect, but it might be OK. Also, I think that if one disables Agg and uses only the plain GTK backend, things go faster (John will correct me if I'm wrong). In any case, I hope you find this useful. Feel free to forward it to those on your team you deem appropriate. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IMPORTANT] Downtime tonight Jan23 5PM EST
On Jan 23, 2008, at 7:18 PM, Ivan Krstić wrote: In what's hopefully one of the last big infrastructure rejigglements[0] required in the foreseeable future, we will be taking a bunch of front-facing OLPC services down tonight starting at 5PM EST. Took a bit longer than expected, but we should be up and running at this point, and in great shape. I'll be keeping an eye on things, but if you notice anything unusual with any of the services (mail, wiki, lists, public web, etc), please let me know immediately. Thanks, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [IMPORTANT] Infrastructure, cont.
The project hosting request queue is now empty, as best I can tell. If you applied for hosting of any kind and don't yet have a tree, please alert me to it directly. That said, the infrastructure situation is continuing to be rocky, and I will have to spend more time on it than expected. We've gone this far without almost any service interruptions while I've juggled things around, but due to the hot offload machine having some issues, there might be turbulence in the week ahead. All effort will be taken to minimize downtime. Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Killing activities
On Dec 31, 2007, at 1:11 PM, Steve Lewis wrote: I am finding myself in a situation where I start an activity that fails to start - this happens alot becaise I am writing my own activities - short of restarting sugar is there any way to kill a stuck activity - one which says it is starting and never gets the Stop/ Resume menu? In the development versions, activities that fail to start after some amount of time should be reaped automatically by Sugar: http://dev.laptop.org/git?p=sugar;a=commitdiff;h=b876648bd616fa57b0e3c8050af46bb1c6268e75 Unless your actual processes are getting stuck (in which case you can sigkill them), there's nothing particularly bad about the pulsating icon being stuck; it's just a visual annoyance. You could crank the activity failed reaping timeout down significantly in your Sugar checkout while doing development. Please note Reply-To. Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [IMPORTANT] Infrastructure, hosting, etc
Folks, we've fallen somewhat behind in our infrastructure work. Notably, a number of you applied for hosting and haven't heard back from us -- our apologies for that. Less visibly, our current server setup isn't what we'd like it to be. We lost our sysadmin recently, so I will personally clean up both issues over the next week. Regarding the former, if you don't hear back from me about your hosting request by tomorrow, please post another copy to the list. Regarding the latter, there will likely be some intermittent downtime on all public-facing OLPC services as I move things around. It hopefully shouldn't be too noticeable, but if you can't get to one of our servers sometime in the next 7 days, don't panic -- take a deep breath, go out, see the daystar, hug your children, try again later. We have a full-time sysadmin starting in January, which should make all this much smoother in the future. He's a great guy, and I will be introducing him on-list when he starts. Cheers, happy holidays, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Data Transport between nodes
On Dec 14, 2007, at 7:03 AM, Dafydd Harries wrote: contents = file(path).read() dbus.ByteArray(contents) How is that possibly supposed to scale? -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] secure /tmp and /var/tmp
On Nov 7, 2007, at 9:09 PM, Albert Cahalan wrote: Using standard directories is not scribbling all over the filesystem! This anti-compatibility attitude needs to stop. It's really hurting OLPC, needlessly making the goals harder to achieve. Breaking compatibility is something to be done as a last resort, when no alterative will work. For better or for worse, compatibility has been broken, and on a level as fundamental as file access. If an application can't even access the user's files without being aware of the datastore, what good is it to pretend that providing small bits of backwards compatibility will make things substantially easier? For us, $SAR/tmp lives in RAM and is severely limited (maybe to as little as 1MB per application). $SAR/instance is used for transient per-instance disk-backed storage. Since it's a given that work needs to be done to port applications to Sugar, it's a _good_ thing that a programmer is also confronted with the decision as to which of these two temporary directories to use. Enabling a wrapper for /tmp would have us make that decision for them, and as fellow Python programmers know: explicit is better than implicit, and in the face of ambiguity, refuse the temptation to guess. The long-term goal should be to support solid sandboxing of true all-over-the-filesystem software installs. This may need a unionfs filesystem so that files can be put everywhere without the dummy files needed for file-on-file bind mounts. Imagine if you could install any RPM, knowing that it had no way to corrupt your OS. That goal is not something I'm spending much time thinking about. The level of protection provided by Bitfrost is not something you can do without serious compatibility breaks with how things are done at present. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] secure /tmp and /var/tmp
On Nov 8, 2007, at 11:33 AM, Jim Gettys wrote: Heh. You are way too young It takes a long time to become young! On the upside, my work did not give rise to xorg.conf ;) Marcus Leech wrote: My first Unix machine had 128K of MOS memory, and we supported about 10-15 interactive users on it MOS memory? _MOS memory_? In my young day we started out as apprentice binary registers. Six o'clock in the morning, come rain, sleet, hail, or snow, we'ed be there kicking each other in the buttocks -- right for 1, left for zero. A'course I say registers, cause they were registers to us. But it were a stack really. None o' this modern stack pointer rubbish, either. You used to 'ave to remember which were t'top element in yer 'ead. Anyway, due to vocal support, we'll preserve /tmp. I don't think it's the best course of action, but we'll roll with it. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Bitfrost Activity Isolation being turn ON.
On Nov 6, 2007, at 9:14 PM, [EMAIL PROTECTED] wrote: LAUNCH EVERY ZIG. For great justice! -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Bitfrost compliance for Update.1
On Nov 3, 2007, at 11:30 AM, Benjamin M. Schwartz wrote: Sugar should set this variable to the preferred temporary directory, so that the above boilerplate is unnecessary. Yes, I'm planning on Sugar doing this and providing getters for the data and conf directories. We wanted to get the compliance message out before any changes to Sugar had a chance to land, however. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Bitfrost compliance for Update.1
On Nov 2, 2007, at 12:24 PM, Carlos Neves wrote: Will os.tempnam() use this dir by default? No, but it's bad security practice to use os.tempnam unless you really know what you're doing (at that point, you can pass in the target directory as the 'dir' keyword argument). Here's how to properly get a temporary file in Python until we provide helpers for it through Sugar: import os.path import tempfile from os import environ tmp_root = os.path.join(environ['SUGAR_ACTIVITY_ROOT'], 'tmp') tmp = tempfile.TemporaryFile(dir=tmp_root) --- At this point, 'tmp' is a file-like object that you can use normally. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] ip4-address buddy property - still needed?
On Nov 2, 2007, at 9:17 PM, Marco Pesenti Gritti wrote: Also I think integrating and properly supporting Pascal's log collector would go a long way in facilitating testing. Working on this bit. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IMPORTANT] build and release process explanation
On Oct 30, 2007, at 3:44 PM, C. Scott Ananian wrote: The details here might be in flux for our first joyride-based build, but we'll do our best to keep everyone informed. After some internal discussions, we will not be using joyride directly for the update.1 build. The instructions in my original e- mail still stand fully: joyride should be used by everyone to get their packages in, but we will actually assemble them into the final update.1 build outside of joyride. More details on this along with a concrete plan will be provided tomorrow sometime after the morning release engineering meeting. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] CODE FREEZE COMING!
Hi Morgan, On Oct 29, 2007, at 9:21 AM, Morgan Collett wrote: You've specified a lot of process, assuming the roadmap dates are authoritative and we aren't in feature freeze yet... Which dates are correct? apologies, there's quite a bit of confusion surrounding dates and releases. We expect to issue a complete clarification later today. Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Resuming by default
Hi Bert, On Oct 23, 2007, at 2:43 PM, Bert Freudenberg wrote: The *actual* problem right now is that resuming an activity is much more complicated than simply clicking the icon in the frame. And *this* is backwards. We do *not* want to start with a clean state every time. we fully agree, but there doesn't appear to be a saner default behavior for FRS. Specifically, in the absence of datastore versioning, switching to 'resume by default' would effectively kill the journal; adding a per-activity flag would add confusion and break consistency. After FRS, we intend to very carefully consider this issue. It's non- trivial, and interactions with multiple activity instances, bulk data, volatile state, etc all need to be considered. The current tentative plan is to have a Journal Summit as soon as FRS is out the door and the immediate post-FRS activities quiet down a bit. You would certainly be invited. Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Configuration Service?
On Oct 24, 2007, at 11:32 AM, [EMAIL PROTECTED] wrote: A hierarchical configuration system, which are just fancy words for a file system paradigm. Background reading for you, in no particular order: http://live.gnome.org/dconf http://pvanhoof.be/wiki/index.php/Temporary_location_for_D-Conf_specs http://svn.rpmforge.net/svn/trunk/tools/dconf/config/dconf- example.conf http://aseigo.blogspot.com/2005/04/stupidity-of-dconf.html http://git.desrt.ca/gitweb/?p=dconf.git;a=summary -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [IMPORTANT] New policy on blocker bugs
Hi, until we ship, we're instituting a new policy on blocker bugs: * Any bugs being newly designated as FRS blockers need to have an e- mail sent to the sugar@ or devel@ list (depending on which part of the system they touch) with a short explanation of why this bug is a blocker, any dependencies it might have, any relevant details, any idea on whether a fix is known or forthcoming, etc. * Any FRS blockers being closed need to have an e-mail sent to sugar@ or devel@ with a short update on whether the fix is in the builds, pending for inclusion, etc. If not yet in the builds, and it's not obvious from the bug's Trac page where to find the fix, please include a link to it. Anything else that's worth knowing about this bug or how it was closed, please include it; we have various dependencies between our blockers, and details you provide might provide clues or directly unblock work on other bugs. When sending these e-mails, please copy and paste a line or two of the bug description itself into the e-mail along with a link to the full bug. For new blocker bugs, please use the subject 'new FRS blocker: #bugnumber', and for closed ones, 'closed FRS blocker: #bugnumber'. This will let people who don't care about the messages ignore them based on the subject line. Thanks. Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] E-Mail Activity
On Oct 24, 2007, at 12:27 AM, Christoph Derndorfer wrote: Can this indeed be true? Are the children only supposed to use webmail solutions, maybe provided by the school or something? For first ship, we're going with webmail because of infrastructure challenges; we'd like to revisit this down the line. (Though Tinymail has certainly been seen running on the XO.) -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Pippy and Calculate
On Sep 5, 2007, at 1:57 AM, Yoshiki Ohshima wrote: Even just making a character/console based plotter would give kids a lot to learn, at the same time. There are some folks in the Python scientific computing community working on this. I'm pretty excited about it. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] emergency server maintenance: 8/31
Public-facing development services (bugtracker, git, development hosting) are offline for emergency maintenance effective immediately, and for an expected duration of under 6 hours. Apologies for the inconvenience. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] emergency server maintenance: 8/31
On Aug 31, 2007, at 11:47 PM, Ivan Krstić wrote: I'm extending this timeframe by up to another 12 hours, due to unexpected difficulties. All services are up and looking good. If anyone notices something strange or broken, please let me know as soon as possible. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity write space
On Aug 8, 2007, at 4:27 AM, Marco Pesenti Gritti wrote: Really? We want Sugar to work also outside the OLPC distribution (and so without Rainbow). I think this /data business is nonsense. The activity should be given a path at startup, and it should only ever attempt to work with known directories under that path (such as 'conf', 'tmp', 'data'). That behavior will work with or without Rainbow, and is the right thing to do anyway; hard-coding paths outside of the activity's own space is clearly not a good idea in any scenario. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity write space
On Aug 8, 2007, at 10:56 AM, Michael Stone wrote: Fine. We'll rewrite P_SANDBOX to make it clear that this is what you meant. Note that this doesn't necessarily impose a change to where activities end up writing; for instance, Rainbow can pass '/' as the activity root to a containerized activity. Would the environment variable OLPC_SANDBOX be an appropriate means of conveying the desired sandbox root to the launching activity? I prefer ACTIVITY_ROOT. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] First impressions of a B4 machine
Hi Ivo, On Jul 23, 2007, at 1:29 AM, Ivo Emanuel Gonçalves wrote: Hello Sugar and Devel lists, please avoid cross-posting to these lists if unnecessary. I have set Reply-To: to the Sugar list. Booting XO was fast for a Linux system, but very likely not fast enough for a child expecting it to turn on immediately. I guess it can't be helped. There's a fastboot version of the firmware that can boot the machine in 3-4 seconds. The boot time, as we get closer to production, will start shrinking towards those numbers. What could be done, however, is hide the diagnostic dialogs with a simple splash screen stating POWERING ON, or LOADING, or whatever. This is being done, yes. I don't understand why the XO asks for my name after I turned it on for the first time, as it has never greeted me by my name since, nor does it seem that my name has any importance for school work. The name is how you're represented on the mesh, and is already utilized by Sugar for this purpose. It seems my version of the XO logo stays in Sugar's background, but otherwise seems to have no other use. The colors of your XO also represent you on the mesh. doesn't seem we may switch the color afterwards, either. They will be changeable. Why not look into smaller and more XO-adequated distros like Damn Small and similar? Red Hat was willing to do the heavy lifting to properly customize a distribution to our needs; given the unique hardware and software of the XO, no existing distribution would work for us off the shelf. That the current distribution is not yet lean as it could be is a known issue and one that will be worked on in the coming weeks. Is it because of SELinux? SELinux may be put on any distro. We do not use SELinux. One of the big issues I have found so far should be easy to solve. And that's the file system. Pretty much every program under the XO with an Open/Save File dialog displays the entire mess that is the Linux filesystem. Are children supposed to even see that? No, they're not. The dialogs are getting replaced by actual Sugar dialogs soon, and the security system won't allow individual applications access to the entirety of the filesystem anyway. Let's go over the programs, shall we? [I'll skip this part since I don't deal with the programs much.] Oh, and let me talk about the shell. Is this really bash? Why, oh why? BusyBox is so much better suited here, especially considering the limitations of the XO, so why put bash here? I'm not sure I understand which limitations you're referring to; surely you're not meaning to imply that our hardware can't deal with a proper shell. It's not like the XO will be used by bearded UNIX users and their emacs. Do not presume how the machines will be used. It's folly. The shell's there to rescue the system in case something goes wrong, am I right? Or to compile software or grab a developer's key and change everything on the machine. Next thing I know and someone's gonna tell me that the XO software is not compiled against uClibc or dietlibc. . . It is, right? Right? No. Battery: Drains too fast, even while the CPU is idle and the display is set on BW mode. There's lots of activity in this area. Expect significant improvements. Before I go, does anyone know who I have to contact to get a developers key? One isn't needed yet. When support for this goes into the builds, I will provide a piece of software that people can use locally on all pre-MP hardware to generate developer keys for themselves. Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Post-trial2] Buddy identification: security and UI requirements?
On Jul 21, 2007, at 4:07 PM, Simon McVittie wrote: (Mailing this now while I remember, because this is something we need to think about relatively soon after Trial 2, I think. Daf and I will be in Boston on Monday, Tuesday and Wednesday trying to debug collaboration, so it'd be great if we could talk to Ivan and Eben about this while we're there.) I'll read the rest of the message in a bit; can you meet with me at 2PM Monday? I'm extremely busy the first three days of next week. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Translations
On Jun 28, 2007, at 4:17 PM, Marco Pesenti Gritti wrote: Anyway, do you who maintains kuku? Julius Lucks, `lucks` in trac. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Using Git / downloading activities and Memory problems
Hi Aneto, Aneto Okonkwo wrote: I have been having difficulty installing git on windows. Does anyone have any instructions I can use to download and set it up? Git still relies on a mudball of shell and Perl scripts, so getting it running under Windows proper is an uphill battle. The recommended way to do it is to first set up Cygwin, which might be more trouble than you're willing to go through. Even then, it'll run quite slowly because of certain FS ops being substantially slower on Windows than on Linux. Alternatively is there anyway to use git on the olpc itself, does anyone have those instructions? As root, 'yum install git-core' should do it. are preloading an array of 26 images ~32K each and this crashes on the olpc. Please provide more details. Memory allocation shouldn't *crash* the machine under any (reasonable set of) circumstances; the OOM killer might kick in and destroy a few processes, however. In your case, you're allocating less than a meg, so something is certainly wrong if it's crashing. What kind of crash are you getting? Can you post the code and the images somewhere where we can test this? -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
