DEVUAN is alive! Hurrah!

[edbarx]

DEVUAN is alive!

It is very clear Devuan DDs are doing their job with great dedication. Thanks for all your efforts and for promoting real software freedom.

This is how my DEVUAN installation responded when I updated it this morning:

Code: Select all

root@devuan-inst:/home/edbarx# apt-get update
Hit http://security.debian.org jessie/updates InRelease
Hit http://security.debian.org jessie/updates/main Sources                     
Hit http://security.debian.org jessie/updates/main amd64 Packages              
Hit http://security.debian.org jessie/updates/main Translation-en              
Get:1 http://us.mirror.devuan.org jessie InRelease [108 kB]                    
Get:2 http://us.mirror.devuan.org jessie-updates InRelease [108 kB]
Get:3 http://us.mirror.devuan.org jessie/main Sources [7,159 kB]
Get:4 http://us.mirror.devuan.org jessie/main amd64 Packages [6,888 kB]        
Get:5 http://us.mirror.devuan.org jessie-updates/main Sources [2,300 B]        
Get:6 http://us.mirror.devuan.org jessie-updates/main amd64 Packages [3,456 B] 
Ign http://us.mirror.devuan.org jessie/main Translation-en_GB                  
Ign http://us.mirror.devuan.org jessie/main Translation-en                     
Ign http://us.mirror.devuan.org jessie-updates/main Translation-en_GB          
Ign http://us.mirror.devuan.org jessie-updates/main Translation-en             
Fetched 14.3 MB in 13s (1,080 kB/s)                                            
Reading package lists... Done
root@devuan-inst:/home/edbarx# apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... The following packages were automatically installed and are no longer required:
  gvfs-common gvfs-libs libaacs0 libbluray1 libsecret-1-0 libsecret-common
Use 'apt-get autoremove' to remove them.
Done
The following packages have been kept back:
  initscripts sysvinit-utils util-linux
The following packages will be upgraded:
  base-files
1 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
Need to get 83.7 kB of archives.
After this operation, 1,024 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://us.mirror.devuan.org/merged/ jessie/main base-files amd64 8+devuan3 [83.7 kB]
Fetched 83.7 kB in 0s (182 kB/s)    
(Reading database ... 51205 files and directories currently installed.)
Preparing to unpack .../base-files_8+devuan3_amd64.deb ...
Unpacking base-files (8+devuan3) over (8+devuan2) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up base-files (8+devuan3) ...
rm /etc/dpkg/origins/default

[mor]

… and for promoting real software freedom.

Don't mean to rain on your parade, actually I'm happy to see Devuan progress, but either explain what "real freedom" means or be fair and retract the statement.

Bye

[alansmithee]

Don't mean to rain on your parade, actually I'm happy to see Devuan progress, but either explain what "real freedom" means or be fair and retract the statement.

judecnelson provided a pretty good explanation of the Devuan view on that in this linuxquestions.org posting.

[mor]

I'm sorry but not the "Freedom 0" defense again!

Interpreting freedom 0 that way is like saying that since Americans use the imperial system, the U.S.A. are violating the freedom of Europeans and other metric system users on American soil to talk centimeters, milliliters or kilograms.
Take the analogy with a grain of salt of course.

Point is that as you know way better than me, some developmental choices are inevitably bound to prevent other choices or make them impractical.
The very freedom that this defense is claiming to be violated is the freedom that allows developers to go in the direction they like the most, and indirectly of distros to adopt the software they see more fit for their projects.

Freedom 0 in fact is about having the right to use software without any explicit restriction. It is against being prevented from using and modifying software in any way one wants, not to guarantee people that they are gonna have their software forever.
By that logic Debian would have had to maintain all software, in order to give everybody every choice.
The only thing that freedom 0 guarantees is the freedom itself, not distros' choice of this over that software.

The beauty of software freedom is that as long as there is a will there is a possibility, forbidden by nobody, to do things differently.
Isn't this very thread about the reality of a project like Devuan taking off, even in spite of the high skepticism of many anti-systemd people?

That is something to celebrate, but Ed said "real freedom" and the words have a meaning. Saying "real freedom" implies that there is a form of freedom that is not real, hence that it is not freedom.
I can't accept the "Freedom 0" defense for that statement.

Cheers.

[Head_on_a_Stick]

I really do wish the Devuan team all the best and hope that their ambitious project succeeds but I don't understand.

Debian is init-agnostic.

Yes, systemd is the *default* but it is very simple to install and use SysVinit (or even upstart) in Debian.
https://wiki.debian.org/FAQsFromDebianU ... _Jessie.3F

And yes, the systemd libraries remain on the system but this is because they are dependencies of other programs and, as such, this is a purely upstream matter.

Also the libraries are inert unless the packages for which they are dependencies interact with systemd, which will *not* happen if SysVinit or upstart is PID1.

