[Dng] Is it useful to create a .so file to replace functions imported from libsystemd & Co.?

[Edward Bartolo]

I am using lsof together with objdump -T executable to determine what
systemd functions are imported by essential XFCE4 executables.

For instance, this is for /usr/lib/gvfs/gvfs-udisks2-volume-monitor:

  DF *UND*    LIBSYSTEMD_209
sd_session_get_seat
  DF *UND*  
udisks_object_get_type
  DF *UND*  
g_dbus_interface_get_type
  DF *UND*    g_object_set_data
  DF *UND*    
g_value_set_variant
  DF *UND*    g_volume_get_drive
  DF *UND*  
g_drive_is_media_check_automatic
  DF *UND*  
udisks_block_get_id_label
  DF *UND*    
g_error_new_literal
  DF *UND*  
udisks_filesystem_get_mount_points
  DF *UND*  
g_timeout_source_new_seconds
  DF *UND*  
udisks_object_info_get_description
  DF *UND*  
g_io_channel_set_flags
  DF *UND*    
g_variant_iter_free
  DF *UND*  
g_drive_get_identifier
  DF *UND*  
g_main_context_ref_thread_default
  DF *UND*  
udisks_client_peek_object
  DF *UND*    g_type_class_peek
  DF *UND*    g_variant_lookup
  DF *UND*    g_strdup_vprintf
  DF *UND*  
udisks_block_dup_id_uuid
  DF *UND*  
g_unix_mount_get_fs_type
  DF *UND*  
g_unix_mount_point_get_options
  DF *UND*  
g_signal_accumulator_true_handled
  DF *UND*  
g_mount_get_symbolic_icon
  DF *UND*    g_quark_try_string
  DF *UND*  
udisks_drive_call_eject_finish
  DF *UND*    LIBSYSTEMD_209
sd_pid_get_session
  DF *UND*    g_file_get_type


The exercise is to search for these functions in systemd's source code
and create a .so file with only the required functions. The functions
can also be reimplemented, but that takes more time than simply
stripping the required functions.

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Jaret Cantu]

On 05/06/2015 01:16 AM, Jude Nelson wrote:
I think the plan is to address needless dependencies and lock-in in a 
more general way, via the constitution 
(https://git.devuan.org/devuan/devuan-project/wikis/DevuanConstitution). 
Sections 2.2 and 9.10 are meant to alleviate this problem--not just 
for systemd, but for all software package suites that get included.
I really do try to be general and say "init systems" instead of focusing 
on systemd, but it is really hard to keep up when one can't think of 
another piece of software with claws as deep as systemd's.


... Glib2, maybe...

You may be interested to know that uselessd is effectively dead in the 
water.  The original uselessd author has since given up 
(https://forums.darknedgy.net/viewtopic.php?id=4963). Someone else 
seems to have taken over, but I haven't heard anything about its 
subsequent progress (last repository commit is January 6: 
https://bitbucket.org/Tarnyko/uselessd).
I did kinda get that impression from the wasteland of a website, but 
getting confirmation does sting a bit.


I'm personally not opposed to someone taking up maintenance of 
uselessd and packaging it in a way that it conforms to Devuan's 
constitution :)  The problem is, we'd need to find someone with the 
time, skill, and willpower to do it.  That person is not me.  I barely 
have enough time to work on vdev as it is :(
It has been on my radar for a while. Or more accurately, at the bottom 
of my To-Do Tower. It is one of those things that is hard to get 
motivated to do when I personally know I'll never use it on a real system.
Prolly would rank a middling effort in terms of my revenge programming 
projects. Maybe I just need fewer revenge projects in my To-Do Tower?
uselessd would at least give me an excuse to learn some of the black 
magic what am systemd. (Last time I encountered a board with systemd on 
it, I wound up booting it to NFS instead just so I could get the ssh 
service properly auto-starting; it was a SOM without serial on the 
carrier board, so "Why didn't you just run sshd?" is not a proper response.)




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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Jude Nelson]

Hi Jaret,


> It would probably help to have some ground rules on how Devuan handles
> packages which provide systemd support.  I know Devuan says "Nope!" when it
> comes to anything that would introduce systemd/init system dependencies,
> but does it ever get more elaborate than that? If it is already in a wiki
> or README on git, I've missed it.
>
> I can think of two ways these dependencies would come up in packages that
> would need to be addressed:
>
> * Configurable systemd support:
>
> All Devuan packages should be configured NOT to depend on systemd,
> whenever possible. This prevents init-system creep. This doesn't stop one
> from using systemd and a package that has potential systemd support (like
> xfce); however, said package on Devuan would not get any of the additional
> benefits from systemd, such as... um, binary logging?
>
> I would recommend against maintaining a separate, systemd-configured
> repository; that would just be mainline Debian.
>
>
I think the plan is to address needless dependencies and lock-in in a more
general way, via the constitution (
https://git.devuan.org/devuan/devuan-project/wikis/DevuanConstitution).
Sections 2.2 and 9.10 are meant to alleviate this problem--not just for
systemd, but for all software package suites that get included.


>
> * Hard systemd requirements:
>
> I believe this is where gnome3 and similar software falls; the project has
> a hard runtime and/or buildtime dependency on systemd. The only way to
> offer these packages on a non-systemd Devuan is to patch out the systemd
> from the source.  Fortunately, FreeBSD already has to do this, right?  Just
> raid their patches.
>

+1


>
> This can become a maintenance burden, which is why it is cool to have a
> second option on how Devuan can handle these packages: *don't*.
>
>
>
> Now, this handling of systemd-dependent packages still means that systemd
> can be offered, but only as an init.  (An init system only be used to
> initialize a system? What madness is this!)  And the only way that systemd
> will ever make it onto your system is with an explicit apt-get install
> since no other packages depend on it.
>
> But IMHO, I think it would be wiser to offer uselessd instead of systemd:
>
> http://uselessd.darknedgy.net/


You may be interested to know that uselessd is effectively dead in the
water.  The original uselessd author has since given up (
https://forums.darknedgy.net/viewtopic.php?id=4963).  Someone else seems to
have taken over, but I haven't heard anything about its subsequent progress
(last repository commit is January 6:
https://bitbucket.org/Tarnyko/uselessd).


>
>
> Thataway, our (e)udev offering would be less muddled. Also, hilarity.
>

Already working on it :)


>
> Besides, going with uselessd instead would make a systemd-ish Devuan
> different than just Debian with poorer systemd integration.  It would kinda
> be like libav over ffmpeg; on this distro, systemd would just be considered
> a "deprecated" version of uselessd (what with its text logs and lack of
> gluttony against fellow software projects), even though both projects (in
> both cases) are considered currently active.
>
>
I'm personally not opposed to someone taking up maintenance of uselessd and
packaging it in a way that it conforms to Devuan's constitution :)  The
problem is, we'd need to find someone with the time, skill, and willpower
to do it.  That person is not me.  I barely have enough time to work on
vdev as it is :(

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Jaret Cantu]

On 05/05/2015 12:35 PM, Hendrik Boom wrote:

On Tue, May 05, 2015 at 11:49:34AM -0400, Steve Litt wrote:

Hi Noel,

Having any systemd-equipped Devuan packages means that I need to always
be on my guard to prevent systemd from sneaking in.

Could segregate the packages by putting them in another category, so
we'd have free, contrib, nonfree, systemd, ...

-- hendrik


It would probably help to have some ground rules on how Devuan handles 
packages which provide systemd support.  I know Devuan says "Nope!" when 
it comes to anything that would introduce systemd/init system 
dependencies, but does it ever get more elaborate than that? If it is 
already in a wiki or README on git, I've missed it.


I can think of two ways these dependencies would come up in packages 
that would need to be addressed:


* Configurable systemd support:

All Devuan packages should be configured NOT to depend on systemd, 
whenever possible. This prevents init-system creep. This doesn't stop 
one from using systemd and a package that has potential systemd support 
(like xfce); however, said package on Devuan would not get any of the 
additional benefits from systemd, such as... um, binary logging?


I would recommend against maintaining a separate, systemd-configured 
repository; that would just be mainline Debian.



* Hard systemd requirements:

I believe this is where gnome3 and similar software falls; the project 
has a hard runtime and/or buildtime dependency on systemd. The only way 
to offer these packages on a non-systemd Devuan is to patch out the 
systemd from the source.  Fortunately, FreeBSD already has to do this, 
right?  Just raid their patches.


This can become a maintenance burden, which is why it is cool to have a 
second option on how Devuan can handle these packages: *don't*.




Now, this handling of systemd-dependent packages still means that 
systemd can be offered, but only as an init.  (An init system only be 
used to initialize a system? What madness is this!)  And the only way 
that systemd will ever make it onto your system is with an explicit 
apt-get install since no other packages depend on it.


But IMHO, I think it would be wiser to offer uselessd instead of systemd:

http://uselessd.darknedgy.net/

Thataway, our (e)udev offering would be less muddled. Also, hilarity.

Besides, going with uselessd instead would make a systemd-ish Devuan 
different than just Debian with poorer systemd integration.  It would 
kinda be like libav over ffmpeg; on this distro, systemd would just be 
considered a "deprecated" version of uselessd (what with its text logs 
and lack of gluttony against fellow software projects), even though both 
projects (in both cases) are considered currently active.




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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Jaret Cantu]

On 05/05/2015 05:36 PM, Miles Fidelman wrote:

Or, migrating to BSD.


I installed it over the weekend just 'cause. I'd be using it now, too, 
if it had write support for ext4.  (I kinda want my 3TB home partition 
to be usable.)


And I find it very hilarious that BSD has gnome 3.14 that seems to run 
just fine without any hints of systemd.



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

Re: [Dng] A novice attempt to speed up Devuan development

[Jaret Cantu]

On 05/05/2015 03:02 PM, Anto wrote:

On 05/05/15 19:50, Peter Maloney wrote:

Try eudev, which is a drop in replacement for udev on openrc systems,
and I think it was forked from udev before systemd got it.

https://github.com/gentoo/eudev
or maybe this
https://aur.archlinux.org/packages/eudev/



Thanks Peter,

I heard about it but I have never had a chance to try it as it has 
never been in Debian repository as far as I remember. I will have a 
look and search around on that now.


Cheers,

Anto


eudev was forked *after* udev got got by systemd.  The first code commit 
(Fork of Original Code Base: anongit.freedesktop.org/systemd, 
2944f347d087ff24ec808e4b70fe104a772a97a0) was based on 195, which is 
after The Systemding: 182 was udev, 184 was systemd, and I don't see a 
tag for 183. Huh, must be like a 13th floor.


The eudev README even calls it a fork of systemd.

eudev continues to pull in relevant udev changes from the systemd tree 
(without the init-specific filth, obviously) and even provides some 
fixes of its own. It is like a window into some magical world where udev 
development continues under the old banner. Well, a similar banner that 
is one character wider, at least.


Gentoo (or rather, Gentoo users) started eudev so that OpenRC could 
continue using udevd (although it does work just fine with any init 
system), so Gentoo is probably the most official place to go for it.  
The github site is listed as eudev's homepage, but there is also:


https://wwwold.gentoo.org/proj/en/eudev/

which I had thought contained some links to history/reasoning, and a 
source repository:


http://dev.gentoo.org/~blueness/eudev/

3.0? Wow, I'm really behind.


The only difference I've really noticed with the last version of udev 
before being cannibalized and eudev is that eudev doesn't build against 
some old (pre-3.0) kernel headers.  That's really only an issue for 
crufty embedded targets, not desktops, tho'.




Cheers,

Jerry



PS: Bonus round!
Version 183 was apparently the merge point of systemd and udev, at which 
point systemd took udev's versioning scheme but not its credibility.
-at which point systemd took udev's versioning scheme but NOT... ITS... 
FREEDOOM!
-at which point systemd took udev's versioning scheme, like a married 
name. No hyphenated versions here! I only mention this because I have it 
on good authority (read: internet rubbish) that we are all terribly 
anti-women.

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

Re: [Dng] why someone might want systemd on devuan

[Isaac Dunham]

On Tue, May 05, 2015 at 09:17:28PM +0100, David Harrison wrote:
> On 05/05/2015 20:43, dng-requ...@lists.dyne.org wrote:
> >Well, the problem here is that systemd is*not*  hot-pluggable, at all,
> >as we have recently learned the hard way.
> 
> Here's a thought. Thrown to the list with no requisite knowledge to back it
> up, so please don't bite!
> 
> Is there any way of building a package or some other installable to create a
> sandboxed/containerised/quarantined/VM'd minimal systemd? That's if minimal
> isn't a contradiction in terms where systemd's concerned? Just complete
> enough for a user to install and use contaminatedware within it, when they
> really have no other choice, but designed not to leak out and infect their
> otherwise clean system?

I'd imagine this would be best done via debootstrap install of Debian
and some script that can properly configure the result as a VM/container
(if it's even possible to use systemd in a container).

HTH,
Isaac Dunham

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Isaac Dunham]

On Tue, May 05, 2015 at 08:44:22PM +0200, Anto wrote:
> 
> On 05/05/15 18:52, Noel Torres wrote:
> >
> >As a resume: If you want a systemd-free system, Devuan is your
> >distribution, and will always be. But if you want a system designed to be
> >unable to run systemd, please leave us. This is not the place for such an
> >anti-freedom POV.

> Do you understand the impact on what you wrote?
> 
> How much efforts will that be to support systemd *without* any locked-in? I
> believe this is what you meant, because Devuan will be exactly the same as
> Debian if the support for systemd would also force the locked-in of a lot of
> packages. And unless the number of Devuan developers will be as many as
> Debian developers, I think you are just dreaming.

I think an overview of the different levels of systemd dependency
is in order to clarify what's under discussion.

Level 0:
On paper, systemd can boot a system even if everything else is
completely unaware of it. (This was an important part of how it got
anywhere to begin with.)
This gives almost exactly the same functionality as sysvinit, since
it uses init scripts.

Level 1:
If someone wants to use the dependency resolution that systemd has,
they need to have a configuration file for the software that specifies
how to start it and what needs to happen first.

Level 2:
The systemd maintainers claim that writing applications to use systemd
"gives the users a better experience" or some such garbage; this usually
means a run-time dependency on libsystemd. Such software usually can
still run if systemd is not PID 1.

Level 3:
A few programs require a DBUS method or similar thing tht must be
provided by systemd at runtime.

It's settled that we don't want *anything* to be at level 2 or higher
integration.

Now, what's under discussion is whether we are OK with *not* rebuilding
packages that are at level 1.

This does not mean adding systemd to the repository, it does not require
supporting systemd, it does not mean that we add service files to
anything: all that it means is we decide that we can ignore configuration
files, when there's no dependency.
Remember: a configuration file can be modified as the user wishes, or
even deleted, and the package manager will respect the user changes.

I read Noel's comments as being in favor of leaving whatever is at
integration level 1 alone, so that *if* someone decides that *they*
want to install systemd on their system, we don't make it harder
than necessary. This does not require that *we* should test it, just
let things remain (without any support from us).


I'd think that this is OK, apart from the question of whether all
packages can be rebuilt on a Devuan system.

Thanks,
Isaac Dunham

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

Re: [Dng] [dng] vdev status updates

[James Powell]

Yes, we need another MacroShaft screwing us over a barrel... NOT.

Sent from my Windows Phone

From: Laurent Bercot
Sent: ‎5/‎5/‎2015 3:21 PM
To: dng@lists.dyne.org
Subject: Re: [Dng] [dng] vdev status updates

On 05/05/2015 23:03, marc...@welz.org.za wrote:
> Hello
> No, sorry. Doing chown root:admin && chmod 2750 does not give anybody
> in the admin group (the ones who should be allowed to run it) any
> extra rights - they are already running with admin group privileges

  Ah, yes, my mistake. The pattern I was thinking of was 4750 on a
thisuser:mygroup binary, to give members of mygroup the access to a
program running with thisuser rights. It works with setuid, but not
setgid, of course.

  If you have a collection of binaries that may be setgid and you
want to restrict their rights to group admin, then yes, putting them
all in a directory that can only be accessed by group admin is the
right thing.

  However, is /sbin even used that way ? I've never seen that, not in
15 years. But I've never been very curious of the practices of
distributions.


> the thing is that everybody uses a classical unix
> system in a slightly different way - a feature that is considered
> antiquated by some is essential to others, so these structures should
> change slowly and in a backward compatible manner.

  Oh, I absolutely agree. Again, I have no intention of fighting against
the existence of /sbin; it's just that if we were to design a directory
structure from scratch today, not much would speak for the creation of
something like /sbin. But legacy is enough of a reason to keep it - it's
not like it's hurting much. :)


> In this regard systemd
> is so irritating since it demolishes so much established code
> to be replaced with something which I think is likely to spald
> and leak in a few years time :)

  I don't hate systemd because it goes against conventions. (I like to
challenge conventions, and break them if they don't provide me with
the functionality I need. I try to do it smartly and in a non-obnoxious
way, though.)
  I hate systemd because it's a horribly engineered product being forced
down people's throats via propaganda and commercial power. It makes the
open source world look just as hopeless and clueless when it comes to
evaluating software quality as businesses, and that's infuriating.

--
  Laurent

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Steve Litt]

