Re: Systemd.

[Jose E. Marchesi]

Hello.
I would suggest to address this to the attention of the guix project?
help-g...@gnu.org perhaps?

> Esteemed recipients,
>
> I greet you, a priori. With the appropriate salutations consummated, I
> will address the tonic theme of the discussion. I was promised GNU
> Shepherd as the init system of Guix, but there is a folder called
> systemd in run, which in turn is in “/”. The question is this: why?
> Was it supposed to come with the operating system, or did it come with
> an application installed later? In addition to this, I would like to
> know exactly what data of mine are collected by you when I use the
> system. Certainly, it is a foolish question, but asking never hurts,
> and I am not obliging anyone to answer. You will probably need more
> information about my operating system, but I will wait for you to ask
> questions so that I give only the strictly necessary information and
> nothing more.
>
> Yours sincerely,
> Me.
>
> Enviado com o e-mail seguro de [Proton Mail](https://proton.me/).

Systemd.

[DieRosedesNordens]

Esteemed recipients,

I greet you, a priori. With the appropriate salutations consummated, I will 
address the tonic theme of the discussion. I was promised GNU Shepherd as the 
init system of Guix, but there is a folder called systemd in run, which in turn 
is in “/”. The question is this: why? Was it supposed to come with the 
operating system, or did it come with an application installed later? In 
addition to this, I would like to know exactly what data of mine are collected 
by you when I use the system. Certainly, it is a foolish question, but asking 
never hurts, and I am not obliging anyone to answer. You will probably need 
more information about my operating system, but I will wait for you to ask 
questions so that I give only the strictly necessary information and nothing 
more.

Yours sincerely,
Me.

Enviado com o e-mail seguro de [Proton Mail](https://proton.me/).

Re: (Really) Free Software future in the light of systemd

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Please forgive my delay.

Regarding HyperbolaBSD:
We do list non-GNU free distros in https://gnu.org/distros/.
The distro developers have to make the same pledge.

If they want this, they should contact us as it says in
https://gnu.org/distros/.

However, GNU package maintainers do not have a responsibility
to support a non-GNU system in any particular way.  That responsibility
is limited to the GNU system.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: (Really) Free Software future in the light of systemd

[Jean Louis]

* Dmitry Alexandrov <321...@gmail.com> [2019-10-21 22:44]:
> While Linux® is indeed might be a very relevant example.  It’s a way
> more widespread; has software more critical that DE, like Wayland,
> that targets it exclusively; and since the advent of LLVM is
> basically the only effectively irreplaceable part of GNU left.

Hyperbola GNU/Linux-libre project is preparing HyperbolaBSD. According
to: https://wiki.hyperbola.info/doku.php?id=en:main:nomenclatures --
It is planned to be based on the OpenBSD operating system with
implementations from different BSD systems and modularized like the
GNU operating system by using the hyperman utility for package
management and HyperRC as its default init system. Its kernel is
called as “HyperBK” and library C as “HyperBLibC”.

hyperman is the name chosen for the version of pacman while HyperRC is
the name chosen for the version of OpenRC. Both are planned to be a
framework (not a fork) to host local modifications and try to push
back Hyperbola changes whenever they are good for upstreams too.

The Hyper Berkeley Kernel (HyperBK) is a kernel which is being
developed and maintained by Hyperbola. It is a kernel planned to be
based on OpenBSD kernel, however with implementations from different
BSD kernels and deblobbed by Hyperbola.

The Hyper Berkeley C Library (HyperBLibC) is a C library which is
being developed and maintained by Hyperbola. It is a C library planned
to be based on OpenBSD C library, however with implementations from
different BSD C libraries.

While this may not be GNU system, Hyperbola team is planning to make
fully free OpenBSD based system after liberating that kernel from
blobs.

That is all good news!

Jean

Re: systemd replacement or standardization

[Jean Louis]

* Richard Stallman  [2019-10-21 22:43]:
> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > I would call projects like IceWM window manager to become GNU project,
>   > IceWM is one of fastest window managers, those maintainers could get
>   > some donation and move it into GNU. Then there is nice and small GNU
>   > Desktop. Why not?
> 
> The first question is, would they like that?  Are they interested?
> 
> Do they say anything about GNU?  If so, what attitude do they
> display?

As of now, their answer is that they think that there is more work
than benefit.

Example answer:

I too think that it is more work than benefit. (I have been around long enough 
to see the Savannah project be born and die.)

Looking at the others' responses, I think that the answer is no.

I am not surprised that you got no response from Marko: I started this
fork because Marko would not respond to support requests nor
incorporate patches. Understandable, though: I hear he is a Submarine
Captain in the US Navy. We are thankful for all his efforts to create
a worthy window manager and influence the GNOME/WMH specification.

From:
https://github.com/bbidulock/icewm/issues/391

I am proposing to you that we campaign to attract various software
pieces. It is teaching developers what is free software movement, many
do not know, but just program.

I have given to them reference on how to apply, but that seems
unlikely.

Maybe you can suggest what benefits they are getting?

IceWM is great Window Manager which makes in my opinion a complete
desktop workspace. It is fast.

Jean

Re: (Really) Free Software future in the light of systemd

[Dmitry Alexandrov]

Stefan Huchler  wrote:
> If I write a program and it's elisp there is only as far as I know one 
> interpreter and all libs I use are also not replacable without rewriting code.

Even if put aside that we have at least two elisp interpreters alive: there is 
also GNU Guile; GNU Emacs is actually quite bad example to illustrate the 
systemd lock-in problem.  For many years it had had a divergent fork — XEmacs, 
and many non-core parts of GNU Emacs, like Gnus, still contain code that tries 
to be portable between them.

> So is all my programmes I ever wrote also not Free software because it's not 
> based on some very primitive Kernel Systemcalls (that have to be then not 
> even linux specific right?

While Linux® is indeed might be a very relevant example.  It’s a way more 
widespread; has software more critical that DE, like Wayland, that targets it 
exclusively; and since the advent of LLVM is basically the only effectively 
irreplaceable part of GNU left.

I wish open software (that how the standard-based software is properly called) 
advocates, which are now focused on systemd, would better turn their attention 
to Linux®.


signature.asc
Description: PGP signature

Re: systemd replacement or standardization

[Jean Louis]

* Richard Stallman  [2019-10-18 08:48]:
> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > I would call projects like IceWM window manager to become GNU project,
>   > IceWM is one of fastest window managers, those maintainers could get
>   > some donation and move it into GNU. Then there is nice and small GNU
>   > Desktop. Why not?
> 
> The first question is, would they like that?  Are they interested?
> 
> Do they say anything about GNU?  If so, what attitude do they
> display?

We will see that. I am asking them.

As people who are only technically focused to develop software may not
understand what free software philosophy is or GNU project and may
need an incentive or a call to join GNU project.

Jean

Re: systemd replacement or standardization

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I would call projects like IceWM window manager to become GNU project,
  > IceWM is one of fastest window managers, those maintainers could get
  > some donation and move it into GNU. Then there is nice and small "GNU
  > Desktop". Why not?

The first question is, would they like that?  Are they interested?

Do they say anything about GNU?  If so, what attitude do they
display?

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: systemd replacement or standardization

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The question is always if its better. People won't change because
  > they are promised freedom. 

Some of us do!  And more of us can.  Teaching people to value freedom
enough to choose it is a high priority.

You don't have to work on that yourself, but please do not spread
defeatism about it.


-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: systemd replacement or standardization

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I was specifically talking about the different build System and
  > the integration with Systemd instead of GNU Shepherd. GNOME
  > project is unwilling to support them.

It would be good for GNOME to support GNU Shepherd as well.
To what extent do they have common APIs to make this easy?
Could we change GNU Shepherd to increase the compatibility?

Could we work with the systemD developers to standardize an API for
this purpose?

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: systemd replacement or standardization

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > GNOME used to be compiled with Autotools from the GNU project.
  > Now it is based on meson.
  > https://mesonbuild.com/index.html 
  > Iniative:
  > https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting 


That is not necessarily a bad thing.  We never made it a standard
that GNU packages must use the Autotools.

The standard we have is that ./configure; make install
should build and install the package.  _How_ they do it
is up to the package maintainers.

Does GNOME implement that spec?


-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: (html emails) Re: systemd replacement or standardization

[Alfred M. Szmidt]

   >Emacs alone cannot handle emails as fast as I wish it should. It is
   >good for smaller volumes.
   > 
   > I think it handles large volumes immensly well, only today I had to go
   > through about 300 messages.

   Which package do you use?

I use rmail.

Re: (html emails) Re: systemd replacement or standardization

[Jean Louis]

* Alfred M. Szmidt  [2019-10-17 00:11]:
>>Emacs alone cannot handle emails as fast as I wish it should. It is
>>good for smaller volumes.
>> 
>> I think it handles large volumes immensly well, only today I had to go
>> through about 300 messages.
> 
>Which package do you use?
> 
> I use rmail.

It is nice and simple. I use it only sometimes. But I do use Emacs for
sending emails, then I move emails to Maildirs.

Jean

Re: systemd replacement or standardization

[Jean Louis]

* marinus.savorit...@tuta.io  [2019-10-17 00:00]:
> GNOME used to be compiled with Autotools from the GNU project.
> Now it is based on meson.
> https://mesonbuild.com/index.html 
> Iniative:
> https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
> 

Well I understand that projects change throughout the time.

I do not see that as any kind of loss any more, as GNU free operating
system is in its existence in many various GNU/Linux distributions and
some others based on other kernels.

I would call projects like IceWM window manager to become GNU project,
IceWM is one of fastest window managers, those maintainers could get
some donation and move it into GNU. Then there is nice and small "GNU
Desktop". Why not?

There could be many various GNU projects if programmers would be moved
to GNU and given some kind of support like web hosting and official
promotion and maybe some donations from FSF.

Jean

Re: (html emails) Re: systemd replacement or standardization

[Jean Louis]

* Alfred M. Szmidt  [2019-10-16 02:33]:
>Emacs alone cannot handle emails as fast as I wish it should. It is
>good for smaller volumes.
> 
> I think it handles large volumes immensly well, only today I had to go
> through about 300 messages.

Which package do you use?

When I have set Gnus for maildir access with 48000+ subfolders, it
could not even finish its initialization, it was running 2 days, and
duplicating stuff in the manner out of any standard of using
maildirs. For maildirs it is broken.

Jean

Re: (html emails) Re: systemd replacement or standardization

[Jean Louis]

* Alfred M. Szmidt  [2019-10-16 02:30]:
>Emacs alone cannot handle emails as fast as I wish it should. It is
>good for smaller volumes.
> 
> I think it handles large volumes immensly well, only today I had to go
> through about 300 messages.

To tell specifics from my side, I am using maildirs and not mbox or
Rmail or other single file formats, and when I have tried using Gnus
with maildirs, it started creating huge new index of maildirs
duplicating the maildir sizes from many gigabytes to double amount,
and process never ended. Thus my specific case does not refer to
mboxes.

Rmail is quite usable and nice, Gnus is probably too, it is just not
good for my specific case of using Maildirs.

Other mail packages are also nice, I think Wanderlust (if not mistaken
by name) is supporting various folders, yet I don't have same speed as
using mutt. I wish there would be some solution, I did not find it
yet.

maildir package in elpa is about almost there to support maildirs,
sometimes I use it, but is incomplete.

Jean

Re: systemd replacement or standardization

[marinus.savoritias]

GNOME used to be compiled with Autotools from the GNU project.
Now it is based on meson.
https://mesonbuild.com/index.html 
Iniative:
https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting 


Fannys

Oct 16, 2019, 05:33 by r...@gnu.org:

> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>  > By that I mean, GNOME has moved away from GNU build tools
>
> Can you tell me more specifics about this?
> What did GNOME do in regard to build tools?
>
> -- 
> Dr Richard Stallman
> Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>

Re: systemd replacement or standardization

[marinus.savoritias]

Oct 15, 2019, 22:48 by bugs@gnu.support:

> * marinus.savorit...@tuta.io  [2019-10-16 01:56]:
>
>> > In my opinion Gnome shall remain independent of the supervisor type.
>> >
>> I wasn't talking about bringing GNOME under control of GNU. I am talking 
>> about integrating with GNU technology. 
>> Build system, Init, service manager and so on. When and if they are
>> developed.
>>
>
> It is already integrated in various free software distributions. Which
> one are you using?
>
> Is it not integrated in yours?
>
I was specifically talking about the different build System and the integration 
with Systemd instead of GNU Shepherd. GNOME project is unwilling to support 
them.

>> > On Hyperbola GNU/Linux-libre there is no systemd, and there is still
>> > Gnome, it works fine.
>> >
>> Sure it works fine. But that wasn't the point I was making. How much effort 
>> does it take for GNOME to work fine if you don't have Systemd?
>> In Gentoo they had a hell of a time to make it work without Systemd
>> and Guix doesn't have the latest version exactly yet.
>>
>
> I understand it is about cooperation between communities, one
> community is tending to support only systemd.
>
Which the Systemd community doesn't play nice to make their things standard.
>> > The time of GNU as sole operating system is already for decades
>> > over. The idea of Dr. Richard Stallman to build a new free software
>> > operating system was realized practically for many people back in time
>> > when somebody used Linux kernel and distributed first GNU distribution
>> > with it. Then when GNU Hurd was not as practical and usable, Linux
>> > within GNU became practical and usable.
>> >
>> > Now there are many various GNU distributions, each can decide which
>> > software to use. The distinction became blurry.
>> >
>> I think that points to a larger problem. As of right now we have a
>> lot of alternatives to various packages that are getting
>> traction. Nobody is eager to join the GNU project. Person or
>> project.
>>
>
> I see it as unfolded flower. Richard Stallman envisioned GNU operating
> system as a single leaf, it unfolded into bush of flowers. There are
> now many free software political groups promoting free software
> philosophy and many various GNU versions of free operating system.
>
> It changed over time, there is not one uniqu GNU alone for
> itself, system.
>
> Maybe some recruitment is necessary to hire new software packages and
> to basically ask for new GNU involved projects, that is up to GNU and
> FSF to invite people for those software packages that are necessary
> for future, like for example replacements for Skype and similar.
>
We have already for replacement for those, just not enough people.
>> I have been doing some reading on GNU the last few days. Seeing the
>> packages. Going through mailing lists. Outside of GUIX and their
>> packages and GIMP there aren't that many active projects.
>>
>
> Then I am sorry I do not know what you mean, for me the statement
> above is way too general.
>
> Look:
> https://www.fsf.org/blogs/community/gnu-spotlight-with-mike-gerwitz-14-new-gnu-releases-in-september
>
>> For some reason we can't attract contributors.
>>
>
> Instead of general statement, why not say which software requires
> contributors in particular?
>
>> Now I have seen from Linux forums (Phoronix, Gentoo) that people are
>> trying to move away from GNU. Or they don't even know it exists.
>>
>
> Could you please give specific link instead of making it general
> statement?
>
> You are also free to introduce "Linux" forum users to what free
> software philosophy really is, as many users do not know about it. 
>
As I said this is not the right forum for the discussion. And no its not about 
them not knowing the philosophy.

>> To keep it short I don't think that other people have better tech
>> necessarily.
>>
>
> Question is not what is better, but if users are given rights as
> envisioned by free software philosophy.
>
The question is always if its better. People won't change because they are 
promised freedom. 
You have to get your foot in the door to convince people to comit. Check KDE 
for example.
>> I think GNU doesn't have contributors. And can't attract new
>> ones. And that is not because people are not coders or they don't
>> want Free Software.
>>
>
> Well that sounds to me as depressive useless statement. How many GNU
> mailing lists are you subscribed to?
>
About 20 

Re: systemd replacement or standardization

[Jean Louis]

* marinus.savorit...@tuta.io  [2019-10-16 01:56]:
> > In my opinion Gnome shall remain independent of the supervisor type.
> >
> I wasn't talking about bringing GNOME under control of GNU. I am talking 
> about integrating with GNU technology. 
> Build system, Init, service manager and so on. When and if they are
> developed.

It is already integrated in various free software distributions. Which
one are you using?

Is it not integrated in yours?

> > On Hyperbola GNU/Linux-libre there is no systemd, and there is still
> > Gnome, it works fine.
> >
> Sure it works fine. But that wasn't the point I was making. How much effort 
> does it take for GNOME to work fine if you don't have Systemd?
> In Gentoo they had a hell of a time to make it work without Systemd
> and Guix doesn't have the latest version exactly yet.

I understand it is about cooperation between communities, one
community is tending to support only systemd.

> > The time of GNU as sole operating system is already for decades
> > over. The idea of Dr. Richard Stallman to build a new free software
> > operating system was realized practically for many people back in time
> > when somebody used Linux kernel and distributed first GNU distribution
> > with it. Then when GNU Hurd was not as practical and usable, Linux
> > within GNU became practical and usable.
> >
> > Now there are many various GNU distributions, each can decide which
> > software to use. The distinction became blurry.
> >
> I think that points to a larger problem. As of right now we have a
> lot of alternatives to various packages that are getting
> traction. Nobody is eager to join the GNU project. Person or
> project.

I see it as unfolded flower. Richard Stallman envisioned GNU operating
system as a single leaf, it unfolded into bush of flowers. There are
now many free software political groups promoting free software
philosophy and many various GNU versions of free operating system.

It changed over time, there is not one uniqu GNU alone for
itself, system.

Maybe some recruitment is necessary to hire new software packages and
to basically ask for new GNU involved projects, that is up to GNU and
FSF to invite people for those software packages that are necessary
for future, like for example replacements for Skype and similar.

> I have been doing some reading on GNU the last few days. Seeing the
> packages. Going through mailing lists. Outside of GUIX and their
> packages and GIMP there aren't that many active projects.

Then I am sorry I do not know what you mean, for me the statement
above is way too general.

Look:
https://www.fsf.org/blogs/community/gnu-spotlight-with-mike-gerwitz-14-new-gnu-releases-in-september

> For some reason we can't attract contributors.

Instead of general statement, why not say which software requires
contributors in particular?

> Now I have seen from Linux forums (Phoronix, Gentoo) that people are
> trying to move away from GNU. Or they don't even know it exists.

Could you please give specific link instead of making it general
statement?

You are also free to introduce "Linux" forum users to what free
software philosophy really is, as many users do not know about it. 

> To keep it short I don't think that other people have better tech
> necessarily.

Question is not what is better, but if users are given rights as
envisioned by free software philosophy. 

> I think GNU doesn't have contributors. And can't attract new
> ones. And that is not because people are not coders or they don't
> want Free Software.

Well that sounds to me as depressive useless statement. How many GNU
mailing lists are you subscribed to?

> > It is in most free software distributions already. Did you try it?
> >
> You mean GNOME right? GNOME has removed GNU from the name since a long time 
> now.
> https://mail.gnome.org/archives/marketing-list/2010-April/msg00050.html 
> <https://mail.gnome.org/archives/marketing-list/2010-April/msg00050.html>
> I have used seemed pleasant to use, good tech.

OK fine, but name or not name it is free software.

Richard Stallman have burried few seeds, and he is still placing it
all over the world, and now we have bushes of flowers everywhere and
plants growing in gardens, and each flower is free to smell and have
various flavours.

> The community when I started getting involved with GNOME pushed me
> away. I don't like the culture.

I am sorry, but generalized statement are not useful, they give
appearance of negativity. When lacking facts generalized statements
create Fear, Uncertainty and Doubts = FUD. That does not help.

If you have some particular constructive proposal, that would be good
to propose.

> > Which one do you use?
> >
> I am starting to 

Re: systemd replacement or standardization

[marinus.savoritias]

Sorry about that. DIdn't notice it is corrected now.

Okay. Sounds fair for the Systemd position.
Fannys
Oct 15, 2019, 20:01 by a...@vapaa.xyz:

> Hi,
>
> firstly I kindly ask you to send a plain text emails without html.
>
> On 10/15/19 12:36 AM, marinus.savorit...@tuta.io wrote:
>
>> What events? Can you link?
>>
>
> I'm speaking about well known petition to remove RMS from FSF and GNU. I
> wouldn't like to repeat my position about that.
> But I do *not* want to work with those people(1) and I do *not* want to
> accept theirs views in order to be accepted(2). GNU should be neutral
> w/o any political shit.
>
> btw, there are another technical points you can find on my previous
> message.
>
>>
>> Fannys
>>
>>
>> Oct 14, 2019, 23:32 by a...@vapaa.xyz:
>>
>>
>>
>>  On 10/15/19 12:12 AM, marinus.savorit...@tuta.io wrote:
>>
>>  Hi,
>>
>>  Pardon for my ignorance but why not GNU Shepherd which is already
>>  developed to be the GNU init system and process supervisor? It is
>>  already used by GUIX.
>>
>>
>>  The problem with it are follow:
>>  - there are no clear specification to work with
>>  - I'd love to use scheme language (GNU Guile), but it's not always
>>  possible (embedded as example)
>>  - according to the last events I need to accept some political views I
>>  wouldn't to
>>
>>  btw, init system used in guix is very nice from my point of view.
>>
>>
>>  Fannys
>>
>>
>>  Oct 14, 2019, 23:03 by a...@vapaa.xyz:
>>
>>
>>
>>  On 10/14/19 10:57 PM, František Kučera wrote:
>>
>>  Dne 14. 10. 19 v 19:54 Alexander Vdolainen napsal(a):
>>
>>  It looks like a xinetd new feature, but - do we really need
>>  a dbus?
>>
>>
>>  I wrote only one D-Bus service and quite simple, so I do not feel
>>  capable to say how much useful is socket activation in this
>>  case. D-Bus
>>  might be an optional feature.
>>
>>  However, I am sure that socket inheritance and activation for unix
>>  domain sockets is useful and needed. Improvement of xinetd (or other
>>  superserver) would be great.
>>
>>
>>  yep, but I found https://github.com/xinetd-org/xinetd looks like
>>  abandoned (and xinetd.org was unable to load anything). However it's
>>  still possible to add this feature, but is it xinetd still used?
>>
>>  But I rather prefer this feature in the
>>  init system. This feature is generic enough and directly linked to
>>  process/service execution, so IMHO it is a task for an init system.
>>
>>
>>  Make sense, but check out a more extended reply to this below.
>>
>>  But not in a way systemd implemented it.
>>
>>
>>  What is bad with them? We can always imagine a better format,
>>  but I do
>>  not think that systemd unit files are somehow terribly wrong.
>>
>>  Is it about a set of user processes running during the login
>>  process ?
>>  If so, I suppose it's out of scope the init system, it's
>>  some kind of
>>  extra feature.
>>
>>
>>  In the user session you might be dealing with same tasks as in the
>>  system session – e.g. service dependencies (run them in the correct
>>  order) or that socket activation. And if you implement it in the
>>  system-wide init system, it would be nice to be able to run another
>>  instance of the same daemon in the user-session and enjoy same
>>  features
>>  there – i.e. same tools or same format of config files. And it
>>  would be
>>  independent from the desktop environment / window manager, so
>>  you can
>>  run same services in KDE, Gnome, Xfce, Window maker atc.
>>
>>
>>  it's actually the same mechanics, and I've got your point. So
>>  let's me
>>  describe my thoughts about init system itself.
>>
>>  Let's split init system:
>>  - (a) init (a POSIX PID 1)
>>  - (b) daemon 'starter'
>>  - (c) daemon 'watchdog'
>>  - (d) tools?
>>
>>  Regarding 'a': this guy should be kept a very small, stable and
>>  simple.
>>  For 'b', 'c' and might be 'd' the best way is to create a shared
>>  library
>>  with all necessary functions. That means b,c and d might works
>>  anywhere
>>  and independently on 'a'.
>>
>>  The next step is to define a functional scope of init system, let's
>>  assume:
>>  - os state support (SySV runlevels

Re: (html emails) Re: systemd replacement or standardization

[Alfred M. Szmidt]

   Emacs alone cannot handle emails as fast as I wish it should. It is
   good for smaller volumes.

I think it handles large volumes immensly well, only today I had to go
through about 300 messages.

Re: systemd replacement or standardization

[Jean Louis]

* marinus.savorit...@tuta.io  [2019-10-15 22:38]:
> So since we have GNU Shepherd and it will keep being developed why
> don't we ask GNOME on their stance?

In my opinion Gnome shall remain independent of the supervisor type.

In my opinion s6 and s6-rc is better, logical and more powerful
system for service management, see: http://skarnet.org/software/

And I have used it for quite some time, now using Hyperbola
GNU/Linux-libre https://www.hyperbola.info which is using OpenRC, not
bad, functional.

Well the service management is good when it "just works", easy to
setup, start, stop services, define run level.

I would like using GNU Shepherd, but now only Guix is using it and
using Guix is bloated, it asks user to download bunch of packages for
any version of the system, it compiles way too much, it is not a
system for average users and certainly not for those located in
countries with more expensive bandwidth.

> By that I mean, GNOME has moved away from GNU build tools and
> requires Systemd (I aknowldge you can replace it with forks but
> still). I remember reading about a discussion to remove the acronym
> too.

On Hyperbola GNU/Linux-libre there is no systemd, and there is still
Gnome, it works fine.

> So in my opinion, we should reevaluate whether GNOME is a part of
> GNU and how open are they to reintegrate to GNU if the right tools
> are developed. If not, there are plenty of environments which are
> open and were open in the past to not be tied to one
> technology. XFCE,KDE etc.

There is not one single GNU operating system, so there are free system
distributions and their maintainers decide how and which software to
include.

Gnome is one part of the system and it does exist and is already
implemented in free software distributions.

The time of GNU as "sole" operating system is already for decades
over. The idea of Dr. Richard Stallman to build a new free software
operating system was realized practically for many people back in time
when somebody used Linux kernel and distributed first GNU distribution
with it. Then when GNU Hurd was not as practical and usable, Linux
within GNU became practical and usable.

Now there are many various GNU distributions, each can decide which
software to use. The distinction became blurry.

> The GNU desktop environment should be integrated with GNU in my
> opinion.

It is in most free software distributions already. Did you try it?

Which one do you use?

Jean

Re: systemd replacement or standardization

[marinus.savoritias]

Oct 15, 2019, 21:47 by bugs@gnu.support:

> * marinus.savorit...@tuta.io  [2019-10-15 22:38]:
>
>> So since we have GNU Shepherd and it will keep being developed why
>> don't we ask GNOME on their stance?
>>
>
> In my opinion Gnome shall remain independent of the supervisor type.
>
I wasn't talking about bringing GNOME under control of GNU. I am talking about 
integrating with GNU technology. 
Build system, Init, service manager and so on. When and if they are developed.
>
> In my opinion s6 and s6-rc is better, logical and more powerful
> system for service management, see: http://skarnet.org/software/
>
> And I have used it for quite some time, now using Hyperbola
> GNU/Linux-libre https://www.hyperbola.info which is using OpenRC, not
> bad, functional.
>
> Well the service management is good when it "just works", easy to
> setup, start, stop services, define run level.
>
I agree. OpenRC works good enough. I didn't have the need to do anything more 
in Gentoo than just starting services. I know that Shepherd, Systemd and the 
likes are more advanced though.
>
> I would like using GNU Shepherd, but now only Guix is using it and
> using Guix is bloated, it asks user to download bunch of packages for
> any version of the system, it compiles way too much, it is not a
> system for average users and certainly not for those located in
> countries with more expensive bandwidth.
>
>> By that I mean, GNOME has moved away from GNU build tools and
>> requires Systemd (I aknowldge you can replace it with forks but
>> still). I remember reading about a discussion to remove the acronym
>> too.
>>
>
> On Hyperbola GNU/Linux-libre there is no systemd, and there is still
> Gnome, it works fine.
>
Sure it works "fine". But that wasn't the point I was making. How much effort 
does it take for GNOME to work fine if you don't have Systemd?
In Gentoo they had a hell of a time to make it work without Systemd and Guix 
doesn't have the latest version exactly yet. 

>> So in my opinion, we should reevaluate whether GNOME is a part of
>> GNU and how open are they to reintegrate to GNU if the right tools
>> are developed. If not, there are plenty of environments which are
>> open and were open in the past to not be tied to one
>> technology. XFCE,KDE etc.
>>
>
> There is not one single GNU operating system, so there are free system
> distributions and their maintainers decide how and which software to
> include.
>
> Gnome is one part of the system and it does exist and is already
> implemented in free software distributions.
>
> The time of GNU as "sole" operating system is already for decades
> over. The idea of Dr. Richard Stallman to build a new free software
> operating system was realized practically for many people back in time
> when somebody used Linux kernel and distributed first GNU distribution
> with it. Then when GNU Hurd was not as practical and usable, Linux
> within GNU became practical and usable.
>
> Now there are many various GNU distributions, each can decide which
> software to use. The distinction became blurry.
>
I think that points to a larger problem. As of right now we have a lot of 
alternatives to various packages that are getting traction. Nobody is "eager" 
to join the GNU project. Person or project. 

I have been doing some reading on GNU the last few days. Seeing the packages. 
Going through mailing lists. Outside of GUIX and their packages and GIMP there 
aren't that many active projects.
For some reason we can't attract contributors. 
Now I have seen from Linux forums (Phoronix, Gentoo) that people are trying to 
move away from GNU. Or they don't even know it exists. 

To keep it short I don't think that other people have better tech necessarily. 
I think GNU doesn't have contributors. And can't attract new ones. And that is 
not because people are not coders or they don't want Free Software.
What is the reason should be discussed on another list though.

>> The GNU desktop environment should be integrated with GNU in my
>> opinion.
>>
>
> It is in most free software distributions already. Did you try it?
>
You mean GNOME right? GNOME has removed GNU from the name since a long time now.
https://mail.gnome.org/archives/marketing-list/2010-April/msg00050.html 
<https://mail.gnome.org/archives/marketing-list/2010-April/msg00050.html>
I have used seemed pleasant to use, good tech.
The community when I started getting involved with GNOME pushed me away. I 
don't like the culture.
They are too entitled and esoteric for my tastes.
> Which one do you use?
>
I am starting to get involved in KDE. After I read about their community and 
their Guidelines, I liked the culture. 
I actually proposed a KDE goal this year and it was picked as a focused. 
They seem much more open to peoples need and recieving feedback.
>
> Jean
>

Fannys

(html emails) Re: systemd replacement or standardization

[Jean Louis]

* Alexander Vdolainen  [2019-10-15 23:37]:
> Hi,
> 
> firstly I kindly ask you to send a plain text emails without html.

I am using mutt E-mail client, http://www.mutt.org/ and it reads both
HTML and plain text, I think it is most efficient.

It runs very well inside the Emacs and I am using vterm module
https://github.com/akermu/emacs-libvterm which was little better than
ansi-term terminal emulation. It works even more cleaner under XTerm.

Mutt works fastest for any handling of emails, and I have tried all
mail clients.

In my opinion mutt shall be part of each GNU free operating system
distribution.

Emacs alone cannot handle emails as fast as I wish it should. It is
good for smaller volumes.

Jean

Re: systemd replacement or standardization

[Alexander Vdolainen]

Hi,

firstly I kindly ask you to send a plain text emails without html.

On 10/15/19 12:36 AM, marinus.savorit...@tuta.io wrote:
> What events? Can you link?

I'm speaking about well known petition to remove RMS from FSF and GNU. I
wouldn't like to repeat my position about that.
But I do *not* want to work with those people(1) and I do *not* want to
accept theirs views in order to be accepted(2). GNU should be neutral
w/o any political shit.

btw, there are another technical points you can find on my previous
message.

> 
> Fannys
> 
> 
> Oct 14, 2019, 23:32 by a...@vapaa.xyz:
> 
> 
> 
> On 10/15/19 12:12 AM, marinus.savorit...@tuta.io wrote:
> 
> Hi,
> 
> Pardon for my ignorance but why not GNU Shepherd which is already
> developed to be the GNU init system and process supervisor? It is
> already used by GUIX.
> 
> 
> The problem with it are follow:
> - there are no clear specification to work with
> - I'd love to use scheme language (GNU Guile), but it's not always
> possible (embedded as example)
> - according to the last events I need to accept some political views I
> wouldn't to
> 
> btw, init system used in guix is very nice from my point of view.
> 
> 
> Fannys
> 
> 
> Oct 14, 2019, 23:03 by a...@vapaa.xyz:
> 
> 
> 
> On 10/14/19 10:57 PM, František Kučera wrote:
> 
> Dne 14. 10. 19 v 19:54 Alexander Vdolainen napsal(a):
> 
> It looks like a xinetd new feature, but - do we really need
> a dbus?
> 
> 
> I wrote only one D-Bus service and quite simple, so I do not feel
> capable to say how much useful is socket activation in this
> case. D-Bus
> might be an optional feature.
> 
> However, I am sure that socket inheritance and activation for unix
> domain sockets is useful and needed. Improvement of xinetd (or other
> superserver) would be great.
> 
> 
> yep, but I found https://github.com/xinetd-org/xinetd looks like
> abandoned (and xinetd.org was unable to load anything). However it's
> still possible to add this feature, but is it xinetd still used?
> 
> But I rather prefer this feature in the
> init system. This feature is generic enough and directly linked to
> process/service execution, so IMHO it is a task for an init system.
> 
> 
> Make sense, but check out a more extended reply to this below.
> 
> But not in a way systemd implemented it.
> 
> 
> What is bad with them? We can always imagine a better format,
> but I do
> not think that systemd unit files are somehow terribly wrong.
> 
> Is it about a set of user processes running during the login
> process ?
> If so, I suppose it's out of scope the init system, it's
> some kind of
> extra feature.
> 
> 
> In the user session you might be dealing with same tasks as in the
> system session – e.g. service dependencies (run them in the correct
> order) or that socket activation. And if you implement it in the
> system-wide init system, it would be nice to be able to run another
> instance of the same daemon in the user-session and enjoy same
> features
> there – i.e. same tools or same format of config files. And it
> would be
> independent from the desktop environment / window manager, so
> you can
> run same services in KDE, Gnome, Xfce, Window maker atc.
> 
> 
> it's actually the same mechanics, and I've got your point. So
> let's me
> describe my thoughts about init system itself.
> 
> Let's split init system:
> - (a) init (a POSIX PID 1)
> - (b) daemon 'starter'
> - (c) daemon 'watchdog'
> - (d) tools?
> 
> Regarding 'a': this guy should be kept a very small, stable and
> simple.
> For 'b', 'c' and might be 'd' the best way is to create a shared
> library
> with all necessary functions. That means b,c and d might works
> anywhere
> and independently on 'a'.
> 
> The next step is to define a functional scope of init system, let's
> assume:
> - os state support (SySV runlevels as example)
> - FS mount
> - Orphaned process handling
> - Networking
> - Daemons startup/shutdown process
> From my point of view PID

Re: systemd replacement or standardization

[marinus.savoritias]

So since we have GNU Shepherd and it will keep being developed why don't we ask 
GNOME on their stance?

By that I mean, GNOME has moved away from GNU build tools and requires Systemd 
(I aknowldge you can replace it with forks but still). I remember reading about 
a discussion to remove the acronym too.

So in my opinion, we should reevaluate whether GNOME is a part of GNU and how 
open are they to reintegrate to GNU if the right tools are developed. If not, 
there are plenty of environments which are open and were open in the past to 
not be tied to one technology. XFCE,KDE etc.

The GNU desktop environment should be integrated with GNU in my opinion.

Fannys

Oct 15, 2019, 11:56 by rek...@elephly.net:

>
> marinus.savorit...@tuta.io writes:
>
>> So do we endorse systemd and stop developing GNU Shepherd, or
>> reevaluate if GNOME fits with the rest of the GNU system?
>>
>
> At least from a Guix point of view we will not stop developing GNU
> Shepherd because it allows us to easily use features from Guix
> (e.g. containerized daemons) via Guile.
>
> Past Google Summer of Code and Outreachy project proposals included the
> implementation of socket activation (a feature that systemd provides),
> cgroups support when Linux is used, and a superficial language to allow
> reuse of declarative systemd service unit files for direct use with the
> Shepherd.
>
> --
> Ricardo
>

Re: systemd replacement or standardization

[Ricardo Wurmus]

marinus.savorit...@tuta.io writes:

> So do we endorse systemd and stop developing GNU Shepherd, or
> reevaluate if GNOME fits with the rest of the GNU system?

At least from a Guix point of view we will not stop developing GNU
Shepherd because it allows us to easily use features from Guix
(e.g. containerized daemons) via Guile.

Past Google Summer of Code and Outreachy project proposals included the
implementation of socket activation (a feature that systemd provides),
cgroups support when Linux is used, and a superficial language to allow
reuse of declarative systemd service unit files for direct use with the
Shepherd.

--
Ricardo

Re: systemd replacement or standardization

[marinus.savoritias]

What events? Can you link?

Fannys

Oct 14, 2019, 23:32 by a...@vapaa.xyz:

>
>
> On 10/15/19 12:12 AM, marinus.savorit...@tuta.io wrote:
>
>> Hi,
>>
>> Pardon for my ignorance but why not GNU Shepherd which is already
>> developed to be the GNU init system and process supervisor? It is
>> already used by GUIX.
>>
>
> The problem with it are follow:
>  - there are no clear specification to work with
>  - I'd love to use scheme language (GNU Guile), but it's not always
> possible (embedded as example)
>  - according to the last events I need to accept some political views I
> wouldn't to
>
> btw, init system used in guix is very nice from my point of view.
>
>>
>> Fannys
>>
>>
>> Oct 14, 2019, 23:03 by a...@vapaa.xyz:
>>
>>
>>
>>  On 10/14/19 10:57 PM, František Kučera wrote:
>>
>>  Dne 14. 10. 19 v 19:54 Alexander Vdolainen napsal(a):
>>
>>  It looks like a xinetd new feature, but - do we really need
>>  a dbus?
>>
>>
>>  I wrote only one D-Bus service and quite simple, so I do not feel
>>  capable to say how much useful is socket activation in this
>>  case. D-Bus
>>  might be an optional feature.
>>
>>  However, I am sure that socket inheritance and activation for unix
>>  domain sockets is useful and needed. Improvement of xinetd (or other
>>  superserver) would be great.
>>
>>
>>  yep, but I found https://github.com/xinetd-org/xinetd looks like
>>  abandoned (and xinetd.org was unable to load anything). However it's
>>  still possible to add this feature, but is it xinetd still used?
>>
>>  But I rather prefer this feature in the
>>  init system. This feature is generic enough and directly linked to
>>  process/service execution, so IMHO it is a task for an init system.
>>
>>
>>  Make sense, but check out a more extended reply to this below.
>>
>>  But not in a way systemd implemented it.
>>
>>
>>  What is bad with them? We can always imagine a better format,
>>  but I do
>>  not think that systemd unit files are somehow terribly wrong.
>>
>>  Is it about a set of user processes running during the login
>>  process ?
>>  If so, I suppose it's out of scope the init system, it's
>>  some kind of
>>  extra feature.
>>
>>
>>  In the user session you might be dealing with same tasks as in the
>>  system session – e.g. service dependencies (run them in the correct
>>  order) or that socket activation. And if you implement it in the
>>  system-wide init system, it would be nice to be able to run another
>>  instance of the same daemon in the user-session and enjoy same
>>  features
>>  there – i.e. same tools or same format of config files. And it
>>  would be
>>  independent from the desktop environment / window manager, so
>>  you can
>>  run same services in KDE, Gnome, Xfce, Window maker atc.
>>
>>
>>  it's actually the same mechanics, and I've got your point. So let's me
>>  describe my thoughts about init system itself.
>>
>>  Let's split init system:
>>  - (a) init (a POSIX PID 1)
>>  - (b) daemon 'starter'
>>  - (c) daemon 'watchdog'
>>  - (d) tools?
>>
>>  Regarding 'a': this guy should be kept a very small, stable and simple.
>>  For 'b', 'c' and might be 'd' the best way is to create a shared library
>>  with all necessary functions. That means b,c and d might works anywhere
>>  and independently on 'a'.
>>
>>  The next step is to define a functional scope of init system, let's
>>  assume:
>>  - os state support (SySV runlevels as example)
>>  - FS mount
>>  - Orphaned process handling
>>  - Networking
>>  - Daemons startup/shutdown process
>>  From my point of view PID 1 - 'a' works with:
>>  - OS states support
>>  - Orphaned process handling
>>  Other functionality is going to the other parts are working
>>  independently ('b', 'c' and 'd's), but still able to sync somehow
>>  (without DBus).
>>  To do so, a few abstractions are coming onto play:
>>  - daemon (yep - just an old good daemon)
>>  - service: a named set of some resources
>>  - sublevel: a sub runlevel
>>  All this things are *not* require a DBus, binary logs, libshitd
>>  incorporated into daemons etc ...
>>
>>   - Have a stable and standardized API: e.g. if some
>>  service takes
>>  advantage 

Re: systemd replacement or standardization

[Alexander Vdolainen]

On 10/15/19 12:12 AM, marinus.savorit...@tuta.io wrote:
> Hi,
> 
> Pardon for my ignorance but why not GNU Shepherd which is already
> developed to be the GNU init system and process supervisor? It is
> already used by GUIX.

The problem with it are follow:
 - there are no clear specification to work with
 - I'd love to use scheme language (GNU Guile), but it's not always
possible (embedded as example)
 - according to the last events I need to accept some political views I
wouldn't to

btw, init system used in guix is very nice from my point of view.

> 
> Fannys
> 
> 
> Oct 14, 2019, 23:03 by a...@vapaa.xyz:
> 
> 
> 
> On 10/14/19 10:57 PM, František Kučera wrote:
> 
> Dne 14. 10. 19 v 19:54 Alexander Vdolainen napsal(a):
> 
> It looks like a xinetd new feature, but - do we really need
> a dbus?
> 
> 
> I wrote only one D-Bus service and quite simple, so I do not feel
> capable to say how much useful is socket activation in this
> case. D-Bus
> might be an optional feature.
> 
> However, I am sure that socket inheritance and activation for unix
> domain sockets is useful and needed. Improvement of xinetd (or other
> superserver) would be great.
> 
> 
> yep, but I found https://github.com/xinetd-org/xinetd looks like
> abandoned (and xinetd.org was unable to load anything). However it's
> still possible to add this feature, but is it xinetd still used?
> 
> But I rather prefer this feature in the
> init system. This feature is generic enough and directly linked to
> process/service execution, so IMHO it is a task for an init system.
> 
> 
> Make sense, but check out a more extended reply to this below.
> 
> But not in a way systemd implemented it.
> 
> 
> What is bad with them? We can always imagine a better format,
> but I do
> not think that systemd unit files are somehow terribly wrong.
> 
> Is it about a set of user processes running during the login
> process ?
> If so, I suppose it's out of scope the init system, it's
> some kind of
> extra feature.
> 
> 
> In the user session you might be dealing with same tasks as in the
> system session – e.g. service dependencies (run them in the correct
> order) or that socket activation. And if you implement it in the
> system-wide init system, it would be nice to be able to run another
> instance of the same daemon in the user-session and enjoy same
> features
> there – i.e. same tools or same format of config files. And it
> would be
> independent from the desktop environment / window manager, so
> you can
> run same services in KDE, Gnome, Xfce, Window maker atc.
> 
> 
> it's actually the same mechanics, and I've got your point. So let's me
> describe my thoughts about init system itself.
> 
> Let's split init system:
> - (a) init (a POSIX PID 1)
> - (b) daemon 'starter'
> - (c) daemon 'watchdog'
> - (d) tools?
> 
> Regarding 'a': this guy should be kept a very small, stable and simple.
> For 'b', 'c' and might be 'd' the best way is to create a shared library
> with all necessary functions. That means b,c and d might works anywhere
> and independently on 'a'.
> 
> The next step is to define a functional scope of init system, let's
> assume:
> - os state support (SySV runlevels as example)
> - FS mount
> - Orphaned process handling
> - Networking
> - Daemons startup/shutdown process
> From my point of view PID 1 - 'a' works with:
> - OS states support
> - Orphaned process handling
> Other functionality is going to the other parts are working
> independently ('b', 'c' and 'd's), but still able to sync somehow
> (without DBus).
> To do so, a few abstractions are coming onto play:
> - daemon (yep - just an old good daemon)
> - service: a named set of some resources
> - sublevel: a sub runlevel
> All this things are *not* require a DBus, binary logs, libshitd
> incorporated into daemons etc ...
> 
>  - Have a stable and standardized API: e.g. if some
> service takes
> advantage of the socket activation feature, it would be
> possible to
> start such service from another i

Re: systemd replacement or standardization

[marinus.savoritias]

I agree completely on your first point. It would make a lot of work much easier 
in porting. 
On the second part I have to admit I don't have the knowledge to know what is 
missing. 

Thanks for the reply,
Fannys

Oct 14, 2019, 23:24 by konfere...@frantovo.cz:

> Dne 14. 10. 19 v 23:12 > marinus.savorit...@tuta.io 
> <mailto:marinus.savorit...@tuta.io>>  napsal(a):
>
>> Pardon for my ignorance butwhy not GNU Shepherd which is already 
>> developed to be the GNUinit system and process supervisor? It is 
>> already used by GUIX.
>>
>
> My intention was not to invent another init system. I rather  suggest:
>
>
> a) Create some stable API / standard and persuade systemd to  adopt it 
> (this might be too optimistic), so application will not  depend on a 
> particular init system (like systemd) but rather on a  well-defined 
> standard (and any init system might implement this  standard).
>
>
> b) Improve existing init system (like GNU Shepherd), so they will  offer 
> same useful features like systemd (with much less complexity  and with 
> better architecture).
>
>
> Franta
>
>

Re: systemd replacement or standardization

[František Kučera]

Dne 14. 10. 19 v 23:12 marinus.savorit...@tuta.io napsal(a):
> Pardon for my ignorance but why not GNU Shepherd which is already
> developed to be the GNU init system and process supervisor? It is
> already used by GUIX.

My intention was not to invent another init system. I rather suggest:

a) Create some stable API / standard and persuade systemd to adopt it
(this might be too optimistic), so application will not depend on a
particular init system (like systemd) but rather on a well-defined
standard (and any init system might implement this standard).

b) Improve existing init system (like GNU Shepherd), so they will offer
same useful features like systemd (with much less complexity and with
better architecture).

