date:20150925

Laurent Bercot  writes:
> On 25/09/2015 17:29, Simon Hobson wrote:

[...]

>> Of course, regardless of what system or definitions you use - if a
>> service then dies then you have a problem. IMO, "it might die at some
>> indeterminate time" isn't an excuse for not trying to get the "start
>> stuff up" part right.
>
>  Apparently Rainer disagrees with that, and seems to think that since
> you can't get a 100% reliable system, it's useless to get the common
> case working as smoothly as possible. I've stopped trying to convince
> him.

Since this is not some technical statement but one about me, I think I
have to address it somehow: We weren't discussing whether or not "get
the common case working as smoothly as possible" makes sense[*] but I
asked for examples of real 'server dependencies' where performing a
topological sort in order to work out a (partial) order for 'starting
servers' would be technically useful. In my opinion, this cannot be
because 'starting the server at time X' is a necessary but not a sufficient
precondition for 'server will serve requests at time Y, Y > X'. The
situation is also going to sort itself out quickly, that is, within
seconds and a system will spend most of its lifetime with being in some
sort of steady state performing whatever its function happens to be, not
with "being started".

[*] In this generality, such a discussion seems useless to me: Eg, the
common case for a human being is that it can read and write Chinese,
hence, use of any other system of writing ought to be avoided.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems

Simon Hobson  writes:

[...]

> Rainer Weikusat  wrote:
>
>>> * anything that uses the syslog should start after the syslog.
>> 
>> That's the same misunderstanding already shown elsewhere: Starting
>> syslog at time X and starting syslog-user at time Y, Y > X, Y - X being
>> 'very small', does not guarantee syslog will already be available at
>> time Y and neither that it will still be available provided it became
>> available in the time interval between X and Y.

[...]

> Of course, regardless of what system or definitions you use - if a
> service then dies then you have a problem. IMO, "it might die at some
> indeterminate time" isn't an excuse for not trying to get the "start
> stuff up" part right.

There is a way to get this wrong, namely, don't ever start the
server. In this case, failure is guaranteed. But there's no way to get
it "right" in the sense of "there's some kind of algorithm execution of
which guarantees success": No matter if you start syslog first, last, or
at some random position in a sequence of server start, it might or might
not be ready by the time some other program tries to use it. If some
program must not continue beyond the point where it tries to log a
message unless the message is (at least) received by a logging process,
some form of explicit locking has to be used to ensure that.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Dng Digest, Vol 12, Issue 79

2015-09-25 Thread aitor_-czr

All projects are instructive.

This is a little instructive project.

My2Cents.

Aitor.

El 25/09/15 a las 18:51, Hleb Valoshka <375...@gmail.com> escribió:

On 9/21/15, Edward Bartolo  wrote:

>Since netman is effectively ready, and I can still offer my coding
>services to the Devuan project, I would like to ask what task should I
>take as my second attempt at helping with the project?

If your possible next project will look like netman then please do
nothing. It's a lowest quality project I've ever seen. It looks really
bad. You better read a good book about software architect.

I don't see any reason to throw away wicd and replace it with your tool.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems


On 25/09/2015 17:29, Simon Hobson wrote:

Windows and MacOS both prioritise those tasks needed to get a desktop
picture (or login prompt) on the screen - as that gives the illusion
of fast boot time.


 Oh, yes, definitely. (My client machine runs Windows, and I experience
that every day.)
 It does not mean the dependencies are broken, though: if you can
actually display a desktop early on in the initialization process,
without stuff breaking, why not do so? It's only cheating if you
pretend the initialization is over at this point. Of course,
vendors are dishonest and incite the consumer to think the system
is ready when the desktop is there, but technically speaking,
unless something fails when you try to launch a program from the
desktop, it's not dependency mismanagement.



it's not worth trying to do anything until all the background stuff
is at least well past it's peak !


 Yes, it would be more honest to have a small console in the corner of
the desktop that displays everything the system is doing, and users
would know to avoid launching heavy programs until the console has
stopped scrolling.
 I'm just afraid that with Windows, the console would *never* stop
scrolling. XD



That all hinges around what is meant by "start service A". If "start
service" means nothing more than "kick off a process that'll run it"
then you are completely correct. On the other hand, if "start
service" actually means a process which is only deemed to be complete
when it's running and ready to go to work then that's a different
matter.


 That is the point of readiness notification.

 Traditional rc systems consider that the service is ready when the
process that has launched it dies. This is correct for oneshot
services (barring a few exceptions). This is not the case for longrun
services, unless the daemon can notify its readiness and the launching
script takes advantage of that; but few sysv-rc - or OpenRC - scripts
actually bother doing this, so their dependency management is actually
incorrect.

 systemd supports readiness notification, in its own over-engineered
