> I can seed it on linuxtracker, if somebody wants to..
I can't understand from the thread what it is. Is it a GNU
installer, a Hurd ISO or what?
It is version of Debian GNU/Hurd, I think.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
It simply halted during the boot of the system.
Sounds as a IRQ conflict.
The latest version of HURD is 4 years old.
It is more like 10 years old actually, Hurd 0.2 and GNU 0.2 were
released in 1997. The latest snapshot of the GNU system[0] is
2006-01-08, but don't let the date fool you,
Please use Emacs from CVS. Emacs 21.x does not work on GNU without
patches.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
In fact, as far as I can tell we don't have a switch to tell
`settrans' to _only_ remove a running active translator from a
node, which would be useful to have.
~$ settrans -acp h /hurd/hello
~$ cat hello
Hello, world!
~$ settrans -ag
~$ ps uxa|grep hello
root 7349 0.0 0.2 145M 7
> glibc hasn't worked out of the box for atleast a year since
> malloc/memusage.c uses __thread without #if's.
Ok so glibc 2.4 as such doesn't work (that was the original
question).
glibc since 2.3 hasn't worked out of the box, either CVS or otherwise.
Nor will the malloc/memusage.c t
> As I said, these patches will become avaiable with time. But as
> such, both GCC and GLIBC work fine on GNU; you are of course free
> to inisist on otherwise if that makes you happy.
By "as such", do you mean "upstream glibc 2.4 release and gcc 4.1",
or your patched versions?
Th
As I said, these patches will become avaiable with time. But as such,
both GCC and GLIBC work fine on GNU; you are of course free to inisist
on otherwise if that makes you happy.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
glibc 2.4 is completely unusable for GNU/Hurd at the moment,
Not true. It might be true for Debian GNU/Hurd though.
Also, a GCC 4.1-build glibc doesn't work correctly: it already
fails during the building process, as soon as the newly created
libc.so is being used (might also be ld.s
OK, building bazaar.
There is a patch for tla (should be included in 1.3.4) that fixes all
known issues in libhackerlab, maybe it could be used for bazaar since
they are kinda the same.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL P
Hi! This is all answered in the Debian GNU/Hurd installation guide,
and the GRUB manual. See http://www.debian.org/ports/hurd and `info
grub' (you might need a special packaged installed on some GNU/Linux
systems).
Happy hacking!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
this should be a easy question, but I'm getting confused becouse
the contradictory info I'm reading out there. Which web page
should I read to stay up to date about hurd?
The Hurd project web page, http://www.gnu.org/software/hurd/
This is the offical place for any information and news
> Having poked around, D-Link DE-600 should be supported, could you
> run the following command and tell us what you get?
>
> devprobe eth0 eth1
It does not show any output.
Then it isn't detected. Is it maybe sharing an IRQ with another
device so that GNU Mach gets confused and t
> What kind of NIC do you have?
A D-Link DE-600 by the looks of it, that may not be supported.
Having poked around, D-Link DE-600 should be supported, could you run
the following command and tell us what you get?
devprobe eth0 eth1
(Thank you for changing to using normal text!)
--
To U
There is nothing wrong with using group replies, it is the bug
reporting software that is broken, not my usage of group replies.
Group replies as you call it is the standard way of replying to mails
posted to a mailing list.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubs
Please report bugs that are related to the Hurd or GNU Mach, to the
Hurd projects bug tracker. http://sv.gnu.org/hurd
If possible, always try to show a backtrace using gdb. See the gdb
manual for info on how to do just that.
Thank you.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a sub
kernel /boot/gnumach.gz root=device:hd2s1 -s
module /hurd/ext2fs.static
--multiboot-command-line=${kernel-command-line}
--host-priv-port=${host-port}
--device-master-port=${device-port}
--exec-server-task=${exec-task} -T typed ${root}
$(task-create) $(task-resume)
module /li
Is this security bug still open, after more than six years?
Yes, but it doesn't belong in the Debian BTS. It would be nice if
someone could file all these bug reports into the proper place,
http://sv.gnu.org/p/hurd.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscrib
title GNU/Hurd mono utilisateur (hd2s1)
root(hd1,0)
kernel /boot/gnumach.gz root=device:hd2s1 -s
module /hurd/ext2fs.static \
--multiboot-command-line=${kernel-command-line} \
--host-priv-port=${host-port} \
--device-master-port=${
Please don't move to glibc with gcc 4.x compiled just yet. It is
fubar. Basicly you're lucky that it actually works.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
The gdb package in Debian is fucked up (I have no politer way of
saying it, this thing wasted me a couple of hours of sleep), info file
causes segfaults, and doing stepi in some circumstances will just jump
to $pc+0xcc or some such. For example:
(gdb) si
0xf412 279 __mig_deallo
Id like todo a install completely over serial console. Anychance there
is a easy way to go about this?
Not without hacking the install process, and making it setup the
console for serial debugging, which kinda means a properly configured
system.
--
To UNSUBSCRIBE, email to [EMAIL PROTECT
furthermore i would consider a "[debian-hurd]"-subjects as kind of
good mailing list style.
It is a bad style. The information about from which mailing list if
any is already stored in the header of a message. No need to
duplicate it in the subject and waste valuable space there. Just
fil
I thought it can run the applications now...
It can run banner if that is what you mean, but it isn't usable for
any thing other than testing various primitive bits right now.
BTW, I'm looking for Hurd image for QEMU. Do you know if the Hurd
on Mach run on QEMU?
It does, but I do not kn
When will you package Hurd ran on L4 microkernel?
When it is usable.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> What about a firmlink? That would solve all problems.
What is a firmlink?
/hurd/firmlink --help, [hurd]/trans/firmlink.c.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
So the problem remains : if you put /bin first in your PATH, you'll
have configure discover 'gzip' in /bin (which is the right thing)
and 'pager' in /bin (which is the wrong thing), and if you put
/usr/bin first you'll have the same problem the other way around.
I see that I misunderst
> What about a firmlink? That would solve all problems.
Would it ?
Yes. You don't get the funky side-effects of symlinks.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
What about a firmlink? That would solve all problems.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
This should be filed upstreams since it isn't a Debian GNU/Hurd bug.
I have filed it into the SV bug tracker, could someone close this?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
You'd be everyone's hero, however, most people who tried that lost
their sanity down the road.
Nobody has ever tried porting Linux >2.0 driver to Mach to my
knowledge. Anyway, the current drivers being in use are not only 2.0
drivers, they are a mixture of lots of versions.
(#hug or
Try having a normal user first in the list of euids or auids, this was
only when I could get it to fail.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
No answer, :-(
No answer since nobody knows what the answer is, you will need to have
to do some hacking on your own. Try checking the obvious if the PCI
ID's exist for your card in GNU Mach, and if they do not, try adding
them.
Sorry, you are on your own unless you send your NIC to someone
Please fix the build system instead of installing ldconfig and
patching glibc to support it on Debian GNU/Hurd. If Debian GNU/Hurd
needs a ldconfig for compatbility with Debian GNU/Linux then one
should make ldconfig just call /bin/true.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subj
If so, would this be a bug?
Yes it is a "bug", but in tsch and not in glibc's netdb.h header.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> Compile Emacs from CVS, it is known to work. Or a Emacs without
> Debian patches.
FWIW, that is not the problem. I compiled emacs21 without any
patches (well, except for the one which fixes a build failure for
us), and got the same problems.
(cue rant about how Debian's glib
Have not got a solution for this problem (getting segmentation
fault while running emacs from console itself). No help?
Compile Emacs from CVS, it is known to work. Or a Emacs without
Debian patches.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble?
Cpu(s): 5.7% us, 1.1% sy, 4.9% ni, 87.8% id, 0.4% wa, 0.0% hi,
0.1% si
Ah, why didn't you say so in the first place? :) You could check what
our top does, it is in the hurdextras repository on Savannah in a
module called pptop. But it is still buggy, hasn't been touched in
three yea
I've read its code (along with pptop, vmstat, and w, from which I
took most of the code, or the ideas, anyway). GNU uptime does not
show statistics about CPU usage, as far as I know. Or is it new? (I
can't see it in coreutils CVS)
It shows CPU load; which I confused with CPU usage. Do
- I can't find a way to get statistics about CPU usage
(user/sys/kernel times, etc.), i.e. what you get in /proc/stat
with Linux.
Don't recall of hand, but you could look at see what GNU uptime does
to get that info.
- I did not find a clean way to get the last running PID
Again, this should be a Debian-specific change for now.
It will be a Debian specific change forever.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Or just hard code it on Debian to /usr/include, even if that is
stupid.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
#v+
# In GNU, "/usr" is a four-letter word.
NATIVE_SYSTEM_HEADER_DIR = /include
#v-
I think that just changing NATIVE_SYSTEM_HEADER_DIR to:
NATIVE_SYSTEM_HEADER_DIR = $(prefix)/include
would fix all problems, could someone with a GNU/Hurd system check
that? It would kinda break stuf
How about making gcc's configure test smart so that when you do
"--prefix=" (the normal way to configure any program for the GNU
system) it looks for headers in /include /local, and if you do
--prefix=/usr (as Debian does) it would look for the files in
/usr/include /usr/local?
/loc
If /usr is a symlink to / and gcc uses /usr/include, it will work.
If /usr is a real directory and gcc uses /usr/include, it will work as well.
And if /usr doesn't exist, it will not work at all. Hard coding is
just bad, period.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subjec
How about making gcc's configure test smart so that when you do
"--prefix=" (the normal way to configure any program for the GNU
system) it looks for headers in /include /local, and if you do
--prefix=/usr (as Debian does) it would look for the files in
/usr/include /usr/local?
This is the right t
However, later it must still be obvious to figure out easily if a
committed change is an update from Linux-2.0.x, a backport from
e.g. Linux-2.2.x, or a Mach-specific change. The ChangeLog is not
always explicit there, at least IMHO.
Then I think we should take care to make them clea
You should put Linux's original files (i.e. the versions your patch
is based on) into linux/src/ and put your modified files into
linux/dev/. The files from linux/dev/ will shadow the linux/src/
ones.
I disagree very strongly (and thus disagree with the comment in one of
the Makefiles
I know there is no dhcp support in hurd.
Then you know wrong. ;-) Marco hacked together a patch for DHCP, it
should be somewhere in the bug-hurd@gnu.org mailing list archives.
Then you can just use dhclient to get the IP and other love.
[Something about 'hurd/trans/pump.c'...]
Does anyone
Yea, but the problem with having a patch is that some of us aren't
quite sure how to apply the patch.
Knowning how to apply patches is a good skill to learn.
but is there any plan to apply the patch permanently so that the
stock kernel used in the base package has support for sis900?
I would like to have the sis900-enabled kernel, too ;-)
Andreas B. Mundt <[EMAIL PROTECTED]> on the 28th of March sent a patch
for SiS-900.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> Since I already have Debian linux on, I used the cross-install
> method, and an older install guide that said to limit my
> partitions to 2GB. If it can recognize partitions greater than
> 2GB, would resizing the partition (using resize_ext2fs) be
> alright? Or should I just delete
> There was a similar problem in the kfreebsd-i386 architecture and
> it was solved by modifying binutils to honor /etc/ld.so.conf.
Didn't Jeff fix this already? CC'ing Jeff to be sure he reads
this...
Adding support for ld.so.conf on Debian GNU/Hurd is not a fix.
Infact, that patch
You may want to try Ubuntu. www.ubuntulinux.org its free and I
guess it could replace windows on your computer.
That won't replace the windows in a wall though...
(nor is Ubuntu free since it contains non-free software)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "uns
I live in NY State and would like to know where I can get
replacement windows.
You have confused the Hurd with a company by a similar name, the Hurd
Millwork Company. This mailing list is dedicated to a operating
system called Debian GNU/Hurd (see
http://hurd.gnu.org. http://www.gnu.org and
If Mach has flaws that need to move the Hurd on L4, I'd rather work
on this latter. And it's maybe too low-level for me, for the
moment.
If Mach has flaws then they should be fixed, not ignored just because
we might in 10 years use L4. See it it as a learning experience to
learn those l
> This kind of attitude isn't helpful.
Yes, asking for help by giving information when it's asked should
be punished. Reporting bugs and problems too.
I suggest that you reread the message posted by Marc, it was a stupid
attempt at flaming. And that kind of attitude is not helpful.
--
If I have understood correctly, the Hurd is, for the moment, unable
to deal with shared IRQs.
The Hurd is totally ignorant to IRQ sharing. It is a problem in GNU
Mach, I don't think anyone has looked into the problem or even tried
to fix it. Would you like to figure out what the problem is
This kind of attitude isn't helpful. Can you provide more information
about the problem instead of trying to start a flamewar? Maybe your
system is broken, have you experienced the behaviour you noted on
other systems?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscrib
Please, don't lecture me about the Hurd being perfect; it's not.
Trust me, I won't lecture you about that, but I might lecture your
about how unperfect it is.
A friend at the AI lab once gave the following dream as an example
of a well-functioning system:
It all sounds like a Lisp Machi
> *wink* how do you purpose to somehow get some kind of interactive
> input from the user when you do a file-system call?
This is a shortcoming in the design of the Hurd (gasp!).
I think you mean that it is a shortcoming in the design of things that
are not or cannot be interactive, file
Keep track of the conversation. You were supposed to be saying
that the Hurd cannot get Debian to agree to /usr->/ for the Hurd,
and you're wrong. Why switch to getting rid of the symlink?
Because *we didn't have shadowfs*. How many times must I explain
the same point?
Bogus, the
Why change back? Because it's better that way.
My sentence was unclear, what I meant was why change from /usr -> /
(which has been long in use) and then back again to /usr -> / when the
plan has always been to have that symlink or atleast have a translator
sitting there. Removing the symlink
And as I said, we need shadow translators. Once we have them, we
could create /usr->/ with little fuss.
We already have a read-only (write support is flakey) implementation
of unionfs. But why change _back_ to /usr -> / when that was used for
years?
Let's change this around. What prob
It would be easy to change /usr; we would need to have shadow
translators, make existing packages install (which is trivial with
the /usr->/ symlink), and so forth.
We don't have a /usr -> / symlink anymore. It is optional, and the
default is to create a seperate /usr directory, and only
Is somebody working in this?
No.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I see no reason to think that Debian GNU/Hurd cant do all of these.
/usr is now by default a seperate directory I think, people bitch
about obviously compliant FHS directories. These are small things
compared to using translators for /share/info or redesigning the deb
format to be nicer for tr
In fact, I find it to be quite destructive.
And I find you spreading lies about what I support or don't support
far more destructive.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> There are two or three people actually involved in making the GNU
> system. And you are not included in that list sadly. :-)
Wow! GNU System is done by two/three people only. Great... Could
you name those two or three people?
Me, Gianluca and Stallman. When I say "the GNU system
Alfred, can you show the document that their plan is now making
"Debian GNU/Linux"?
I dislike these kind of silly questions since they serve no point.
Ask a DD or the DPL if the point of Debian is to create Debian
GNU/Hurd or Debian GNU/Linux. Look around www.debian.org.
Let's try again
I was still wanting clarification of this comment of yours.
'I also know that you cannot mean the GNU system, since "we"
consists of less people then there are people hacking on the Hurd
right now.'
There are two or three people actually involved in making the GNU
system. And you are
> Debian GNU/Hurd is about playing with Hurd politics.
The same could be said for you. You won't find people helping you
on the GNU system just by bashing Debian and claiming it does not
care.
Get of your high horse, for one I'm not looking for help, second I
haven't bashed anything,
>Those people who are hacking the GNU Hurd and not playing Hurd
>politics.
>
> Then you can't mean Debian GNU/Hurd.
?
Debian GNU/Hurd is about playing with Hurd politics.
Other Debian GNU/Linux people defend their Linux position and start
a debate. This is to be
>There is a major difference between the GNU/Hurd and all the
>Linux and BSD ports. We are creating a new os.
>
> I fail to see who exactly is creating a new OS.
Those people who are hacking the GNU Hurd and not playing Hurd
politics.
Then you can't mean Debian GNU/Hurd
This should put the whole stupid discussion to rest since the orignal
poster is incapable of reading the actual standard in question.
,[ FHS 2.3 ]
| Chapter 3. The Root Filesystem
|
| ...
| Distributions should not create new directories in the root
| hierarchy without extremely caref
> Debian GNU/Hurd will always be Debian GNU/Linux+translators. It
> will never use any of the nice things that the Hurd allows for
Could you be more precise? I don't see the point... What are these
nice things Debian GNU/Hurd won't use?
Top of the head: managing configuration files u
> /lib is for libraries, and is on the linkers library search
> path. It was a mistake for FHS to use it as broadly as it does,
> because that slows down linking and makes filesystem arrangement
> harder.
If the current use of /lib in the FHS is a problem, have proposal
been sent
> I think I can speak for all who care about the Hurd here, be it
> within Debian or not: We will NOT change /hurd to be somewhere
> else.
OK. If you have decided to be stubborn, just don't try to argue
that /hurd is FHS compliant. Just say you don't care about it.
We have decided
As not being mentioned in it, /hurd might be considered not
compliant to the FHS.
It is FHS compliant.
First, even if it is not the prefered solution, nothing prevents
a distributor from adding things in / that are not explicitly
described in the FHS.
It is the prefered
> Is it *REALLY* that important if there are two extra directories
> on GNU/Hurd?
It would just be very comfortable to newcomers in Hurd if things
were in standard places they have already learned about.
They are in standard places, /hurd and /servers. You obviously don't
get it do y
> Debian is not interested in creating a new operating system.
^^
Quoting http://debian.org/intro/about:
``The Debian Project is an association of individuals who have
made common cause to create a free operating system
My concern is moving away from Debian. I would like to stay w/ Debian.
Why do you have this concern?
Setting up a repository outside and external to Debian seems to
warrant an entirely new project name, not Debian GNU/Hurd. I would
not care to contribute to such a project at this time
You didn't know that people start hacking on the Hurd because you are
such a cutie pie?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How about attracting new developers, porting packages, having
something useful to work with for Hurd developers, etc?
That hasn't happened in the several years I have been around here.
People start hacking on the Hurd for other reasons. And you know that
quite well...
--
To UNSUBSCRIBE,
While I agree with most of what you wrote, I don't think "progress"
can be made within Debian, but what will happen is that things won't
go broken. And that is a good thing.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
That might not be a bad thing anyway, but it would be more work and
a change.
The work needed would be minimal, and I doubt you would need any
changes. There has always been a seperate archive where Debian
GNU/Hurd has put hacks.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subje
There is a major difference between the GNU/Hurd and all the Linux
and BSD ports. We are creating a new os.
I fail to see who exactly is creating a new OS.
I know you cannot mean Debian GNU/Hurd, since it is a second class
citizen within Debian and will _always_ be a second class citizen.
> [Hurd servers] are totally useles to have in PATH
But /lib/hurd is not in PATH, and the Hurd servers would perfectly
fit in there.
No they would not, they are not libraries. Please stop discussing
this issue.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscr
So what we need then are bug fixes. :) What are the crashes? I saw
messages about crashing during libc, but the talk was all about how
to reconfigure libc so it wouldn't crash when compiling...though we
shouldn't crash even for bogus compiles.
The crash happened since when compiling l
We do? Guillem and Michael are active DDs. Who else? Thomas is I
think. What about Marcus and Neal, are they both DDs?
Please don't count me to "we" if you just mean Debian.
The following people come to my mind: Thomas, Marcus, Michael, Jeff,
Roland (I think), Guillem, Neal (I think).
You really need to lighten up!
(a proper response might have been along the lines "Alfred, what have
you done lateley huh? When will you send those patches that you have
in your tree?", etc.)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL
>> "WE"??? Does that mean you are joining us again??
>
> Hrm.
I mean, let's see some code, some patches, some input man. We miss
you.. :-)
Where are your patches, Barry? Where is your code, Barry? Did you
give any input lately, Barry?
(and I agree about the missing bit...)
2. the architecture must be able to run a buildd 24/7 sustained
(without crashing)
3. the architecture must have an actual, running, working buildd
This, I think needs to be our target.
I think the "without crashing" is the only thing that needs the
target. Just compiling gl
Look, you have obviously not done your homework about the FHS or the
Hurd. So please get a clue about those two things before you bother
with this bullshit again.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
OK, would you mind explain me how it harms?
I explained it already. They are totally useles to have in PATH since
the only useful option you can pass to a translator is --help or
--version.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAI
We are compliant with FHS.
And even if we weren't we wouldn't change it anyway, since such
stupdity shouldn't exist in a standard in the first palce. Standards
are not rules that should be followed blindly nor can they contain all
"oddities" that one might come up with.
--
To UNSUBSCRIBE, e
GNU/Linux has it modules in /lib/modules/$kernel-version, so why
you do not the same for Hurd?
They are _programs_, not libraries.
I think I can speak for all who care about the Hurd here, be it within
Debian or not: We will NOT change /hurd to be somewhere else.
--
To UNSUBSCRIBE, emai
Translators are in that directory, you cannot start them (in most
cases) by just typing /hurd/TRANSLATOR. The only useles options to
them is --help/--version. Hence, they do not belong in /sbin or /bin.
s/useles/useful/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
> What the FHS calls "binaries" are only some executables on the
> Hurd; we have other executables that don't work like FHS
> "binaries", gotcha?
Sincerely, I'm not sure I see why it is needed to make a
difference. I may ask the question from a different point of view:
does it ha
But they are binaries that make the system work, so they would fit
in /sbin:
This is a useless way of arguing, ld.so.1 is a "binary
that make the system work", so is libc.so, and all files in /lib.
As I don't have (yet) a working Hurd system on one of my machines,
could someone list m
Why don't Hurd servers are in /sbin or /usr/sbin?
Because they don't belong there. /hurd is infact FHS compliant,
nothing prohibits a system distributor of introducing a new directory
in /.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAI
1 - 100 of 480 matches
Mail list logo
