[00:16:02] --- SecureEndpoints has left: Disconnected [00:38:43] --- dev-zero@jabber.org has left [00:46:01] stevenjenkins: I'm in the process of ansi-fying the code base. I'm nearly there in my local tree. More K&R prototypes would make me sad ... [02:19:21] do you have some code guideline for openafs ? [02:19:35] --- dev-zero@jabber.org has become available [02:57:39] --- haba has become available [03:24:52] --- dev-zero@jabber.org has left [03:45:23] --- dev-zero@jabber.org has become available [04:31:28] --- manfred furuholmen has left [05:20:49] --- SecureEndpoints has become available [05:45:01] --- matt has become available [05:47:28] SecureEndpoints: ok (I think I follow that :) [05:59:21] code guideline: "it should work and do something cool" [06:02:53] 3d? [06:03:21] there just aren't enough theaters equipped for 3D [06:06:56] anyone see one of the the 3D television displays? [06:09:21] never heard of it [06:10:45] simon - I'll ansi-fy the stuff I'm reviewing before I submit it..never fear. [06:10:58] http://blogs.zdnet.com/Berlind/?p=635 [06:46:23] any MR-AFS-savvy people around? [06:46:39] * stevenjenkins peers in the general direction of haba [06:55:42] Steven: I don't know if "savvy" applies. [07:02:54] I'm just trying to grasp some of the usage/interfaces for dealing with MR-AFS. [07:03:32] Hartmut's 'OpenAFS+Object Storage' paper, though, in his SVN repo, gives Rx OSD equivalents, so I think I'm mostly ok with respect to inferring what the old MR-AFS commands did. [07:04:10] but he mentions he used to do things like 'fs mkdir', 'fs cd', 'fs write', etc, which I've never heard of. [07:30:27] --- matt has left [07:33:08] --- dev-zero@jabber.org has left [07:37:59] Steven: I can look what I find in that respect in code and in his papers. I have only recollection of "osd write" and "osd read". [07:38:22] Where has he "hidden" his SVN? [07:39:05] %^&*, have to offline a litte while, hopefully back soon. [07:39:19] --- haba has left [07:48:56] --- matt has become available [08:19:59] --- reuteras has left [08:26:07] is there some kind of wiki, mailing list, archive, repository, etc, for collection of ideas that will be in 2.0? [08:26:41] openafs 2? [08:26:45] yes. [08:26:54] maybe we should 1.6 and 1.8 first [08:27:24] Not necessarily. [08:27:29] for when things like volume name lengths, max #'s of clones, max file lengths, etc are more-or-less expected to get changed. [08:28:43] well, I'd like to see more than one of those things change sooner than 2.0 implies, so I'd use the "feature backlog" (roadmap) concept, rather than put a release number on some of those--we should better analyze and document their dependencies [08:31:17] I would agree that after some analysis, you could arrive at some consensus for some type of feature that could go in at 2.0--once you had similarly established a planned feature baseline for 1.8, and before that, finalized that of 1.6. right? [08:32:16] You are making the assumption that there must be a 1.6, and a 1.8, before there can be a 2.0, and that 2.0 implies a certain amount of time in the future, rather than a certain amount of change. [08:32:45] I was assuming that. It's not necessary, but what is gained from changing release numbers? Does anyone want to? [08:33:30] Release numbers do not express time; they express degree of change. [08:34:21] That said, I think Steven is mistaken if he associates the particular features mentioned with 2.0. For one thing, one of them happened quite a long time ago. [08:34:50] Release numbering seems to be a concept without a fully fixed definition, even within one project or company, over time. [08:35:42] Sometimes, people say, lets just call the new one 5! or 7. or, let's go back to 2.x, for what would have been 8. [08:36:42] I have thought what we were doing was counting release cycles, not measuring degrees of change. [08:37:39] sorry. for some reason, I put my responses into another IM channel. [08:38:09] (that terminates my remark on release number marketing) [08:38:31] I'm not so concerned about 'is this for 1.6, 1.8, 2.0, etc', but rather trying to make sure that information is not lost and is easily communicated. [08:39:01] That could be efficiently expressed as a feature backlog, with dependencies. [08:39:18] right. [08:39:26] Sort of what our roadmap is, with added structure. [08:40:13] the current roadmap is quite useful, but there is no place for people to add comments, volunteer to test/participate/receive information when that chunk gets changed/etc. [08:40:43] Yes, that is a feature for the backlog. [08:41:13] I'd like to see that in place, in other words. [08:42:48] a current example is that I've poked at Rx OSD quite a bit and only recently got connected with Felix Frank, who has already done quite a bit of work on pulling out small bits from Rx OSD. Since I knew Hartmut was the main contact, it was fairly efficient for me to communicate with him, and he connected me to Felix, but for other projects on the roadmap, I'd have to ask the gatekeepers or the mailing lists, which seems inefficient to me. [08:43:32] one is too narrow, so certain questions are really a distraction (i.e, the gatekeepers) and the other is too broad, so questions can get lost. [08:45:34] wikifying the roadmap (with a permissioning system) might be a reasonable way to go. The software wouldn't need to be a wiki, though. The Real Time Haskell authors used some software to let people comment on sections, yet they maintained control of what got put into the actual sections themselves. That model is probably closer to what would work for OpenAFS. [08:49:08] Did you mean, "Real World Haskell" perhaps? [08:49:13] yes, sorry. [08:49:24] Ok. [08:50:24] Well, I'd start with a mediawiki, personally. It's proved by construction you can implement a process you'd approve, I think. [08:50:33] (so to speak) [08:51:42] * stevenjenkins nods. mediawiki (among other wikis) would work. [08:51:57] but if people have major objections to wikis, there are other solutions out there. [08:52:44] I would hope not, but this is openafs *sigh* [08:55:02] haba - when you get back, the latest url for the rx osd svn repo is https://svnsrv.desy.de/public/openafs-osd [09:02:08] --- Dale Ghent has become available [09:03:55] mm k&r C [09:04:11] feel the h8 [09:08:36] I've been considering a small project... each week, convert one afs utility and any of its source code file dependencies to ansi [09:09:34] this will have to compete with the NAS project tho. a welcome break from coding in perl and javascript [09:16:35] --- manfred furuholmen has become available [09:26:03] dale: probably need simon's diffs [09:26:47] oh, someone's working on this already? [09:28:36] I've been out of the openafs loop for a while [09:29:34] ah, I see the prototype fixes from him in cvs [09:29:59] there's some recent discussion from yesterday/today (logs) [09:30:16] he has more in a tree he's working on [09:30:19] --- SecureEndpoints has left [09:31:35] doing a s/register//g in the code would be nice as well [09:32:23] most compilers ignore that now and make their own decisions based on the optimization level [09:33:33] I don't think you'll get an argument about that. [09:39:13] --- dev-zero@jabber.org has become available [09:56:57] --- manfred furuholmen has left [10:14:35] --- matt has left [10:16:17] --- matt has become available [10:36:13] > doing a s/register//g in the code would be nice as well yeah probably [10:48:49] i kinda hate mediawiki but would happily work with it. my hatred of mediawiki is entirely based on trying to install it. it worked, kinda. [10:50:44] wikifying the roadmap or coming up with better software for managing it would be good. if it's something shipping with debian, we could get it on the openafs hardware. [10:51:33] i'd suggest that information rightfully belongs in RT, if our RT weren't so slow. [10:54:13] If feels to me like there would logically be a mapping to RT tickets, perhaps. [10:56:46] yes, mapping an item to a ticket and then giving the ticket to the person coordinating the project (if any) would be clever [10:57:55] speaking of RT performance..any hope there for better performance? [10:58:18] if jhutz is around he can comment. i am basically out of the loo [10:58:21] p [10:58:47] was there going to be a migration to a new server? (did that happen already, still planned, plan cancelled, etc) [10:59:04] istr it migrated to a VM and that moved to a newer machine [10:59:09] but jhutz will have to comment [10:59:20] the remaining issue will be "RT needs to be upgraded" [10:59:52] it's pretty spectacularly slow for me. [11:00:09] It feels faster than previously, actually. [11:00:25] hm. might be my browser, then. [11:01:02] I've installed wikimedia, and played with it a bit. It's nice, but totally unsuited to an application where you want to do access control. [11:01:43] There was going to be a migration. Like so many other things I was going to do over break, it didn't happen. [11:01:45] hm. pretty peppy w/konqueror. my firefox must be messed up. [11:02:18] jhutz let me do a quick check wrt access control & mediawiki; istr one of my colleagues did something w/that recently. [11:03:32] I think there are solutions, please do: [11:03:36] . [11:06:14] actually, i find interfacing with it via https often wedges for long periods of time if you interrupt a page loading, but swtiching immediately to http, the page loads promptly, for the same query [11:08:36] Interesting [11:09:37] like, load "all open tickets" in https; while loading, click top of one of the columns to reorder. it will wedge (does for me anyway) [11:09:46] if you are VERY patient it recovers [11:09:48] shadow - tx for that suggestion. I'll try it sometime. [11:10:20] that scenario is pretty much what happens to me (ie, interrupt page loading) [11:10:47] ok. well, be patient or use http, i guess. [11:11:39] is it running on a NeXT slab in jhutz's basement? ;) [11:12:10] (hopefully a turbo slab at least) [11:14:46] No, it's running on a VM on a machine here at CMU, having been migrated from an old machine in my office (which I ought to get rid of or get cg2v to take back, since I think it's his). [11:15:11] --- dev-zero@jabber.org has left [11:16:04] My group's RT runs on another machine in my office, next to the first one. My plan is to upgrade that and move it to another machine (not in my office), and then reuse the work I do for that to move the openafs RT as well. I was going to do that over break but ended up not getting to it. I also failed to do other things then, like cleaning my basement. [11:17:10] jhutz - fwiw, my colleague's comment on mediawiki is that if we need decent access control, mediawiki is not as good as twiki. although others note that twiki has its own set of challenges. [11:17:29] and at least one colleague notes that twiki's access control isn't so hot either. [11:17:58] if it would be helpful, I could poke more in that direction, but if we're not really thinking of going in that direction, I'll skip it.. [11:18:11] there's always Confluence [11:18:24] Please don't use a twiki for any purpose. [11:18:25] it can get pretty granular wrt access control [11:18:57] Dale - confluence..um. non open-source.. [11:19:06] twiki has issues, yes. mediawiki has some extensions that do access control, but they're _very_ primitive. In putting together a wiki for marathon-related things which required public, private, and public-but-restricted-write sections, I ended up settling on MoinMoin. I expect to use the same for the registrar wiki, once I get a chance to spin that up. [11:19:15] oh, was being open source a requirement? [11:19:23] Yes [11:19:23] There -must- be some mediawiki angle. [11:19:38] we could probably work out a mediawiki angle. [11:19:59] What is the granularity we're discussing--ACLs on sections of a document? [11:20:00] there are access control add ons..one could review, adopt, adapt one or more. [11:20:08] For a traditional mostly-free-for-all wiki, I think mediawiki is a good choice. [11:20:11] Yeah, that's the ticket. [11:20:29] well then wrt mediawiki access control desires and the requirement for it to be open source, then I'll take a line from the freetard camp and say "then fix it yourself, use the source!" [11:20:32] The richness of extensions, scalability, and all else... [11:20:46] going back to derrick's note earlier (and expanding on it): we could always bounce over to RT for stronger access control where needed. [11:20:48] There are access control addons; they all fairly well suck, in large part because the architecture isn't really designed for security, and the problem is harder than you think. [11:21:04] --- manfred furuholmen has become available [11:21:09] I don't assume it's an easy problem. [11:21:21] I assume there are a lot of great minds engaged near by it. [11:22:32] I doubt it. Effective access control is not really part of their philosophy. Though you might be able to manage if all you want is to have a small set of pages which can only be modified by a few people. [11:22:57] Anyway, I don't really have any more time for this discussion. [11:23:15] We weren't trying to force you to have one :) [11:27:39] --- manfred furuholmen has left [11:31:49] If we take the view that the mediawiki architecture is not suited, my fallback position would be the one suggesed by the Group Based Access Control extension authors, and use a CMS with wikitext (eg, Drupal appears likely to suit). [11:33:08] or derrick's suggestion of rt. [11:33:27] if people can post to rt tickets, that can be useful as well. [11:33:55] Sure, and RT isn't going anywhere. But it's not a content editing package. [11:34:04] rt would need skinning to give more accounts out iirc [11:35:25] right. rt could be useful to have a place to discuss things and keep logs and do access control. it's not good for presentation of information, though. [11:35:56] I think we need solutions to both problems, and one has been solved for a long time. [11:36:11] RT isn't even really a place to discuss things. And it doesn't really have per-ticket access control. [11:36:43] I don't want to use RT for content um management. [11:38:05] If what you need is a CMS, then mediawiki is the wrong answer and a CMS is the right answer. If what you need is a wiki with access control, then mediawiki is still the wrong answer, but so is a CMS. The people who wrote the advice you quote were assuming that there is no use case for a wiki with access control, and that anyone who thinks they want that must really be looking for a CMS. Since we are not looking for a CMS, that part of their advice is not relevant. [11:39:22] Are we looking for a wiki with access control, or do we have a problem for which these tools are hypothetical solutions? [11:40:05] jhutz - I believe you're reading too much into the advice I quoted. I simply asked them about MW's access control mechanisms and described what we are trying to do. No one suggested that trying to do access control in a wiki is wrong or that there is no valid use case for that, just that MW doesn't -support- that use case very well. [11:40:52] I think jhutz was referring to my remark, I was summarizing remarks here (red box) [11:40:54] http://www.mediawiki.org/wiki/Extension:Group_Based_Access_Control [11:41:03] (meeting [11:41:05] ) [11:41:15] ah, sorry. I thought he was referring to mine. (those indefinite pronouns..) [12:22:54] --- dev-zero@jabber.org has become available [12:50:07] --- manfred furuholmen has become available [13:18:09] I'm not reading too much into what you quoted. I looked into this question fairly thoroughly wrt MW, and came to the conclusion that there was a philosophical disconnect that made it unlikely MW would _ever_ be the right answer for that. [13:18:30] No, I get that. [13:19:21] But I think the MW devs suggestion may be the next thing we wish to consider--ie, buildup of what we want from a Drupal, or similar. [13:20:21] A Drupal view on a collection of access-controlled nodes, for access in groups in ldap backed by cosign (or whatever you prefer), would fulfill fairly demanding requirements. [13:22:13] Ie, you could build up a document spine manipulable by one group, with objects off the spine elaborable by others. Etc. [13:22:43] matt, you are scaring me [13:23:21] I thought that's what your minimal requirement was. You could also just have logins, with group membership to edit whatever. [13:24:35] Not defining what is actually required is bound to lead to me misreading something you've said, I guess. [13:25:49] I felt that a collection of RT tickets wasn't it. [13:28:21] (Having said I'm scary, follow up on my last text would be helpful.) [13:30:43] I am not interested in solving theoretical problems of collaborative editing, but rather giving openafs some place to do collaborative edits people wish to perform. [13:31:00] Like the ones Steven suggested. [13:35:11] I'm not setting the requirements here. I heard a desire for something wiki-like that arbitrary people could contribute to, with some portions writable only by some people. To me that says wiki-with-access-control, not CMS. [13:35:43] Ok, my impression was there's overlap. Drupal has the access control, and wikitext. [13:36:53] And is free software, of course. [13:37:03] Hrm. I have a Linux machine running some 1.4.x, dead in osi_AllocSmallSpace ... afs_EvalFakeStat_int afs_access afs_linux_permission ... [13:37:23] This looks familiar, but I don't recall why [13:38:03] Oh, there probably is some overlap. I haven't seen enough drupal-as-wiki to know if it's good at that model [13:38:50] 2.6.23.1, 1.4.6 [13:39:08] It's not as sophisticated as MW for that, it might be a good a trade, I'm not sure. [13:52:43] Looking further, seems less likely. [13:58:29] are there any pioctl_to_string and rpc_to_string tables, macros, or functions anywhere? [13:58:53] You mean, that take a pioctl or RPC number and tell you its name? [13:59:14] I'm looking at some code that hard-codes those mappings, and I'm concerned that this chunk of code is too brittle [13:59:15] yes. [13:59:39] I've looked at a few of the debugging utilities (but not all); the ones I've looked at appear to hard-code values. [14:00:12] it seems to me that a library would be better -- e.g., something to go into src/util [14:00:35] but I'm hoping that something exists already that I just haven't found..so I can use that. [14:00:54] There is no general facility for that. afs_syscall numbers and afs_syscall_call opcodes are in config/afs_args.h pioctl's are in config/venus.h RPC numbers are generally in a header in the same directory as the xg file. [14:01:34] let me give some more context here; that might be helpful. [14:01:49] A table of pioctls is at http://grand.central.org/pages/numbers/pioctls.html but is probably somewhat out of date. [14:01:54] I'm looking at the 'fs threads' command from the Rx OSD 'goodies' package. It shows the active RPCs on a given fileserver. [14:02:11] Oh. [14:02:17] so it attempts to map from the RPC opcode back to the RPC name. [14:02:59] I don't actually need a pioctl mapper or syscall id <-> name mapper, but if a general facility exists already, I might be able to leverage that. Since it doesn't seem to exist..hm. [14:03:04] --- mcohan has left [14:03:59] --- mcohan has become available [14:04:00] If there's going to be a feature like that, it does seem like there should be some supporting mechanism. [14:04:00] the current implementation hard codes the mapping. That could use improvement, so what I'm thinking is taking rxgen output and using that to autogenerate another table. [14:04:38] --- abo has left [14:04:45] It seems like it would be pretty easy to extend rxgen to have another mode where it produces such a table. [14:04:54] * stevenjenkins nods. that's exactly what I'm thinking. [14:05:04] Sounds like a reasonable idea. [14:05:14] Or rather, not a table, but a function which does the conversion. It already has to do that, turning the RPC number into a function to call. [14:05:24] --- abo has become available [14:05:48] right..a name like Suffix_RPC_to_string [14:06:00] where Suffix comes from the .xg file. [14:06:22] I'll try to put a spec together for it and bounce it off openafs-devel tonight/tomorrow. [14:11:07] HuH? What is "Suffix" ? [14:12:33] sorry, Prefix. [14:14:15] e.g., take package RXAFS; prefix S; and use that to build SRXAFS_RPC_to_name and SRXAFS_name_to_RPC. [14:14:40] ye-ah [14:15:33] although with some thought, we might be able to just have a single pair of functions, and let the package + prefix stuff be handled inside the functions rather than have to know what package+prefix your particular RPC is in. [14:15:45] that's part of the thinking I want to do. [14:16:29] Don't you have to collect output from multiple invocations? [14:16:35] yes. [14:16:45] Seems more useful to establish a framework for that. [14:16:45] but that could be something over in src/util [14:17:13] i.e., it does #include of the output of the various rxgen invocations and uses that to build it's table; then exports the two functions. [14:17:17] No, you really should using the naming conventions it actually uses. If the package is RXAFS_ and prefix S, your function should be something like RXAFS_ProcName (note "prefix" is used _only_ in server-side stubs, and rxgen does not insert an _ after the package name) [14:18:49] FooProcName should use exactly the same logic as FooExecuteRequest, so you don't end up with a huge table. The reverse is a bit more complicated. [14:21:08] * stevenjenkins nods. as I mentioned, I need to do some more thinking and get something more complete put together, then bounce it off openafs-devel. I'll try to get the details about package names, prefixes, etc correct in that so we can focus on the core issues rather than my typos. [14:25:36] --- matt has left [14:29:44] --- matt has become available [14:53:12] --- manfred furuholmen has left [14:54:34] --- manfred furuholmen has become available [15:27:11] --- manfred furuholmen has left [19:08:30] --- matt has left [22:11:51] --- SecureEndpoints has become available [22:32:42] --- SecureEndpoints has left: Replaced by new connection [23:01:57] --- reuteras has become available [23:27:22] --- SecureEndpoints has become available