way, but doesn't even get it right: see http://ewontfix.com/15/

 s6-rc uses the hooks provided by s6 to correctly handle readiness
notification.



Of course, regardless of what system or definitions you use - if a
service then dies then you have a problem. IMO, "it might die at some
indeterminate time" isn't an excuse for not trying to get the "start
stuff up" part right.


 Apparently Rainer disagrees with that, and seems to think that since
you can't get a 100% reliable system, it's useless to get the common
case working as smoothly as possible. I've stopped trying to convince
him.



Taking the example of syslog - if it dies
(regardless of when, whether it's seconds or days after system start)
then you are going to lose logging. You can try and manage that (spot
the problem and deal with it automatically), but short of predicting
the failure in advance, there will always be a window during which
logging can be lost.


 No, you don't have to lose logs if you're maintaining the logging
file descriptor open and your new logger instance can actually reuse
it. In that case, logs simply accumulate in the kernel buffer
(blocking the client if the buffer fills up), until the logger restarts
and can read it.
 I call this "fd-holding", and it is precisely the only thing of value
that systemd's "socket activation" brings. On that point, systemd
actually does something better than traditional rc systems.

 s6-rc, and even just s6, also performs fd-holding for loggers. The
system creates a pipe from a service to its logger and maintains
it open, so you never lose logs either. You get the useful feature,
but not the surrounding socket activation crap.

--
 Laurent
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems

2015-09-25 Thread Hendrik Boom

On Fri, Sep 25, 2015 at 03:59:19PM +0200, Laurent Bercot wrote:
> On 25/09/2015 09:05, Simon Hobson wrote:
> 
> 
> >There's nothing that gets people impatient
> >better than something that appears to be taking a long time "doing
> >nothing" !
> 
>  Show them a terminal with a lot of scrolling gibberish! That should
> convince them that 1. the computer is actually doing something, and
> 2. the uninitiated should not be questioning what it is doing or the
> time it takes - they should shut up and worship! ;)

This has always worked for me!  It bothers me when the gibberish is 
hidden behind a pretty piture. 

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems

2015-09-25 Thread Simon Hobson

Laurent Bercot  wrote:

> On 25/09/2015 09:05, Simon Hobson wrote:
>> More to the point, I'd rather have reliability over speed any day.
> 
> How about you get both?

Well yes, that's better still.

> The dichotomy is a false one. People believe they can't have both
> because init systems have never been done right so far, and always
> forced them to choose between one and the other. This is what
> I'm aiming to change. No less.

Well yes. I tend to be happy to stick with sysv-init because a) I know how it 
works, and b) it's easy enough to diagnose issues, and c) it's "good enough" 
for my needs. Yeah, it's not perfect, but *for my needs* I can easily work 
around those imperfections.

What you are doing does sound good, guess I should really add it to my list of 
stuff I'll probably not find time to look into :-(

>> But one trick that the desktop vendors are doing, and I suspect
>> SystemD are copying, is to "fake" a fast boot. By prioritising
>> certain bits, you get the illusion of a fast boot
> 
> Yes. I have no idea how Windows does it, or how other OSes do it,

Windows and MacOS both prioritise those tasks needed to get a desktop picture 
(or login prompt) on the screen - as that gives the illusion of fast boot time. 
That the system is still far from ready is evidenced by a) the time it takes to 
load all the applications I am usually running, and b) the disk and CPU 
activity going on for quite a while afterwards.
IME the fast boot is largely illusionary anyway - the disk I/O and CPU 
utilisation makes the whole system "sluggish" so it's not worth trying to do 
anything until all the background stuff is at least well past it's peak !

Rainer Weikusat  wrote:

>> * anything that uses the syslog should start after the syslog.
> 
> That's the same misunderstanding already shown elsewhere: Starting
> syslog at time X and starting syslog-user at time Y, Y > X, Y - X being
> 'very small', does not guarantee syslog will already be available at
> time Y and neither that it will still be available provided it became
> available in the time interval between X and Y.

That all hinges around what is meant by "start service A". If "start service" 
means nothing more than "kick off a process that'll run it" then you are 
completely correct. On the other hand, if "start service" actually means a 
process which is only deemed to be complete when it's running and ready to go 
to work then that's a different matter.

Of course, regardless of what system or definitions you use - if a service then 
dies then you have a problem. IMO, "it might die at some indeterminate time" 
isn't an excuse for not trying to get the "start stuff up" part right. Taking 
the example of syslog - if it dies (regardless of when, whether it's seconds or 
days after system start) then you are going to lose logging. You can try and 
manage that (spot the problem and deal with it automatically), but short of 
predicting the failure in advance, there will always be a window during which 
logging can be lost.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems

2015-09-25 Thread Hendrik Boom

On Fri, Sep 25, 2015 at 07:01:16AM +0100, KatolaZ wrote:
> On Thu, Sep 24, 2015 at 09:28:28PM +0200, Jaromil wrote:
> 
> [cut]
> 
> > > 
> > > But let's be honest here: how many times does it happen that you have
> > > to reboot a production server nowadays?
> > 
> > I think you are overlooking the vastity of use-cases here and I agree
> > with Laurent for a 5 minutes down you can have users raging at the door.
> > 
> > for instance I can well imagine we may end up using s6-rc for
> > http://dowse.equipment which isn't a server, but a home network
> > appliance that filters a lot of traffic (adblocking and such), caches
> > and tunnels DNS queries etc.
> > 
> 
> 
> I sincerely appreciate the work made by Laurent. Just please try to
> avoid falling in the same "everybody needs to boot-up in 12 seconds
> because high availability requires so" rhetoric championed by
> systemd-fanboys. That would do no good at all to s6-rc, and would not
> help acquiring new use bases, IMHO.

Weren't there measurements reported here fa few months ago that systemd 
isn't even any better n this metric?

-- hendrik
o

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems

Jaromil  writes:
> On Fri, 25 Sep 2015, Simon Hobson wrote:

[...]

> What I'm particularly interested is something to do process monitoring
> and respawning for a certain group of daemons - bundle in s6-rc? however
> not necessarily mixed with the system-wide base daemons.  For instance
> in Dowse's current proof-of-concept it happens (very seldom, once every
> 2 months, yet it does) that squid segfaults. I wish to have something
> that is not a lousy shell-script (and of course not a monster of
> office-suite dimensions taking over the whole setup) to notice the
> crash, save the logs aside and restart the daemon - and fast.

I can't publish the code as that's something I've been paid to write and
hence, it subject to the usual, draconic "even if you dream of code, it
belongs to us" employement contract clauses but this (including safely
sending signals to processes, restarts in certain intervals and
reliable process termination using a custom signal [specifically added
for squid]) can be implemented with a C program of less than 1000 lines
of code and such that it does "play well" with existing init scripts
(because it's just a command and not an attempt to remodel the whole
system).
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What can I do after netman?

2015-09-25 Thread Hleb Valoshka

On 9/21/15, Edward Bartolo  wrote:

> Since netman is effectively ready, and I can still offer my coding
> services to the Devuan project, I would like to ask what task should I
> take as my second attempt at helping with the project?

If your possible next project will look like netman then please do
nothing. It's a lowest quality project I've ever seen. It looks really
bad. You better read a good book about software architect.

I don't see any reason to throw away wicd and replace it with your tool.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems

2015-09-25 Thread KatolaZ

On Fri, Sep 25, 2015 at 03:40:35PM +0200, Didier Kryn wrote:

[cut]

> 
> But, as you or Jaromil said, and we all agree on this, the
> important thing is that Devuan provide this new high quality
> software, so that admins have more freedom. Important also is the
> fact that fast and dependency-based startup and supervision is the
> major sales argument for Systemd, and s6-rc does it better and in a
> simpler way, and does only that.
> 

Just to clarify: I am very happy that s6-rc is out, even if I would
probably not benefit directly from it, as much as I am happy that
things like KDE 4 exist, even if I have never used them. It
contributes to freedom of choice, and seems to adhere to KISS
principles, hence I consider it *good* :)

I was just warning ourselves about the risks of embracing the wrong
narrative to support projects like s6-rc. Despite the recent
degeneracies we have been witnessing, the usefulness of a software
does not increase or get diminished if we keep saying that it is more
or less useful than this or that other existing software, for this or
that particular reason. The users will have the final say, and their
decision might (or might not) coincide with the expectations of the
developers, whatever they are...

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems


On 25/09/2015 11:27, KatolaZ wrote:

I actually had the impression that servers was what Laurent was
referring to... :)


 Was I? It's possible.
 I usually refer to servers because it's the environment I'm used
to; but what I'm saying about boot times, parallelism and so on
is also true for clients, or any kind of machines really.

 I think it's a mistake to say "Boot times do not matter".
Additionally to embedded systems, which I've already written about,
virtual machines are now ubiquitous. There are several projects
now that boot Linux in a Javascript virtual machine, in your
browser. I've just used one today:
http://linsam.homelinux.com/extra/s6-altsim/jor1k/demos/s6-rc.html
Lots of companies are now moving their production environments
to Docker containers, which are easier to host and manage than
physical machines. And yes, mobile computing - the future of
client machines is the phone, not the PC, with wildly different
user demographics and habits.

 Boot times may not matter to you, on your desktop PC, because