On Tue, 05 May 2015 17:34:19 -0400
Miles Fidelman  wrote:


> Nicely put.  But do you draw any implication from that vis-a-vis 
> supporting systemd in Devuan?  (I certainly do :-)
> 
> Cheers,
> 
> Miles

*I* certainly do. Why in the world would we make Devuan development and
packaging one bit harder by supporting systemd? Why would we increase,
by even 1/1000, the chance that systemd could "sneak path" onto our
Devuan computers, knowing the immensity of the removal task?

Why are we even talking about this? Who would possibly benefit from a
systemd-optionally-enabled Devuan? A person who wants Devuan with
systemd? No, they use Debian. Or Redhat. Or SuSE. Or 100 other distros.

A person with that one must-have app that requires systemd? No. He/she
would use that app in a VM or container to prevent systemd infection of
the host OS.

A person who wants to use Gnome? Well, maybe, but please remember, the
people who made Gnome/Devuan an either/or choice was the Gnome project,
not Devuan. Gnome could have been created to run well without systemd,
but that's not their style. Incorporating Gnome would decrease, not
increase, Devuan's init freedom.

Nobody, on this list or anywhere else, benefits from putting systemd or
systemd hooks into Devuan. Why are we discussing a principle that
cannot provide benefit, when there is so much else to discuss?

SteveT

Steve Litt 
May 2015 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Laurent Bercot]

On 05/05/2015 23:03, marc...@welz.org.za wrote:

Hello
No, sorry. Doing chown root:admin && chmod 2750 does not give anybody
in the admin group (the ones who should be allowed to run it) any
extra rights - they are already running with admin group privileges


 Ah, yes, my mistake. The pattern I was thinking of was 4750 on a
thisuser:mygroup binary, to give members of mygroup the access to a
program running with thisuser rights. It works with setuid, but not
setgid, of course.

 If you have a collection of binaries that may be setgid and you
want to restrict their rights to group admin, then yes, putting them
all in a directory that can only be accessed by group admin is the
right thing.

 However, is /sbin even used that way ? I've never seen that, not in
15 years. But I've never been very curious of the practices of
distributions.



the thing is that everybody uses a classical unix
system in a slightly different way - a feature that is considered
antiquated by some is essential to others, so these structures should
change slowly and in a backward compatible manner.


 Oh, I absolutely agree. Again, I have no intention of fighting against
the existence of /sbin; it's just that if we were to design a directory
structure from scratch today, not much would speak for the creation of
something like /sbin. But legacy is enough of a reason to keep it - it's
not like it's hurting much. :)



In this regard systemd
is so irritating since it demolishes so much established code
to be replaced with something which I think is likely to spald
and leak in a few years time :)


 I don't hate systemd because it goes against conventions. (I like to
challenge conventions, and break them if they don't provide me with
the functionality I need. I try to do it smartly and in a non-obnoxious
way, though.)
 I hate systemd because it's a horribly engineered product being forced
down people's throats via propaganda and commercial power. It makes the
open source world look just as hopeless and clueless when it comes to
evaluating software quality as businesses, and that's infuriating.

--
 Laurent

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Anto]

On 06/05/15 00:04, Isaac Dunham wrote:

On Tue, May 05, 2015 at 11:53:30AM -0400, Steve Litt wrote:

Before we get too deeply into this whole thing, what was the original
question? What exact thing are we arguing whether or not to include in
Devuan?

Whether or not we need to rebuild packages that have .service files so
they will not be installed.
A .service file is a configuration file exactly analogous to an init
script.

I would argue that a configuration file is not enough justification for
a rebuild in itself unless it trigggers harmful behavior, and the proper
solution for those who want to be shed of them is to create a trigger for
dpkg which will run "rm -rf /etc/systemd"...

HTH,
Isaac Dunham


Thanks Isaac,

That is what I am currently doing every time I see those directories 
being created after I install new packages. I actually also do "rm -rf 
/lib/systemd".


Since I started to re-compile some packages, I thought to remove that 
completely from those packages as I don't want to use systemd.


Cheers,

Anto

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[KatolaZ]

On Tue, May 05, 2015 at 05:34:19PM -0400, Miles Fidelman wrote:

[cut]

> >I meant "we should live with the fact that systemd is not unpluggable"
> >:)
> 
> Nicely put.  But do you draw any implication from that vis-a-vis
> supporting systemd in Devuan?  (I certainly do :-)
> 

If it was up to me (and it is not), I would make no effort at all in
trying to have systemd in Devuan, since I believe there is no point in
doing that. There is already a Debian with systemd, and is called
Debian, while some great people out there are working hard to give us
a Debian *without* systemd, which will be called Devuan. And the work
of those people has been made extremely difficult by the fact that
systemd is not designed to be pluggable on and off, and the systemd
developers keep answering "won't fix" to any request for compatibility
with other init system and low-level system daemons. They are
definitely determined to go their way, whatever the cost of it,
because they think that systemd is "right and technically sound".

So why should we waste man-power on allowing to use systemd in a
distribution whose first aim and motivation is to provide a
systemd-free GNU/Linux?!?!? 

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] Which package generates /lib/systemd and /etc/systemd files?

[Isaac Dunham]

On Tue, May 05, 2015 at 11:53:30AM -0400, Steve Litt wrote:
> Before we get too deeply into this whole thing, what was the original
> question? What exact thing are we arguing whether or not to include in
> Devuan?

Whether or not we need to rebuild packages that have .service files so
they will not be installed.
A .service file is a configuration file exactly analogous to an init
script.

I would argue that a configuration file is not enough justification for
a rebuild in itself unless it trigggers harmful behavior, and the proper
solution for those who want to be shed of them is to create a trigger for
dpkg which will run "rm -rf /etc/systemd"...

HTH,
Isaac Dunham


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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Anto]

On 05/05/15 21:41, Noel Torres wrote:


Anto  escribió:


On 05/05/15 18:52, Noel Torres wrote:


As a resume: If you want a systemd-free system, Devuan is your 
distribution, and will always be. But if you want a system designed 
to be unable to run systemd, please leave us. This is not the place 
for such an anti-freedom POV.




Are you for real?

Do you understand the impact on what you wrote?


Of course yes. We are not a bunch of anti-systemd fanboys, but a set 
of system administrators that want to be free not to have systemd 
imposed on us by what was our distribution of choice for its technical 
soundness and reliability: Debian.


How much efforts will that be to support systemd *without* any 
locked-in? I believe this is what you meant, because Devuan will be


That of the required effort is a completely different issue to that of 
freedom!
exactly the same as Debian if the support for systemd would also 
force the locked-in of a lot of packages. And unless the number of 
Devuan developers will be as many as Debian developers, I think you 
are just dreaming.


Yes, dreaming, but also setting a line on the sand: rejecting systemd 
on Devuan for reason A is good, and for reason B is bad. The line is 
on the reasons, not on systemd itself.


I can write this now that you can be sure I will be the first one to 
leave Devuan as soon as it starts to support systemd. This encourages 
me to start learning about building a deb repository and forking, 
because as soon as Devuan starts to support systemd, it will be much 
easier for me to fork Devuan.


Feel free to leave, fork, contribute or just argue with me, but even 
if you leave, I'll support your freedom.


It is quite sad for me to write this as Devuan does not even exist 
yet. But I can see it now that the future of Devuan is not really 
promising for me. I will wait and still be around until that day comes.


Regards

Noel
er Envite


Hello Noel,

In term of effort vs freedom of choice, I think you have to be realistic.