Franta

Re: systemd replacement or standardization

[marinus.savoritias]

Hi,

Pardon for my ignorance but why not GNU Shepherd which is already developed to 
be the GNU init system and process supervisor? It is already used by GUIX.

Fannys

Oct 14, 2019, 23:03 by a...@vapaa.xyz:

>
>
> On 10/14/19 10:57 PM, František Kučera wrote:
>
>> Dne 14. 10. 19 v 19:54 Alexander Vdolainen napsal(a):
>>
>>> It looks like a xinetd new feature, but - do we really need a dbus?
>>>
>>
>> I wrote only one D-Bus service and quite simple, so I do not feel
>> capable to say how much useful is socket activation in this case. D-Bus
>> might be an optional feature.
>>
>> However, I am sure that socket inheritance and activation for unix
>> domain sockets is useful and needed. Improvement of xinetd (or other
>> superserver) would be great.
>>
>
> yep, but I found https://github.com/xinetd-org/xinetd looks like
> abandoned (and xinetd.org was unable to load anything). However it's
> still possible to add this feature, but is it xinetd still used?
>
>> But I rather prefer this feature in the
>> init system. This feature is generic enough and directly linked to
>> process/service execution, so IMHO it is a task for an init system.
>>
>
> Make sense, but check out a more extended reply to this below.
>
>>> But not in a way systemd implemented it.
>>>
>>
>> What is bad with them? We can always imagine a better format, but I do
>> not think that systemd unit files are somehow terribly wrong.
>>
>>> Is it about a set of user processes running during the login process ?
>>> If so, I suppose it's out of scope the init system, it's some kind of
>>> extra feature.
>>>
>>
>> In the user session you might be dealing with same tasks as in the
>> system session – e.g. service dependencies (run them in the correct
>> order) or that socket activation. And if you implement it in the
>> system-wide init system, it would be nice to be able to run another
>> instance of the same daemon in the user-session and enjoy same features
>> there – i.e. same tools or same format of config files. And it would be
>> independent from the desktop environment / window manager, so you can
>> run same services in KDE, Gnome, Xfce, Window maker atc.
>>
>
> it's actually the same mechanics, and I've got your point. So let's me
> describe my thoughts about init system itself.
>
> Let's split init system:
>  - (a) init (a POSIX PID 1)
>  - (b) daemon 'starter'
>  - (c) daemon 'watchdog'
>  - (d) tools?
>
> Regarding 'a': this guy should be kept a very small, stable and simple.
> For 'b', 'c' and might be 'd' the best way is to create a shared library
> with all necessary functions. That means b,c and d might works anywhere
> and independently on 'a'.
>
> The next step is to define a functional scope of init system, let's assume:
>  - os state support (SySV runlevels as example)
>  - FS mount
>  - Orphaned process handling
>  - Networking
>  - Daemons startup/shutdown process
> From my point of view PID 1 - 'a' works with:
>  - OS states support
>  - Orphaned process handling
> Other functionality is going to the other parts are working
> independently ('b', 'c' and 'd's), but still able to sync somehow
> (without DBus).
> To do so, a few abstractions are coming onto play:
>  - daemon (yep - just an old good daemon)
>  - service: a named set of some resources
>  - sublevel: a sub runlevel
> All this things are *not* require a DBus, binary logs, libshitd
> incorporated into daemons etc ...
>
>>>>  - Have a stable and standardized API: e.g. if some service takes
>>>> advantage of the socket activation feature, it would be possible to
>>>> start such service from another init system without loosing this useful
>>>> feature and without the need of changing the source code. (note that it
>>>> is not as easy as it looks because the service might use several sockets
>>>> and you need an API to say, which FD is which socket e.g. one socket for
>>>> management and several sockets for accepting client connections or one
>>>> for encrypted and one for unencrypted communication, or one for IMAP4
>>>> and one for POP3) Or some watchdog API to check whether the service is
>>>> running properly or it is jammed.
>>>>
>>> I suppose to not follow the systemd story to be so invasive. It should
>>> be quite optional.
>>>
>>
>> The API might be just a set of stand

