C != Java
Which is to say, a null pointer is not a valid argument to unlink, and the
Hurd's use of a signal instead of an error is allowed by Posix.
Thomas
On Jan 14, 2012 8:48 AM, Steven McDonald steven.mcdon...@libremail.me
wrote:
Hi,
I've been looking at the problems with visudo as
A hurd ioctl has to also have something which documents the exact structure
layout in a way that the library can use to reformat it into a Mach
message. That's what the _IOT_foo thing would be. Since it's missing, the
_IOW call fails.
Some ioctls can't be represented, for various reasons, and
Cheroot isn't supposed to change the namespace of Unix domain sockets in the
case where the chroot shares a file with the main system.
On Jun 2, 2011 6:56 PM, olafbuddenha...@gmx.net wrote:
Hi,
On Tue, May 31, 2011 at 09:35:32AM +0200, Samuel Thibault wrote:
You just need another partition,
Yes. Timers do create new threads to wait for the event in question, and
then they send the signal in the normal way.
On May 10, 2011 11:18 AM, Richard Braun rbr...@sceen.net wrote:
But it would be a nice feature to add. Each filesystem could report the
filesystems mounted on it, and df could walk that tree.
On Mon, Apr 11, 2011 at 1:06 PM, Patrik Olsson p...@xaci.be wrote:
On 11/04/11 21:40, startx wrote:
hello.
as another long time reader on this list (several
On Mon, Aug 9, 2010 at 1:55 PM, olafbuddenha...@gmx.net wrote:
Originally the Hurd was meant to be binary compatible with BSD BTW; but
this is no longer relevant...
That idea died so long ago the ashes aren't even visible.
Thomas
On Thu, 2008-08-14 at 18:35 +0200, Joerg Jaspert wrote:
As both of your architectures are affected by the first rule (m68k
missed etch and will miss lenny, hurd never had a release), it is time
for us to think about the best possible way for you to move elsewhere,
like debian-ports.org. We (as
On Tue, 2008-01-01 at 04:10 +, Samuel Thibault wrote:
Thomas Bushnell BSG, le Thu 27 Dec 2007 18:06:39 -0800, a écrit :
Now, that said, we'd have to modify libc's gnu/stubs.h to also include
a gnu/stubs-pthread.h provided by the hurd's libpthread.
Yes, certainly, or at least
On Fri, 2007-12-28 at 01:14 +, Samuel Thibault wrote:
Thomas Bushnell BSG, le Mon 24 Dec 2007 15:45:17 -0500, a écrit :
On Sun, 2007-12-23 at 21:53 +0100, Samuel Thibault wrote:
Thomas Bushnell BSG, le Fri 21 Dec 2007 21:10:12 -0500, a écrit :
We are supposed to gave libc #defines
On Fri, 2007-12-28 at 02:04 +, Samuel Thibault wrote:
Actually, it happens that in the pike7.6 case, it doesn't, because its
configure.in doesn't use AC_CHECK_FUNCS for that function. Yes, that's
evil, but that's unfortunately what people do.
So then they get what they deserve. :)
Now,
On Sun, 2007-12-23 at 21:53 +0100, Samuel Thibault wrote:
Hi,
Thomas Bushnell BSG, le Fri 21 Dec 2007 21:10:12 -0500, a écrit :
We are supposed to gave libc #defines that say that a function is a stub
when it just returns ENOSYS, which configure checks for. Or something
like
On Sat, 2007-12-22 at 01:35 +, Samuel Thibault wrote:
Hello,
At least in pike7.6, ./configure detects pthread_atfork() and then the
resulting program uses it, and fails because for now our implementation
is
return ENOSYS;
If we weren't providing the function, pike would manage to
On Mon, 2007-08-20 at 10:38 +0200, Samuel Thibault wrote:
Hi,
Thomas Bushnell BSG, le Mon 20 Aug 2007 00:26:47 -0400, a écrit :
1: I think it should be raised in gnumach itself, not just in the Debian
version.
Well, it's the same for THREAD_MAX, TASK_MAX, etc.. ;)
Yes, of course
On Mon, 2007-08-20 at 02:52 +0200, Samuel Thibault wrote:
Samuel Thibault, le Mon 20 Aug 2007 02:18:44 +0200, a écrit :
Samuel Thibault, le Mon 20 Aug 2007 02:06:18 +0200, a écrit :
int vm_object_cached_max = 200;/* may be patched*/
We should probably raise it in
Philip Charles [EMAIL PROTECTED] writes:
Once sarge is released could we get the d-i team to start looking at
incorporating Debian GNU/Hurd into the installer?
My expectation is that members of the debian-hurd team will be
expected to do the lion's share of the actual work, but that the d-i
Alfred M. Szmidt [EMAIL PROTECTED] writes:
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
Alfred M. Szmidt [EMAIL PROTECTED] writes:
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 for
Thread moved over to bug-hurd since it's about design and not Debian
GNU/Hurd per se. Alfred Szmidt had pointed out that a dpkg
installation translator (one where you copy a .deb into a directory to
install it into the system) cannot be easily written, because Debian
package installation scripts
Alfred M. Szmidt [EMAIL PROTECTED] writes:
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.
They've already created Debian GNU/Linux. The point of
Pierre THIERRY [EMAIL PROTECTED] writes:
Scribit Michael Banck dies 19/03/2005 hora 02:59:
Bad idea.
Why?
Because a better way is to support negative archs. Listing all archs
but one in Architecture: lines is a Bad Thing in Debian, it's a last
possible resort. It's much better, for
Alfred M. Szmidt [EMAIL PROTECTED] writes:
Top of the head: managing configuration files using a translators by
default. Using unionfs to eliminate /usr. Redesining the package
format so one can use a translator to install/remove packages.
/share/info/dir managed by a translator. I could
Alfred M. Szmidt [EMAIL PROTECTED] writes:
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
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
Alfred M. Szmidt [EMAIL PROTECTED] writes:
What Debian GNU/Hurd will be is Debian GNU/Linux + translator support,
and a easy way for people to try the Hurd, without all the nice
things. Debian is not interested in creating a new operating system.
That's fine. I'm not out here to say that
Marco Gerards [EMAIL PROTECTED] writes:
But doing this because the bureaucracy wants it seems like a silly
reason to me. I am considering writing a new pfinet from scratch
because the current one really sucks, in my opinion. If we want
firewall support it should be in the new pfinet, IMHO.
Marcus Brinkmann [EMAIL PROTECTED] writes:
I have considered a Debian port outside of Debian a couple of years
ago very carefully, for some reasons. And it is not an easy task, if
you want to do it properly. There is a major difference between
having a couple of extra packages on a server,
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
Some changes to the way Debian manages its archive and releases
architectures may be in the works. Most of this doesn't affect Debian
Hurd because we aren't a release architecture anyway.
Architectures which are not released or have low download rates will
be hosted on a separate archive; this
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
Barry deFreese [EMAIL PROTECTED] writes:
WE??? Does that mean you are joining us again??
Hrm.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Alfred M. Szmidt [EMAIL PROTECTED] writes:
How is one supposed to demonstrate that a port has atleast 50 users by
the way?
Popularity-contest is one way. Another is just asking them.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Barry deFreese [EMAIL PROTECTED] writes:
Yes, that is going to be a tough one. I was hoping to use my new box
with an 80Gb drive but it has been very unstable.
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
Barry deFreese [EMAIL PROTECTED] writes:
We do? Guillem and Michael are active DDs. Who else? Thomas is I
think. What about Marcus and Neal, are they both DDs?
I am, and Marcus is.
There's 4. I would like to throw my name in the NM queue but that
might take a while. Who else?
Pierre THIERRY [EMAIL PROTECTED] writes:
[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.
They would fit in /usr/share/unrelated too. But we chose /hurd as
being more descriptive. /lib is for libraries, and
Marc Dequnes (Duck) [EMAIL PROTECTED] writes:
Asking for having one of the autobuilder's pool always up should be a
sufficient criteria ; we could acheive that and push this modified
criteria to the release-team draft.
Ok, I'll see if I can get that going.
Marcus Brinkmann [EMAIL PROTECTED] writes:
I am not even trying to comprehend where these rules come from, or
what their sanity is. I am just going to accept whatever comes out of
the Debian cabal as long as I can morally accept it.
See debian-devel.
Does this mean eternally, or only for
Michael Banck [EMAIL PROTECTED] writes:
To be precise, we were a 'second class citizen' for all the time. So in
case we manage to stay at that level for the time being, we might even
profit from it. E.g. unstable snapshots look very much like what Philip
Charles did with the CD releases in
Here's one fellow's interpretation of that requirement.
---BeginMessage---
On Mar 17, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
One of the conditions for SCC is fully functioning Unix, including
DNS and firewall support. What specifically is intended by firewall
support?
I
Philip Charles [EMAIL PROTECTED] writes:
There is a major difference between the GNU/Hurd and all the Linux and
BSD ports. We are creating a new os.
Right, but it wouldn't be unfair for Debian to say that the purpose of
Debian is something else. So we can use the Debian infrastructure,
but
Philip Charles [EMAIL PROTECTED] writes:
Generally agree, but I think that the decision about GNU/Hurd should be
made on the basis of it being a new os under development, and not the
criteria set up for mature os's and their ports.
Can you offer specific criteria that will ease their fears
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
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
Alfred M. Szmidt [EMAIL PROTECTED] writes:
Bollocks, it isn't important to GNU/Hurd nor does it _need_ it, since
it doesn't follow the philosophy of GNU. It might be important to
Debian GNU/Hurd, but if you meant that then say so.
I'm not suce which philosophy of GNU you mean. It is true
Ron Graves [EMAIL PROTECTED] writes:
-rwsr-sr-x1 root root 7828 Apr 28 11:23 X
The 's' is a 'stickybit', right? Is this something Hurd needs? Can I chmod
+x X, without causing any grief.
Right now it's ignored, but we may well in the future have VM handling
pay attention to
Ron Graves [EMAIL PROTECTED] writes:
Still, why would you want to turn it off, since we may in the future
take it as some kind of VM preferencing hint?
I can't 'startx' as an unprivileged user. Not knowing the purpose
of 's', and comparing permissions of my working Debian GNU/Linux
[EMAIL PROTECTED] writes:
So, should settrans refuse to set a translator if the
translating program (in this case /dev/hd1s1) is not executable
or is there any reason not to do this?
It seems reasonable to make it refuse unless you give it a -f
option; or perhaps prompt
Wolfgang Jaehrling [EMAIL PROTECTED] writes:
So, should settrans refuse to set a translator if the translating
program (in this case /dev/hd1s1) is not executable or is there any
reason not to do this?
It seems reasonable to make it refuse unless you give it a -f option;
or perhaps prompt for
Jonathan Daugherty [EMAIL PROTECTED] writes:
That's interesting; is it some kind of FIFO, which fills with messages
but whose contents are not maintained internally?
Yes; that's standard. It's supposed to be read by syslog under normal
circumstances.
Thomas
Marco Gerards [EMAIL PROTECTED] writes:
Perhaps this has something to do with forgetting to put swap in
/etc/fstab after installing this system, but it should not happen
because I have 390MB RAM. Please test this. I have used bonnie++ for
this (it is in debian).
You can only make that
Georg Lehner [EMAIL PROTECTED] writes:
- One promise of the microkernel architecture is better performance on
multiprocessor systems, or multicomputer systems. What is the status
of Gnu Mach with respect to these.
This may or may not be true. The Hurd is built around a microkernel
Johannes Rohr [EMAIL PROTECTED] writes:
Alfred M. Szmidt [EMAIL PROTECTED] writes:
How do you access this `login' shell from remote?
See the login prompt when you login? That is the login shell, it is
just a normal shell that is running as an anonymous user (see the
output of
Alfred M. Szmidt [EMAIL PROTECTED] writes:
Why do I feel like repeating this old mantra: Bad security is worse
than no security.
Sez you. Many disagree. Especially for a system in development, with
already has bad security.
Fine, would you like to work on this? Or do you
[EMAIL PROTECTED] (Niels Möller) writes:
The argument is really simple. Programs that use /dev/urandom
generally expect to get numbers that are not only uniform, but numbers
which are actually *useful* for *cryptographic* purposes. Creating a
/dev/urandom that does something different is
[EMAIL PROTECTED] (Neal H. Walfield) writes:
Why do I feel like repeating this old mantra: Bad security is worse
than no security.
Sez you. Many disagree. Especially for a system in development, with
already has bad security.
I think that we can all accept that there are
Alfred M. Szmidt [EMAIL PROTECTED] writes:
Telnet has worse security than even a buggy miserably fake ssh.
Telnet has _no_ security. It doesn't have fake security, which you
get by using crappy random bits and Open SSH. That is a huge
difference. Open SSH was designed for security,
Alfred M. Szmidt [EMAIL PROTECTED] writes:
I think that we can all accept that there are currently a variety of
security holes in the Hurd. The type of security holes which would be
introduced by using bad random data, however, is far worse as it has
the potential to allow an
Alfred M. Szmidt [EMAIL PROTECTED] writes:
Telnet has worse security than even a buggy miserably fake ssh.
Telnet has _no_ security. It doesn't have fake security, which you
get by using crappy random bits and Open SSH. That is a huge
difference. Open SSH was
Alfred M. Szmidt [EMAIL PROTECTED] writes:
Please, could you bother reading my mails even for a small amount of
time? I have _not_, I repeat, _not_ suggested the removal of Open SSH!
If our only alternatives are
1) no ssh
2) ssh with no security
you have advocated (2), right? It is that
Alfred M. Szmidt [EMAIL PROTECTED] writes:
If our only alternatives are
1) no ssh
2) ssh with no security
you have advocated (2), right? It is that statement which I am
arguing against.
No, I have advocated against including a unsecure random translator.
You are
[EMAIL PROTECTED] (Neal H. Walfield) writes:
If our only alternatives are
1) no ssh
2) ssh with no security
Wrong, which just proves that you have not read this thread: we are
arguing about entropy; ssh is only a side argument.
*IF*. Can you read the word *IF*?
The proposition was
[EMAIL PROTECTED] writes:
tcpdump needs live packet capture, and whatever that is, we don't have it.
Yes, Marcus, I realized it from the error message.
But my question is:
- tcpdump: live packet capture not supported on this system
what does this term live packet capture mean?
Alfred M. Szmidt [EMAIL PROTECTED] writes:
Why do I feel like repeating this old mantra: Bad security is worse
than no security.
Sez you. Many disagree. Especially for a system in development, with
already has bad security.
Alfred M. Szmidt [EMAIL PROTECTED] writes:
Ssh should provide a non-cryptographically secure mode (such as
using hashes of the low time bits, for example) for use on systems
without a real random bit source.
What Open SSH should do and not do, should be discussed on the Open
SSH
Moritz Schulte [EMAIL PROTECTED] writes:
Michal 'hramrach' Suchanek [EMAIL PROTECTED] writes:
- the separation of partitions should be solved by union(shadow)fs
and not directories
I have one doubt about using a unionfs as root filesystem:
performance.
Why do you think it would
Alfred M. Szmidt [EMAIL PROTECTED] writes:
Without ext2fs the system is completly unusable, without random the
system is quite usable. Without GNU Mach you don't even have a
working system.
But you said that bad security is worse than no security. So better
no GNU Mach than an insecure one,
Jeff Bailey [EMAIL PROTECTED] writes:
On Tue, Dec 17, 2002 at 11:07:35AM -0800, Thomas Bushnell, BSG wrote:
Without ext2fs the system is completly unusable, without random the
system is quite usable. Without GNU Mach you don't even have a
working system.
But you said that bad
Alfred M. Szmidt [EMAIL PROTECTED] writes:
Really, I don't think we delete packages just because we have bugs.
We have *lots* of bugs, and it's inappopriate to remove packages as
if we were a production system.
Delete what exactly? We were talking about _adding_ a package.
The
Alfred M. Szmidt [EMAIL PROTECTED] writes:
I agree that we should not have a fictitious /dev/urandom, but we
should support ssh even so.
Open SSH is supported, in an insecure way, by either a random
translator, or the copying hack.
Ssh should provide a non-cryptographically secure
[EMAIL PROTECTED] (Neal H. Walfield) writes:
ext2fs should be quite robust: Even pulling the plug at any time should not
corrupt the filesystem beyond what e2fsck can repair.
Let us assume that ext2fs writes a block of metadata to disk. In the
kernel, in the middle of the DMA operation,
[EMAIL PROTECTED] (Neal H. Walfield) writes:
Disk hardware guarantees that a sector write can always be completed
even if the power goes out partway through. That means that writing a
single sector *is* always atomic.
The size of a single sector does not necessarily equal the size of of
Marcus Brinkmann [EMAIL PROTECTED] writes:
On Mon, Dec 16, 2002 at 08:32:18PM -0500, Neal H. Walfield wrote:
Disk hardware guarantees that a sector write can always be completed
even if the power goes out partway through. That means that writing a
single sector *is* always atomic.
Philip Charles [EMAIL PROTECTED] writes:
The typescript of an fsck. A mild corruption. A full scale corruption
means that the floppy cannot be mounted or the network setup. The
typescript itself is rather scrambled.
You mention a floppy. Are you popping the floppy out in mid-write?
The
Jeff Bailey [EMAIL PROTECTED] writes:
In fact, I think I presented clearly that *I* thought that there might
be value in eliminating sbin iff it could be shown that a very high
percentage of the utilities were useful to a competent user.
I think that consistency with GNU/Linux systems is such
Jeff Bailey [EMAIL PROTECTED] writes:
It's questionable that they should be artificially hidden in the first
place, but hey. =)
The purpose of /sbin is not to hide anything, but to avoid
cluttering users' command namespace with commands they can't usefully
ever use.
Jeff Bailey [EMAIL PROTECTED] writes:
My point was that if we can reasonably show that on a GNU/Hurd system
that most (say 90-95%?) of the commands in sbin would be reasonable for
a power user to use there is probably value in just having that in the
general users path.
You seem to be
Robert Millan [EMAIL PROTECTED] writes:
On Sat, Nov 09, 2002 at 01:57:31PM -0500, Richard Kreuter wrote:
Also, unfortunately, at the moment, the body of FHS requires mkfs,
fsck, et al. in /sbin, if these files exist on a system (section
3.14.2), so Debian GNU/Hurd may need to provide
Marcus Brinkmann [EMAIL PROTECTED] writes:
The only standard that is applicable here is that of the IA32
architecture and the peripherial devices, not all of those latter are well
standardized. As the Hurd certainly runs on an IA32 machine (it runs on
mine!), any problem of running it inside
[EMAIL PROTECTED] (Alfred M. Szmidt) writes:
I really would like to know who everyone is here, there are already a
couple questions about Daniel's response to me on the FHS list about
not a distribution is not allowed to add root-level directories.
Sorry, I can't even parse that.
For
Roger Leigh [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
Jeff Bailey [EMAIL PROTECTED] writes:
The issues is that by Debian policy, all Debian ports must follow the
FHS. The same is true of the FreeBSD and NetBSD ports (I only noticed
this because
[EMAIL PROTECTED] (Alfred M. Szmidt) writes:
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
1) What gets added to the FHS is not a Debian decision,
2) Debian released architectures need to conform to FHS, and
3) Ports still being worked on don't need to treat (2) as their top
Jeff Bailey [EMAIL PROTECTED] writes:
The issues is that by Debian policy, all Debian ports must follow the
FHS. The same is true of the FreeBSD and NetBSD ports (I only noticed
this because of the patch to support FreeBSD).
Certainly after */libexec is added into the FHS, we can add it
Jeff Bailey [EMAIL PROTECTED] writes:
I didn't really follow the earlier discussions on this - Can you
remind me what mailing list it was on? The idea of libexec being in a
Hurd annex seems silly (and something a committee would be unlikely to
accept if we were storing anything other than
Yantis Green [EMAIL PROTECTED] writes:
The rapture is coming soon!! Where are you headed!!
Geez, if it's that much an emergency, you'd think you'd help us finish
our software project before time runs out.
Niklas Höglund [EMAIL PROTECTED]@MIT.EDU writes:
Users can maintain the groups themselves, so one member in the club can
maintain that group if it is named user_a:club, but I don't think the
group management can be shared, and one user would own the group.
A group can own another group, in
Guillem Jover [EMAIL PROTECTED] writes:
While porting util-linux i've found that in the Hurd there is no define
for TABDLY and TAB3 when including termios.h. I've looked the SUSv2 and
SUSv3 drafts and it mentions this two defines. Also XTABS is defined, but not
mentioned in the drafts.
Anthony Towns aj@azure.humbug.org.au writes:
I'm sorry, but you simply do not get to have it both ways. Either Linux
systems are an implementation of the GNU system that happens to have a
Linux kernel, or GNU/Linux is an entirely unjust publicity stunt to
promote a completely separate system.
Yann Forget [EMAIL PROTECTED] writes:
So, I managed to install it alright, ... but I can't boot it !!!
Do you have a bug report to give?
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
HAESSIG Jean-Christophe [EMAIL PROTECTED] writes:
This is all about modifying the FHS...
Yes, but not on this list. This is not the appropriate place to
discuss FHS modifications.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Anthony Towns aj@azure.humbug.org.au writes:
*shrug* I haven't seen anything in a year and a half to convince me
that the Hurd has something else that can replace firewalling tools,
and they've only become a more standard part of OS security in that time.
Since we are so totally far away from
Anthony Towns aj@azure.humbug.org.au writes:
It's not what the hack does that matters, it's the quality of it. If
you don't leave time for it to be tested, there's no way I'm going to
have faith in it.
And we are so far away from release that discussing now whether to do
such a hack is
Lars Weber [EMAIL PROTECTED] writes:
Is this also true for passive translators? Do they also not store the
path to the translator executable (as I've thought until now) but a direct
reference to the file instead? If so, what would happen if the translator
is replaced by a newer version for
Oystein Viggen [EMAIL PROTECTED] writes:
Experiment:
$ cp /hurd/null somedir/
$ settrans somedir somedir/null
$ cat somedir
If translators within directories within translators worked, cat somedir
would return nothing, just the same as cat /dev/null. On my system, cat
would hang,
Emile van Bergen [EMAIL PROTECTED] writes:
Ok, but it's a bit of a pity IMHO that you bring this up when we're
getting at what I thought was the heart of the matter, something that
could be used to amend the Debian policy in a good, general way:
When do you think, *in general*, that new
Anthony Towns aj@azure.humbug.org.au writes:
Firewalling tools are provided with the Debian system.
Firewalling tools are not available for Debian GNU/Hurd.
Debian GNU/Hurd will not be released until they are available.
I think that it is foolish to insist on this. Router firewalling
Lars Weber [EMAIL PROTECTED] writes:
All this talk about reasons for using `/hurd' got me wondering: Do there
exist potential problems when a translator that translates a certain
directory is itself located somewhere inside that directory?
There aren't any such problems (hidden ones, at
Anthony Towns aj@azure.humbug.org.au writes:
Hrm? Why are you typing /hurd/foo in your settrans command instead of
/servers/foo then? What's /servers for?
Speaking in Unix speak which is somewhat inaccurate, but gets the
basic idea across:
/servers is a set of standard names for mount points
1 - 100 of 289 matches
Mail list logo