you can make yourself a coffee while your machine boots. It may
not matter to the NOC person managing real servers, because
while one machine is booting, there are a hundred others already
serving. But boot times do matter for the person powering up an
Internet box, a VR machine or any "smart thing". They matter for
the person whipping up a complete OS in a Javascript VM, or
booting a container, or a phone. They will matter in tomorrow's
uses of Linux that we can't even foresee today.

--
 Laurent

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems

Isaac Dunham  writes:
> On Thu, Sep 24, 2015 at 02:31:40PM +0100, Rainer Weikusat wrote:
>> Laurent Bercot  writes:
>> 
>> [...]
>> 
>> > It manages dependencies between services, no matter whether they are
>> > oneshots or longruns; it can intertwine oneshot starts and longrun
>> > starts, or oneshot stops and longrun stops. When changing the machine
>> > state, it always ensures the consistency of the dependency graph.
>> 
>> I'd still very much like to see an actual example which really needs
>> these depenencies which isn't either bogus or a workaround for a bug in
>> the software being managed.
>
> Well, let's see:
>
> * cups should be started after avahi if you want zeroconf network printers
>   accessible by name

[more of this]

If a certain server doesn't handle "dynamic network configuration
changes" as it ought to, "starting it such that it hopefully won't have
to" is a sensible workaround. 

> * anything that uses the syslog should start after the syslog.

That's the same misunderstanding already shown elsewhere: Starting
syslog at time X and starting syslog-user at time Y, Y > X, Y - X being
'very small', does not guarantee syslog will already be available at
time Y and neither that it will still be available provided it became
available in the time interval between X and Y. And there is, of course,
another time Z involved here, Z > Y, Z - Y unknown, which is the time
when the services started at time Y will actually log the first
message. Unless syslog is available at that time, the message will
likely be lost. But "it was started earlier than the program trying to
log the message" does not guarantee that (and neither does "it was
started later" preclude it).

NB: I'm going to break this off here because I'm not interested in
trying to convince anyone of anything. I'm maintaining a certain,
proprietary system which works fine without performing a topological
sort of "actions to be performed" to determine a partial ordering for
them based on declared dependencies on startup.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems


On 25/09/2015 09:26, Jaromil wrote:

What I'm particularly interested is something to do process monitoring
and respawning for a certain group of daemons


 Just supervise the daemons you want to supervise, and don't
supervise the ones you don't want to. But really, there's no
reason *not* to supervise every daemon on your system: even if
you're not using the respawning mechanism, it gives you a
reproducible environment to start them (without 40 lines of
boilerplate) as well as a nice, race-free interface to send
them signals - no .pid files.

 The only reason why supervision is not more widespread is
inertia. There's a huge historical collection of sysv-rc-like
scripts that does not play well with supervision, and rewriting
them requires a tremendous effort. But I'm hopeful: since the
init wars, people have realized that some work was necessary.
There are initiatives to develop collections of supervision
scripts already. And daemon authors have started putting in the
effort to write systemd .service files, when supervision scripts
are easier, so there's no reason they can't be convinced.



I wish to have something
that is not a lousy shell-script (and of course not a monster of
office-suite dimensions taking over the whole setup) to notice the
crash, save the logs aside and restart the daemon - and fast.


 That's exactly what a supervision suite does. You could already
do it with daemontools in 1998! :P
 Nowadays, supervision suites are a dime a dozen. Of course, I'm
advertising s6, the one I wrote - but it is honestly more featureful
than the other ones, and, I like to think, correctly maintained.



It has been since the times of Icecast1 (pre-kh) that I need something
like that, been using restartd for a quick setup, but it does not handle
dependencies.. now wondering if s6-rc does it.


 s6 does it. s6-rc is not a supervision suite, it's a service manager
working on top of s6. The distinction is important:
 - booting a machine (s6-linux-init),
 - supervising processes (s6), and
 - managing services (s6-rc)
are not the same job, even if they are somewhat related. It's the
confusion between those three jobs that led to the birth of
mediocre software like sysvinit (I'm not hating: we didn't know
better at the time), and later on, of abominations like systemd
(I *am* hating).

 But yes, if all you need is process supervision, s6, or any
other supervision suite, is what you need. If you need dependency
management, especially between oneshots and longruns, then s6-rc
can do it.



