commit and the
ability to prepare patches without network is attractive to me.
That said, I have no opinion on using decentralised systems, since I
don't know them. However, if they are considered the best, but it is
impractical to make the switch, going from cvs to svn would still be
well worth
Hello all,
On Fri, Apr 21, 2006 at 01:22:15PM -0400, Thomas Schwinge wrote:
> If the community is not able to ``handle'' a ricochet like Alfred is, my
> time is for me no longer worth to be wasted on this project.
>
> For this reason:
>
> I will stop any work on the Hurd from now on until a) Alf
On Mon, Apr 03, 2006 at 06:07:57PM +0200, Ralf Wildenhues wrote:
> Hi Bas,
Hi,
> > There's one major hack in there: automake doesn't support += on things like
> > bin_PROGRAMS, so I had to create temporary variables for it and do
> > bin_PROGRAMS = $(programs).
>
> This sounds awfully like a bug
On Mon, Apr 03, 2006 at 04:29:29AM +0200, Ralf Wildenhues wrote:
> * Thomas Schwinge wrote on Fri, Mar 31, 2006 at 11:42:28AM CEST:
> >
> > In the old build system we had the very conventient feature that you
> > could `make progb' from the top level build directory and it would
> > automagically
On Wed, Dec 21, 2005 at 03:43:56PM +0100, Alfred M. Szmidt wrote:
>There are some problems with Mach which seem very hard or even
>impossible to fix without using a new microkernel.
>
> Impossible it is not, very hard it is or might be, but so is porting
> to a new kernel, which is infact
On Wed, Dec 21, 2005 at 09:38:50AM +0100, Patrick Leslie Polzer wrote:
> Hello list,
Hi,
> please excuse my ignorance, but what's the Status of GNU Mach?
GNU Mach is currently the only microkernel which is supported by the Hurd.
That is: If you want to run Hurd, you need Mach. That may change,
On Wed, Nov 09, 2005 at 03:00:15PM +0100, Alfred M. Szmidt wrote:
>> You should go into politics with the evading answers you are
>> giving, they have no substance other than: Do as you please, I do
>> not care.
>>
>> Which is immensly useful for setting a direction...
>
>A
On Wed, Nov 09, 2005 at 10:10:09AM +0100, Alfred M. Szmidt wrote:
> You should go into politics with the evading answers you are giving,
> they have no substance other than: Do as you please, I do not care.
>
> Which is immensly useful for setting a direction...
As you very well know, the current
On Sun, Aug 28, 2005 at 11:03:31PM +0200, Thomas Schwinge wrote:
> > > +
> > > +void (*__malloc_initialize_hook) (void) = (void *) init_hook;
> >
> > Do you really need the void * cast?
>
> The cast avoids the following warning:
> #v+
> [...]
> ../../hurd-0/mach-defpager/../serverboot/kalloc.c:4
Hi,
On Thu, Aug 25, 2005 at 05:01:01PM +0200, Marco Gerards wrote:
> So I am considering a library that is capable of the same things as
> the ioctls. Would that be a wise choice or is there any way to
> overcome the problems I described? My choice would be a library that
> should be used for co
[EMAIL PROTECTED] wrote:
I like device drivers, scheduling, memory managment, security.
I've read that device drivers are a good and simpler way to get
started in kernel development...
It sounds to me that you are interested in working on the L4 port,
particularly the device driver framework. It w
Alfred M. Szmidt wrote:
Other suggestions for what? You didn't tell us what your current
problem was (atleast, I couldn't see it).
His booting stopped after saying
start (hd0,2)/hurd/ext2fs.static:
(hd0,2)/hurd/ext2fs.static:
(as he described in his original post, and is still in the topic)
Howeve
Alfred M. Szmidt wrote:
#ifdef SWAPOFF
const char *argp_program_version = STANDARD_HURD_VERSION (swapoff);
+
+static int require_signature = 0;
+static int ignore_signature = 1;
#else
const char *argp_program_version = STANDARD_HURD_VERSION (swapon);
+
+static int require_signature = 1;
+static
Alfred M. Szmidt wrote:
BTW Isn't this question for the FAQ? ;-)
Great idea! And thanks for the answer to the question.
?? Why is there so much on bug-hurd/help-hurd?
{OK} Because anyone can post to GNU mailing lists without being
subscribed (to ease asking questions), and there are no spam fil
implements "get the root capability"-support in the capability
server code.
2005-01-11 Bas Wijnen <[EMAIL PROTECTED]>
* bucket-manage-mt.c (struct workerinfo): added member root.
* bucket-manage-mt.c (manage_demuxer, manage_mt_worker,
hurd_cap_bucket_manage
Alfred M. Szmidt wrote:
I think the second way to configure screensavers is the best. What
do you think?
I think it sucks, the console client and all plugins already take so
many arguments that it is very confusing.
I think it should be possible to use a configuration file, however it
shoul
Alfred M. Szmidt wrote:
> 2 July 2003
> The tarball for Debian GNU/Hurd that Marcus Brinkmann made over
> the years has been discontinued in favour of Jeff Bailey's
> crosshurd package. To install Debian GNU/Hurd from now on, this
> package should be used. Anothe
Marco Gerards wrote:
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
I think it might also be nice to create a "punch list" of known bugs
or missing features that people think are essential for a 1.0
release.
Just to be really clear: I did not suggest a 0.3 release.
Was that a mistake, or are yo
Alfred M. Szmidt wrote:
There are very few hackers on the project, and that is a problem.
We can call it lack of their imagination, but it's our problem, not
theirs, so blaming them isn't going to help.
I disagree, it is not our problem that people don't want to hack.
We want the software
Alfred M. Szmidt wrote:
- mozilla and/or mozilla firefox should run.
- gnome and/or kde should run.
- probably OpenOffice.org as well.
... are not related to the Hurd.
- decent network support (including dhcp).
We have DHCP now it seems,
Oh, I had the feeling a program like dhclient sti
Alfred M. Szmidt wrote:
What is the problem with the Hurd? Lack of proper direction? Lack
of hackers? Lack of documentation? Lack of ...? What is the
problem, really? We need to know it in order to fix it.
There is no problem, but the lack of imagination from those who wish
to hack I think
Alfred M. Szmidt wrote:
I think it might also be nice to create a "punch list" of known
bugs or missing features that people think are essential for a 1.0
release.
And/Or for the next release. Features that would take time to
implement (libchannel?) could wait a bit, but bug fixes should
Alfred M. Szmidt wrote:
If someone is Hurd newbie and (s)he tries to use fakeroot for
building Debian packages, what do you think that (s)he'll think
about the Hurd?
What will the newbie think if she/head finds a totally obscure bug
that eats the file-system, or any other horrible thing?
Giuseppe Scrivano wrote:
server_socket = socket (PF_INET, SOCK_STREAM, 0);
Check if the call succeeded (server_socket >= 0)
/* address family. */
sock_in.sin_family = PF_INET;
/* port used. */
sock_in.sin_port = htons (8080);
sock_in.sin_addr.s_addr = INADDR_ANY;
err = bind (s
Alfred M. Szmidt wrote:
I don't think we care about POSIX at all here. If Alfred wants to
write a translator which is totally non-POSIX, he should be free to
do so.
What I meant was that we can disregard POSIX aslong as programs
reading/writting from the file work as expected. And as far
Hi,
A rollover translator sounds like a nice idea :-)
Danilo Segan wrote:
Today at 9:09, Alfred M. Szmidt wrote:
I like this idea too, for real log files this has more sense. But I
am not sure at all how one would go about to implement.
When one writes N bytes to the file when at the end of the f
Santiago Vila wrote:
On Sat, 16 Oct 2004, Alfred M. Szmidt wrote:
Jeez, each time this topic comes up people start throwing out stupid
ideas. Just run a spam filter will yah?
Sorry, but your suggestion to use a spam filter *is* the stupid idea.
If this may be fixed by simply "running a spam filt
On Wed, Jul 28, 2004 at 01:53:47PM -0700, Thomas Bushnell, BSG wrote:
>
> Be very careful in general with select on network thingies. This
> doesn't apply to your use, but I want it on the record. To return
> select true means that you can immediately do I/O with no waiting.
>
> That means that
On Wed, Jul 21, 2004 at 04:57:55PM +0200, Marco Gerards wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> > volatile sig_atomic_t should_we_die;
> > global flag every second should be ok. A max delay of 1 second at kill is
> > acceptable, IMHO.
>
> Absolutely. AFAIK signals are not reliabl
On Wed, Jun 16, 2004 at 08:57:18PM +0200, Marco Gerards wrote:
> The main problem to consider here is how to prevent the journal to get
> filled too quickly. Consider a 1GB file which you drastically change. That
> means you will have a 1GB transaction. Normally a journal is a lot smaller.
The
On Tue, Jun 15, 2004 at 11:18:35PM +0200, Marco Gerards wrote:
> This is a really important feature for a server os to have, IMHO.
Not just for a server OS. Any OS would get rock solid from it. The problem
that a crashing computer kills your installation is only partly gone with
journalling as i
which should have a higher priority. Which means I'll help to get
that port ready before going into details like journalling file systems.
They're very nice details, but quite useless without a good OS.
> So, shutup and code.
Forming an opinion about what should be implemented and how is an
uch stuff.
I just wanted to mention it at this early stage, because it may be very hard
to implement it later if it wasn't considered as a posibility.
Bye,
Bas Wijnen
--
I encourage sending me encrypted e-mail.
Please send the central message of e-mails as plain text in the message body,
l of it, and if it didn't, then it didn't do any of it. I
don't expect the program to continue if the filesystem crashes, but if it does
then it might do some recovery if it likes. One thing it knows for sure: its
database is not corrupted by the filesystem crash.
Please let me
systems, everything should be possible. It's up to the
system administrator to choose what (s)he wnats. Capabilities allow the
administrator to give the users much more freedoms without compomising the
whole system's security. But it's still up to the administrator if those
righ
35 matches
Mail list logo