Re: systemd replacement or standardization

[Alexander Vdolainen]

On 10/14/19 10:57 PM, František Kučera wrote:
> Dne 14. 10. 19 v 19:54 Alexander Vdolainen napsal(a):
>> It looks like a xinetd new feature, but - do we really need a dbus?
> 
> I wrote only one D-Bus service and quite simple, so I do not feel
> capable to say how much useful is socket activation in this case. D-Bus
> might be an optional feature.
> 
> However, I am sure that socket inheritance and activation for unix
> domain sockets is useful and needed. Improvement of xinetd (or other
> superserver) would be great.

yep, but I found https://github.com/xinetd-org/xinetd looks like
abandoned (and xinetd.org was unable to load anything). However it's
still possible to add this feature, but is it xinetd still used?

> But I rather prefer this feature in the
> init system. This feature is generic enough and directly linked to
> process/service execution, so IMHO it is a task for an init system.

Make sense, but check out a more extended reply to this below.

> 
>> But not in a way systemd implemented it.
> 
> What is bad with them? We can always imagine a better format, but I do
> not think that systemd unit files are somehow terribly wrong.
> 
>> Is it about a set of user processes running during the login process ?
>> If so, I suppose it's out of scope the init system, it's some kind of
>> extra feature.
> 
> In the user session you might be dealing with same tasks as in the
> system session – e.g. service dependencies (run them in the correct
> order) or that socket activation. And if you implement it in the
> system-wide init system, it would be nice to be able to run another
> instance of the same daemon in the user-session and enjoy same features
> there – i.e. same tools or same format of config files. And it would be
> independent from the desktop environment / window manager, so you can
> run same services in KDE, Gnome, Xfce, Window maker atc.