In general I'd be incline to use s6 more because the whole suite Laurent
is developing seems very minimal and... no-bullshit (Gandi's tm)


 It's Gandi's motto (I like those guys, my VPS is hosted by them,
I have a few of their T-shirts), it's the suckless philosophy,
and it's mine. I like to think it's also the philosophy of
Devuan people, who voluntarily rejected the biggest bullshit of
the decade.

--
 Laurent

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems

On 25/09/2015 09:05, Simon Hobson wrote:

More to the point, I'd rather have reliability over speed any day.

How about you get both?
The dichotomy is a false one. People believe they can't have both
because init systems have never been done right so far, and always
forced them to choose between one and the other. This is what
I'm aiming to change. No less.

But one trick that the desktop vendors are doing, and I suspect
SystemD are copying, is to "fake" a fast boot. By prioritising
certain bits, you get the illusion of a fast boot

Yes. I have no idea how Windows does it, or how other OSes do it,
but systemd sacrifices a lot of reliability to gain a little speed
by starting services before their dependencies are ready. Start
your services before the loggers are ready to log! Who cares if
something goes wrong and you have no logs to analyze to understand
what happened?

This is definitely not what s6-rc is doing - on the contrary.
s6-rc does not cheat: when it says that a service is up, it is
really up - no stuff that keeps loading in the background,
unless the author of the service designed it so.

As I wrote one year ago at
https://forums.gentoo.org/viewtopic-t-994548-postdays-0-postorder-asc-start-25.html#7581522
you gain speed by doing two things:

- eliminating times when the processor is doing nothing
- eliminating times when the processor is doing unnecessary work

The former is what parallelism accomplishes. This is where s6-rc
wins over sysv-rc or OpenRC. (Yes, I'm aware that OpenRC has a
"rc_parallel" option. It is not reliable; it uses ugly, ugly hacks
to make it appear to work. Don't use it.)
The latter is what simplicity accomplishes. This is where s6-rc
wins over systemd - and over basically anything else than starting
your services by hand with zero overhead.

But, if you are going to boot slowly and methodically, it helps if
there's signs of progress.

If s6-rc is run with "-v2", it prints in real time to stderr what
it is doing. It's the equivalent of OpenRC's "ebegin" and "eend",
without the pretty-printing.
Anything more elaborated is the domain of a user interface; I'm bad
at user interfaces. But a distribution can add progress bars to
their service start scripts if it wishes, nothing prevents it from
doing so.

There's nothing that gets people impatient
better than something that appears to be taking a long time "doing
nothing" !

Show them a terminal with a lot of scrolling gibberish! That should
convince them that 1. the computer is actually doing something, and
2. the uninitiated should not be questioning what it is doing or the
time it takes - they should shut up and worship! ;)

--
Laurent
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What can I do after netman?

2015-09-25 Thread richard white

Maybe we could make a meta Roadmap/Priority project.
This project would use Milestones to track releases and
their issues.

This could be a central place to determine the highest
priority work.

-Rich
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems

2015-09-25 Thread Didier Kryn


Le 25/09/2015 11:27, KatolaZ a écrit :

On Fri, Sep 25, 2015 at 11:06:50AM +0200, Didier Kryn wrote:

Le 24/09/2015 19:54, KatolaZ a écrit :

But let's be honest here: how many times does it happen that you have
to reboot a production server nowadays? It is quite rare that a
failing program actually needs a reboot, right? And even when it
happens, 1 minute or 5 minutes boot won't change your overall uptime
percentage that much. If you are at 99.999% with a 1 minute boot
(which corresponds to one reboot every 2 months and a half, already
ways too much for the vast majority of production servers) with an
exagerated 5 minutes boot you will move to 99.995%.

 Dear Katolaz,

 I'm sory but you only think "server". I think this
dpendency-base startup and supervision is primarily dedicated to
laptops, although there must be other cases needing ultra-fast
boots. Linux is not dedicated only to big server farms.


Dear Didier,

I actually had the impression that servers was what Laurent was
referring to... :)

Anyway, it doesn't matter. Your clarification confirms my doubts: this
quest for "speed" could make sense mainly for mobile devices (I
personally reboot my laptop every 3/4 months, on average, and only
because I forget to plug the AC adapter overnight, so I still can't
see the issue for laptops), and I could agree on that, but please do
not bring servers and high availability scenario to support "smart"
dependency-based boots, since, as strange as it might sound, high
availability has nothing to do with boot speed, at all.




As far as I understand s6 is for supervision only, while s6-rc 
provides both fast startup and supervision. Supervision is a usefull 
feature for servers, but I fully agree that startup speed is not.


But, as you or Jaromil said, and we all agree on this, the 
important thing is that Devuan provide this new high quality software, 
so that admins have more freedom. Important also is the fact that fast 
and dependency-based startup and supervision is the major sales argument 
for Systemd, and s6-rc does it better and in a simpler way, and does 
only that.


