On Mon, 23 Dec 2019 10:15:11 +
Jonathan de Boyne Pollard
wrote:
> Oliver Schad:
>
> > A booting tools should be in /bin - full stop!
> >
>
> That is historically untrue. The real world has not actually worked
> in the way that some people think.
Sorry, this is a historical explanation o
Oliver Schad:
A booting tools should be in /bin - full stop!
That is historically untrue. The real world has not actually worked in
the way that some people think.
* https://unix.stackexchange.com/a/448799/5132
However - what is the concrete suggestion from the Debian guys what
Laurent should do?
The Debian people are happy with putting execline binaries in a
separate
directory that is not in the default PATH. They don't see a problem with
that. And the thing is, nobody will notice a problem either
You can sling all the insults you want, but the fact is
... the fact is, I have explained this multiple times on this very list,
I am tired of seeing the same fallacy come up again and again, and I am
tired of repeating myself.
fine with me, as long as the distro cooperates. But if the distro
On Sun, 22 Dec 2019 23:20:03 +
"Laurent Bercot" wrote:
> >That being said, is having your stuff on the executable path such an
> >advantage?
>
> I don't know, why does Unix like to have its binaries in /bin? Why
> does PATH exist? What is the nature of an executable? You have two
> hours.
On Sun, 22 Dec 2019 23:20:03 +
"Laurent Bercot" wrote:
> I don't know, why does Unix like to have its binaries in /bin? Why
> does PATH exist? What is the nature of an executable? You have two
> hours.
Sorry, this discussion is crazy: Laurent provides a basic booting tools
with his toolchain
On the question of PATH for BSD land (FreeBSD, TrueOS, HardenedBSD et
al), binaries installed from packages (ports) live under /usr/local,
with the exception of /var and /tmp. The wars were fought and
/usr/local can easily be mounted read-only.
Of the 1446 packages I have installed (no deskto
That being said, is having your stuff on the executable path such an
advantage?
I don't know, why does Unix like to have its binaries in /bin? Why does
PATH exist? What is the nature of an executable? You have two hours.
December 2019 featured book: Rapid Learning for the 21st Century
Ah,
On Sat, 21 Dec 2019 23:46:34 +
"Laurent Bercot" wrote:
> No, you're falling for the pretext - because this is only the current
> pretext they're using. Debian *does not provide* a POSIX-compliant cd
> binary, so their claims at POSIX compliance are just lies.
> The current version of execline
On Sun, Dec 22, 2019 at 02:05:14AM +0100, Jan Braun wrote:
> > It doesn't help that neither Adam nor Jakub read the documentation for
> > the execline equivalents for cd, umask, or wait.
>
> Why would you say that? They effectively only claim that execline's
> cd/umask/wait binaries don't conform
Laurent Bercot schrob:
> No, you're falling for the pretext - because this is only the current
> pretext they're using. Debian *does not provide* a POSIX-compliant cd
> binary, so their claims at POSIX compliance are just lies.
Including execline's (non-compliant) cd would preclude them from
becom
Colin Booth schrob:
> > If you're referring to
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906250#37
> > then, well, you are fighting against POSIX. There's little choice for
> > Debian in the matter. Taking a hardline stance on such "legal" issues is
> > part of their identity as a distr
If you're referring to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906250#37
then, well, you are fighting against POSIX. There's little choice for
Debian in the matter. Taking a hardline stance on such "legal" issues is
part of their identity as a distro.
No, you're falling for the prete
On Sat, Dec 21, 2019 at 10:26:39AM +0100, Jan Braun wrote:
> > I hear you. Unfortunately, I have no control over what Debian does.
> > Debian isn't even able to ship a not-broken execline package, so I'm at
> > a loss on what to do with them. I'm working on a version of execline that
> > they *migh
El sáb., 21 dic. 2019 a las 6:26, Jan Braun escribió:
>
> > > 1) Debian ships with a working and maintained runit-init package.
> [...]
> > I hear you. Unfortunately, I have no control over what Debian does.
> [...]
> If you're referring to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906250
Steve Litt schrob:
> > From a Linux distribution perspective, there's also the question of
> > if s6 can be made a drop-in replacement for daemontools, [...]
>
> In my opinion, 99% of all people currently using daemontools are highly
> technically proficient and could easily either rename commands
Hey,
and sorry for taking so long to reply.
Laurent Bercot schrob:
> > 1) Debian ships with a working and maintained runit-init package. It
> >provides pid 1 and hooks into /etc/rcS.d/* to integrate with other
> >Debian packages. s6-linux-init and s6-rc are not packaged in Debian.
>
> I h
From a Linux distribution perspective, there's also the question of if s6 can be
made a drop-in replacement for daemontools, since it does follow djb's naming
scheme. In gentoo, there are various packages that depend on
virtual/daemontools; for example, the nullmailer test suite uses ipcserver. Fr
Samuel Holland:
Then, with the symlinks, s6 could "provide" virtual/daemontools.
I do this with the nosh toolset already, for Debian. Several of the
"shim" and "-run" packages, which are separate from the main tools
packages, "provide" stuff. I even have a things such as a dummy
"nosh-log
On Sun, Dec 01, 2019 at 09:47:52PM -0500, Steve Litt wrote:
> Would it be acceptable to you and them to put the binaries in /bin/s6
> and then very early in the boot add /bin/s6 to the path? This isn't a
> lot different from what djb did with /command, except it's not off the
> root, which everyone
On Mon, 2 Dec 2019 17:17:50 -0600
Samuel Holland wrote:
> On 12/2/19 3:32 PM, Laurent Bercot wrote:
> >> As a guy who has both daemontools and s6 installed on the same
> >> box, I thank you from the bottom of my heart for:
> >>
> >> 1) Prepending s6- to each command so they don't clash with djb's
On 12/2/19 3:32 PM, Laurent Bercot wrote:
>> As a guy who has both daemontools and s6 installed on the same box, I
>> thank you from the bottom of my heart for:
>>
>> 1) Prepending s6- to each command so they don't clash with djb's
>> 2) Except for the s6-, naming them the same as djb's so I have l
sure, that was just an idea for Jan, he could just create a dir somewhere,
populate it with symlinks he prefers to the original s6 tools and put this dir
in front of the PATH when running s6 since it seems the utilities do not bother
under what name they run.
Right, but I've heard enough people
Would it be acceptable to you and them to put the binaries in /bin/s6
and then very early in the boot add /bin/s6 to the path? This isn't a
lot different from what djb did with /command, except it's not off the
root, which everyone seems to hate.
s6 binaries aren't a problem for Debian; but a
30.11.2019, 19:58, "Laurent Bercot" :
>> the solution here could be a simple symlink to the original s6 tool without
>> the prefix if you prefer (maybe even located in an other dir than /bin).
>
> That would be a decision for users, not software authors - else it would
> defeat the point of not inv
As a test for portability for the 66 software, other than its display
case based on arch - called obarun - a couple of devs recently tried it
in a few distributions that have the s6 in their repository.
Funtoo was the first target
https://forum.obarun.org/viewtopic.php?id=956 and this was done by
Hi Steve,
Does the *user* need to code execline scripts, or is it just
something the program does? If the former, then make a point that one
doesn't need to use execline for s6-rc to be a very powerful startup
system.
No the user doesn't need to write execline scripts. The following
equally a
On Sat, 30 Nov 2019 10:15:27 +
"Laurent Bercot" wrote:
> I hear you. Unfortunately, I have no control over what Debian does.
> Debian isn't even able to ship a not-broken execline package, so I'm
> at a loss on what to do with them. I'm working on a version of
> execline that
> they *might*
the solution here could be a simple symlink to the original s6 tool without
the prefix if you prefer (maybe even located in an other dir than /bin).
That would be a decision for users, not software authors - else it would
defeat the point of not invading the namespace. Daemontools is still
aroun
30.11.2019, 11:15, "Laurent Bercot" :
> This is very interesting. I thought that having a s6- prefix was a *good*
> thing, because I valued clarity above everything, and especially above
> terseness. I understand the advantages of having commands named "sv" and
> "chpst", but I believed, in my naïv
As a relatively new convert to supervision software, my reasons for
preferring runit over s6 are, in order of priority:
Hi Jan,
Thank you a lot for this feedback. This is very useful UX return.
Let me address the points one by one.
1) Debian ships with a working and maintained runit-init p
31 matches
Mail list logo