[stevepusser]

I really do wish the Devuan team all the best and hope that their ambitious project succeeds but I don't understand.

Debian is init-agnostic.

Yes, systemd is the *default* but it is very simple to install and use SysVinit (or even upstart) in Debian.
https://wiki.debian.org/FAQsFromDebianU ... _Jessie.3F

And yes, the systemd libraries remain on the system but this is because they are dependencies of other programs and, as such, this is a purely upstream matter.

Also the libraries are inert unless the packages for which they are dependencies interact with systemd, which will *not* happen if SysVinit or upstart is PID1.

Stop making sense! It's very boring.

[Sarge-in-charge]

I really do wish the Devuan team all the best and hope that their ambitious project succeeds but I don't understand.

Debian is init-agnostic.

Debian is not init-agnostic, as it is not MTA-agnostic, as it is not kernel-agnostic.

The fact that you can do some convoluted calisthenics and change a default setting, does not make it agnostic about that setting.

[Head_on_a_Stick]

it is not kernel-agnostic.

Code: Select all

empty@BunsenLabs ~ % uname -a
Linux BunsenLabs 4.0-4.dmz.1-liquorix-amd64 #1 ZEN SMP PREEMPT Debian 4.0-8 (2015-05-17) x86_64 GNU/Linux

Also: https://www.debian.org/ports/hurd/

[Sarge-in-charge]

it is not kernel-agnostic.

Code: Select all

empty@BunsenLabs ~ % uname -a
Linux BunsenLabs 4.0-4.dmz.1-liquorix-amd64 #1 ZEN SMP PREEMPT Debian 4.0-8 (2015-05-17) x86_64 GNU/Linux

Also: https://www.debian.org/ports/hurd/

What part of "convoluted calisthenics" didn't you understand?

[Head_on_a_Stick]

What part of "convoluted calisthenics" didn't you understand?

Code: Select all

apt-get install sysvinit-core systemd-shim systemd-sysv-

One command, mate -- that is not complicated at all...
https://wiki.debian.org/FAQsFromDebianU ... _Jessie.3F

[Danielsan]

You're right unfortunately is impossible to avoid to install systemd all we are obligated to have it installed in our computer even if your are using another init system, thanks Lennart, we really appreciated it...

[edbarx]

Also the libraries are inert unless the packages for which they are dependencies interact with systemd, which will *not* happen if SysVinit or upstart is PID1.

Could you please, explain this by reference to systemd code?

On this installation, $ lsof | grep systemd returns nothing.

[Head_on_a_Stick]

Also the libraries are inert unless the packages for which they are dependencies interact with systemd, which will *not* happen if SysVinit or upstart is PID1.

Could you please, explain this by reference to systemd code?

No I can't.

What a strange question...

The systemd code will not be called unless the systemd *program* is run; the systemd program will not be run unless it is PID1; systemd will not be called as PID1 if SysVinit (or upstart) is being used as /sbin/init (which is called by the kernel as PID1 unless it is over-ridden by a kernel command line parameter).

Use the command string I listed above to convert your system to SysVinit and then check the output of:

Code: Select all

ls -l /sbin/init

Then compare that to the output on my Debian sid box using systemd as PID1:

Code: Select all

empty@Debian ~ % ls -l /sbin/init
lrwxrwxrwx 1 root root 20 Jun  2 07:31 /sbin/init -> /lib/systemd/systemd*

How exactly are you proposing that the systemd binary is called and run on a system using SysVinit as PID1?

EDIT: Also, if I may, the last line in your signature is erroneous -- I am a confirmed CLI-addict and systemd does not stop me from using it at every opportunity for all sysadmin tasks on my machines.

[edbarx]

The systemd code will not be called unless the systemd *program* is run; the systemd program will not be run unless it is PID1; systemd will not be called as PID1 if SysVinit (or upstart) is being used as /sbin/init (which is called by the kernel as PID1 unless it is over-ridden by a kernel command line parameter).

systemd is much more than than /bin/systemd as the project also includes libraries like libsystemd0.

Use the command string I listed above to convert your system to SysVinit and then check the output of:

Code: Select all

ls -l /sbin/init

My system is already 'converted' to SysVinit.

Code: Select all

-rwxr-xr-x 1 root root 37064 May 29 06:08 /sbin/init

Mine is an executable, yours is a symbolic link to the systemd executable.

How exactly are you proposing that the systemd binary is called and run on a system using SysVinit as PID1?

I am not proposing that. That would be a serious bug Debian DDs will correct immediately. Debian is still used to power servers and there are still those who are not comfortable with systemd as PID 1. The reason for their choice of not using systemd, is probably, the fact that systemd is still new software, and they want the test of time.