it's actually the same mechanics, and I've got your point. So let's me
describe my thoughts about init system itself.

Let's split init system:
 - (a) init (a POSIX PID 1)
 - (b) daemon 'starter'
 - (c) daemon 'watchdog'
 - (d) tools?

Regarding 'a': this guy should be kept a very small, stable and simple.
For 'b', 'c' and might be 'd' the best way is to create a shared library
with all necessary functions. That means b,c and d might works anywhere
and independently on 'a'.

The next step is to define a functional scope of init system, let's assume:
 - os state support (SySV runlevels as example)
 - FS mount
 - Orphaned process handling
 - Networking
 - Daemons startup/shutdown process
From my point of view PID 1 - 'a' works with:
 - OS states support
 - Orphaned process handling
Other functionality is going to the other parts are working
independently ('b', 'c' and 'd's), but still able to sync somehow
(without DBus).
To do so, a few abstractions are coming onto play:
 - daemon (yep - just an old good daemon)
 - service: a named set of some resources
 - sublevel: a sub runlevel
All this things are *not* require a DBus, binary logs, libshitd
incorporated into daemons etc ...

> 
>>>  - Have a stable and standardized API: e.g. if some service takes
>>> advantage of the socket activation feature, it would be possible to
>>> start such service from another init system without loosing this useful
>>> feature and without the need of changing the source code. (note that it
>>> is not as easy as it looks because the service might use several sockets
>>> and you need an API to say, which FD is which socket e.g. one socket for
>>> management and several sockets for accepting client connections or one
>>> for encrypted and one for unencrypted communication, or one for IMAP4
>>> and one for POP3) Or some watchdog API to check whether the service is
>>> running properly or it is jammed.
>> I suppose to not follow the systemd story to be so invasive. It should
>> be quite optional.
> 
> The API might be just a set of standardized environment variables. It do
> not have to require even a single header file. One variable might
> contain comma separated list of inherited FDs and then you will check
> e.g. INHERITED_FD_5_TYPE and see that this should be IMAP socket, so you
> will respond to IMAP requests on it. Then check INHERITED_FD_6_TYPE and
> see that this socket should be POP3.