BTW I don't trust enough suspend mode to use it all the time. On 
some of the servers I am running, uptime often exceed a year, but I like 
shuting down my laptop when I don't use it. Good to know that suspend 
works so well for you :-)


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What can I do after netman?

2015-09-25 Thread natacha

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

I have been following the devuan mailing list during the last couple
of weeks, and I would like to present myself, I come from a human
science and media arts background always involved in F/Loss
communities, where I search for new forms of creativity and social
organisation. I am based in Brussels where my point of reference is
www.constantvzw.org, but I also have other research activities in
academia.

As Jaromil has already explained at the beginning of this month I am
very interested in understanding the way Devuan community organises
itself, and eventually helping to formalise some collaboration model.
I have no personal or professional goal in this process,(I am not
planning to study or write about anything happening here). I am rather
interested to contribute to the project with skills that are different
from those of a developer's but that I believe can also help the project
.

On 09/22/2015 09:58 PM, Edward Bartolo wrote:
> Dear All,
> 
> My question is still open as I have no idea which project I can
> join to help. I was told it is easy to continue contributing to the
> Devuan Project, but this is proving to be next to impossible. This
> is NOT a rhetorical question; yes, I know the obvious answer that I
> can help in other projects, but which projects? I expected someone
> to provide some information, after all, feedback between coders is
> among the many purposes of the mailing list.
> 
> Snappy answers indicating an irritated sender, do not help: first
> calm down, then think, and when you have the right frame of mind,
> reply in a polite and educated manner.
> 
> Edward

Apparently there has been no direct answer to this question through
the list, I wonder if you have found others sources that could inform
you about projects that needed your help in Devuan, and if not, it
would be nice to have your view: how would you explain that the
response does not seem so obvious?

cheers

Natacha

> 
> 
> On 22/09/2015, aitor_czr  wrote:
>> Beautifull idea !!
>> 
>> I will add to debian/control:
>> 
>> Homepage: http://devuan.org XS-Vcs-Git:
>> g...@git.devuan.org:edbarx/netman.git XS-Vcs-Browser:
>> https://git.devuan.org/edbarx/netman.git
>> 
>> Aitor.
>> 
>> On 22/09/15 17:37, Edward Bartolo wrote:
>>> Hi Aitor,
>>> 
>>> If you can still rename the netman package I would like to have
>>> it renamed "netman-devuan-nm".
>>> 
>>> It is important for any users to know from where netman was
>>> conceived, and this is, the Devuan Project.
>>> 
>>> Edward
>>> 
>>> On 07/04/2021, aitor_czr  wrote:
> Good idea:-)
> 
> On 22/09/15 11:20, tilt! wrote:
>>> On 04/07/2021 10:54 PM, aitor_czr wrote:
> gpg-netman (git-buildpackage)
>>> 
>>> People will think it's related to "gpg", which it
>>> isn't.
>>> 
>>> I would like to suggest the name "netman-package" for
>>> that project.
>>> 
>>> Greetings, T.
>> 
>> 
> ___ Dng mailing list 
> Dng@lists.dyne.org 
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iQIcBAEBAgAGBQJWBTxuAAoJEB4vJZJLVJYmJKEQAIHfb0K7lt5clMZ2lw1x6XVo
88rfg4wZ7kUjtCeeqC0hT2aebD0PJhU0U+w2D5pMK1TCMzCB9memW75VqjlvxB9o
uOvL9XgHtpP2rK95ZprRqMJBVY4Ni+E4Ro9UfC/+JuFi40r658hwdD3KctH3/54R
URDawYnjHB3slLVH0b+TUGFDrFWDFnHpLUBXQWpOfxnyq98glgW9fAcgVeErJDwn
/NzRMXZDO3nJIL/b9KG5wRuCvemuDnywnHD9dxAYhnfk8Vw8lmqtBR4jhzgQcZ4H
zGCFMyFB3h9eKmHXiDOaxgf+jQWo/qAMbhkNFpI19jY8YjurbKYKm4fw9bSiwqkZ
qH91aXdryQr0djFz8IOQzwSYmeFu+hOAkUVPw7g0UurgciDhkv8LIz5RjuTGQmC+
QTA07BNR1MQ0rKYIKJGx2rn/b8dj4WNO/ZQmv8zM5eWBr49uQ1uWujOcJQVo5Dqz
CzfN7F0h6BatcqgmZbQIqCmglFv2UtAd2bFwNm9Xk1bSmGe6Fq1DImJjDSb8GUDC
7mZASlMqaiAbcTGZL8OrCvWSP9VSdpinASvcRm5cIJPyQlZSnehuj30nnfupT3f/
PLoLi02eGSNJCwQLicAc6MSFmuvyd93MpwW/XC/v8n6ulNpGi4Hrq9b2G6KFrhcX
WCzryN7JviT7Q8uopd9x
=yJ48
-END PGP SIGNATURE-
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What can I do after netman?

