--- Topic for #qc is Next talk: "The Hurd: a GNU approach to OS design Friday Dec 13, at 21:00 GMT Wolfgang Jaehrling | Comments #qc; Spanish #redes; Dutch #taee |
sarnold | is there any need to ensure that parts of glibc don't use servers that recursively use those parts of glibc? |
wolfgang | not generally, since servers are multithreaded. |
wolfgang | so one thread of a server can block on waiting for a response, while another one handles the recursive request |
wolfgang | question answered? |
sarnold | sortof... :) |
sarnold | it still worries me about resource consumption :) |
wolfgang | how so? |
sarnold | ahh, i can pester later :) |
marco | For L4 the client has to provide resources, for gnumach the server has to allocate memory pages |
MJesus | please, copypaste of question and answerd in #linux, for traslators |
wolfgang | MJesus: ah, will do that next time |
wolfgang | MJesus: i did not know that |
MJesus | :)) thanks |
vegai | umm, module bugs? |
sarnold | vegai, "modulo bugs" ... meaning, "except in the case of bugs" |
vegai | ah, modulo. Of course. Carry on ;) |
E0x | hehe yes that guys forget something very importa :) |
riel | how about running non-free software on the hurd ? |
sarnold | well, being able to, and being legally allowed to, are different things.. is the lgpl-ness of glibc sufficient to shield all programs from GPL's "linking" clause (for using the hurd servers)? |
marco | some libraries of the Hurd are GPL'ed... |
wolfgang | marco: all of them. |
marco | ahh |
wolfgang | marco: but not the stubs for the interfaces themselfes. |
wolfgang | marco: there is no need to use any of these libraries |
wolfgang | except for that it is more convenient. |
marco | the interface definition files are GPL'ed |
wolfgang | marco: but not the MiG-generated stubs, are they? |
marco | wolfgang: well, object files don't have a GPL copyright message too... IMHO you should use object files and stubs the same way when speaking about the GPL... |
wolfgang | marco: it is GNU-policy to not impose license restrictions on output files. |
marco | ok :) |
wolfgang | marco: no matter whether they are generated by bison, mig, gcc or whatever |
marco | ic |
wolfgang | (or automake etc.) |
bunny | brrr |
jmgv | we should answer all questions at linux |
marco | wolfgang: it could be fun to talk about this later ;) |
wolfgang | that was an objection, not a question ;) |
marco | yeah :P |
jmgv | okey :-), but remenber not everybody are reading this channel. ;-) |
sarnold | are there security problems with allowing users to modify the filesystem namespace? or is the user performing the mount the only user who can see the newly added filesystem mount? |
sarnold | if so, what happens if two users both try to mount to the same mount-point? (well, that sounds like trouble anyway...) |
vegai | I guess they would be mounting on their own directories mostly. |
vegai | s/on/under/ |
wolfgang | vegai: exactly :) |
Arador | and can you mount something (a iso image in loop device for example) for N users? |
sarnold | is there an easy way for the sysadmin to prevent users from mounting new filesystems, to prevent someone from doing while true ; do mount ; done ? |
sarnold | ahhhh, good point! :) so different. |
marco | A sysadmin can use a custom glibc that ignores user "mounts", I guess... No security problems... |
bunny | brrr |
marco | bunny: ? |
wolfgang | marco: yes. |
bunny | marco: what can i not brrr ? jeez ;) |
marco | bunny: Sure you can :) |
bunny | thanks ur maYESHty ;) |
marco | lol |
bunny | is it bad if i got tetrinetting now? |
bunny | i love you wolfinchen .. =* |
wolfgang | bunny: i know. |
marco | *hhhmpff* fatfs *hmmmpff* |
Arador | how does ftpfs handles things such as "password incorrect" or "timeout" to the POSIX applications? |
marco | ahh, hostmux stuff :) |
vegai | wolfgang: in that example, 'foo' is a translator, right? |
vegai | the run-translator, that is |
* vegai nods. |
sarnold | does the translator run with the privs of whoever ran "run" or whoever performs the read(2)? |
vegai | what about language independence? Is C the only choice for coding translators? |
vegai | ah, sounds good |
sarnold | if you don't mind (heh heh, you must be tired of me :) what tops the list of what needs doing? |
mentor | AFAI can see: essentially HURD translators/servers provide a service in a different context (processor context, security context, and any other contexts the microkernel maintains); would it ever be considered useful to implement services in such a way that specfic contexts can be chosen for segregation? |
wolfgang | ok, i'm done. |
vegai | I have one |
wolfgang | will you tell me? :) |
mentor | SSH would be a good example(?). Currently hte OpenBSD team has priviliege where there are two processes, one to validate network data in lowly context, and then pass it to the privileged shell server, the server is then only waiting on the network server for data (an over simpification...); in this case is it truly efficient to have seperate process and full context switch for each (a full Active Object)? |
vegai | I'm under the impression, that the current microkernel is limited in several ways, and it's being replaced by L4. What will this cause to the current Hurd? |
wolfgang | i will respind to vegai first. |
sarnold | mentor: the privsep stuff in openssh is only to reduce the amount of code running as root; not for any performance reasons. once authentication has taken place, the root process is finished.. |
mentor | sarnold: well, not exactly the best example then. |
mentor | sarnold: I wonder if there is a good example?... |
marco | adding and dropping privileges on the Hurd is really interesting :)) |
vegai | wolfgang: perhaps most importantly: are the translators/servers coupled to Mach? Do they need to be rewritten for L4? |
vegai | ah, you answered already |
sarnold | mentor: well, dan kaminsky's packetto keiretsu presentation a few days ago mentioned some useful properties of using a sending-only process and a recieving-only process |
wolfgang | vegai: if you think that using a type like mach_port_t makes it Mach-dependend, then it needs to be ported. but except for such mostly syntactic issues, we are already quite Mach-independend. |
sarnold | mentor: i would expect benefits/problems to carry over to hurd similarly |
wolfgang | mentor: so your question is basically about performance issues? |
MJesus | this text are not tralated to Spanish or Ducht |
marco | Dutch... ;) |
MJesus | please, at #linux the answerd |
MJesus | Dutch ! |
garoeda | yes, Dutch :-) |
Geryon | garoeda will filter it out ;) |
dT | well this _is_ translated to ducht tape tho :) |
wolfgang | it was just a minor note :) |
dT | (as in duct tape -> silence) |
jmones | ohhh... did i arrive late? |
marco | jmones: jup |
jmones | :( |
marco | jmones: You can read the logs and ask questions on #hurd or the ml ;) |