If systemd was not designed to force massive dependencies, I would not 
hate it this much. I would not even look for alternative distros if I 
could easily uninstall it or uninstall any of its components in Debian. 
It works like that by design which makes it hard for people to have a 
distro that is free of systemd, otherwise Devuan would have been 
released before January 2015. The efforts that have been put into Devuan 
development are already quite a lot, just to free it up from systemd.


I am quite sure that the efforts to make systemd and its components 
easily uninstallable in Devuan and maintain it, will be much more than 
the current ones. All of that just for the sake of providing choice to 
the users who want to have systemd in Devuan. The number of those users 
is questionable. There will probably be very few of them (if not *none*) 
by the time Devuan starts to support systemd, as most of them will 
probably choose more mature distros with systemd. And Devuan with 
uninstallable systemd will always be on the side line, due to its 
radical approach compare to other systemd based distros.


Cheers,

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

Re: [Dng] why someone might want systemd on devuan

[Miles Fidelman]

David Harrison wrote:

On 05/05/2015 20:43, dng-requ...@lists.dyne.org wrote:

Well, the problem here is that systemd is*not*  hot-pluggable, at all,
as we have recently learned the hard way.


Here's a thought. Thrown to the list with no requisite knowledge to 
back it up, so please don't bite!


Is there any way of building a package or some other installable to 
create a sandboxed/containerised/quarantined/VM'd minimal systemd? 
That's if minimal isn't a contradiction in terms where systemd's 
concerned? Just complete enough for a user to install and use 
contaminatedware within it, when they really have no other choice, but 
designed not to leak out and infect their otherwise clean system?




As others have alluded: If you absolutely, positively have to run 
something that depends on systemd,

- run your base system without systemd
- run your systemd-dependent code in a container or a virtual machine w/ 
systemd


Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Miles Fidelman]

Harald Arnesen wrote:

Noel Torres [2015-05-05 18:52]:


As a resume: If you want a systemd-free system, Devuan is your
distribution, and will always be.

At the moment, it is either Trios or Funtoo or Slackware, right? Or some
limited distro like Alpine (which I run on my netbook).


I believe Gentoo is another reasonable choice.  Or one of the BSDs.

Personally, I'm looking more and more at building our next server update 
on either LSF (Linux from Scratch), and using GUIX to generate 
replicable packages.  Or, migrating to BSD.


Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Miles Fidelman]

KatolaZ wrote:

On Tue, May 05, 2015 at 03:53:55PM -0400, Miles Fidelman wrote:

[cut]


Unfortunately, systemd has been *designed* to be unpluggable, and to
munch as much as possible of the low-level userspace. We should live
with it, especially because the typical answer you get about systemd
compatibility issues is "it's not our problem. We won't fix it". I
also have my personal (conspiracy) theory about why it is like that,
which I am sure you don't want to hear


Don't you mean "we should live WITHOUT it?"


I meant "we should live with the fact that systemd is not unpluggable"
:)


Nicely put.  But do you draw any implication from that vis-a-vis 
supporting systemd in Devuan?  (I certainly do :-)


Cheers,

Miles


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

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

Re: [Dng] Linux boot documentation

[Isaac Dunham]

On Tue, May 05, 2015 at 12:29:59PM +0200, Jürgen Buchmüller wrote:
> Am Dienstag, den 05.05.2015, 11:22 +0200 schrieb Didier Kryn:
> > I'm not sure what happens if init crashes after other processes have
> > been started, wether the kernel panics or other processes continue
> > without init - not a very good situation.
> 
> FWIW: I've seen this happening with a home grown jessie (RC2) for
> Cubietruck (armv7hf) where a module was seriously broken and led to a
> segfault.
> 
> Since with systemd modules seem to be loaded by pid 1 itself, the crash
> takes down systemd with it and the system reboots after exiting pid 1,
> just crash again when trying to load the broken module the next time. No
> chance to break out of this loop AFAIK.
> 
> To me this looks like a fundamental design flaw. A crashing module
> should never _ever_ take the whole system down. There has to be some
> privilege separation and signal handling in place to prevent that.
> 
> With SysV init this is no big problem, as usually some child process of
> init (a shell script) loads the detected (udev rules) or defined
> (/etc/modules) modules and if it crashes, init will still be alive.

I presume "module" == "kernel module".
A module is never run in the same context as the process that loads it.
It is a part of the kernel, and thus runs in the kernel context.
If it crashes, it crashes the kernel or the associated device disappears.

By default, udev automatically loads non-blacklisted modules based
on the hardware it detects.
On a systemd-based system, udev is mandatory; it is not a part of pid 1,
though it is built from the systemd source.

If you can figure out what module is causing the crash, you can blacklist
it.

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

Re: [Dng] [dng] vdev status updates

[marcxdv]

Hello

>  * I then argue that in the current world, autocompletion is not
> reliable, because since it does not stat(), it cannot hide filenames
> the user cannot execute, such as a 0644 file. What your autocompletion
> is currently printing is an approximation of the programs you can run,
> not an accurate list - in other words, merging /bin and /sbin would not
> "break" autocompletion, because it is already "broken". You are just
> not seeing it because the (good) convention of not putting anything
> non-executable in /bin is widely followed - but the whole mechanism
> is simply relying on a convention, and stricto sensu you should not
> entirely trust it. 

So ultimately everything in the computer world is just a convention.
It is just convention that stat() gives you real filesystem permissions - 
strictly speaking you should first check the kernel source, that nobody
has broken that, and then the hardware underneath that too. 

But snark aside, maybe view that these things are just conventions
allows you to argue that they should be changed easily, while my position 
is that many things (like the shell) do rely on them being that way, and 
then won't work (or work as well) if they are changed. If they are 
called conventions, rules or laws doesn't make that much difference.

> >* You have say a setgid executable which probably isn't perfectly
> >   secure. You trust your admin crowd to run it, but maybe not
> >   a php script which has escaped apache.
> >
> >* So you put it into /usr/sbin and do
> >
> >   chmod 750 /usr/sbin
> >   chgrp admin /usr/sbin
> >
> >* And now if an exploit for said setgid tool becomes available
> >   then the php script won't be able to run it.
> 
>  OK, thanks for clarifying. This isn't security through obscurity
> indeed. However, you could achieve the exact same result by putting
> this tool in /usr/bin - or anywhere else - with chown root:admin
> and chmod 2750 - you don't need a separate directory to hold binaries
> you only want a specific group to run.

No, sorry. Doing chown root:admin && chmod 2750 does not give anybody
in the admin group (the ones who should be allowed to run it) any
extra rights - they are already running with admin group privileges - 
setgid would be used to grant controlled access to another group 
(like disk, dialout, mail, etc, etc). 

So I think I understand your desire to clean things up, rationalise
them - but the thing is that everybody uses a classical unix
system in a slightly different way - a feature that is considered
antiquated by some is essential to others, so these structures should
change slowly and in a backward compatible manner. 

There are lots of examples of that, eg vim is a superset of vi,
and in vim you can still drop down to ex mode which is the
successor to ed. Maybe to use a sentimental analogy: A city
with layers of history is much more rich/interesting and often
more liveable than somewhere which has been bulldozed flat and
centrally planned by a funky architect. In this regard systemd
is so irritating since it demolishes so much established code
to be replaced with something which I think is likely to spald
and leak in a few years time :)

regards

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Harald Arnesen]

Noel Torres [2015-05-05 18:52]:

> As a resume: If you want a systemd-free system, Devuan is your  
> distribution, and will always be.

At the moment, it is either Trios or Funtoo or Slackware, right? Or some
limited distro like Alpine (which I run on my netbook).
-- 
Hilsen Harald
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] why someone might want systemd on devuan

[David Harrison]

On 05/05/2015 20:43, dng-requ...@lists.dyne.org wrote:

Well, the problem here is that systemd is*not*  hot-pluggable, at all,
as we have recently learned the hard way.


Here's a thought. Thrown to the list with no requisite knowledge to back 
it up, so please don't bite!


Is there any way of building a package or some other installable to 
create a sandboxed/containerised/quarantined/VM'd minimal systemd? 
That's if minimal isn't a contradiction in terms where systemd's 
concerned? Just complete enough for a user to install and use 
contaminatedware within it, when they really have no other choice, but 
designed not to leak out and infect their otherwise clean system?


Cheers,

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[KatolaZ]

On Tue, May 05, 2015 at 03:53:55PM -0400, Miles Fidelman wrote:

[cut]

> >Unfortunately, systemd has been *designed* to be unpluggable, and to
> >munch as much as possible of the low-level userspace. We should live
> >with it, especially because the typical answer you get about systemd
> >compatibility issues is "it's not our problem. We won't fix it". I
> >also have my personal (conspiracy) theory about why it is like that,
> >which I am sure you don't want to hear
> >
> 
> Don't you mean "we should live WITHOUT it?"
> 

I meant "we should live with the fact that systemd is not unpluggable"
:)

HND

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] why someone might want systemd on devuan

[James Powell]

Plus, libsystemd is also a static library which everything has to link against. 
I haven't messed with systemd for a while, but last I remember there was no 
dynamically shared object version of the library.

Sent from my Windows Phone

From: Edward Bartolo
Sent: ‎5/‎5/‎2015 12:52 PM
To: Hendrik Boom
Cc: dng@lists.dyne.org
Subject: Re: [Dng] why someone might want systemd on devuan

I will only say a few words.

The purpose of Devuan was to promote software freedom and more
specifically software choice. If systemd & Co. change drastically,
which is clearly very unlikely to happen, it will be a completely
another situation, and systemd & Co. may start forming part of a
project like Devuan.

In my humble opinion, this is the only way systemd to become a
candidate worthy of consideration. Those who want systemd have already
more than enough to choose from.

Edward


On 05/05/2015, Hendrik Boom  wrote:
> On Tue, May 05, 2015 at 05:53:28PM +0100, KatolaZ wrote:
>> On Tue, May 05, 2015 at 12:35:57PM -0400, Hendrik Boom wrote:
>> > On Tue, May 05, 2015 at 11:49:34AM -0400, Steve Litt wrote:
>> > >
>> > > Hi Noel,
>> > >
>> > > Having any systemd-equipped Devuan packages means that I need to
>> > > always
>> > > be on my guard to prevent systemd from sneaking in.
>> >
>> > Could segregate the packages by putting them in another category, so
>> > we'd have free, contrib, nonfree, systemd, ...
>> >
>>
>> But guys, I thought that the challenge over here was to have a
>> systemd-free system to start with, or not? I thought that there were a
>> bunch of people out there trying their best to eradicate systemd from
>> debian packages, making a lot of work to repackage everything as
>> Devuan, a new systemd-free distribution...Or am I mistaken?
>>
>> IMHO anybody who wants systemd has plenty of good alternatives to
>> choose from, without waiting for a new systemd-free GNU/Linux
>> distribution to become usable. After all, what's the point of
>> stubbornly wanting a systemd-free distro if in the end you are going
>> to use systemd anyway?
>
> Well, yes.  I can imagine a systemd hater who discovers down the road
> that he needs a package that's been comtaminated with systemd.  Maybe
> instead of going whole-hog systemd, which is that the other distros
> force him to do, he can put up with systemd until that package hass
> been cleaned out.  And then ge rid of it again, with few other stray
> dependencies getting in his way.
>
> Now this  scenario may seem a little far-fetched, but the trutrh is, I
> can't imagine all the uses that knowledgable users will come up with.
> I'm sure there's another possible reason that I'm not creative enough to
> come up with.
>
> Maybe he needs to be able to test whether software he's written will
> work when systemd is present, just in case others want to use it on
> other systems.
>
> I still use Windows once every six months or so, though I'd prefer not
> to have to, and normally use Linux for everything.
>
> It's about freedom.
>
> -- hendrik
>
>>
>> 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
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] A novice attempt to speed up Devuan development

[James Powell]

Technically eudev is udev that is preextracted from the source. There is no 
real difference between it and the systemd-udev code... yet.

Sent from my Windows Phone

From: Anto
Sent: ‎5/‎5/‎2015 12:02 PM
To: Peter Maloney; 
dng@lists.dyne.org
Subject: Re: [Dng] A novice attempt to speed up Devuan development