I will send again this post rectifying the content in the Digest:

El 23/08/15 a las 17:19, Steve Litt  escribió:

I make mistakes, that's why my pencil has an eraser.

Well..., when i built those packages, Gitorious had already announced 
the end. But there wasn't a consensus on which use in the future: 
BitBucket, GitLab, GitHub...?

I porposed trying with Savannah, but there was no time...

Thank you again for your clarifications.

Aitor.

El 25/09/15 a las 12:19, Hleb Valoshka <375...@gmail.com> escribió:

On 9/25/15, aitor_czr  wrote:

>The Development Team of BulmaGes has been using those lines:
>
>|Homepage:http://bulmages.net
>XS-Vcs-Git: git://gitorious.org/bulmages/bulmages.git
>XS-Vcs-Browser:https://gitorious.org/bulmages/bulmages/trees/.
>
>during years in debian/control. Gitorious is missing. But here you are an
>example:
>
>https://gitlab.com/aitor_cz/bulmages/blob/gbp-release15/debian/control
>
>So, it is wrong?

Of course, they should point to actual location. And XS- prefix should
be removed.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Hleb Valoshka <375...@gmail.com>

When i built those packages, Gitorious had already announced the end. 
But there wasn't a consensus on which use in the future: BitBucket, 
GitLab, GitHub...?

I porposed trying with Savannah, but there was no time...

Thank you again for your clarifications.

Aitor.

El 25/09/15 a las 12:19, Hleb Valoshka <375...@gmail.com> escribió:

On 9/25/15, aitor_czr  wrote:

>The Development Team of BulmaGes has been using those lines:
>
>|Homepage:http://bulmages.net
>XS-Vcs-Git: git://gitorious.org/bulmages/bulmages.git
>XS-Vcs-Browser:https://gitorious.org/bulmages/bulmages/trees/.
>
>during years in debian/control. Gitorious is missing. But here you are an
>example:
>
>https://gitlab.com/aitor_cz/bulmages/blob/gbp-release15/debian/control
>
>So, it is wrong?

Of course, they should point to actual location. And XS- prefix should
be removed.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [announce] Nostalgia (Was: s6-rc, a s6-based service manager for Unix systems)

2015-09-25 Thread Simon Hobson

KatolaZ  wrote:

> Agree! That's why I would warmly suggest mobile devices producers to
> include a pluggable nixie-tubes display like this:
> 
> http://ad7zj.net/kd7lmo/images/ground_nixie_front.jpg

Metaphorical "hands up" - how many of us went "gosh, how long is it since I saw 
one of those in the front of some kit ?" (or something similar)

Is it one of those "if you remember that, you must be getting old" technologies 
?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What can I do after netman?

2015-09-25 Thread Hleb Valoshka

On 9/25/15, aitor_czr  wrote:
> The Development Team of BulmaGes has been using those lines:
>
> |Homepage: http://bulmages.net
> XS-Vcs-Git: git://gitorious.org/bulmages/bulmages.git
> XS-Vcs-Browser: https://gitorious.org/bulmages/bulmages/trees/.
>
> during years in debian/control. Gitorious is missing. But here you are an
> example:
>
> https://gitlab.com/aitor_cz/bulmages/blob/gbp-release15/debian/control
>
> So, it is wrong?

Of course, they should point to actual location. And XS- prefix should
be removed.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What can I do after netman?

Another clarification about XS-Vcs headers: as of dpkg 1.14.6, the Xs- 
prefix is no longer necessary. See this link:

https://lintian.debian.org/tags/xs-vcs-header-in-debian-control.html

Aitor.

El 25/09/15 a las 11:35, aitor_czr escribió:
Hi again Hleb, the link in my example points to a *Git* repository *of 
a debian package*. I didn't understand you, sorry.

The Development Team of BulmaGes has been using those lines:
|Homepage:http://bulmages.net
XS-Vcs-Git: git://gitorious.org/bulmages/bulmages.git
XS-Vcs-Browser:https://gitorious.org/bulmages/bulmages/trees/.

during years in debian/control. Gitorious is missing. But here you are an 
example:

https://gitlab.com/aitor_cz/bulmages/blob/gbp-release15/debian/control

So, it is wrong?

Have a nice day,

Aitor.|
El 25/09/15 a las 11:16, aitor_czr  escribió:

Hi Hleb, you are right !!

El 25/09/15 a las 08:44, aitor_czr escribió:

