Scribit Marco Gerards dies 16/03/2005 hora 20:06:
May I ask you why you care that much about the FHS?
As an admin, I found it useful. Like many other standards, it avoids
that every single projet deal common problems in a way that is
incompatible with others (or just different, as far as
Scribit Pierre THIERRY dies 18/03/2005 hora 19:51:
If it's a frequenty asked question, why about putting a complete and
clean answser in the Hurd's FAQ, with pros and cons?
Here is a very quick first try for that answer:
FHS and /hurd?
As not being mentioned in it, /hurd might be
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.
Easily,
Nowhere man
--
[EMAIL
/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 to the FHS editors?
Pierre THIERRY [EMAIL PROTECTED] writes:
It would just be very comfortable to newcomers in Hurd if things were in
standard places they have already learned about.
Nobody has any settled expectation of where Hurd translators will be
found, well, sort of. Those who know about them expect to
Pierre THIERRY [EMAIL PROTECTED] writes:
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
Pierre THIERRY [EMAIL PROTECTED] writes:
/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
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
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 to
/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 to
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
Scribit Manuel Hoppe dies 15/03/2005 hora 18:56:
[wise to move /hurd to /srv/hurd]
But it's meant to be site-specific, and an administrator should be
able to wipe it without rendering the system unusable.
No, not at all. Eg. Apache rely on the existence of certain files and
directories at
FHS assumes that every program works from the shell. Hurd servers
don't really work from the shell.
Noone starts init on the shell, and it is in /sbin.
What the FHS calls binaries are only some executables on the Hurd;
we have other executables that don't work like FHS binaries, gotcha?
Pierre THIERRY, le mer 16 mar 2005 12:15:24 +0100, a dit :
FHS assumes that every program works from the shell. Hurd servers
don't really work from the shell.
Noone starts init on the shell, and it is in /sbin.
I start init on the shell: init 1, init q, ...
Regards,
Samuel
--
To
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 [EMAIL
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 me
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 harm to
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
Hey,
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 /.
What is with /lib/hurd or /lib/servers? GNU/Linux has it modules
in
Pierre THIERRY [EMAIL PROTECTED] writes:
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
Pierre Gillmann [EMAIL PROTECTED] writes:
What is with /lib/hurd or /lib/servers? GNU/Linux has it modules
in /lib/modules/$kernel-version, so why you do not the same for Hurd?
They are not libraries.
In fact /hurd is very easy to use, but if there are same problems with
the FHS, it will be
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,
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,
Scribit Thomas Bushnell BSG dies 16/03/2005 hora 09:45:
What is with /lib/hurd or /lib/servers? GNU/Linux has it modules in
/lib/modules/$kernel-version, so why you do not the same for Hurd?
They are not libraries.
Nor are the kernel modules in Linux... Thus, quoting the FHS:
``/lib :
Scribit Thomas Bushnell BSG dies 16/03/2005 hora 09:45:
does it harm to respect FHS and put what is in /hurd in /sbin and
/usr/sbin?
We are not disrespecting FHS, and yes, it does harm.
OK, would you mind explain me how it harms? Or just give me the
reference to the FM where it is explained.
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 [EMAIL
Pierre THIERRY [EMAIL PROTECTED] writes:
Scribit Thomas Bushnell BSG dies 16/03/2005 hora 09:45:
What is with /lib/hurd or /lib/servers? GNU/Linux has it modules in
/lib/modules/$kernel-version, so why you do not the same for Hurd?
They are not libraries.
Nor are the kernel modules in
Pierre THIERRY [EMAIL PROTECTED] writes:
As the Hurd works with a -kernel, the Hurd servers do precisely what,
in Linux, the loadable modules do, and they are in /lib.
No, they don't. Kernel modules are very close to shared libraries,
which is why they are in that directory.
It's not as
Pierre THIERRY [EMAIL PROTECTED] writes:
Scribit Thomas Bushnell BSG dies 16/03/2005 hora 09:45:
does it harm to respect FHS and put what is in /hurd in /sbin and
/usr/sbin?
We are not disrespecting FHS, and yes, it does harm.
OK, would you mind explain me how it harms? Or just give
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]
[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.
Easily,
Nowhere man
--
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
[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
It does not fit perfectly (and it does not fit at all) because /lib is
for libraries, not for executables. Translators are executables (that
don't belong in PATH). Let the vicious circle stop.
On Wed, 16 Mar 2005 21:54:20 +0100, Pierre THIERRY
[EMAIL PROTECTED] wrote:
[Hurd servers] are
, 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.
/hurd is FHS compliant, so we put it there.
Why don't you explain why you care about this, since it isn't FHS
compliance
Thomas Bushnell BSG wrote:
I was wondering why the /hurd directory exists. I googlized a bit about
Hurd and the FHS, and didn't found really enlighting documentation about
that particular point.
Why don't Hurd servers are in /sbin or /usr/sbin? If I understand
correctly, they just are userland
Scribit Thomas Bushnell BSG dies 14/03/2005 hora 23:38:
Why don't Hurd servers are in /sbin or /usr/sbin? If I understand
correctly, they just are userland programs like any other, aren't
they?
They are not programs that are usefully run (normally) from the shell,
so they should not be in
Isn't it better to put it in /srv/hurd? That should be a better place
for this imho.
``/srv contains site-specific data which is served by this system.''
It's not for the servers, but for what they serve.
Quickly,
Nowhere man
--
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A
signature.asc
Hi Pierre!
On Tue, March 15, 2005 11:34, Pierre THIERRY said:
Isn't it better to put it in /srv/hurd? That should be a better place
for this imho.
``/srv contains site-specific data which is served by this system.''
It's not for the servers, but for what they serve.
Indeed, it's content
Pierre THIERRY [EMAIL PROTECTED] writes:
But they are binaries that make the system work, so they would fit in
/sbin:
``/sbin contains binaries essential for booting, restoring,
recovering, and/or repairing the system''
As I don't have (yet) a working Hurd system on one of my
Indeed, it's content related, but it's not limited for only this
purpose.
But it's meant to be site-specific, and an administrator should be able
to wipe it without rendering the system unusable.
Quickly,
Nowhere man
--
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A
signature.asc
Description: Digital
Nota bene: no need to CC me, as I'm a subscriber of this list.
Thanks,
Nowhere man
--
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
Hi Pierre!
On Tue, March 15, 2005 18:04, Pierre THIERRY said:
[wise to move /hurd to /srv/hurd]
But it's meant to be site-specific, and an administrator should be able
to wipe it without rendering the system unusable.
No, not at all. Eg. Apache rely on the existence of certain files and
Pierre THIERRY [EMAIL PROTECTED] writes:
Nota bene: no need to CC me, as I'm a subscriber of this list.
No one will bother to check if you are subscribed or not. Personally
I won't respond to emails in which people ask not to send a CC (this
is just an exception). AFAIK CC'ing is normal
On Tue, Mar 15, 2005 at 09:27:00PM +0100, Marco Gerards wrote:
AFAIK CC'ing is normal behavior on every mailinglist.
It is not on Debian lists.
Personally, I don't have a problem with being CC'd (though I find it
useless most of the time), and I CC new faces on the list until I'm sure
they
I was wondering why the /hurd directory exists. I googlized a bit about
Hurd and the FHS, and didn't found really enlighting documentation about
that particular point.
Why don't Hurd servers are in /sbin or /usr/sbin? If I understand
correctly, they just are userland programs like any other,
Pierre THIERRY [EMAIL PROTECTED] writes:
I was wondering why the /hurd directory exists. I googlized a bit about
Hurd and the FHS, and didn't found really enlighting documentation about
that particular point.
Why don't Hurd servers are in /sbin or /usr/sbin? If I understand
correctly, they
46 matches
Mail list logo