On 05/05/15 19:50, Peter Maloney wrote:
> On 05/05/2015 08:55 AM, Anto wrote:
>> Just FYI. I just noticed that the changes that I have made seem to
>> break udev. It was not started after reboot- I have not investigate
>> further, but re-installing udev solve the problem. It seems that I
>> have to re-compile udev as well. But it looks more complicated as udev
>> *is* in systemd source.
>>
> Try eudev, which is a drop in replacement for udev on openrc systems,
> and I think it was forked from udev before systemd got it.
>
> https://github.com/gentoo/eudev
> or maybe this
> https://aur.archlinux.org/packages/eudev/
>

Thanks Peter,

I heard about it but I have never had a chance to try it as it has never
been in Debian repository as far as I remember. I will have a look and
search around on that now.

Cheers,

Anto

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Miles Fidelman]

KatolaZ wrote:

On Tue, May 05, 2015 at 07:33:32PM +, Noel Torres wrote:

[cut]


Maybe I'm a dreamer, but I follow Lennon on this. I Imagine a world
where systemd is optional (probably against its own core developers
wishes), and can be installed or deinstalled as any other init
system.


Well, you should probably open a ticket here then:

https://bugs.freedesktop.org/enter_bug.cgi?product=systemd

Unfortunately, systemd has been *designed* to be unpluggable, and to
munch as much as possible of the low-level userspace. We should live
with it, especially because the typical answer you get about systemd
compatibility issues is "it's not our problem. We won't fix it". I
also have my personal (conspiracy) theory about why it is like that,
which I am sure you don't want to hear



Don't you mean "we should live WITHOUT it?"

Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

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

Re: [Dng] why someone might want systemd on devuan

[Edward Bartolo]

I will only say a few words.

The purpose of Devuan was to promote software freedom and more
specifically software choice. If systemd & Co. change drastically,
which is clearly very unlikely to happen, it will be a completely
another situation, and systemd & Co. may start forming part of a
project like Devuan.

In my humble opinion, this is the only way systemd to become a
candidate worthy of consideration. Those who want systemd have already
more than enough to choose from.

Edward


On 05/05/2015, Hendrik Boom  wrote:
> On Tue, May 05, 2015 at 05:53:28PM +0100, KatolaZ wrote:
>> On Tue, May 05, 2015 at 12:35:57PM -0400, Hendrik Boom wrote:
>> > On Tue, May 05, 2015 at 11:49:34AM -0400, Steve Litt wrote:
>> > >
>> > > Hi Noel,
>> > >
>> > > Having any systemd-equipped Devuan packages means that I need to
>> > > always
>> > > be on my guard to prevent systemd from sneaking in.
>> >
>> > Could segregate the packages by putting them in another category, so
>> > we'd have free, contrib, nonfree, systemd, ...
>> >
>>
>> But guys, I thought that the challenge over here was to have a
>> systemd-free system to start with, or not? I thought that there were a
>> bunch of people out there trying their best to eradicate systemd from
>> debian packages, making a lot of work to repackage everything as
>> Devuan, a new systemd-free distribution...Or am I mistaken?
>>
>> IMHO anybody who wants systemd has plenty of good alternatives to
>> choose from, without waiting for a new systemd-free GNU/Linux
>> distribution to become usable. After all, what's the point of
>> stubbornly wanting a systemd-free distro if in the end you are going
>> to use systemd anyway?
>
> Well, yes.  I can imagine a systemd hater who discovers down the road
> that he needs a package that's been comtaminated with systemd.  Maybe
> instead of going whole-hog systemd, which is that the other distros
> force him to do, he can put up with systemd until that package hass
> been cleaned out.  And then ge rid of it again, with few other stray
> dependencies getting in his way.
>
> Now this  scenario may seem a little far-fetched, but the trutrh is, I
> can't imagine all the uses that knowledgable users will come up with.
> I'm sure there's another possible reason that I'm not creative enough to
> come up with.
>
> Maybe he needs to be able to test whether software he's written will
> work when systemd is present, just in case others want to use it on
> other systems.
>
> I still use Windows once every six months or so, though I'd prefer not
> to have to, and normally use Linux for everything.
>
> It's about freedom.
>
> -- hendrik
>
>>
>> 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
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[KatolaZ]

On Tue, May 05, 2015 at 07:33:32PM +, Noel Torres wrote:

[cut]

> 
> Maybe I'm a dreamer, but I follow Lennon on this. I Imagine a world
> where systemd is optional (probably against its own core developers
> wishes), and can be installed or deinstalled as any other init
> system.
> 

Well, you should probably open a ticket here then:

https://bugs.freedesktop.org/enter_bug.cgi?product=systemd

Unfortunately, systemd has been *designed* to be unpluggable, and to
munch as much as possible of the low-level userspace. We should live
with it, especially because the typical answer you get about systemd
compatibility issues is "it's not our problem. We won't fix it". I
also have my personal (conspiracy) theory about why it is like that,
which I am sure you don't want to hear

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] why someone might want systemd on devuan

[Steve Litt]

On Tue, 5 May 2015 14:43:09 -0400
Hendrik Boom  wrote:
 
> Well, yes.  I can imagine a systemd hater who discovers down the road 
> that he needs a package that's been comtaminated with systemd.  Maybe 
> instead of going whole-hog systemd, which is that the other distros 
> force him to do, he can put up with systemd until that package hass 
> been cleaned out.  And then ge rid of it again, with few other stray 
> dependencies getting in his way.

This is the exact situation in which I'm glad for containers and VMs.
Use all the systemd you want, but keep it in a Biosafety level 4
containment facility.

SteveT

Steve Litt 
May 2015 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Noel Torres]

Anto  escribió:


On 05/05/15 18:52, Noel Torres wrote:


As a resume: If you want a systemd-free system, Devuan is your  
distribution, and will always be. But if you want a system designed  
to be unable to run systemd, please leave us. This is not the place  
for such an anti-freedom POV.




Are you for real?

Do you understand the impact on what you wrote?


Of course yes. We are not a bunch of anti-systemd fanboys, but a set  
of system administrators that want to be free not to have systemd  
imposed on us by what was our distribution of choice for its technical  
soundness and reliability: Debian.


How much efforts will that be to support systemd *without* any  
locked-in? I believe this is what you meant, because Devuan will be


That of the required effort is a completely different issue to that of  
freedom!
exactly the same as Debian if the support for systemd would also  
force the locked-in of a lot of packages. And unless the number of  
Devuan developers will be as many as Debian developers, I think you  
are just dreaming.


Yes, dreaming, but also setting a line on the sand: rejecting systemd  
on Devuan for reason A is good, and for reason B is bad. The line is  
on the reasons, not on systemd itself.


I can write this now that you can be sure I will be the first one to  
leave Devuan as soon as it starts to support systemd. This  
encourages me to start learning about building a deb repository and  
forking, because as soon as Devuan starts to support systemd, it  
will be much easier for me to fork Devuan.


Feel free to leave, fork, contribute or just argue with me, but even  
if you leave, I'll support your freedom.


It is quite sad for me to write this as Devuan does not even exist  
yet. But I can see it now that the future of Devuan is not really  
promising for me. I will wait and still be around until that day  
comes.


Regards

Noel
er Envite


binIOIqzMyoBG.bin
Description: Clave PGP pública
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Noel Torres]

Jaromil  escribió:


dear Noel,

I'm happy that you are back, we really miss DWN, but I'm also sorry to
contradict you on this one.


I like you contradicting me. Maybe it is not so big contradiction.  
About DWN, I've had bad days in the personal (and I'm still having) so  
maybe writing to the list is all I can do for now. But I'm not dead!


On Tue, 05 May 2015, Noel Torres wrote:

As a resume: If you want a systemd-free system, Devuan is your
distribution, and will always be. But if you want a system designed to
be unable to run systemd, please leave us. This is not the place for
such an anti-freedom POV.


perhaps we could say it was to simplify the transition, but in operating
on packages so far we have removed systemd and the possibility to run it
on Devuan, which is now as far as that of running sysvinit on Debian for
normal users. This is more of a consequence of how Debian imposed
systemd than a deliberate choice from our side. I personally agree with
your line about init-freedom, but less agree with the line of telling
people this is not their place especially if they look for a
systemd-free system for whatever reason they have.


I agree on your view of the situation and the causes that lead to it,  
but still think that freedom whould be what leads us. If we must pay  
the price to being unable to support systemd, that's ok, because it is  
teh price for the bigger Good of user freedom, but forbidding our  
users to have such an option as a principle is a completely different  
thing.


At the inception of Devuan we have analysed the tradeoff of keeping
systemd optional and thought it was too much work in a direction we
weren't interested: we recommend Debian as the system of choice for
those wanting to have systemd crippl*cough*cough*manage their computers.


I agree, but that still does not invalidate my main point! This is an  
issue on feasability, not on principles.


As simple as this, the result is that there is no option to have systemd
in Devuan now and the simpliest way to have it would be anyway to use
Debian. I'm not sure it will be ever a priority to get systemd back as


Having it is not a priority for me, either. But the philosophical  
point of rejecting it by itself and thus consciously removing freedom  
from our users for no good technical/workforce/feasability reason is  
an idea I'm not comfortable with.



optional for Devuan. Perhaps init-freedom is really realized by a
plurality of distributions and if there is a merit for Devan is still
that of preserving this freedom by providing an OS that is open to every
init system *but systemd* since the latter does exclude anyone else by
an enormous network of dependencies. In the future we'll invest efforts


Maybe I'm a dreamer, but I follow Lennon on this. I Imagine a world  
where systemd is optional (probably against its own core developers  
wishes), and can be installed or deinstalled as any other init system.



in supporting sysvinit and more init systems our there (OpenRC, DMD
etc.) thus we'll be a bit more "universal" than Debian.


We will be, soon!


Again personally I think that is an arrogant move today for any OS to
declare itself "universal" as init-freedom and more freedom in the
future is really realized by a plurality of distributions, a lesson we
learn from this fork perhaps.



Wise words


ciao


Saludos

Noel
er Envite


bink0vIGSbCyE.bin
Description: Clave PGP pública
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] why someone might want systemd on devuan

[KatolaZ]

On Tue, May 05, 2015 at 02:43:09PM -0400, Hendrik Boom wrote:

[cut]

> 
> Well, yes.  I can imagine a systemd hater who discovers down the road 
> that he needs a package that's been comtaminated with systemd.  Maybe 
> instead of going whole-hog systemd, which is that the other distros 
> force him to do, he can put up with systemd until that package hass 
> been cleaned out.  And then ge rid of it again, with few other stray 
> dependencies getting in his way.
> 

Well, the problem here is that systemd is *not* hot-pluggable, at all,
as we have recently learned the hard way. If systemd were
hot-pluggable (and hot-unpluggable), there would not be any need to
have Devuan, since one could have plugged it on and off Debian at
will. Unfortunately, this is not the case, the main reason being that
systemd does not want to be just an init system but a middleware
mediating most of the interactions between user-space and
kernel-space, and managing in a centralised way most of the typical
"ancillary" little things which make a GNU/Linux system run. 

Devuan exists only because systemd makes impractical any alternative
to systemd.

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] A novice attempt to speed up Devuan development

[Anto]

On 05/05/15 19:50, Peter Maloney wrote:

On 05/05/2015 08:55 AM, Anto wrote:

Just FYI. I just noticed that the changes that I have made seem to
break udev. It was not started after reboot- I have not investigate
further, but re-installing udev solve the problem. It seems that I
have to re-compile udev as well. But it looks more complicated as udev
*is* in systemd source.


Try eudev, which is a drop in replacement for udev on openrc systems,
and I think it was forked from udev before systemd got it.

https://github.com/gentoo/eudev
or maybe this
https://aur.archlinux.org/packages/eudev/



Thanks Peter,

I heard about it but I have never had a chance to try it as it has never 
been in Debian repository as far as I remember. I will have a look and 
search around on that now.


Cheers,

Anto

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Anto]

On 05/05/15 18:52, Noel Torres wrote:


As a resume: If you want a systemd-free system, Devuan is your 
distribution, and will always be. But if you want a system designed to 
be unable to run systemd, please leave us. This is not the place for 
such an anti-freedom POV.




Are you for real?

Do you understand the impact on what you wrote?

How much efforts will that be to support systemd *without* any 
locked-in? I believe this is what you meant, because Devuan will be 
exactly the same as Debian if the support for systemd would also force 
the locked-in of a lot of packages. And unless the number of Devuan 
developers will be as many as Debian developers, I think you are just 
dreaming.


I can write this now that you can be sure I will be the first one to 
leave Devuan as soon as it starts to support systemd. This encourages me 
to start learning about building a deb repository and forking, because 
as soon as Devuan starts to support systemd, it will be much easier for 
me to fork Devuan.


