Re: learning curve
Am Samstag, 28. November 2009 00:48:26 schrieb olafbuddenha...@gmx.net: > Sure, I don't question the need for smart developers... What I'm saying > is that (unlike switching microkernels), the existing implementation > requires a lot of less challenging work also -- it's just not true that > we don't need many developers. And that's why I started this thread. I write the Month Of The Hurd, because I want to make the Hurd more appealing to general users. Maybe some of the interested people will be the really smart developers, but most will be general users and "normal" developers. And I believe that these are the majority of the people who are important to the Hurd (if only because they are the majority of people in general). Once the basic foundation of the Hurd matures, it will be far easier to go into very low-level stuff for general desktop computing, and what good is it to write a great system and then attract only people who don't really benefit from that, because they could do the low-level almost as easily in Linux? The Hurd opens up options, not only to excellent developers but also to all those people who are very good game designers, very good documenters, very good community managers, etc. Giving all these people additional options means zip (at least from the view of society in general), if they never find the Hurd. And the learning curve of the Hurd - including closing in on its internals step by step - is an important part of that. When someone who finds the Hurd can easily see what he can do (and get a glimpse of the full potential), he's far more likely to tell others about that. If on the other hand most people aren't able to utilize the power of the Hurd in any way, they won't tell others how great the Hurd is. And one of those who then doesn't learn about the Hurd might be one of the excellent programmers who are needed for the delicate work. And that this isn't consensus in here shows me, that the decision to keep this thread in bug-hurd was right. More: The thread was needed badly. Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de signature.asc Description: This is a digitally signed message part.
Re: Hurdish Desktop
Am Mittwoch, 25. November 2009 14:31:30 schrieb olafbuddenha...@gmx.net: > The other plan would have the advantage that it would be built directly > on top of the stuff I'm doing for my thesis... Essentially, I'm telling > myself that the KGI stuff is part of the big puzzle -- so I don't have > to admit that it's mostly pointless ;-) Since you're already doing that work, I think it's a great idea to just *make* it part of the big puzzle. Why let good work go to waste, when you can put it to good use? I have a similar issue: I tend to do many different things, so in most projects I try to knit as many of my different interests together as possible. The advantage of that approach is that a well chosen project can benefit from real synergy effects. When the better desktop is your focus, then I don't see anything which should keep you from using your thesis to further that goal - ideally together with the other things you do instead of working on the thesis full-time. Best wishes, Arne signature.asc Description: This is a digitally signed message part.
Re: learning curve
Hi, On Wed, Nov 25, 2009 at 12:04:24PM +0100, Samuel Thibault wrote: > olafbuddenha...@gmx.net, le Sun 22 Nov 2009 22:04:22 +0100, a écrit : > > (BTW, I don't actually agree on the "really smart developers only" > > part either. Unless you are among those who believe that any work on > > the existing implementation is pointless, and only working on a new > > microkernel would provide any benefit...) > > The existing implementation needs really smart developers. It needs > not so smart developers too, but a lot of things that _need_ to be > fixed (e.g. including parts of perl testsuite failures, ghc6 failures, > I/O performance) probably won't be fixable without good skills. Sure, I don't question the need for smart developers... What I'm saying is that (unlike switching microkernels), the existing implementation requires a lot of less challenging work also -- it's just not true that we don't need many developers. -antrik-
Re: [PATCH 2/3] Implement mountee startup.
Hi, On Wed, Nov 25, 2009 at 07:59:33PM +0100, Carl Fredrik Hammar wrote: > On Sun, Nov 22, 2009 at 09:05:16PM +0100, olafbuddenha...@gmx.net wrote: > > On Thu, Nov 19, 2009 at 10:28:37AM +0200, Sergiu Ivanov wrote: > > > + /* Fetch the effective UIDs of the unionfs process. */ > > > + nuids = geteuids (0, 0); > > > + if (nuids < 0) > > > +return EPERM; > > > + uids = alloca (nuids * sizeof (uid_t)); > > > + > > > + nuids = geteuids (nuids, uids); > > > + assert (nuids > 0); > > > > Hrmph, I didn't spot this before: I don't think the assert() is right -- > > "nuids" (or "ngids") being exactly 0, is probably a perfectly valid > > case... And even if it is not, the test in the assert should be > > equivalent to the EPERM test above, to avoid confusion. > > geteuids() actual error (in errno) should be returned instead of EPERM. Does geteuids() actually set errno? > Also credentials can be changed at any moment by other processes > through the msg_set_init_port() RPC (very much like a signal), Yeah, I realized that after thinking more about it. On IRC I told Sergiu to return to the original code, doing the same check again on the second call. Too bad I didn't properly think it through in the first place, before even suggesting the change... > which becomes a problem if the number of UIDs grows between the calls > to geteuid(). Not sure this is really a problem. If the credentials change in the middle of things, we can't rely on the set being current anyways; so it's probably fine if it's truncated to the old size... > It would be much easier if it just returned malloced memory to begin > with... Agreed. -antrik-
Re: news 2009-11-30
Hi, Am Mittwoch, 2. Dezember 2009 09:24:54 schrieb Emilio Pozuelo Monfort: > Arne Babenhauserheide wrote: > >> Also thanks to Samuel Thibault, the latest grub2 package > >> (1.97+20091125-1) > > Note that this version has a segfault that is triggered when running > grub-install or grub-mkconfig. The 1.97+20091130-1 package fixes this issue > though, so I suggest to use that version. Fixed and pushed. Many thanks! Best wishes, Arne signature.asc Description: This is a digitally signed message part.
Re: news 2009-11-30
Heya Arne Babenhauserheide wrote: >> Also thanks to Samuel Thibault, the latest grub2 package (1.97+20091125-1) Note that this version has a segfault that is triggered when running grub-install or grub-mkconfig. The 1.97+20091130-1 package fixes this issue though, so I suggest to use that version. >> [supports native installation](http://lists.debian.org/debian- > hurd/2009/11/msg00095.html) >> from GNU/Hurd itself. Grub was originally designed >> [to allow booting of GNU/Hurd systems] > (http://www.gnu.org/software/grub/manual/grub.html#History), >> so this step brings it closer to its original purpose again. Cheers from a newcomer! Emilio signature.asc Description: OpenPGP digital signature