EDIT: Also, if I may, the last line in your signature is erroneous -- I am a confirmed CLI-addict and systemd does not stop me from using it at every opportunity for all sysadmin tasks on my machines.

In this one I am afraid I cannot answer your question. It is better to forward it to the systemd developers themselves, they know better than me.

[Head_on_a_Stick]

systemd is much more than than /bin/systemd as the project also includes libraries like libsystemd0.

Accessing those libraries would be part of the code of the programs that are attempting to access the libraries rather than systemd; as I said above this is purely an upstream matter.

[TobiSGD]

EDIT: Also, if I may, the last line in your signature is erroneous -- I am a confirmed CLI-addict and systemd does not stop me from using it at every opportunity for all sysadmin tasks on my machines.

In this one I am afraid I cannot answer your question. It is better to forward it to the systemd developers themselves, they know better than me.

Did you just admit that you make unfounded claims (some people call that spreading FUD) and will do so until proven wrong explicitly by systemd developers?
Wow, I thought you were one of the reasonable ones. I must have made a mistake.

[edbarx]

EDIT: Also, if I may, the last line in your signature is erroneous -- I am a confirmed CLI-addict and systemd does not stop me from using it at every opportunity for all sysadmin tasks on my machines.

In this one I am afraid I cannot answer your question. It is better to forward it to the systemd developers themselves, they know better than me.

Did you just admit that you make unfounded claims (some people call that spreading FUD) and will do so until proven wrong explicitly by systemd developers?

Quote these claims, please.

That is why I replied, ask the systemd developers as I have no authority to be their voice. They, definitely, know better their motivations. What I know is, at least one of them, is more in favour of graphical programs and that systemd facilitates a distribution to default installations without a terminal.

I only expressed an opinion that I hope is proven wrong with time. Now, if an opinion like mine is spreading fear of the unknown and death (I have no idea how death is related to systemd), I can expect the Sun to implode and form a supermassive blackhole tomorrow.

[TobiSGD]

Quote these claims, please.

I don't have to, they show up on every of your posts, but if you really want:

It is hard to get away from CLI tools but systemd assumes the CLI is passe!

That is why I replied, ask the systemd developers as I have no authority to be their voice.

Wait, just so that I get it: You claim that systemd assumes that the CLI is passe, and when asked about it you are claiming you can't say because you aren't a systemd developer. But then you also can't claim what systemd assumes in the first place. From whatever angle you look at it, this doesn't fit together.

They, definitely, know better their motivations.

Of course they know better, after all its their motivation. But that doesn't answer why you make claims on topics you admit you don't know if they are true.

What I know is, at least one of them, is more in favour of graphical programs

So one of the 300+ active developers prefers GUI programs, so of course this must be a systemd agenda. Doesn't that look weird to you?

and that systemd facilitates a distribution to default installations without a terminal.

Ah, I see, because it is possible to use systemd on systems that don't have a shell installed it must be their agenda to totally get rid of the CLI. Now that makes sense. Unless you think about it.

I only expressed an opinion that I hope is proven wrong with time. Now, if an opinion like mine is spreading fear of the unknown and death (I have no idea how death is related to systemd), I can expect the Sun to implode and form a supermassive blackhole tomorrow.

[/quote]
Spreading FUD is a well known term, used for people that spread Fear, Uncertainty and Doubt using baseless claims. Fits pretty much for your case, I would think.
Way to go if you want to destroy your own credibility.

[Sarge-in-charge]

Spreading FUD is a well known term, used for people that spread Fear, Uncertainty and Doubt using baseless claims.

Systemd is not UNIX-portable, and that is enough to make it a turd.

Systemd fixes a problem we didn't have in the sphere a sysadmining.

Those two points alone make Systemd a bullshit proposition.

Many people thought Debian had what it would take to remain bullshit-free. Alas, that has not come to be the case.

Debian is game over. Sorry about that.

[edbarx]

The systemd developer I referred to, is not any casual systemd developer, but Lennart Poettering himself. He doesn't like the CLI and considers it outdated. Also the fact that systemd uses a kernel parameter to allow an emergency terminal corroborates the impression systemd is primarily intended for desktop use. Even Microsoft Windows boasts of a shell, notwithstanding in the not so remote past, the same company wanted to impoverish it. Now, it boasts of a power shell and of scripting for the shell! It appears, systemd is lagging behind Microsoft repeating the same mistakes. Why doesn't it try to learn from them instead?

To state the subtle, rather than the obvious, in my case, and I dare say in the case of many critics of systemd, if the latter passes the test of time with good points, I will consider using it. However, it has to pass the test of time, and that includes many tests sysvinit has already passed.

You cannot blame us, critics of systemd, for choosing an alternative that is already qualified for use as it passed its tests with good marks.

Finally, to satisfy your request, although not done explicitly, I will edit my signature.