It is quite sad for me to write this as Devuan does not even exist yet. 
But I can see it now that the future of Devuan is not really promising 
for me. I will wait and still be around until that day comes.


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

[Dng] why someone might want systemd on devuan

[Hendrik Boom]

On Tue, May 05, 2015 at 05:53:28PM +0100, KatolaZ wrote:
> On Tue, May 05, 2015 at 12:35:57PM -0400, Hendrik Boom wrote:
> > On Tue, May 05, 2015 at 11:49:34AM -0400, Steve Litt wrote:
> > > 
> > > Hi Noel,
> > > 
> > > Having any systemd-equipped Devuan packages means that I need to always
> > > be on my guard to prevent systemd from sneaking in.
> > 
> > Could segregate the packages by putting them in another category, so 
> > we'd have free, contrib, nonfree, systemd, ...
> > 
> 
> But guys, I thought that the challenge over here was to have a
> systemd-free system to start with, or not? I thought that there were a
> bunch of people out there trying their best to eradicate systemd from
> debian packages, making a lot of work to repackage everything as
> Devuan, a new systemd-free distribution...Or am I mistaken?
> 
> IMHO anybody who wants systemd has plenty of good alternatives to
> choose from, without waiting for a new systemd-free GNU/Linux
> distribution to become usable. After all, what's the point of
> stubbornly wanting a systemd-free distro if in the end you are going
> to use systemd anyway?

Well, yes.  I can imagine a systemd hater who discovers down the road 
that he needs a package that's been comtaminated with systemd.  Maybe 
instead of going whole-hog systemd, which is that the other distros 
force him to do, he can put up with systemd until that package hass 
been cleaned out.  And then ge rid of it again, with few other stray 
dependencies getting in his way.

Now this  scenario may seem a little far-fetched, but the trutrh is, I 
can't imagine all the uses that knowledgable users will come up with.  
I'm sure there's another possible reason that I'm not creative enough to 
come up with.

Maybe he needs to be able to test whether software he's written will 
work when systemd is present, just in case others want to use it on 
other systems.

I still use Windows once every six months or so, though I'd prefer not 
to have to, and normally use Linux for everything.

It's about freedom.

-- hendrik

> 
> 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] Which package generates /lib/systemd and /etc/systemd files?

[Jude Nelson]

On Tue, May 5, 2015 at 1:41 PM, shraptor shraptor 
wrote:

> But I guess there is no obstacle to for instance run vdev with systemd,
> huh?
>

There shouldn't be.  However, someone will have to write a .service file
for it.

-Jude


>
> On Tue, May 5, 2015 at 7:33 PM, Jaromil  wrote:
>
>>
>> dear Noel,
>>
>> I'm happy that you are back, we really miss DWN, but I'm also sorry to
>> contradict you on this one.
>>
>> On Tue, 05 May 2015, Noel Torres wrote:
>> > As a resume: If you want a systemd-free system, Devuan is your
>> > distribution, and will always be. But if you want a system designed to
>> > be unable to run systemd, please leave us. This is not the place for
>> > such an anti-freedom POV.
>>
>> perhaps we could say it was to simplify the transition, but in operating
>> on packages so far we have removed systemd and the possibility to run it
>> on Devuan, which is now as far as that of running sysvinit on Debian for
>> normal users. This is more of a consequence of how Debian imposed
>> systemd than a deliberate choice from our side. I personally agree with
>> your line about init-freedom, but less agree with the line of telling
>> people this is not their place especially if they look for a
>> systemd-free system for whatever reason they have.
>>
>> At the inception of Devuan we have analysed the tradeoff of keeping
>> systemd optional and thought it was too much work in a direction we
>> weren't interested: we recommend Debian as the system of choice for
>> those wanting to have systemd crippl*cough*cough*manage their computers.
>>
>> As simple as this, the result is that there is no option to have systemd
>> in Devuan now and the simpliest way to have it would be anyway to use
>> Debian. I'm not sure it will be ever a priority to get systemd back as
>> optional for Devuan. Perhaps init-freedom is really realized by a
>> plurality of distributions and if there is a merit for Devan is still
>> that of preserving this freedom by providing an OS that is open to every
>> init system *but systemd* since the latter does exclude anyone else by
>> an enormous network of dependencies. In the future we'll invest efforts
>> in supporting sysvinit and more init systems our there (OpenRC, DMD
>> etc.) thus we'll be a bit more "universal" than Debian.
>>
>> Again personally I think that is an arrogant move today for any OS to
>> declare itself "universal" as init-freedom and more freedom in the
>> future is really realized by a plurality of distributions, a lesson we
>> learn from this fork perhaps.
>>
>> ciao
>>
>>
>>
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] A novice attempt to speed up Devuan development

[Peter Maloney]

On 05/05/2015 08:55 AM, Anto wrote:
>
>>
>
> Just FYI. I just noticed that the changes that I have made seem to
> break udev. It was not started after reboot- I have not investigate
> further, but re-installing udev solve the problem. It seems that I
> have to re-compile udev as well. But it looks more complicated as udev
> *is* in systemd source.
>
Try eudev, which is a drop in replacement for udev on openrc systems,
and I think it was forked from udev before systemd got it.

https://github.com/gentoo/eudev
or maybe this
https://aur.archlinux.org/packages/eudev/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[shraptor shraptor]

But I guess there is no obstacle to for instance run vdev with systemd, huh?

On Tue, May 5, 2015 at 7:33 PM, Jaromil  wrote:

>
> dear Noel,
>
> I'm happy that you are back, we really miss DWN, but I'm also sorry to
> contradict you on this one.
>
> On Tue, 05 May 2015, Noel Torres wrote:
> > As a resume: If you want a systemd-free system, Devuan is your
> > distribution, and will always be. But if you want a system designed to
> > be unable to run systemd, please leave us. This is not the place for
> > such an anti-freedom POV.
>
> perhaps we could say it was to simplify the transition, but in operating
> on packages so far we have removed systemd and the possibility to run it
> on Devuan, which is now as far as that of running sysvinit on Debian for
> normal users. This is more of a consequence of how Debian imposed
> systemd than a deliberate choice from our side. I personally agree with
> your line about init-freedom, but less agree with the line of telling
> people this is not their place especially if they look for a
> systemd-free system for whatever reason they have.
>
> At the inception of Devuan we have analysed the tradeoff of keeping
> systemd optional and thought it was too much work in a direction we
> weren't interested: we recommend Debian as the system of choice for
> those wanting to have systemd crippl*cough*cough*manage their computers.
>
> As simple as this, the result is that there is no option to have systemd
> in Devuan now and the simpliest way to have it would be anyway to use
> Debian. I'm not sure it will be ever a priority to get systemd back as
> optional for Devuan. Perhaps init-freedom is really realized by a
> plurality of distributions and if there is a merit for Devan is still
> that of preserving this freedom by providing an OS that is open to every
> init system *but systemd* since the latter does exclude anyone else by
> an enormous network of dependencies. In the future we'll invest efforts
> in supporting sysvinit and more init systems our there (OpenRC, DMD
> etc.) thus we'll be a bit more "universal" than Debian.
>
> Again personally I think that is an arrogant move today for any OS to
> declare itself "universal" as init-freedom and more freedom in the
> future is really realized by a plurality of distributions, a lesson we
> learn from this fork perhaps.
>
> ciao
>
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Jaromil]

dear Noel,

I'm happy that you are back, we really miss DWN, but I'm also sorry to
contradict you on this one.

On Tue, 05 May 2015, Noel Torres wrote:
> As a resume: If you want a systemd-free system, Devuan is your
> distribution, and will always be. But if you want a system designed to
> be unable to run systemd, please leave us. This is not the place for
> such an anti-freedom POV.

perhaps we could say it was to simplify the transition, but in operating
on packages so far we have removed systemd and the possibility to run it
on Devuan, which is now as far as that of running sysvinit on Debian for
normal users. This is more of a consequence of how Debian imposed
systemd than a deliberate choice from our side. I personally agree with
your line about init-freedom, but less agree with the line of telling
people this is not their place especially if they look for a
systemd-free system for whatever reason they have.

At the inception of Devuan we have analysed the tradeoff of keeping
systemd optional and thought it was too much work in a direction we
weren't interested: we recommend Debian as the system of choice for
those wanting to have systemd crippl*cough*cough*manage their computers.

As simple as this, the result is that there is no option to have systemd
in Devuan now and the simpliest way to have it would be anyway to use
Debian. I'm not sure it will be ever a priority to get systemd back as
optional for Devuan. Perhaps init-freedom is really realized by a
plurality of distributions and if there is a merit for Devan is still
that of preserving this freedom by providing an OS that is open to every
init system *but systemd* since the latter does exclude anyone else by
an enormous network of dependencies. In the future we'll invest efforts
in supporting sysvinit and more init systems our there (OpenRC, DMD
etc.) thus we'll be a bit more "universal" than Debian.

Again personally I think that is an arrogant move today for any OS to
declare itself "universal" as init-freedom and more freedom in the
future is really realized by a plurality of distributions, a lesson we
learn from this fork perhaps.

ciao



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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[KatolaZ]

On Tue, May 05, 2015 at 04:52:44PM +, Noel Torres wrote:

[cut]

> 
> Because it is so intrincately depended on by the core of a Debian
> system that we can not simply "get Debian and remove the systemd
> bits". We owe our users a truly systemd-free system, and that's why
> we are here, but we do not owe them a systemd-forbidding system.
> 
> We are building a distribution, and as such we make decisions and
> set defaults. But the user is in the wheel, not us. There is where
> Debian failed us.
> 
> Do I want systemd in my boxes? For sure not, but I still want to be
> free to choose "yes" inside Devuan, exactly the same I'm free to
> shout some political views on the street. It's a matter of freedom,
> not a matter of forbidding. Devuan gives me the choice, and I will
> chose "No systemd, thanks".
> 
> As a resume: If you want a systemd-free system, Devuan is your
> distribution, and will always be. But if you want a system designed
> to be unable to run systemd, please leave us. This is not the place
> for such an anti-freedom POV.
> 

I totally agree with the spirit of your post, but you would reckon
that such a variety (in terms of init choices, for instance) is bound
to the availability of a sizable cohort of developers.

The problem of systemd IMHO is that of introducing in GNU/Linux an
*indispensable* piece of software which is hard to remove and replace,
and this is something that I am sure most of the community, including
the systemd-fanboys, will regret to have done, sooner or later. That's
why I believe it is fundamental to have a systemd-free distro, in
order to confirm that nothing is *indispensable* in a unix
environment...

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] Which package generates /lib/systemd and /etc/systemd files?

[KatolaZ]

On Tue, May 05, 2015 at 12:35:57PM -0400, Hendrik Boom wrote:
> On Tue, May 05, 2015 at 11:49:34AM -0400, Steve Litt wrote:
> > 
> > Hi Noel,
> > 
> > Having any systemd-equipped Devuan packages means that I need to always
> > be on my guard to prevent systemd from sneaking in.
> 
> Could segregate the packages by putting them in another category, so 
> we'd have free, contrib, nonfree, systemd, ...
> 

But guys, I thought that the challenge over here was to have a
systemd-free system to start with, or not? I thought that there were a
bunch of people out there trying their best to eradicate systemd from
debian packages, making a lot of work to repackage everything as
Devuan, a new systemd-free distribution...Or am I mistaken?

IMHO anybody who wants systemd has plenty of good alternatives to
choose from, without waiting for a new systemd-free GNU/Linux
distribution to become usable. After all, what's the point of
stubbornly wanting a systemd-free distro if in the end you are going
to use systemd anyway?

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] Which package generates /lib/systemd and /etc/systemd files?

[Noel Torres]

Steve Litt  escribió:


On Tue, 05 May 2015 16:50:13 +0200
Anto  wrote:


In my view, the decision to use systemd as the default init of Debian
forces the locked-in of massive number of packages into systemd. That
is the main problem which leads to the birth of Devuan. They then
provide workarounds for people who want to use other init systems,
e.g. shim, etc., to be able to use the whole systemd base distro.

Cheers,

Anto


As a guy involved in the Debian-User systemd wars, and an early
resident of the Modular-Debian and Dng lists, what Anto says is how I
remember things. We were going for sans-systemd, not systemd optional.


Hi Steve:

We are going sans-systemd for Jessie, to be able to give our users  
true freedom at some point. Debian gives no freedom since systemd is  
imposed (forget chatter about the meaning of "default" and headless  
machines).


It was clearly said before: our main points are freedom and choice.  
And yes, this includes freedom to choose the worst ever init system  
dinosaur out there.


Why do we, then, remove systemd?

Because it is so intrincately depended on by the core of a Debian  
system that we can not simply "get Debian and remove the systemd  
bits". We owe our users a truly systemd-free system, and that's why we  
are here, but we do not owe them a systemd-forbidding system.


We are building a distribution, and as such we make decisions and set  
defaults. But the user is in the wheel, not us. There is where Debian  
failed us.


Do I want systemd in my boxes? For sure not, but I still want to be  
free to choose "yes" inside Devuan, exactly the same I'm free to shout  
some political views on the street. It's a matter of freedom, not a  
matter of forbidding. Devuan gives me the choice, and I will chose "No  
systemd, thanks".


As a resume: If you want a systemd-free system, Devuan is your  
distribution, and will always be. But if you want a system designed to  
be unable to run systemd, please leave us. This is not the place for  
such an anti-freedom POV.


To the service files removal point: don't be the Inquisition. It just  
gives extra work for no gain. Keeping the files off means keeping a  
constant patch, whose work will be better invested in actually  
removing dependencies on systemd in other packages, testing the  
distribution, building sane environments, etc.


Regards

Noel
er envite


binjS4QXZjRgz.bin
Description: Clave PGP pública


pgpsGy0wYWDdo.pgp
Description: Firma digital PGP
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Hendrik Boom]

On Tue, May 05, 2015 at 11:49:34AM -0400, Steve Litt wrote:
> 
> Hi Noel,
> 
> Having any systemd-equipped Devuan packages means that I need to always
> be on my guard to prevent systemd from sneaking in.

Could segregate the packages by putting them in another category, so 
we'd have free, contrib, nonfree, systemd, ...

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Steve Litt]

On Tue, 05 May 2015 16:50:13 +0200
Anto  wrote:

> In my view, the decision to use systemd as the default init of Debian 
> forces the locked-in of massive number of packages into systemd. That
> is the main problem which leads to the birth of Devuan. They then
> provide workarounds for people who want to use other init systems,
> e.g. shim, etc., to be able to use the whole systemd base distro.
> 
> Cheers,
> 
> Anto

As a guy involved in the Debian-User systemd wars, and an early
resident of the Modular-Debian and Dng lists, what Anto says is how I
remember things. We were going for sans-systemd, not systemd optional.

SteveT

Steve Litt 
May 2015 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Steve Litt]

On Tue, 5 May 2015 16:40:55 +0200
Martin Waschbüsch  wrote:


> At any rate, Devuan's distinguishing factor, as Noel has correctly
> pointed out, is that freedom of choice is promoted. So that people
> can continue to mix and match components as they see fit. Therefore,
> (at least from my POV), the argument that systemd is not a 'good'
> piece of software should go something like this:

I'd say the minute systemd comes on the scene, the ability to mix and
match components is drastically reduced. Devuan isn't doing the
reduction, systemd is.

Before we get too deeply into this whole thing, what was the original
question? What exact thing are we arguing whether or not to include in
Devuan?

Thanks,

SteveT

Steve Litt 
May 2015 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Anto]

On 05/05/15 16:53, Tilmann Hentze wrote:

dpkg -S /lib/systemd /etc/systemd


Thanks Tilmann,

I tried that command as well, though I usually use --search.

But I actually just found it, with "find" command (Doh!)

anto@d945gclf:~/packages/cron-3.0pl1-devuan$ find . -name "cron.service"
./debian/cron.service
anto@d945gclf:~/packages/cron-3.0pl1-devuan$

I just removed that file, recompiled cron, purged the current one and 
re-installed it. And guess what, no /lib/systemd/system/cron.service 
anymore :)


I always get the impression that there should be is a copy command on 
one of the compile scripts. So I think removing the file is not a good 
solution, in case Devuan must support systemd :)


I am sorry for all the noise. I should be more carefull next time.

Cheers,

Anto

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Steve Litt]

On Tue, 05 May 2015 14:00:31 +
Noel Torres  wrote:

> 
> Anto  escribió:
> [...]
> > Hello Noel,
> >
> > I think I have a good reason to want to have them removed. I hate
> > them :)
> 
> You are free to do so.
> >
> > I don't think Devuan should provide the option to use systemd. Why  
> > should it? The decision in Debian to default the init system to  
> > systemd is the main reason to fork Debian in the first place. And  
> > the users who want systemd are better of using Debian instead of  
> > Devuan.
> 
> You don't think that we should provide the option. But we should,  
> because not doing so means removing freedom fro mour users: removing  
> the freedom to use systemd.

Hi Noel,

Having any systemd-equipped Devuan packages means that I need to always
be on my guard to prevent systemd from sneaking in.

How about this: Unlike Redhat/Debian, we put in no poison pills,
landmines or Halloween Code to prevent others from installing systemd.
If someone wants to install systemd, let them do it on their own time.
Heck, once Devuan becomes my daily driver, I'm almost certainly going to
install an init other than sysvinit on it. Guys wanting systemd on
Devuan (doesn't that sound like an oxymoron?) can do the same thing.
We're not stopping them.

SteveT

Steve Litt 
May 2015 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Steve Litt]

On Tue, 05 May 2015 14:31:45 +0200
Anto  wrote:

> 
> 
> On 05/05/15 13:48, Noel Torres wrote:
> >
> > Didier Kryn  escribió:
> >
> > [...]
> >> I bet every service daemon package would now provide
> >> a .service file, just like everyone used to provide an init
> >> script. As far as I understand, the .service files are the systemd
> >> counterpart of sysvinit scripts. I imagine it is just enough to
> >> remove the file from the package; it would be usefull only to
> >> systemd.
> >>
> >> Didier
> >
> > There is no reason to remove them. That would be a Delta that we
> > must maintain package over package, version after version. Just
> > allow them to be there, unused.
> >
> > Please remember that our objective is not to forbid nor impede
> > usage of systemd. A Devuan user might quite well **CHOOSE** to use
> > systemd (well, not for the first version that we will launch
> > without systemd at all). Our objective is to allow freedom. It
> > would be wonderful if all packages provides start/stop scripts for
> > all init systems.
> >
> > Regards
> >
> > Noel
> > er Envite
> 
> Hello Noel,
> 
> I think I have a good reason to want to have them removed. I hate
> them :)
> 
> I don't think Devuan should provide the option to use systemd. Why 
> should it? The decision in Debian to default the init system to
> systemd is the main reason to fork Debian in the first place. And the
> users who want systemd are better of using Debian instead of Devuan.
> 
> On my particular case, I want to have that cron.service file gone as 
> that is the main reason for me to re-compile it.
> 
> Cheers,
> 
> Anto

I have two contradictory comments.

First, like Anto, to the extent possible, I want nothing systemd on my
computer. For practical reasons, I disagree with Noel about giving the
user the right to choose systemd. As a practical matter, no non-troll
person would choose Devuan if they wanted systemd. They might choose
Devuan if they wanted runit, s6, nosh, Epoch, Suckless Init and the
like, but for systemd, their universe is like a million dollar gift
certificate at the mall. Almost every distro on the planet comes
with systemd. We owe systemd to nobody: They have plenty of other
alternatives.

Oppositely, the perfect is the enemy of the good, and if we need to
keep a few systemdisms in order to roll out a distribution, so be it.
If, on an ongoing basis, there's a lag between Debian's welding of
systemd to new functionalities, and our ability to undo the weld, we
should give the user the welded version until we can free the
capability.

To me, the degree to which we "support" systemd has nothing to do with
"choice", and everything to do with practicality. To me, in a perfect
world, there wouldn't be a line of systemd code in Devuan. If someone
wants Devuan with systemd, there's a word for that: Debian.

SteveT

Steve Litt 
May 2015 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Tilmann Hentze]

On 2015-05-05, Anto  wrote:

> Which package actually generates all of the files and directories under 
> /lib/systemd and /etc/systemd if not the packages themselves, like cron 
> on the example above?

dpkg -S /lib/systemd /etc/systemd

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Hendrik Boom]

On Tue, May 05, 2015 at 02:31:45PM +0200, Anto wrote:
> 
> I don't think Devuan should provide the option to use systemd. Why
> should it? The decision in Debian to default the init system to
> systemd is the main reason to fork Debian in the first place. And
> the users who want systemd are better of using Debian instead of
> Devuan.

Nono.  A user may view the headlong ruch to imposing systemd as a 
symptom that matters have gone badly wrong with the way Debian is 
being assembled, and wish to use Devuan because its development process 
is more conservative.  That user may still want to install systemd.

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Didier Kryn]

Please Guys, my answer to Anto was purely technical but it 
triggered a philosophical discussion which happened already several 
times. Could we stop the thread please? Maybe this discussion may happen 
later, when we are all happy with our working devuan system.


Didier

Le 05/05/2015 16:43, Marlon Nunes a écrit :

On 2015-05-05 11:34, Anto wrote:

On 05/05/15 16:00, Noel Torres wrote:


Anto  escribió:
[...]

Hello Noel,

I think I have a good reason to want to have them removed. I hate 
them :)


You are free to do so.


I don't think Devuan should provide the option to use systemd. Why 
should it? The decision in Debian to default the init system to 
systemd is the main reason to fork Debian in the first place. And 
the users who want systemd are better of using Debian instead of 
Devuan.


You don't think that we should provide the option. But we should, 
because not doing so means removing freedom fro mour users: removing 
the freedom to use systemd.


We are not anti-systemd, we are anti-systemd-being-imposed. And the 
first step is to create a distribution able to work without systemd 
at all.


Truly speaking, we are no anti-anything. We are pro-freedom 
(including the freedom to choose systemd). This was extensively 
discussed on the first days of this list.


On my particular case, I want to have that cron.service file gone 
as that is the main reason for me to re-compile it.


Well, I would say that is not a reason to recompile it at all, but 
that's up to you. I say, tough, that only the removal of a systemd 
service file is not a reason for Devuan to maintain a Delta over 
Debian (and all the associated wasted effort).


Cheers,

Anto


Regards

Noel
er Envite


I think you are contradicting yourself, Noel.

On one hand you wrote that removing anything related to systemd like
what I am doing, is a waste of efforts. On the other hand, you wrote
that Devuan should support systemd in the future and that is not a
waste of efforts.

In my view, the later is really a waste of efforts as that means all
the efforts that are currently being done in removing systemd and
stripping all systemd related components from a lot of packages, will
have to be repeated to implement them again in the future possibly in
different form.

The freedom of choice for the users who prefer systemd already exists
a few years ago. If I would be one of those people, I wouldn't wait
for Devuan to support systemd as I can use any other distros. In fact
I wouldn't even look at Devuan as I would probably be already happily
using a distro with systemd.

I completely agree that Devuan must offer choices to the users. But
that must not clash with the principle as to why Devuan must exist in
the first place.

Cheers,

Anto

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


1+




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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Anto]

On 05/05/15 16:05, David Hare wrote:



The decision in Debian to default the init system to systemd
is the main reason to fork Debian in the first place.


Not exactly.. The reason is Debian's decision to *require* systemd 
with the only alternative a crippled OS. What is "default" matters less..


D


Sorry David, I have to disagree with that. (What happened to me today, I 
have a lot of disagreements with people including at work).


In my view, the decision to use systemd as the default init of Debian 
forces the locked-in of massive number of packages into systemd. That is 
the main problem which leads to the birth of Devuan. They then provide 
workarounds for people who want to use other init systems, e.g. shim, 
etc., to be able to use the whole systemd base distro.


Cheers,

Anto

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Marlon Nunes]

On 2015-05-05 11:34, Anto wrote:

On 05/05/15 16:00, Noel Torres wrote:


Anto  escribió:
[...]

Hello Noel,

I think I have a good reason to want to have them removed. I hate 
them :)


You are free to do so.


I don't think Devuan should provide the option to use systemd. Why 
should it? The decision in Debian to default the init system to 
systemd is the main reason to fork Debian in the first place. And the 
users who want systemd are better of using Debian instead of Devuan.


You don't think that we should provide the option. But we should, 
because not doing so means removing freedom fro mour users: removing 
the freedom to use systemd.


