**** BEGIN LOGGING AT Thu May 26 02:59:57 2011
May 26 07:17:46 <JaMa|Off> moin
May 26 10:34:42 <jeepingben> antrik: I have shr-chroot, so I have a tarball of the kernel instead of a git repo,  I didn't expect to spend so much time on it
May 26 10:35:35 <JaMa|Wrk> you can build from git repo if you want
May 26 10:35:57 <JaMa|Wrk> you can use devshell to setup your shell env and build manually
May 26 10:36:23 <jeepingben> is it in the shr build article?
May 26 10:36:24 <JaMa|Wrk> or you can use slightly modified recipe directly in git checkout to build and rebuild faster
May 26 10:36:37 <jeepingben> that sounds promising
May 26 10:36:43 <JaMa|Wrk> article?
May 26 10:37:15 <jeepingben> http://shr-project.org/trac/wiki/Building%20SHR
May 26 10:38:07 <JaMa|Wrk> partially in "Making changes"
May 26 10:38:16 <JaMa|Wrk> and for devshell just build recipes/addons/devshell.bb
May 26 10:38:47 <JaMa|Wrk> and in deploy/addons you'll find script to setup paths to your sysroot to use same toolchain for local manuall builds
May 26 10:39:54 <jeepingben> that sounds like exactly what I need.  When I first built the mlx90614 (thermometer) module  for my FR, I had toolchain and a git checkout of the kernel
May 26 10:40:13 <jeepingben> I'll look at this a bit this morning, but I have to work soon
May 26 10:44:44 <JaMa|Wrk> and thanks for working on nand/badblocks issue, I wasn't able to reproduce it here, maybe I'm lucky without any real badblock in my nand
May 26 10:45:27 <jeepingben> I was thinking about that, I spoke with someone who didnt see it, but did have bad blocks and I was wondering if they weren't on mtd6, but on some other part of the nad
May 26 10:45:53 <jeepingben> is the plan to switch to .39 quickly?
May 26 10:46:24 <JaMa|Wrk> it would be nice, but don't know if MMC issues with .39 will go away soon :/
May 26 10:46:49 <JaMa|Wrk> jeepingben: you can try .39 if you can reproduce nand issue from .37?
May 26 10:47:10 <jeepingben> sure, are images up on shr.bearstech.....
May 26 10:47:41 <jeepingben> and does the mmc boot work enough to let me test nand?
May 26 10:47:55 <JaMa|Wrk> not yet.. use mine http://jama.dyndns-home.com/org.openembedded.shr.images/om-gta02/kernel-39-mmc-debug/
May 26 10:48:05 <JaMa|Wrk> no you have to boot from nand
May 26 10:48:51 <JaMa|Wrk> booting from nand works for me fine.. but here also 2.6.37 works fine in nand (jffs2 now)
May 26 10:50:13 <jeepingben> I could do jffs2 with 2.6.37, it would give some errors at startup, but work
May 26 10:51:13 <jeepingben> does 39 have ubifs support?
May 26 10:51:28 <JaMa|Wrk> yes
May 26 10:51:39 <JaMa|Wrk> but I haven't tried it with .39
May 26 10:52:30 <JaMa|Wrk> defconfig is pretty similar to 2.6.37 except this http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=608e60f0ef16122568f868f79e673e955c52c709
May 26 10:55:43 <jeepingben> I saw errors before the splash screen came up, looks like it is mounting read only (this is ubi)
May 26 11:02:32 <JaMa|Wrk> so it's not usable, right?
May 26 11:02:36 <jeepingben> right
May 26 11:02:43 <jeepingben> looks like it will need the same fix
May 26 11:05:28 <JaMa|Wrk> ok, at least you know that trying to fix it in .37 is worth it even if we switch to .39 soon
May 26 11:05:38 <jeepingben> yup
May 26 14:33:48 <ChristW_ZZZzzz> Afternoon all!
May 26 14:35:06 <ChristW> I've made changes to the shr-messages app, and was wondering if anyone could take a gander at my changes before I commit them. There seem to be some DEBUG messages that indicate an error, but I've about 0 experience tracking those down on the FR...
May 26 14:35:08 <JaMa|Wrk> hi
May 26 14:38:36 <ChristW> Diffs are here: http://pastebin.com/ufUXB02Z
May 26 14:42:02 <JaMa|Wrk> ChristW: is it really for shr-messages (looks so) why not phoneui-apps?
May 26 14:42:45 <JaMa|Wrk> ah it's libphone-ui-shr :)
May 26 14:43:04 <ChristW> Yes, it's libphone-ui-shr, the 'messages' part. Sorry if I was unclear.
May 26 14:44:21 <ChristW> What it does is add another button to the 'Compose' screen, named 'Insert'. That lists your contacts, and you can click a name to add the phone number to the currently composing SMS.
May 26 14:47:01 <JaMa|Wrk> so something like "Send bussiness card" on other phones?
May 26 14:47:27 <ChristW> Yes, but only the text is inserted. For now...
May 26 14:52:13 <antrik> jeepingben: sorry, I realized that bisect is probably not helpful anyways, as various modifications are necessary to make the kernel work on FR at all AIUI...
May 26 16:04:20 <GNUtoo> hi mrmoku 
May 26 17:21:44 <JaMa|Off> larsc: do you have somewhere glamo driver for 2.6.39 before adapting it to use Per Forlin's patches? I'm trying to test MMC without them, but ie host_cookie is used on few places and I'm not sure if I'll be able to revert using it without breaking something else (and making my test useless..)
May 26 17:45:50 <morphis> heyho
May 26 17:46:23 <JaMa> heyho
May 26 17:46:27 <CIA-81> SHR: 03Martin.Jansa 07shr-chroot * r20c4c910a286 10/ (265 files in 43 dirs): system upgrade
May 26 17:48:51 <CIA-81> freesmartphone.org: 03morphis 07msmcomm * r7d972e0c6049 10/ (4 files in 2 dirs): msmcommd: some minor fixes and adjustments I had outstanding on my local disk
May 26 17:50:32 <morphis> mickeyl: ping
May 26 17:50:54 <CIA-81> freesmartphone.org: 03morphis 07aurora * r21f87c57b00c 10/aurora/components/ (10 files in 4 dirs): 
May 26 17:50:54 <CIA-81> freesmartphone.org: aurora: move application specific logic out of global controller into a service component
May 26 17:50:54 <CIA-81> freesmartphone.org: Each application has to take care to handle specific system events. For example the phone
May 26 17:51:30 <CIA-81> freesmartphone.org: 03morphis 07aurora * r4dfaf0d5d1f1 10/aurora/ (6 files in 4 dirs): aurora: next round to get the call feature working; this time handle a incomming call
May 26 17:58:54 <mrmoku> hey GNUtoo 
May 26 18:12:59 <mickeyl> morphis: pong
May 26 18:14:11 <mickeyl> hmm, my pyside installation is broken
May 26 18:14:25 <mickeyl>     from aurora import kernel
May 26 18:14:25 <mickeyl> ImportError: /usr/local/lib/python2.7/dist-packages/aurora/kernel.so: undefined symbol: _ZN6PySide6Signal18updateSourceObjectEP7_object
May 26 18:14:25 <mickeyl> m
May 26 18:15:23 <morphis> mickeyl: my was too
May 26 18:15:28 <morphis> mickeyl: I am currently rebuilding
May 26 18:16:04 <mickeyl> k
May 26 18:16:08 <mickeyl> two things i wanted to tell you
May 26 18:16:27 <mickeyl> 1st, please don't use synchronous dbus calls
May 26 18:16:27 * morphis opens his eyes :)
May 26 18:16:49 <mickeyl> they will block the UI, even if they don't require an answer
May 26 18:17:01 <mickeyl> so always use reply and error handlers, even if you don't care about the result
May 26 18:17:07 <morphis> ok
May 26 18:17:36 <mickeyl> 2nd since i've seen you having introduced custom cpp code, consider that there's also another alternative, depending on when/who calls what
May 26 18:17:56 <mickeyl> we could also do the main binary in cpp and run the python code from there
May 26 18:18:13 <morphis> yes, I even thought about this
May 26 18:18:23 <mickeyl> if all we have to do is do things on startup/shutdown time, it'll save you the bindings work
May 26 18:18:30 <mickeyl> if we have to call it in between, then we need the bindings
May 26 18:18:51 <morphis> the main reason I introduced the kernel plugin is that I don't have the time anymore to mess with pyside
May 26 18:19:05 <morphis> getting qws support into it was not quite easy as I thought
May 26 18:19:45 <morphis> mickeyl: do you think we should do the change for the main binary from python to cpp now?
May 26 18:20:31 <mickeyl> well, now that you have the bindings, it's probably no longer necessary. we should reconsider it though, if we have more non-python stuff to call
May 26 18:20:54 <mickeyl> for the speed, it's irrelevant. both are same
May 26 18:21:02 <morphis> yes
May 26 18:21:30 <morphis> but in later versions of aurora we will switch to cpp as the main language (with vala additions) anyway
May 26 18:21:35 <mickeyl> correct
May 26 18:23:31 <morphis> I did more things to get the phone feature working the last days
May 26 18:23:57 <morphis> after we have done 0.1 we should even think more about where we place things
May 26 18:24:30 <morphis> currently the backlight handling is in QML but it's not the right place
May 26 18:24:59 <morphis> even the application handling like loading apps into the application slot and pushing pages into the stack
May 26 18:25:08 <morphis> maybe things are faster if we do them in Cpp
May 26 18:27:29 <morphis> I even want to get rid of this pyside stuff as far as possible
May 26 18:28:42 <mickeyl> yes, but lets get a first version out of the door where people can contribute. by then we know the QML <-> non-QML communication patterns good enough that we can work on getting rid of more python and doing things in vala & cpp
May 26 18:30:34 <morphis> thats the plan :)
May 26 18:31:04 <morphis> mickeyl: you build your own image or took it from the amethyst?
May 26 18:31:47 <mickeyl> i don't have anything on the devices atm.
May 26 18:31:53 <mickeyl> only doing it on the workstation
May 26 18:31:55 <morphis> ah ok
May 26 18:32:06 <mickeyl> with an attached gsm modem
May 26 18:34:34 <morphis> mickeyl: how much time do you have in the next weeks until 01.08?
May 26 18:36:28 <morphis> mickeyl: can you remove branches from git.openembedded.org?
May 26 18:36:48 <JaMa> larsc: nevermind, done and it boots from uSD now again fine :)
May 26 18:38:11 <JaMa> mrmoku, jeepingben: if you want .39 which boots from uSD, I have something for you :)
May 26 18:39:55 <mickeyl> morphis: right now it's a bit hectic for me due to all those preparations (marriage of my friend, baby), I hope that i can do some more things mid june, but that again depends on how stressful the baby is... if she only would come now... 
May 26 18:40:11 <mickeyl> morphis: let me check whether i still have access. which one would you want to remove?
May 26 18:40:31 <JaMa> mickeyl: and for you too if you want to try n_gsm on freerunner
May 26 18:41:24 <mickeyl> JaMa: yes, i'm interested. no idea whether my FR still works, but i want to try
May 26 18:43:07 <JaMa> do you need whole image or just 2.6.39 kernel is fine?
May 26 18:43:44 <mickeyl> i'm afraid i also need a matching image, i didn't do anything with the FR for months now
May 26 18:43:56 <mickeyl> no hurry though, i won't be able to check today
May 26 18:44:03 <mickeyl> weekend would be good
May 26 18:44:25 <mickeyl> morphis: need to leave now, i still can remove branches, just tell me which ones
May 26 18:45:23 <JaMa> kernel is here: http://build.shr-project.org/shr-kernels/om-gta02/kernel-39-without-pers-patchset/
May 26 18:45:35 <JaMa> mickeyl: ok I'll upload lite image, tar.gz for uSD?
May 26 18:49:18 <morphis> mickeyl: the aurora/devlopment I pushed in an accident
May 26 18:50:03 <morphis> mickeyl: yes, thats why I asking. It very ok, you do your personal things first!
May 26 18:50:11 <morphis> thats what I would do as well
May 26 18:50:36 <morphis> mickeyl: mid june/early july is even early enough for getting the last things done
May 26 18:53:24 <morphis> mickeyl: I will reorganize our roadmap this weekend so we have more specific tasks people or you can pick up
May 26 18:54:23 <playya_> builder.py tells me that the shr uImage is too big, too:
May 26 18:54:25 <playya_> -rw-r--r-- 1 playya playya 2111348 2011-05-17 00:21 uImage-2.6.37+gitr0+570058abb97844fd30c396772b1a078bf572dd0c-r62-nokia900.bin
May 26 18:54:25 <playya_> -rw-r--r-- 1 playya playya 2111428 2011-05-17 22:50 uImage.shr
May 26 18:55:08 <morphis> playya_: I see you start working with the N900 :)
May 26 18:55:13 <playya_> yes
May 26 18:55:26 <JaMa> playya_: mrmoku told you to use maemo kernel
May 26 18:55:42 <playya_> let's start working on a gps with known protocol and then with an unknown
May 26 18:56:06 <JaMa> playya_: read U-Boot section http://trac.shr-project.org/trac/wiki/Devices/NokiaN900/InstallGuide
May 26 18:56:09 <playya_> then the link in the wiki is wrong :(
May 26 18:56:14 <playya_> yes
May 26 18:56:23 <JaMa> playya_: ah sorry
May 26 18:56:46 <JaMa> playya_: my fault.. You can use different uImage ie from default maemo kernel package or kernel-power
May 26 18:57:13 <JaMa> I'll upload maemo and power kernel binaries somewhere and update it
May 26 18:59:32 <mrmoku> JaMa: ohhh
May 26 18:59:46 <mrmoku> still without bq27x00 I guess?
May 26 19:00:33 <JaMa> yes
May 26 19:03:37 <JaMa> playya_: uImage from power-kernel uploaded and wiki updated
May 26 19:10:10 <DocScrutinizer> who wants bq27x00?
May 26 19:10:23 <DocScrutinizer> it seems kinda borked anyway
May 26 19:12:01 * DocScrutinizer seems to recall you need a "while sleep 10; do echo BUH >/dev/watchdog; done" really early in boot of a maemo kernel
May 26 19:12:24 <DocScrutinizer> anyway...
May 26 19:12:32 <DocScrutinizer> time for dinner, sort of
May 26 19:13:07 <DocScrutinizer> anybody knows what a nonsense ls -l --author is meant to do?
May 26 19:13:27 <playya_> JaMa, thx
May 26 19:15:20 <JaMa> playya_: uploading uImage from default maemo kernel
May 26 19:15:33 <JaMa> playya_: would be great if you can test it
May 26 19:15:40 <JaMa> because I never used it with u-boot
May 26 19:16:15 <JaMa> always some power-kernel version
May 26 19:16:30 <playya_> you're using the eMMC for SHR?
May 26 19:17:05 <JaMa> no
May 26 19:17:17 <JaMa> GNUtoo is iirc
May 26 19:18:23 <JaMa> but I have power-kernel modules installed in maemo@eMMC, so I need power-kernel+u-boot to boot
May 26 19:19:09 <playya_> i'm using the normal kernel atm
May 26 19:19:18 <playya_> so I need the normal kerneL?
May 26 19:19:45 <playya_> btw. is there any nice way to turn on usb networking?
May 26 19:20:07 <mrmoku> DocScrutinizer: talking about gta02 (bq27x00)
May 26 19:20:28 <playya_> and is it possible to mount the eMMC from SHR?
May 26 19:21:06 <JaMa> yes for kernel (you need corresponding modules on rootfs)
May 26 19:21:38 <JaMa> and yes for eMMC mount (at least it worked for me from 2.6.35, it's ubi iirc)
May 26 19:21:58 <JaMa> haven't tried to mount it from current 2.6.37
May 26 19:24:58 <JaMa> mickeyl: http://build.shr-project.org/tests/jama/image-with-2.6.39/ update feed uri after install to shr feed if you need something not available in my..
May 26 19:41:34 <DocScrutinizer> mrmoku: ah
May 26 20:03:31 <playya_> JaMa, if I run "run maemo" uboot uncompresses the kernel and reboots after a while
May 26 20:04:05 <JaMa> playya_: try to enable r&d mode
May 26 20:04:34 <JaMa> or only disable watchdog
May 26 20:04:56 <playya_> r&d mode is enable
May 26 20:05:08 <playya_> i ran the 3 commands from fso wiki
May 26 20:05:35 <JaMa> did you use u-boot binary linked from wiki page?
May 26 20:06:29 <JaMa> some different toolchain/*FLAGS combination causes hangs or reboots after uncompresses I can confirm only those binaries listed there
May 26 20:06:30 <playya_> iirc yes
May 26 20:07:10 <playya_> which one?
May 26 20:07:21 <playya_> iir I used the second link
May 26 20:07:53 <JaMa> http://build.shr-project.org/shr-unstable/images/nokia900/u-boot-nokia900-2010.06+gitr0+bd2313078114c4b44c4a5ce149af43bcb7fc8854-r68.bin.mmcblk0.dos-like
May 26 20:10:48 <jeepingben> JaMa: I got far enough with 2.6.39 in NAND to see that it has the badblocks issue, I'll do more with 2.6.37 tonight, and hopefully have a patch
May 26 20:12:12 <mrmoku> DocScrutinizer: with 2.6.37 bq27x00 does not deliver any more uevents
May 26 20:12:25 <mrmoku> and thus fso does not know when it's charging
May 26 20:12:41 <DocScrutinizer> ouch
May 26 20:13:56 <DocScrutinizer> anyway, for bq27x00 the uevent concept seems kinda useless, as the chip shouldn't get read out constantly and there's no way to trigger events via IRQ
May 26 20:14:45 <DocScrutinizer> the charging signal IRQ should be from PCF50633
May 26 20:14:50 <playya_> continues rebooting on all suggested options
May 26 20:22:15 <playya_> ok. if i use elektranox's maemo kernel it works again
May 26 20:23:16 <JaMa> what is elektranox's maemo kernel ?
May 26 20:24:47 <JaMa> playya_: this should be the same as uImage created with their how-to http://build.shr-project.org/shr-kernels/nokia900/uImage-maemo-2.6.28-20103103+0m5
May 26 20:25:36 <playya_> at least it has the same version
May 26 20:27:04 <JaMa> so what did you use from that site? zImage/uImage/u-boot binary?
May 26 20:27:30 <playya_> http://build.shr-project.org/shr-kernels/nokia900/uImage-maemo-2.6.28-20103103+0m5 + u-boot-nokia900-2010.06+gitr0+bd2313078114c4b44c4a5ce149af43bcb7fc8854-r68.bin.dos-like
May 26 20:27:30 <JaMa> I see only u-boot binary there,, so no idea what you mean by "elektranox's maemo kernel"
May 26 20:27:47 <playya_> oh. sorry :/
May 26 20:28:02 <playya_> i thought it was on elek's server
May 26 20:28:29 <JaMa> so this combination works for you?
May 26 20:30:25 <playya_> at least to boot maemo
May 26 20:33:18 <JaMa> good
May 26 22:10:43 <playya_> still kernel panic because the kernel cannot open mmcblk0p1
May 26 22:11:59 <JaMa> which image?
May 26 22:12:30 <playya_> I'm using my own image compiled with bb
May 26 22:12:39 <playya_> and own u-boot
May 26 22:12:51 <JaMa> with 2.6.37 kernel right?
May 26 22:12:53 <playya_> d2313078114c4b44c4a5ce149af43bcb7fc8854-r76
May 26 22:13:09 <playya_> ^u-boot version
May 26 22:13:15 <playya_> uImage: 2.6.37+gitr0+570058abb97844fd30c396772b1a078bf572dd0c-r62
May 26 22:13:19 <lindi-_> playya_: does the kernel detect the SD?
May 26 22:13:39 <playya_> one second
May 26 22:14:10 <playya_> no
May 26 22:14:24 <playya_> mmcblk0 is internal eMMC
May 26 22:14:44 <lindi-_> ah this was not FR?
May 26 22:14:46 <lindi-_> sorry then
May 26 22:15:03 <lindi-_> then I kind of lack the experience probably
May 26 22:15:28 <playya_> yes. but thanks anyways
May 26 22:15:50 * JaMa rebooting n900
May 26 22:17:40 <lindi-_> playya_: the dmesg should still show is SD was detected or not
May 26 22:17:57 <playya_> i cannot mount root
May 26 22:18:11 <playya_> but it shows a filesystem table
May 26 22:18:15 <JaMa> playya_: still boots fine and I see uSD as mmcblk0
May 26 22:54:50 <jeepingben> can I get " bitbake -c devshell linux" to run do_config before do_devshell? 
May 26 22:57:15 <angelox>  jeepingben: bitbake -c configure linux should only do to that step,without another thing
May 26 22:58:43 <jeepingben> angelox: thanks, I guess I can open a 3rd screen (1 for devshell, 1 for bitbake -c devshell and 1 more), but that doesnt seem like the right way to do it
May 26 23:02:17 <jeepingben> angelox: that seems to work, it looks like I still have a few more steps to do before building a kernel in devshell
May 26 23:11:28 <angelox> jeepingben: np
May 27 00:17:05 <antrik> DocScrutinizer51: I know what --author is, but I'm not sure whether I want to tell that ;-)
May 27 00:17:52 <antrik> DocScrutinizer51: it's a Hurd-specific file attribute, for tracking the original creator of a file or something like that... never tried using it for anything
May 27 00:18:18 <DocScrutinizer> heh
May 27 00:18:38 <DocScrutinizer> got no Hurd here ;-P
May 27 00:18:58 <DocScrutinizer> so it seems it's same as owner for all that matters, on linux
May 27 00:19:52 <DocScrutinizer> thought it might do some weird file scanning to get file properties from document formats...
May 27 00:20:17 <antrik> well, the field simply doesn't exist on Linux... but possibly ls falls back to the owner in this case
May 27 00:20:23 <antrik> nah
May 27 00:20:35 <DocScrutinizer> as I never heard of any filesystem for unix that supports those atributes like author
May 27 00:21:14 <antrik> ext2 supports it, if you format with -o hurd... but the Linux implementation will still not be able to read it :-)
May 27 00:21:17 <DocScrutinizer> ntfs might, in those shadow thingies:4
May 27 00:21:34 <DocScrutinizer> haha
May 27 00:21:53 <DocScrutinizer> -o hurd, WTF?! :-D
May 27 00:22:10 <DocScrutinizer> nice to learn sth new every day
May 27 00:22:29 <DocScrutinizer> even if it's something bizarre like this author thing
May 27 00:22:38 <DocScrutinizer> or -o hurd
May 27 00:22:55 <DocScrutinizer> which is as new to me as --author
May 27 00:23:34 <DocScrutinizer> antrik: thanks for enlightening me
May 27 00:24:17 <antrik> well, we'd like to switch to standard xattrs for the Hurd-specific fields now they exist... but you know, small volunteer project, little manpower, other priorities...
May 27 00:25:16 <DocScrutinizer> heh, I'm just starting to make use of xattr every now and then
May 27 00:26:23 <DocScrutinizer> sometimes I feel like I understand ACLs better than posix perms
May 27 00:26:41 <antrik> well, I'm sceptical of using xattrs extensively in general, as they make information more obscure than storing it separately... but for this kind of things, they really make sense
May 27 00:28:00 <DocScrutinizer> I have to think hard each time I need to decide if a chown will work or not
May 27 00:29:40 <DocScrutinizer> usually I just get root to do chown ;oD
May 27 00:31:20 <DocScrutinizer> system security is a funny domain. E.G all the implications of 'mount'
May 27 00:32:28 <DocScrutinizer> mount -o bind to a chroot ;-)
May 27 00:33:26 <DocScrutinizer> there's a reason why changeable media usually is noexec
May 27 00:35:11 <DocScrutinizer> ohwell, I think we need a completely different type of fs, on the long run. sth db based
May 27 00:35:26 <DocScrutinizer> object oriented
May 27 00:35:43 <antrik> you mean, like WinFS?... :-P
May 27 00:35:57 <DocScrutinizer> err whatever that is
May 27 00:36:30 <antrik> that was supposed to be the great new feature of Windows Vista... ultimately it turned out unworkable and they sacked it
May 27 00:36:42 <DocScrutinizer> hehe
May 27 00:37:27 <antrik> relational databases are out of fashion anyways ;-)
May 27 00:38:21 <DocScrutinizer> hmm, yeah, for a filesystem you probably don't need nor want relational db, more sth like associative
May 27 00:38:30 <angelox> sorry,i was off and that called me,WinFS is a filesystem for Vista,or just another name to NTFS ? :)
May 27 00:39:38 <DocScrutinizer> actually OO as mentioned above. 
May 27 00:41:00 <DocScrutinizer> any object in your storage could inherit, and define own new properties and methods
May 27 00:41:33 <DocScrutinizer> and the "fs" behind that probably should have sth like a kind of persistence
May 27 00:42:10 <DocScrutinizer> means you can do snapshots any time, and deleted objects could get reconstructed
May 27 00:42:46 <angelox> interesting
May 27 00:42:47 <DocScrutinizer> well that's nothing new basically. There are fs with nice snapshot functions
May 27 00:43:25 <DocScrutinizer> angelox: I'm wildly brainstorming, not related to WinFS
May 27 00:44:52 <angelox> DocScrutinizer: yes,but now with that messages i could understand what you was talking about(my chat was cleaned page and i hadn't saw the msgs :-)
May 27 00:51:12 <DocScrutinizer> storage objects like sourcecode, plain text etc can store itself as a diff to any parent object (the last version of same file). Executable code would know how it wants to get started... tempfiles know they have to vanish after a while or on certain other criteria
May 27 00:54:11 <DocScrutinizer> and you'd get completely rid of any directory concept and fs-tree. Objjects know when they are looked for, by comparing the query to their own set of properties
May 27 00:59:25 <DocScrutinizer> darn. grep, find, cp, rm etc would look really different :-D
May 27 01:58:03 <Lopi> anyone around familiar with mapping a button to the SHR lock screen?
**** ENDING LOGGING AT Fri May 27 02:59:58 2011