... could you provide some working example for this ?

> 
> This is not invasive, you can use any language and you do not have to
> depend on any library or header file. Such standard would be very simple
> and anyone would be able to implement it.

IMO, if you need to adopt your daemon for some sy

Re: systemd replacement or standardization

[marinus.savoritias]

Hi,

I agree too. Systemd has too much Corporate interests for my taste.
Good or not ,(I agree is too bloated and has a history of contributor 
hostility), it is integrated with GNOME now.

So the questions we need to ask ourselves are:

1) Do we want to commit to Systemd or find something else?
2) Are we good with something corporate/profit driven or do we want something 
community based?

Right now GNU has failed to go into any direction paralized and left in the 
past. The official environment of GNU doesn't even use GNU tools anymore. 

So do we endorse systemd and stop developing GNU Shepherd, or reevaluate if 
GNOME fits with the rest of the GNU system?

Regards,Fannys

Oct 14, 2019, 19:54 by a...@vapaa.xyz:

> Hi,
>
> On 10/14/19 2:22 PM, František Kučera wrote:
>
>> In <https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00322.html>
>> Svante Signell touched the topic of systemd. I think that it deserves
>> its own thread.
>>
>
> That's for sure!
>
>>
>> I like several features of systemd:
>>
>>  - Socket activation: the service might inherit a file descriptor (FD)
>> with an open socket (TCP, UDP, unix domain socket, D-Bus) and not only
>> that: the service can be lazily-started when the first request comes to
>> the socket. It is similar to xinetd, but supports more socket types and
>> seems overall better.
>>
>
> It looks like a xinetd new feature, but - do we really need a dbus?
>
>>
>>  - Declarative configuration: a simple service can be described in a few
>> lines of config file. No procedural scripting or boilerplate code is
>> necessary.
>>
>
> But not in a way systemd implemented it.
>
>>
>>  - User-defined services – not only system-wide (root) ones.
>>
>
> Is it about a set of user processes running during the login process ?
> If so, I suppose it's out of scope the init system, it's some kind of
> extra feature.
>
>>
>> But I also seriously hate several features of systemd:
>>
>
> I don't like systemd at all, but it's offtopic.
>
>>
>>  - Complexity: circa 480 000 lines of code (and still growing).
>>
>>  - Monolithic design: it is a single repository containing too much
>> features and tools. And if you like only certain features, there is no
>> easy way how to pick just them and enjoy less complexity.
>>
>>  - Versioning: wrong versioning scheme (not semantic) and lack of stable
>> and standardized API.
>>
>> Yes, we have GNU Shepherd and many other init systems and we can convert
>> users/distributions from systemd to other init system. But what about
>> doing – at the same time – some kind of „damage control“? Because we
>> already live in the world where systemd is widespread. Some ideas:
>>
>
> GNU Shepherd is a nice thing however.
>
>>
>>  - Have a stable and standardized API: e.g. if some service takes
>> advantage of the socket activation feature, it would be possible to
>> start such service from another init system without loosing this useful
>> feature and without the need of changing the source code. (note that it
>> is not as easy as it looks because the service might use several sockets
>> and you need an API to say, which FD is which socket e.g. one socket for
>> management and several sockets for accepting client connections or one
>> for encrypted and one for unencrypted communication, or one for IMAP4
>> and one for POP3) Or some watchdog API to check whether the service is
>> running properly or it is jammed.
>>
>
> I suppose to not follow the systemd story to be so invasive. It should
> be quite optional.
>
>>
>>  - Convert – or even load at runtime – the systemd declarative
>> configuration files. This also requires a stable standard.
>>
>>  - Implement useful features of systemd in other init systems or
>> software: like implementing socket activation feature in another init
>> system or adding the unix domain socket support to xinetd[1]. It would
>> be a great „selling point“ if we can say: „we can provide same useful
>> features as systemd but with just a fraction of its complexity and in a
>> modular way (so you install only features, you need)“.
>>
>
> I can start with that, because by a strange coincidence I have had a
> problem starting a set of daemons properly. Well, in my case there are a
> few daemons depends on other daemon and/or other service (service is a
> udp/tcp/unix socket(s)). Another problem was a requirement to start
> those daemons as soon as possible. Finally - I do *not* want to modify
> code of the well working daemons (and this

Re: systemd replacement or standardization

[František Kučera]

Dne 14. 10. 19 v 19:54 Alexander Vdolainen napsal(a):
> It looks like a xinetd new feature, but - do we really need a dbus?

I wrote only one D-Bus service and quite simple, so I do not feel
capable to say how much useful is socket activation in this case. D-Bus
might be an optional feature.

However, I am sure that socket inheritance and activation for unix
domain sockets is useful and needed. Improvement of xinetd (or other
superserver) would be great. But I rather prefer this feature in the
init system. This feature is generic enough and directly linked to
process/service execution, so IMHO it is a task for an init system.

> But not in a way systemd implemented it.

What is bad with them? We can always imagine a better format, but I do
not think that systemd unit files are somehow terribly wrong.

> Is it about a set of user processes running during the login process ?
> If so, I suppose it's out of scope the init system, it's some kind of
> extra feature.

In the user session you might be dealing with same tasks as in the
system session – e.g. service dependencies (run them in the correct
order) or that socket activation. And if you implement it in the
system-wide init system, it would be nice to be able to run another
instance of the same daemon in the user-session and enjoy same features
there – i.e. same tools or same format of config files. And it would be
independent from the desktop environment / window manager, so you can
run same services in KDE, Gnome, Xfce, Window maker atc.

>>  - Have a stable and standardized API: e.g. if some service takes
>> advantage of the socket activation feature, it would be possible to
>> start such service from another init system without loosing this useful
>> feature and without the need of changing the source code. (note that it
>> is not as easy as it looks because the service might use several sockets
>> and you need an API to say, which FD is which socket e.g. one socket for
>> management and several sockets for accepting client connections or one
>> for encrypted and one for unencrypted communication, or one for IMAP4
>> and one for POP3) Or some watchdog API to check whether the service is
>> running properly or it is jammed.
> I suppose to not follow the systemd story to be so invasive. It should
> be quite optional.

The API might be just a set of standardized environment variables. It do
not have to require even a single header file. One variable might
contain comma separated list of inherited FDs and then you will check
e.g. INHERITED_FD_5_TYPE and see that this should be IMAP socket, so you
will respond to IMAP requests on it. Then check INHERITED_FD_6_TYPE and
see that this socket should be POP3.

This is not invasive, you can use any language and you do not have to
depend on any library or header file. Such standard would be very simple
and anyone would be able to implement it.

> I can start with that, because by a strange coincidence I have had a
> problem starting a set of daemons properly. Well, in my case there are a
> few daemons depends on other daemon and/or other service (service is a
> udp/tcp/unix socket(s)). 

I am quite interested in unix domain sockets. Recently, I played with
them in Java <https://blog.frantovo.cz/c/372/> which officially does not
support them but is able to inherit an FD – so I was able to make e.g.
Jetty or Tomcat HTTP servers listen on an inherited unix domain socket.
It was quite fun. I did also a proof-of-concept of full unix domain
socket support for Java <http://frantovo.cz/disk/openjdk-uds-08/> and
offered it to OpenJDK, but they have not accepted it yet
<https://mail.openjdk.java.net/pipermail/net-dev/2019-July/012908.html>
(it seems that they would rather implement it themselves – but at least
someone from OpenJDK is working on it now).

> Going back to the systemd replacing - it might be done and, personally I
> want to replace it, but needless to say it's a huge effort for one man.
> BTW I suppose the following things should be taken onto account:
>  - this new init should be a set of optional things like tools and daemons
>  - new init shouldn't looks like a systemd-mess
>  - sw architecture should be proposed first
>  - features should be determined firstly

Definitely. The core of the init system must be separated from various
daemons/services that must be optional. Things like DNS or HTTP server
are not part of an init system and should be distributed as an optional
module.

Franta




signature.asc
Description: OpenPGP digital signature

Re: systemd replacement or standardization

[Alexander Vdolainen]

Hi,

On 10/14/19 9:33 PM, marinus.savorit...@tuta.io wrote:
> Hi,
> 
> I agree too. Systemd has too much Corporate interests for my taste.
> Good or not ,(I agree is too bloated and has a history of contributor
> hostility), it is integrated with GNOME now.
> 
> So the questions we need to ask ourselves are:
> 
> 1) Do we want to commit to Systemd or find something else?