We are not anti-systemd, we are anti-systemd-being-imposed. And the 
first step is to create a distribution able to work without systemd at 
all.


Truly speaking, we are no anti-anything. We are pro-freedom (including 
the freedom to choose systemd). This was extensively discussed on the 
first days of this list.


On my particular case, I want to have that cron.service file gone as 
that is the main reason for me to re-compile it.


Well, I would say that is not a reason to recompile it at all, but 
that's up to you. I say, tough, that only the removal of a systemd 
service file is not a reason for Devuan to maintain a Delta over 
Debian (and all the associated wasted effort).


Cheers,

Anto


Regards

Noel
er Envite


I think you are contradicting yourself, Noel.

On one hand you wrote that removing anything related to systemd like
what I am doing, is a waste of efforts. On the other hand, you wrote
that Devuan should support systemd in the future and that is not a
waste of efforts.

In my view, the later is really a waste of efforts as that means all
the efforts that are currently being done in removing systemd and
stripping all systemd related components from a lot of packages, will
have to be repeated to implement them again in the future possibly in
different form.

The freedom of choice for the users who prefer systemd already exists
a few years ago. If I would be one of those people, I wouldn't wait
for Devuan to support systemd as I can use any other distros. In fact
I wouldn't even look at Devuan as I would probably be already happily
using a distro with systemd.

I completely agree that Devuan must offer choices to the users. But
that must not clash with the principle as to why Devuan must exist in
the first place.

Cheers,

Anto

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


1+

--
Stop slacking you lazy bum!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Martin Waschbüsch]

Unlurking here for a moment...
> Am 05.05.2015 um 16:05 schrieb David Hare :
> 
> 
>> The decision in Debian to default the init system to systemd
>> is the main reason to fork Debian in the first place.
> 
> Not exactly.. The reason is Debian's decision to *require* systemd with the 
> only alternative a crippled OS. What is "default" matters less..

I disagree w/r to the 'crippled OS' part: Depending on the use-case, you *can* 
have a fully working Debian 8 system that does not require systemd. For 
instance if you run a headless mail or webserver.
On the server systems I run using Jessie, everything runs find and runs fine 
using sysvinit as the init system.
Granted, you still need to run udev and have libsystemd installed, but that is 
a different matter.

At any rate, Devuan's distinguishing factor, as Noel has correctly pointed out, 
is that freedom of choice is promoted. So that people can continue to mix and 
match components as they see fit. Therefore, (at least from my POV), the 
argument that systemd is not a 'good' piece of software should go something 
like this:

A) systemd is (arguably) aiming to be(come) a sort of middleware to sit between 
kernel and userspace.
B) As such, it aims at making itself an indispensable, integral part of 
GNU/Linux as a complete OS.
C) Once it has become an integral part, people will no longer have a choice 
about using it or not.
D) Devuan promotes freedom of choice and tries to maximize freedom of choice 
w/r to all pieces of software.
E) Devuan regards software that tries to eleminate or minimize freedom of 
choice as 'bad'.
F) Since systemd matches these criteria, it is a 'bad' piece of software.


This had been very succinctly described by Christopher Barry 
(https://lkml.org/lkml/2014/8/12/459 )

"For me, Linux had already won that war way back in 1994 when I started
using it. It did it without firing a shot or attempting to be just like
the other OSes. It won it it by not giving a flying fuck about market
share. It won it by being exactly NOT them. It won it by being simple
and understandable and configurable to be exactly how *I* wanted it to
be. It won it by being a collection of simple modular components that
could be plugged together at will to do real work. It won it by
adhering to a deeply considered philosophy of the user being in the
drivers seat, and being free to run the things she wanted to, without
layers and layers of frameworks wrapping their tendrils into all manor
of stuff they should not be touching. It won it without the various
'CrapKit' shit that's begun to insinuate itself into the heart of my
system of late. It won it without being overly complex and unknowable.
That kind of opacity was was the core of Windows and Mac, and that's
exactly what I despise about them, and exactly why I chose to use Linux
in the first goddamn place. systemd is embracing *all* that I hate about
Windows and Mac, and doing so in the name of 'modernity' and
'simplifying' a developer's job."





Best,

Martin


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Marlon Nunes]

On 2015-05-05 11:34, Anto wrote:

On 05/05/15 16:00, Noel Torres wrote:


Anto  escribió:
[...]

Hello Noel,

I think I have a good reason to want to have them removed. I hate 
them :)


You are free to do so.


I don't think Devuan should provide the option to use systemd. Why 
should it? The decision in Debian to default the init system to 
systemd is the main reason to fork Debian in the first place. And the 
users who want systemd are better of using Debian instead of Devuan.


You don't think that we should provide the option. But we should, 
because not doing so means removing freedom fro mour users: removing 
the freedom to use systemd.


We are not anti-systemd, we are anti-systemd-being-imposed. And the 
first step is to create a distribution able to work without systemd at 
all.


Truly speaking, we are no anti-anything. We are pro-freedom (including 
the freedom to choose systemd). This was extensively discussed on the 
first days of this list.


On my particular case, I want to have that cron.service file gone as 
that is the main reason for me to re-compile it.


Well, I would say that is not a reason to recompile it at all, but 
that's up to you. I say, tough, that only the removal of a systemd 
service file is not a reason for Devuan to maintain a Delta over 
Debian (and all the associated wasted effort).


Cheers,

Anto


Regards

Noel
er Envite


+1



I think you are contradicting yourself, Noel.

On one hand you wrote that removing anything related to systemd like
what I am doing, is a waste of efforts. On the other hand, you wrote
that Devuan should support systemd in the future and that is not a
waste of efforts.

In my view, the later is really a waste of efforts as that means all
the efforts that are currently being done in removing systemd and
stripping all systemd related components from a lot of packages, will
have to be repeated to implement them again in the future possibly in
different form.

The freedom of choice for the users who prefer systemd already exists
a few years ago. If I would be one of those people, I wouldn't wait
for Devuan to support systemd as I can use any other distros. In fact
I wouldn't even look at Devuan as I would probably be already happily
using a distro with systemd.

I completely agree that Devuan must offer choices to the users. But
that must not clash with the principle as to why Devuan must exist in
the first place.

Cheers,

Anto

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


--
Stop slacking you lazy bum!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Anto]

On 05/05/15 16:00, Noel Torres wrote:


Anto  escribió:
[...]

Hello Noel,

I think I have a good reason to want to have them removed. I hate 
them :)


You are free to do so.


I don't think Devuan should provide the option to use systemd. Why 
should it? The decision in Debian to default the init system to 
systemd is the main reason to fork Debian in the first place. And the 
users who want systemd are better of using Debian instead of Devuan.


You don't think that we should provide the option. But we should, 
because not doing so means removing freedom fro mour users: removing 
the freedom to use systemd.


We are not anti-systemd, we are anti-systemd-being-imposed. And the 
first step is to create a distribution able to work without systemd at 
all.


Truly speaking, we are no anti-anything. We are pro-freedom (including 
the freedom to choose systemd). This was extensively discussed on the 
first days of this list.


On my particular case, I want to have that cron.service file gone as 
that is the main reason for me to re-compile it.


Well, I would say that is not a reason to recompile it at all, but 
that's up to you. I say, tough, that only the removal of a systemd 
service file is not a reason for Devuan to maintain a Delta over 
Debian (and all the associated wasted effort).


Cheers,

Anto


Regards

Noel
er Envite


I think you are contradicting yourself, Noel.

On one hand you wrote that removing anything related to systemd like 
what I am doing, is a waste of efforts. On the other hand, you wrote 
that Devuan should support systemd in the future and that is not a waste 
of efforts.


In my view, the later is really a waste of efforts as that means all the 
efforts that are currently being done in removing systemd and stripping 
all systemd related components from a lot of packages, will have to be 
repeated to implement them again in the future possibly in different form.


The freedom of choice for the users who prefer systemd already exists a 
few years ago. If I would be one of those people, I wouldn't wait for 
Devuan to support systemd as I can use any other distros. In fact I 
wouldn't even look at Devuan as I would probably be already happily 
using a distro with systemd.


I completely agree that Devuan must offer choices to the users. But that 
must not clash with the principle as to why Devuan must exist in the 
first place.


Cheers,

Anto

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[David Hare]

The decision in Debian to default the init system to systemd
is the main reason to fork Debian in the first place.


Not exactly.. The reason is Debian's decision to *require* systemd with 
the only alternative a crippled OS. What is "default" matters less..


D

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Noel Torres]

Anto  escribió:
[...]

Hello Noel,

I think I have a good reason to want to have them removed. I hate them :)


You are free to do so.


I don't think Devuan should provide the option to use systemd. Why  
should it? The decision in Debian to default the init system to  
systemd is the main reason to fork Debian in the first place. And  
the users who want systemd are better of using Debian instead of  
Devuan.


You don't think that we should provide the option. But we should,  
because not doing so means removing freedom fro mour users: removing  
the freedom to use systemd.


We are not anti-systemd, we are anti-systemd-being-imposed. And the  
first step is to create a distribution able to work without systemd at  
all.


Truly speaking, we are no anti-anything. We are pro-freedom (including  
the freedom to choose systemd). This was extensively discussed on the  
first days of this list.


On my particular case, I want to have that cron.service file gone as  
that is the main reason for me to re-compile it.


Well, I would say that is not a reason to recompile it at all, but  
that's up to you. I say, tough, that only the removal of a systemd  
service file is not a reason for Devuan to maintain a Delta over  
Debian (and all the associated wasted effort).


Cheers,

Anto


Regards

Noel
er Envite


binqR69GmAl5E.bin
Description: Clave PGP pública


pgpAu9hHUJvim.pgp
Description: Firma digital PGP
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Anto]

On 05/05/15 13:48, Noel Torres wrote:


Didier Kryn  escribió:

[...]
I bet every service daemon package would now provide a .service 
file, just like everyone used to provide an init script. As far as I 
understand, the .service files are the systemd counterpart of 
sysvinit scripts. I imagine it is just enough to remove the file from 
the package; it would be usefull only to systemd.


Didier


There is no reason to remove them. That would be a Delta that we must 
maintain package over package, version after version. Just allow them 
to be there, unused.


Please remember that our objective is not to forbid nor impede usage 
of systemd. A Devuan user might quite well **CHOOSE** to use systemd 
(well, not for the first version that we will launch without systemd 
at all). Our objective is to allow freedom. It would be wonderful if 
all packages provides start/stop scripts for all init systems.


Regards

Noel
er Envite


Hello Noel,

I think I have a good reason to want to have them removed. I hate them :)

I don't think Devuan should provide the option to use systemd. Why 
should it? The decision in Debian to default the init system to systemd 
is the main reason to fork Debian in the first place. And the users who 
want systemd are better of using Debian instead of Devuan.


On my particular case, I want to have that cron.service file gone as 
that is the main reason for me to re-compile it.


Cheers,

Anto

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Svante Signell]

On Tue, 2015-05-05 at 13:15 +0100, David Hare wrote:
> On 05/05/15 12:48, Noel Torres wrote:
> >
> > Didier Kryn  escribió:

> >
> > Please remember that our objective is not to forbid nor impede usage of
> > systemd. A Devuan user might quite well **CHOOSE** to use systemd (well,
> > not for the first version that we will launch without systemd at all).
> > Our objective is to allow freedom. It would be wonderful if all packages
> > provides start/stop scripts for all init systems.
> >
> 
> Yes.. freedom of choice is why we are here. Also, the priority is those 
> packages which actually reqire *systemd* (cups, udisks2, gvfs, 
> util-linux, sane-utils, consolekit, policykit-1.. and more).
> 
> That's a lot of work already and why some of us are at the moment still 
> relying on 3rd-party/"unofficial" packages.

Well, strictly speaking they can be removed if we have a Devuan version
of the package, they are already there in the Debian version. But, as
written above, the most important packages are the ones requiring
*systemd*. 

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Anto]

On 05/05/15 13:29, David Hare wrote:

On 05/05/15 11:57, Anto wrote:


I pinned *systemd* packages into Pin-Priority: -1, and re-compiled cron
package without anything related to systemd. But there is still
/lib/systemd/system/cron.service file as we can see below.



Which package actually generates all of the files and directories under
/lib/systemd and /etc/systemd if not the packages themselves, like cron
on the example above?


Quite a few (here including cron, rsysn, sudo, ssh, wpa-supplicant..)

 will tell you.