>Hi Hleb,
>
>Those lines are located in debian/control. So..., an APT repository
>pointing to itself?
>
>Here you are an example random search in git:
>
>https://github.com/andrenth/postfix-erlang/blob/master/debian/control
>
>Aitor.
>
>El 25/09/15 a las 05:02, Hleb Valoshka<375...@gmail.com>  escribió:

>>On 9/24/15, Edward Bartolo  wrote:

>>> >What about these?
>>> >
>>> >debhttp://packages.gnuinos.org/devuan/  jessie main
>>> >deb-srchttp://packages.gnuinos.org/devuan/  jessie main

> >>>XS-Vcs-Git:g...@git.devuan.org:edbarx/netman.git
> >>>XS-Vcs-Browser:https://git.devuan.org/edbarx/netman.git

 >>
 >>These two should point to a package repository not an upstream one.

>>Once again: XS-Vcs-* should point to VSC (git/hg/svn/etc) repository
>>of debian package.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What can I do after netman?

2015-09-25 Thread Hleb Valoshka

On 9/25/15, aitor_czr  wrote:

> Those lines are located in debian/control. So..., an APT repository
> pointing to itself?

https://wiki.debian.org/DebianPackageInformation

QUESTION: is that (Vcs-*) an upstream source or a debian source?

ANSWER: It's the debian source. There is a difference because often
the Debian developers have a version control system where they do the
packaging, which is not necessarily the same one used by the software
author.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What can I do after netman?

Hi again Hleb, the link in my example points to a *Git* repository *of a 
debian package*. I didn't understand you, sorry.

The Development Team of BulmaGes has been using those lines:

|Homepage: http://bulmages.net
XS-Vcs-Git: git://gitorious.org/bulmages/bulmages.git
XS-Vcs-Browser: https://gitorious.org/bulmages/bulmages/trees/.

during years in debian/control. Gitorious is missing. But here you are an 
example:

https://gitlab.com/aitor_cz/bulmages/blob/gbp-release15/debian/control

So, it is wrong?

Have a nice day,

Aitor.|

El 25/09/15 a las 11:16, aitor_czr  escribió:

Hi Hleb, you are right !!

El 25/09/15 a las 08:44, aitor_czr escribió:

>Hi Hleb,
>
>Those lines are located in debian/control. So..., an APT repository
>pointing to itself?
>
>Here you are an example random search in git:
>
>https://github.com/andrenth/postfix-erlang/blob/master/debian/control
>
>Aitor.
>
>El 25/09/15 a las 05:02, Hleb Valoshka<375...@gmail.com>  escribió:

>>On 9/24/15, Edward Bartolo  wrote:

>>> >What about these?
>>> >
>>> >debhttp://packages.gnuinos.org/devuan/  jessie main
>>> >deb-srchttp://packages.gnuinos.org/devuan/  jessie main

> >>>XS-Vcs-Git:g...@git.devuan.org:edbarx/netman.git
> >>>XS-Vcs-Browser:https://git.devuan.org/edbarx/netman.git

 >>
 >>These two should point to a package repository not an upstream one.

>>Once again: XS-Vcs-* should point to VSC (git/hg/svn/etc) repository
>>of debian package.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems

2015-09-25 Thread KatolaZ

On Fri, Sep 25, 2015 at 11:06:50AM +0200, Didier Kryn wrote:
> Le 24/09/2015 19:54, KatolaZ a écrit :
> >But let's be honest here: how many times does it happen that you have
> >to reboot a production server nowadays? It is quite rare that a
> >failing program actually needs a reboot, right? And even when it
> >happens, 1 minute or 5 minutes boot won't change your overall uptime
> >percentage that much. If you are at 99.999% with a 1 minute boot
> >(which corresponds to one reboot every 2 months and a half, already
> >ways too much for the vast majority of production servers) with an
> >exagerated 5 minutes boot you will move to 99.995%.
> 
> Dear Katolaz,
> 
> I'm sory but you only think "server". I think this
> dpendency-base startup and supervision is primarily dedicated to
> laptops, although there must be other cases needing ultra-fast
> boots. Linux is not dedicated only to big server farms.
> 

Dear Didier, 

I actually had the impression that servers was what Laurent was
referring to... :) 

Anyway, it doesn't matter. Your clarification confirms my doubts: this
quest for "speed" could make sense mainly for mobile devices (I
personally reboot my laptop every 3/4 months, on average, and only
because I forget to plug the AC adapter overnight, so I still can't
see the issue for laptops), and I could agree on that, but please do
not bring servers and high availability scenario to support "smart"
dependency-based boots, since, as strange as it might sound, high
availability has nothing to do with boot speed, at all.

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What can I do after netman?