I suppose everybody can decide it for himself, but personally I don't
like systemd, so I will never be interested in committing for this
project. Systemd is ugly from many points of view.

> 2) Are we good with something corporate/profit driven or do we want
> something community based?

We're certainly need something corporate independent for the open and
free operating system.

> 
> Right now GNU has failed to go into any direction paralized and left in
> the past. The official environment of GNU doesn't even use GNU tools
> anymore. 
> 
> So do we endorse systemd and stop developing GNU Shepherd, or
> reevaluate if GNOME fits with the rest of the GNU system?

As I asked before - are there somebody ready to commit for the other
init system with systemd features?

As I understood nobody is even interested on that, but yep - I've heard
a lot of "systemd sucks" critics.

> 
> Regards,
> Fannys
> 
> Oct 14, 2019, 19:54 by a...@vapaa.xyz:
> 
> Hi,
> 
> On 10/14/19 2:22 PM, František Kučera wrote:
> 
> In
> <https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00322.html>
> Svante Signell touched the topic of systemd. I think that it
> deserves
> its own thread.
> 
> 
> That's for sure!
> 
> 
> I like several features of systemd:
> 
>  - Socket activation: the service might inherit a file
> descriptor (FD)
> with an open socket (TCP, UDP, unix domain socket, D-Bus) and
> not only
> that: the service can be lazily-started when the first request
> comes to
> the socket. It is similar to xinetd, but supports more socket
> types and
> seems overall better.
> 
> 
> It looks like a xinetd new feature, but - do we really need a dbus?
> 
> 
>  - Declarative configuration: a simple service can be described
> in a few
> lines of config file. No procedural scripting or boilerplate code is
> necessary.
> 
> 
> But not in a way systemd implemented it.
> 
> 
>  - User-defined services – not only system-wide (root) ones.
> 
> 
> Is it about a set of user processes running during the login process ?
> If so, I suppose it's out of scope the init system, it's some kind of
> extra feature.
> 
> 
> But I also seriously hate several features of systemd:
> 
> 
> I don't like systemd at all, but it's offtopic.
> 
> 
>  - Complexity: circa 480 000 lines of code (and still growing).
> 
>  - Monolithic design: it is a single repository containing too much
> features and tools. And if you like only certain features, there
> is no
> easy way how to pick just them and enjoy less complexity.
> 
>  - Versioning: wrong versioning scheme (not semantic) and lack
> of stable
> and standardized API.
> 
> Yes, we have GNU Shepherd and many other init systems and we can
> convert
> users/distributions from systemd to other init system. But what
> about
> doing – at the same time – some kind of „damage control“? Because we
> already live in the world where systemd is widespread. Some ideas:
> 
> 
> GNU Shepherd is a nice thing however.
> 
> 
>  - Have a stable and standardized API: e.g. if some service takes
> advantage of the socket activation feature, it would be possible to
> start such service from another init system without loosing this
> useful
> feature and without the need of changing the source code. (note
> that it
> is not as easy as it looks because the service might use several
> sockets
> and you need an API to say, which FD is which socket e.g. one
> socket for
> management and several sockets for accepting client connections
> or one
> for encrypted and one for unencrypted communication, or one for
> IMAP4
> and one for POP3) Or some watchdog API to check whether the
> service is
> running properly or it is jammed.
> 
> 
> I suppose to not follow the systemd story to be so invasive. It shou