Because they are built with systemd support doesn't mean (yet) they 
actually require it. They can't use it if it's not installed.


Here *systemd* is excluded (except udev) but eveything seems to work.

D



Thanks David,

Me too. On all my Debian wheezy install, I excluded anything with 
*systemd* and I use udev 175-7.2. I also always remove /lib/systemd and 
/etc/systemd after any package installation.


I tried apt-file though, but the merged Devuan repository does not have 
the information for that. That was why I asked the question.


root@d945gclf:~# apt-file update
Ignoring source without Contents File:
http://packages.devuan.org/merged/dists/jessie/main/Contents-amd64.gz
Ignoring source without Contents File:
http://packages.devuan.org/merged/dists/jessie/contrib/Contents-amd64.gz
Ignoring source without Contents File:
http://packages.devuan.org/merged/dists/jessie/non-free/Contents-amd64.gz
root@d945gclf:~#
root@d945gclf:~#
root@d945gclf:~# apt-file search "/lib/systemd/system/cron.service"
E: The cache is empty. You need to run 'apt-file update' first.
root@d945gclf:~#

Cheers,

Anto


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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[David Hare]

On 05/05/15 12:48, Noel Torres wrote:


Didier Kryn  escribió:

[...]

I bet every service daemon package would now provide a .service
file, just like everyone used to provide an init script. As far as I
understand, the .service files are the systemd counterpart of sysvinit
scripts. I imagine it is just enough to remove the file from the
package; it would be usefull only to systemd.

Didier


There is no reason to remove them. That would be a Delta that we must
maintain package over package, version after version. Just allow them to
be there, unused.

Please remember that our objective is not to forbid nor impede usage of
systemd. A Devuan user might quite well **CHOOSE** to use systemd (well,
not for the first version that we will launch without systemd at all).
Our objective is to allow freedom. It would be wonderful if all packages
provides start/stop scripts for all init systems.



Yes.. freedom of choice is why we are here. Also, the priority is those 
packages which actually reqire *systemd* (cups, udisks2, gvfs, 
util-linux, sane-utils, consolekit, policykit-1.. and more).


That's a lot of work already and why some of us are at the moment still 
relying on 3rd-party/"unofficial" packages.


D

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Noel Torres]

Didier Kryn  escribió:

[...]
I bet every service daemon package would now provide a .service  
file, just like everyone used to provide an init script. As far as I  
understand, the .service files are the systemd counterpart of  
sysvinit scripts. I imagine it is just enough to remove the file  
from the package; it would be usefull only to systemd.


Didier


There is no reason to remove them. That would be a Delta that we must  
maintain package over package, version after version. Just allow them  
to be there, unused.


Please remember that our objective is not to forbid nor impede usage  
of systemd. A Devuan user might quite well **CHOOSE** to use systemd  
(well, not for the first version that we will launch without systemd  
at all). Our objective is to allow freedom. It would be wonderful if  
all packages provides start/stop scripts for all init systems.


Regards

Noel
er Envite


bin4hwHwbTuRD.bin
Description: Clave PGP pública
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Didier Kryn]

Le 05/05/2015 12:57, Anto a écrit :

Hello Everybody,

I pinned *systemd* packages into Pin-Priority: -1, and re-compiled 
cron package without anything related to systemd. But there is still 
/lib/systemd/system/cron.service file as we can see below.


anto@d945gclf:~/packages/cron-3.0pl1-devuan$ grep -R systemd *
debian/changelog:  * Remove any systemd related components
debian/changelog:  * Change systemd definition in order for the daemon 
to read an honor
debian/changelog:  * Add systemd service file. Thanks to Michael 
Stapelberg (Closes: #652440)

anto@d945gclf:~/packages/cron-3.0pl1-devuan$
anto@d945gclf:~/packages/cron-3.0pl1-devuan$ ls -ltr /lib/systemd/system
total 40
-rw-r--r-- 1 root root  344 Mar 23 00:08 ssh.service
-rw-r--r-- 1 root root  715 Apr 16 17:52 systemd-udev-trigger.service
-rw-r--r-- 1 root root  823 Apr 16 17:52 systemd-udev-settle.service
-rw-r--r-- 1 root root  826 Apr 16 17:52 systemd-udevd.service
-rw-r--r-- 1 root root  575 Apr 16 17:52 systemd-udevd-kernel.socket
-rw-r--r-- 1 root root  578 Apr 16 17:52 systemd-udevd-control.socket
-rw-r--r-- 1 root root  217 Apr 16 17:52 udev-finish.service
lrwxrwxrwx 1 root root   21 Apr 16 17:53 udev.service -> 
systemd-udevd.service

-rw-r--r-- 1 root root  234 May  4 22:00 cron.service
drwxr-xr-x 2 root root 4096 May  5 08:46 sysinit.target.wants
drwxr-xr-x 2 root root 4096 May  5 08:46 sockets.target.wants
anto@d945gclf:~/packages/cron-3.0pl1-devuan$

Which package actually generates all of the files and directories 
under /lib/systemd and /etc/systemd if not the packages themselves, 
like cron on the example above?


Thanks in advance.

Anto
I bet every service daemon package would now provide a .service 
file, just like everyone used to provide an init script. As far as I 
understand, the .service files are the systemd counterpart of sysvinit 
scripts. I imagine it is just enough to remove the file from the 
package; it would be usefull only to systemd.


Didier

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[David Hare]

On 05/05/15 11:57, Anto wrote:


I pinned *systemd* packages into Pin-Priority: -1, and re-compiled cron
package without anything related to systemd. But there is still
/lib/systemd/system/cron.service file as we can see below.



Which package actually generates all of the files and directories under
/lib/systemd and /etc/systemd if not the packages themselves, like cron
on the example above?


Quite a few (here including cron, rsysn, sudo, ssh, wpa-supplicant..)

 will tell you.

Because they are built with systemd support doesn't mean (yet) they 
actually require it. They can't use it if it's not installed.


Here *systemd* is excluded (except udev) but eveything seems to work.

D


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

[Dng] Which package generates /lib/systemd and /etc/systemd files?

[Anto]

Hello Everybody,

I pinned *systemd* packages into Pin-Priority: -1, and re-compiled cron 
package without anything related to systemd. But there is still 
/lib/systemd/system/cron.service file as we can see below.


anto@d945gclf:~/packages/cron-3.0pl1-devuan$ grep -R systemd *
debian/changelog:  * Remove any systemd related components
debian/changelog:  * Change systemd definition in order for the daemon 
to read an honor
debian/changelog:  * Add systemd service file. Thanks to Michael 
Stapelberg (Closes: #652440)

anto@d945gclf:~/packages/cron-3.0pl1-devuan$
anto@d945gclf:~/packages/cron-3.0pl1-devuan$ ls -ltr /lib/systemd/system
total 40
-rw-r--r-- 1 root root  344 Mar 23 00:08 ssh.service
-rw-r--r-- 1 root root  715 Apr 16 17:52 systemd-udev-trigger.service
-rw-r--r-- 1 root root  823 Apr 16 17:52 systemd-udev-settle.service
-rw-r--r-- 1 root root  826 Apr 16 17:52 systemd-udevd.service
-rw-r--r-- 1 root root  575 Apr 16 17:52 systemd-udevd-kernel.socket
-rw-r--r-- 1 root root  578 Apr 16 17:52 systemd-udevd-control.socket
-rw-r--r-- 1 root root  217 Apr 16 17:52 udev-finish.service
lrwxrwxrwx 1 root root   21 Apr 16 17:53 udev.service -> 
systemd-udevd.service

-rw-r--r-- 1 root root  234 May  4 22:00 cron.service
drwxr-xr-x 2 root root 4096 May  5 08:46 sysinit.target.wants
drwxr-xr-x 2 root root 4096 May  5 08:46 sockets.target.wants
anto@d945gclf:~/packages/cron-3.0pl1-devuan$

Which package actually generates all of the files and directories under 
/lib/systemd and /etc/systemd if not the packages themselves, like cron 
on the example above?


Thanks in advance.

Anto

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

Re: [Dng] Linux boot documentation

[Jürgen Buchmüller]

Am Dienstag, den 05.05.2015, 11:22 +0200 schrieb Didier Kryn:
> I'm not sure what happens if init crashes after other processes have
> been started, wether the kernel panics or other processes continue
> without init - not a very good situation.

FWIW: I've seen this happening with a home grown jessie (RC2) for
Cubietruck (armv7hf) where a module was seriously broken and led to a
segfault.

Since with systemd modules seem to be loaded by pid 1 itself, the crash
takes down systemd with it and the system reboots after exiting pid 1,
just crash again when trying to load the broken module the next time. No
chance to break out of this loop AFAIK.

To me this looks like a fundamental design flaw. A crashing module
should never _ever_ take the whole system down. There has to be some
privilege separation and signal handling in place to prevent that.

With SysV init this is no big problem, as usually some child process of
init (a shell script) loads the detected (udev rules) or defined
(/etc/modules) modules and if it crashes, init will still be alive.

Jürgen

P.S.: It may be that I did something wrong myself, while I basically
just debootstrapped jessie to an SD card image and added some custom
modules to the system.


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

Re: [Dng] Linux boot documentation

[Laurent Bercot]

On 05/05/2015 11:22, Didier Kryn wrote:

I'm not sure what happens if init crashes after other processes have
been started, wether the kernel panics or other processes continue
without init - not a very good situation.


 The Linux kernel panics when init dies. It's the dreaded "attempted
to kill init!" error message, the same you get at boot time when the
kernel fails to execute init for some reason (often a rootfs not
found).
 This behaviour is debatable - a cleaner solution would probably be
to reboot when init dies. But it's how it has always worked.

 Other OSes may exhibit different behaviours. On an old version of
Solaris, for instance, pid 1 could die like any other process and the
kernel would simply keep running. However, no process would reap
orphans, and zombies would accumulate, eventually making the machine
unusable - full process table with no way to clean up - so it was not
an acceptable design, and I think they changed it later on (but I
stopped using Solaris so I'm not sure how it evolved).



Hope this helps and there are no errors :-)


 AFAIK, it was pretty spot-on :)

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

Re: [Dng] Linux boot documentation

[Didier Kryn]

Le 04/05/2015 16:48, Steve Litt a écrit :

Hi all,

I just documented the boot process, from Grub through init.

See http://troubleshooters.com/linux/diy/howboot.htm

Hope you like it.

SteveT



Dear Steve, I have a few comments, more or less important to 
understand how things work:


It is pretty seldom, I think, that /bin and /sbin are symbolic 
links to /usr/bin and /usr/sbin. I have never seen it in a major distro 
up to now.


The root= argument to kernel is usefull also when using an 
initramfs. In this case the the argument is ignored by the kernel but it 
is available to the initramfs init program. Note that custom initramfs 
may ignore it and have other ways to find the root partition.


The initramfs init does a few things before it pivot-root and 
passes control to the ondisk init. It mounts /proc, /sys, /dev, creates 
device files, mounts the disk root partition, then mounts proc, sys and 
dev on this partition. On Debian, it mounts /run on tmpfs. When the 
ondisk init starts, there are quite a few things ready.


Processes are created with a process-id which is incremented for 
every new process, until it reaches the maximum and restarts from the 
begining. If init has pid 1, it is because it is just the first one 
created. There is no other process started by the kernel before init. If 
the second init (after pivot-root) also has pid 1, it is because it is 
just the same process, running a different program. I'm not sure what 
happens if init crashes after other processes have been started, wether 
the kernel panics or other processes continue without init - not a very 
good situation.


The initramfs is a live OS and you can make it a friendly debugging 
environment to help understand what is going on. As Laurent mentionned 
some time ago, it is not even necessary to pivot-root; you could keep 
/bin and /sbin  in ramfs and just mount the rest. Of course upgrading 
the files in /bin and /sbin would involve re-creating the whole initramfs.


A ramfs or tmpfs is not exactly like the old initrd. The Linux VFS 
keeps data in buffers and filesystems periodically swap the data in 
these buffers with hardware backup stores, that is disks. A ramdisk is 
when the backup store is in some fixed location in ram. The ramfs is a 
filesystem simply *without* a backing store - very nice idea which 
emerged around 10 years ago I think, which shows that simplicity is not 
given, it is an achievement. tmpfs is like ramfs, except it can expand 
to the swapping area. I think that ramfs and tmpfs have been completely 
merged a few years ago.


Hope this helps and there are no errors :-)

Didier

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