| === johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #upstart | ||
| === Ingmar^ [n=ingmar@d51A482FD.access.telenet.be] has joined #upstart | ||
| === wasabi [n=wasabi@ubuntu/member/wasabi] has joined #upstart | ||
| === j_ack [n=rudi@p508D92B9.dip0.t-ipconnect.de] has joined #upstart | ||
| === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| === johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #upstart | ||
| === wasabi [n=wasabi@ubuntu/member/wasabi] has joined #upstart | ||
| === Admiral_Chicago [n=freddy@st0660990722.monm.edu] has joined #upstart | ||
| === j_ack [n=rudi@p508D92B9.dip0.t-ipconnect.de] has joined #upstart | ||
| === j_ack [n=rudi@p508D86D0.dip0.t-ipconnect.de] has joined #upstart | ||
| === johnnybuoy0 [n=jano@nilus-268.adsl.datanet.hu] has joined #upstart | ||
| === theCore [n=alex@modemcable106.200-70-69.mc.videotron.ca] has joined #upstart | ||
| === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| === Ingmar^ [n=ingmar@d51A482FD.access.telenet.be] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === Ingmar^ [n=ingmar@d51A482FD.access.telenet.be] has joined #upstart | ||
| === Ingmar^ [n=ingmar@d51A482FD.access.telenet.be] has joined #upstart | ||
| === Ingmar^ [n=ingmar@d51A482FD.access.telenet.be] has joined #upstart | ||
| === Ingmar^ [n=ingmar@d51A482FD.access.telenet.be] has joined #upstart | ||
| === Ingmar^ [n=ingmar@d51A482FD.access.telenet.be] has joined #upstart | ||
| === neuralis [n=krstic@solarsail.hcs.harvard.edu] has joined #upstart | ||
| === xhochy [n=uwe@p54A6BBE1.dip0.t-ipconnect.de] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === j_ack [n=rudi@p508D86D0.dip0.t-ipconnect.de] has joined #upstart | ||
| === johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #upstart | ||
| === j_ack [n=rudi@p508D86D0.dip0.t-ipconnect.de] has joined #upstart | ||
| === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| === maro_ [n=mark@0x55511dab.adsl.cybercity.dk] has joined #upstart | ||
| === theCore [n=alex@modemcable106.200-70-69.mc.videotron.ca] has joined #upstart | ||
| === theCore [n=alex@modemcable106.200-70-69.mc.videotron.ca] has joined #upstart | ||
| === j_ack [n=rudi@p508D86D0.dip0.t-ipconnect.de] has joined #upstart | ||
| === Keybuk [n=scott@syndicate.netsplit.com] has joined #upstart | ||
| === ajgenius [n=andrew@c-68-48-76-28.hsd1.md.comcast.net] has joined #upstart | ||
| === j_ack [n=rudi@p508D86D0.dip0.t-ipconnect.de] has joined #upstart | ||
| === Ingmar^ [n=ingmar@244.75-64-87.adsl-dyn.isp.belgacom.be] has joined #upstart | ||
| _ion | keybuk: An idea: an optional, purely informative "triggers" stanza that lists the events the job (either script or the daemon) may trigger, e.g. a hald job might contain "triggers block-device-added" and a mount job might contain "triggers path-mounted fhs-filesystem". That would make it easy to 1) grep event.d/* for "starts on jobname" and 2) visualize the relations between jobs programmatically. | 10:11 |
|---|---|---|
| Keybuk | could be just a normative comment? | 10:12 |
| _ion | Yes. | 10:12 |
| _ion | Just like "author" and "description". :-) | 10:13 |
| Keybuk | true, true | 10:13 |
| Keybuk | description is actually useful, as you have to describe the job in listings | 10:13 |
| _ion | For example, a GUI for managing jobs might display a list of jobs that act on events the currently selected job may trigger. | 10:15 |
| _ion | When you click "hal", it lists "check-filesystem" and when you click it, it lists "mount". | 10:16 |
| _ion | Also cool graphviz graphs would be possible. ;-) | 10:17 |
| Keybuk | true | 10:18 |
| Keybuk | a bit like Java's "throws" ? | 10:18 |
| Keybuk | :p | 10:18 |
| ajgenius | hmm ok. question the first. From todo - "Per-user services" "for "root-user services" but not for jobs/tasks", I am trying to figure out what that means, and what the intent is for User level services down the road | 10:19 |
| _ion | keybuk: Well, a bit like it. :-) | 10:20 |
| Keybuk | well, the obvious thing is for users to be able to register services to be run on their behalf | 10:21 |
| Keybuk | so I can have an hourly script run | 10:22 |
| Keybuk | or even daemons run for me | 10:22 |
| Keybuk | PAM needs to be used to set up the session properly | 10:22 |
| Keybuk | the root bit is that the root _user_ should be able to register services/tasks | 10:22 |
| Keybuk | and thus be run with PAM to set up the session | 10:23 |
| Keybuk | which is different from those in /etc/event.d which should not be run in a PAM session, maybe | 10:23 |
| _ion | I'd assume the root user's jobs to be different from the /etc/event.d jobs similarly as the root user's crontab is different from the system crontab. | 10:24 |
| _ion | I mean the semantical difference, not the technical difference. | 10:24 |
| Keybuk | indeed | 10:25 |
| Keybuk | the technical difference is the same, actually | 10:25 |
| ajgenius | ok. hm. | 10:27 |
| ajgenius | the thing I am trying to understand is the long term goal for user level integration, in regards to allowing users to have purely user session jobs and scripts. | 10:28 |
| ajgenius | and I am not finding any real information on goals regarding that in the docs or todo's :) | 10:28 |
| Keybuk | well, it depends what you mean by "user session" at this point? | 10:28 |
| ajgenius | I mean.. desktop situation. the user wants to register a task to do some operation on their files, by them, (they wouldn't think of it in the terms of sessions), on given events | 10:30 |
| Keybuk | the lack of information doesn't mean anything other than I haven't written it down in stone yet, and am still thinking about it and taking suggesions | 10:30 |
| Keybuk | right, but would these tasks need access to running X desktops? | 10:30 |
| _ion | mkdir -p ~/.event.d; vim ~/.event.d/job ... :wq and it just works. :-) | 10:31 |
| ajgenius | sometimes yes sometimes no. that would be a task level dependency | 10:31 |
| Keybuk | there's several levels of thing: | 10:31 |
| _ion | (As long as the bofh hasn't disabled it) | 10:31 |
| Keybuk | - new system session (process group and session) | 10:31 |
| Keybuk | - new user session | 10:31 |
| Keybuk | - existing user's session | 10:31 |
| Keybuk | the second is "switch to the user, create a new session, login that session, run the task" | 10:32 |
| Keybuk | the third is run the task for a user that is logged in | 10:32 |
| Keybuk | which is an interesting case all to itself | 10:32 |
| Keybuk | but potentially conflicting with a desktop session manager | 10:32 |
| ajgenius | right. I am interesting in both the latter cases | 10:32 |
| ajgenius | mostly the last however | 10:32 |
| Keybuk | it's definitely something that's worth serious thought | 10:33 |
| ajgenius | one of the problems is for example - right now we have "hald" for gnome integration, which handles hardware events etc. thats nice and interesting, but it doesn't allow much real integration on a user level | 10:33 |
| Keybuk | there's been some interesting discussion about that on the dbus mailing list last week | 10:34 |
| ajgenius | I think most of that belongs in an upstart space. | 10:35 |
| ajgenius | otherwise we have multiple event based systems for different kinds of things | 10:36 |
| Keybuk | which part though? | 10:40 |
| ajgenius | which part of what? | 10:40 |
| Keybuk | <ajgenius> I think most of that belongs in an upstart space. | 10:40 |
| Keybuk | you wouldn't have upstart monitoring battery levels, for example? | 10:40 |
| ajgenius | yes. anything to do with handling events and starting jobs | 10:40 |
| ajgenius | Keybuk: that wouldn't be IN upstart. but there is no reason not to have a way of registering new events of that nature into upstart space | 10:41 |
| ajgenius | the event daemon is something which recieves events, and starts jobs. it doesn't generate the events. something else does | 10:42 |
| Keybuk | +----------------------+ | 10:42 |
| Keybuk | | gnome-power-manager | | 10:42 |
| Keybuk | +-------+--------------+ | 10:42 |
| Keybuk | | HAL | | | 10:42 |
| Keybuk | +-------+ +-----------------+ | 10:42 |
| Keybuk | | D-Bus | Suspend Scripts | | 10:42 |
| Keybuk | +----------------------+-----------------+ | 10:42 |
| Keybuk | | Upstart | | 10:42 |
| Keybuk | +----------------------------------------+ | 10:42 |
| Keybuk | that kind of thing? | 10:42 |
| _ion | 10:43 | |
| ajgenius | ehm | 10:43 |
| Keybuk | _ion: ? | 10:43 |
| _ion | Just some line drawing characters for cooler boxes. ;-) | 10:43 |
| Keybuk | _ion: harder to type than just '-' :p | 10:44 |
| _ion | Hehe. | 10:44 |
| Keybuk | gnome-power-manager receives information from HAL that indicates the battery is critical | 10:44 |
| Keybuk | so it issues a battery critical event | 10:44 |
| ajgenius | Keybuk: yes and no. gnome-power-manager is on top of HAL, but what should trigger it to start in the first place? | 10:44 |
| Keybuk | which upstart receives and runs the suspend scripts for | 10:44 |
| Keybuk | that's another point | 10:44 |
| Keybuk | we know that HAL and the D-Bus system daemon are run by upstart | 10:45 |
| Keybuk | but what runs the D-Bus session daemon, and gnome-power-manager? | 10:45 |
| _ion | It would be quite cool if upstart were abstracted as much to allow _it_ to be the desktop session manager. | 10:46 |
| ajgenius | thats the point I care about - there are a lot of really cool things that can be done from a user POV. but forcing multiple levels of start abstraction actually detracts what can be done. if they can all be started by the same thing - now in this case I think that perhaps an upstart user level daemon. | 10:46 |
| ajgenius | each user starts its own instance of a user only upstart - which gets events from the main system, but can only start them in that users context | 10:47 |
| ajgenius | that allows a single point of origin for anything in that users space | 10:48 |
| ajgenius | _ion: yeah exactly. thats a large part of it | 10:48 |
| Keybuk | kinda, you end up with two ... started by the X session manager or started by upstart | 10:48 |
| ajgenius | but it wouldn't JUST be a "desktop" dession manager it would be a user space manager. desktop | 10:48 |
| ajgenius | is really seperate at that point. | 10:49 |
| ajgenius | Keybuk: why would the X session manager have anything to do with it :) | 10:49 |
| ajgenius | it just starts a user session. why not make what it starts, a user level upstart. | 10:50 |
| theCore | why would you want upstart as your desktop-manager? | 10:50 |
| Keybuk | ajgenius: it doesn't just do that though | 10:50 |
| Keybuk | an X session manager actually does a whole bunch of stuff | 10:50 |
| Keybuk | http://live.gnome.org/SessionManagement | 10:50 |
| Keybuk | also there's | 10:51 |
| Keybuk | http://freedesktop.org/wiki/Standards_2fautostart_2dspec | 10:51 |
| ajgenius | yes I know about them | 10:51 |
| maro_ | why not just hook users up to the system upstart? (as it looks to be the current plan) | 10:52 |
| Keybuk | would upstart need to implement those? | 10:52 |
| ajgenius | Keybuk: no | 10:52 |
| ajgenius | well and yes ;) | 10:52 |
| Keybuk | maro: there isn't any current plan in this regard | 10:52 |
| ajgenius | hmm | 10:52 |
| Keybuk | ajgenius: see, this is where the lines to me get fuzzy | 10:52 |
| ajgenius | Autostart Specificatio | 10:52 |
| maro_ | Keybuk: I was thinking of the "on ~scott/..." examples I found somewhere | 10:53 |
| ajgenius | Keybuk: its clear to me. upstart doesn't DO any of those things. it just recieves events, and starts jobs | 10:53 |
| Keybuk | maro_: those are just for "new temporary session" jobs (e.g. cron/atd) | 10:53 |
| ajgenius | thats it. in the rough ;) | 10:53 |
| Keybuk | X sessions are odd anyway | 10:54 |
| Keybuk | as they're not true sessions, they're just a bunch of background processes without controlling terminal that happen to share some environment variables | 10:54 |
| ajgenius | personally I see no REASON to have the autostart specification persay. in the sense that, in terms of events, everything in a desktop environment depends on core parts of the desktop to start first, its desktop dependent. aka jobs | 10:55 |
| ajgenius | and events | 10:55 |
| Keybuk | it certainly makes an amount of elegant sense to have upstart start things like the panel | 10:56 |
| ajgenius | thats kind of it. you might have a "session management" daemon that upstart begins first | 10:56 |
| Keybuk | but then you wonder whether upstart should receive a "user clicked a launcher" event, which causes upstart to start openoffice | 10:56 |
| ajgenius | to handle autosave stuff | 10:56 |
| Keybuk | and I'm not sure at which point the line between genius and insanity gets crossed yet | 10:56 |
| ajgenius | Keybuk: no | 10:56 |
| ajgenius | hum. if someone chooses to use it in that fashion. that is up to them. but it has nothing to do with upstart itself | 10:57 |
| Keybuk | openoffice ends up being a child of upstart :) | 10:57 |
| ajgenius | thats not a problem to me | 10:57 |
| ajgenius | I see no reason it shouldn't be | 10:58 |
| Keybuk | it is by default | 10:58 |
| Keybuk | parent process is #1 for most X apps | 10:58 |
| ajgenius | right | 10:58 |
| ajgenius | the idea is in effect to make the user space all started as a child of a single point of origin, a user space upstart. thats it | 10:59 |
| ajgenius | it doesn't have anything to do with the actual processes or gui or whatnot | 10:59 |
| ajgenius | people could make jobs | 10:59 |
| ajgenius | that do those sorts of things. | 11:00 |
| ajgenius | but thats not upstarts concern | 11:00 |
| ajgenius | so you still will probably need a "session manager", but for example - it handles the other aspects, like close/shutdown things. | 11:01 |
| ajgenius | but it doesn't need to start them | 11:01 |
| Keybuk | it doesn't seem unreasonable | 11:03 |
| ajgenius | that allows everything upstart can do for a system. to be done for just a user. in that users scope. and does it in a GUI and Desktop agnostic fashion | 11:04 |
| ajgenius | and it would just have system events forwarded to it from the system instance. | 11:05 |
| Keybuk | I was just thinking about how that would work | 11:05 |
| Keybuk | sounds a bit dbus-like to me | 11:05 |
| ajgenius | you could do it on dbus at that level, because the system upstart would already be started. but I don't know if it needs to be | 11:06 |
| _ion | A user session upstart daemon would give a lot of flexibility for things, e.g. it would be possible to set niceness and environment variables for specific user session jobs. | 11:08 |
| Keybuk | I'm not immediately sure you need a user session daemon at all | 11:09 |
| === johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #upstart | ||
| Keybuk | due to the way X has historically worked, all you need is something to register a session with the master daemon | 11:09 |
| Keybuk | give the DISPLAY, DBUS_*, etc. environment variables | 11:09 |
| Keybuk | so then init can just include those in anything marked for that "session" | 11:09 |
| ajgenius | but thats based on X | 11:09 |
| Keybuk | they don't need to be children of any particular process | 11:09 |
| ajgenius | hm | 11:10 |
| theCore | that is what I'm thinking, an user upstart could be just a small program that would send message to upstart | 11:10 |
| Keybuk | then you would add a new first-class object to upstart ... "session" | 11:10 |
| Keybuk | jobs might exist in a session or not | 11:10 |
| ajgenius | but what about starting jobs in user space? who would be the root level? upstart | 11:10 |
| Keybuk | yes | 11:11 |
| Keybuk | that's easy | 11:11 |
| Keybuk | fork () | 11:11 |
| Keybuk | setsid () | 11:11 |
| Keybuk | setuid () | 11:11 |
| Keybuk | exec () | 11:11 |
| Keybuk | :p | 11:11 |
| ajgenius | hm. maybe | 11:11 |
| Keybuk | nothing X related has a controlling terminal | 11:11 |
| Keybuk | only the X server itself | 11:11 |
| ajgenius | but if nothing else it would make the process tree horrible to make sense of in a multiuser environment ;) | 11:11 |
| Keybuk | so there's no UNIXish signal interaction to worry about here | 11:11 |
| Keybuk | ps fjax | 11:11 |
| Keybuk | this is what the process tree looks like *today* | 11:11 |
| ajgenius | not on my system ;) | 11:12 |
| Keybuk | note that everything in your X "session" has PID=1 | 11:12 |
| Keybuk | why not on your system? | 11:12 |
| Keybuk | show me | 11:12 |
| ajgenius | I can't at the moment because I am booted up under a normal system | 11:12 |
| === Keybuk doesn't follow | ||
| ajgenius | but under my normal environment I use a hacked system like what I am talking about | 11:12 |
| Keybuk | any particular reason? | 11:13 |
| ajgenius | proof of concept. I started something like upstart about 2 years ago but nobody cared ;) | 11:13 |
| Keybuk | ahh | 11:13 |
| Keybuk | so you'd see something like | 11:13 |
| Keybuk | init | 11:13 |
| Keybuk | `- X | 11:13 |
| Keybuk | `- x-session-manager | 11:13 |
| Keybuk | `- user-init | 11:14 |
| Keybuk | `- gnome-panel | 11:14 |
| Keybuk | ? | 11:14 |
| ajgenius | yes | 11:14 |
| Keybuk | probably with a "`- gdm" in the middle there somewhere | 11:14 |
| ajgenius | I called it ProcessManager | 11:14 |
| ajgenius | but yeah | 11:14 |
| ajgenius | amazing how what two years ago was a stupid idea is todays big new thing ;) | 11:14 |
| Keybuk | heh | 11:15 |
| Keybuk | I've not yet managed to convince anyone inside the Boston Conspiracy that this is a good thing yet | 11:15 |
| ajgenius | hehe | 11:16 |
| Keybuk | Havoc does seem interested though | 11:16 |
| ajgenius | I never managed to get as big a following as you though(or any at all), so thats something. at least you have momentum to make this idea actually work :) | 11:16 |
| Keybuk | don't suppose, btw, you could write a summary mail about the above and post it to the mailing list? | 11:16 |
| Keybuk | well, we have a distro ;) that's a big help | 11:17 |
| ajgenius | hm | 11:17 |
| Keybuk | if it works, Ubuntu will rock because of it, and everyone else will adopt it | 11:19 |
| Keybuk | if it doesn't work, then it doesn't | 11:19 |
| ajgenius | it will work :) | 11:20 |
| === johnnybuoy hopes too | ||
| Keybuk | I just mean upstart in general | 11:20 |
| ajgenius | the concept is sound, and as I say. I have been running on it for a long time now. | 11:20 |
| ajgenius | Keybuk: sure it will | 11:21 |
| ajgenius | :) | 11:21 |
| === johnnybuoy is running it, and is quite pleased! | ||
| ajgenius | I mean. just conceptually it really makes integration into the new udev design system a lot easier | 11:22 |
| Keybuk | yeah | 11:24 |
| Keybuk | next is a matter of integrating it with dbus and HAL properly | 11:24 |
| johnnybuoy | dbus?? | 11:24 |
| Keybuk | johnnybuoy: message passing bus | 11:24 |
| johnnybuoy | doesn't that slow down the machine horribly. | 11:24 |
| johnnybuoy | ?? | 11:24 |
| Keybuk | no? | 11:24 |
| johnnybuoy | yes? | 11:24 |
| ajgenius | why would it? | 11:25 |
| Keybuk | it's just an IPC bus | 11:25 |
| Keybuk | how one program tells another that something happened | 11:25 |
| johnnybuoy | i mean the cpu has to put itself into adm. mode everytime a message comes or goes | 11:25 |
| Keybuk | is logical for upstart to be able to start and stop things because of dbus broadcast messages | 11:25 |
| Keybuk | err? | 11:25 |
| johnnybuoy | hmm | 11:25 |
| Keybuk | what's "adm. mode" ? | 11:25 |
| LarstiQ | supervisor? | 11:26 |
| johnnybuoy | i don't remember the word :( | 11:26 |
| johnnybuoy | but the cpu has two modes? | 11:26 |
| Keybuk | you're thinking of a Mach-like kernel aren't you? | 11:26 |
| johnnybuoy | CONTEXT SWITCH i think | 11:26 |
| johnnybuoy | right | 11:26 |
| Keybuk | where the entire kernel is based on message-passing? | 11:26 |
| Keybuk | dbus is just a user-space process for passing messages between user processes | 11:26 |
| LarstiQ | L4 shows that can be quite fast. | 11:26 |
| johnnybuoy | ahh, so no context switch | 11:27 |
| Keybuk | it's how gnome power manager can tell the screensaver you're on battery, so don't waste power bouncing cows and just blank the screen | 11:27 |
| johnnybuoy | yet l4 doesn't even have userlan tools to do proof-of-concept | 11:27 |
| LarstiQ | proof-of-concept of what? | 11:28 |
| johnnybuoy | that the linux drivers an 'really' be run in userland as servers | 11:28 |
| johnnybuoy | s/an/can | 11:28 |
| johnnybuoy | i tested it, it got me to a pretty screen that was mooving fast, bu no user interaction at all | 11:29 |
| LarstiQ | L4 isn't really interested in that either. | 11:29 |
| LarstiQ | Perhaps you are thinking of linux-on-l4? | 11:29 |
| johnnybuoy | bu if dbus doesn't need those context switching.. | 11:29 |
| ajgenius | dbus isn't in kernel space. its in user space space. thats a whole different concept then a messaging bus in kernel | 11:33 |
| === johnnybuoy_ [n=void@nilus-1746.adsl.datanet.hu] has joined #upstart | ||
| _ion | ajgenius: Excuse my ignorance, but what is "the new udev design system"? | 11:36 |
| Keybuk | kernel sends events when stuff changes | 11:38 |
| _ion | Isn't that how udev has worked for a long time? | 11:38 |
| === johnnybuoy_ is now known as johnnybuoy | ||
| _ion | I.e. listening to uevent? | 11:39 |
| johnnybuoy | my ISP is ging me crap, sorry, but in the lat 5-10 minutes i wasn't here...didn't miss me ehh?;) | 11:39 |
| ajgenius | _ion: uevents etc is new | 11:50 |
| ajgenius | as in, for proper functionality it requires a 2.6.15(16?) kernel iirc | 11:52 |
| ajgenius | it completely replaces hotplug now | 11:52 |
| ajgenius | before it just integrated with it | 11:53 |
| ajgenius | there is some documentation if you want to read up on the history and the recent changes :) | 11:53 |
| ajgenius | its one of the important reasons for upstart NOW | 11:58 |
| ajgenius | before it was just a good idea. now its almost necesary | 12:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!