Re: systemd replacement or standardization

[Alexander Vdolainen]

Hi,

On 10/14/19 2:22 PM, František Kučera wrote:
> In <https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00322.html>
> Svante Signell touched the topic of systemd. I think that it deserves
> its own thread.

That's for sure!

> 
> I like several features of systemd:
> 
>  - Socket activation: the service might inherit a file descriptor (FD)
> with an open socket (TCP, UDP, unix domain socket, D-Bus) and not only
> that: the service can be lazily-started when the first request comes to
> the socket. It is similar to xinetd, but supports more socket types and
> seems overall better.

It looks like a xinetd new feature, but - do we really need a dbus?

> 
>  - Declarative configuration: a simple service can be described in a few
> lines of config file. No procedural scripting or boilerplate code is
> necessary.

But not in a way systemd implemented it.

> 
>  - User-defined services – not only system-wide (root) ones.

Is it about a set of user processes running during the login process ?
If so, I suppose it's out of scope the init system, it's some kind of
extra feature.

> 
> But I also seriously hate several features of systemd:

I don't like systemd at all, but it's offtopic.

> 
>  - Complexity: circa 480 000 lines of code (and still growing).
> 
>  - Monolithic design: it is a single repository containing too much
> features and tools. And if you like only certain features, there is no
> easy way how to pick just them and enjoy less complexity.
> 
>  - Versioning: wrong versioning scheme (not semantic) and lack of stable
> and standardized API.
> 
> Yes, we have GNU Shepherd and many other init systems and we can convert
> users/distributions from systemd to other init system. But what about
> doing – at the same time – some kind of „damage control“? Because we
> already live in the world where systemd is widespread. Some ideas:

GNU Shepherd is a nice thing however.

> 
>  - Have a stable and standardized API: e.g. if some service takes
> advantage of the socket activation feature, it would be possible to
> start such service from another init system without loosing this useful
> feature and without the need of changing the source code. (note that it
> is not as easy as it looks because the service might use several sockets
> and you need an API to say, which FD is which socket e.g. one socket for
> management and several sockets for accepting client connections or one
> for encrypted and one for unencrypted communication, or one for IMAP4
> and one for POP3) Or some watchdog API to check whether the service is
> running properly or it is jammed.

I suppose to not follow the systemd story to be so invasive. It should
be quite optional.

> 
>  - Convert – or even load at runtime – the systemd declarative
> configuration files. This also requires a stable standard.
> 
>  - Implement useful features of systemd in other init systems or
> software: like implementing socket activation feature in another init
> system or adding the unix domain socket support to xinetd[1]. It would
> be a great „selling point“ if we can say: „we can provide same useful
> features as systemd but with just a fraction of its complexity and in a
> modular way (so you install only features, you need)“.

I can start with that, because by a strange coincidence I have had a
problem starting a set of daemons properly. Well, in my case there are a
few daemons depends on other daemon and/or other service (service is a
udp/tcp/unix socket(s)). Another problem was a requirement to start
those daemons as soon as possible. Finally - I do *not* want to modify
code of the well working daemons (and this is a bad way to get it
works). So, I have decided to write another daemon runs them in a right
order, waits for the sockets, solve dependencies etc ...
Some code pieces might be located on sf.net, but I don't expect someone
else might have a real interest with that.
(but I need to point here - it works on linux only (relies on /proc and
inotify() I guess))

I'm not sure is it interesting or not, however if somebody will join
with that - I can spend some of my spare time with that.

Going back to the systemd replacing - it might be done and, personally I
want to replace it, but needless to say it's a huge effort for one man.
BTW I suppose the following things should be taken onto account:
 - this new init should be a set of optional things like tools and daemons
 - new init shouldn't looks like a systemd-mess
 - sw architecture should be proposed first
 - features should be determined firstly

> 
> Franta
> 
> P.S. I might missed some news. It is some time since I studied various
> init systems and compared them. So if something is already happening or
> done, I would be happy to hear about it.

systemd 

systemd replacement or standardization

[František Kučera]

In <https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00322.html>
Svante Signell touched the topic of systemd. I think that it deserves
its own thread.

I like several features of systemd:

 - Socket activation: the service might inherit a file descriptor (FD)
with an open socket (TCP, UDP, unix domain socket, D-Bus) and not only
that: the service can be lazily-started when the first request comes to
the socket. It is similar to xinetd, but supports more socket types and
seems overall better.

 - Declarative configuration: a simple service can be described in a few
lines of config file. No procedural scripting or boilerplate code is
necessary.

 - User-defined services – not only system-wide (root) ones.

But I also seriously hate several features of systemd:

 - Complexity: circa 480 000 lines of code (and still growing).

 - Monolithic design: it is a single repository containing too much
features and tools. And if you like only certain features, there is no
easy way how to pick just them and enjoy less complexity.

 - Versioning: wrong versioning scheme (not semantic) and lack of stable
and standardized API.

Yes, we have GNU Shepherd and many other init systems and we can convert
users/distributions from systemd to other init system. But what about
doing – at the same time – some kind of „damage control“? Because we
already live in the world where systemd is widespread. Some ideas:

 - Have a stable and standardized API: e.g. if some service takes
advantage of the socket activation feature, it would be possible to
start such service from another init system without loosing this useful
feature and without the need of changing the source code. (note that it
is not as easy as it looks because the service might use several sockets
and you need an API to say, which FD is which socket e.g. one socket for
management and several sockets for accepting client connections or one
for encrypted and one for unencrypted communication, or one for IMAP4
and one for POP3) Or some watchdog API to check whether the service is
running properly or it is jammed.

 - Convert – or even load at runtime – the systemd declarative
configuration files. This also requires a stable standard.

 - Implement useful features of systemd in other init systems or
software: like implementing socket activation feature in another init
system or adding the unix domain socket support to xinetd[1]. It would
be a great „selling point“ if we can say: „we can provide same useful
features as systemd but with just a fraction of its complexity and in a
modular way (so you install only features, you need)“.

Franta

P.S. I might missed some news. It is some time since I studied various
init systems and compared them. So if something is already happening or
done, I would be happy to hear about it.

[1] yes, I know that it collides with the xinetd/inetd name which means
„internet daemon“ and AF_UNIX != AF_INET, but…