One possible slick will occupy the freedom of choice of advanced users from the mother distro: Debian; that one that respects diversity and freedom of choice at the level of “Startup Systems (Init), all due to the future General Resolution 2019-002 of the DEBIAN Project on how the great Mother Distro should address the existing Diversity on Startup Systems.
Summarizing there are 3 resolutions that eliminate freedoms of diversity, leaving only the "systemd", hence the one that most people hate systemd, all this is called "a healthy approach to PID1" in technical jargon.
Its consequences: death / obstruction to the work of other distros through extra workload because there will only be systemd: Devuan and MXLinux among others.
We talked about the Debian General Resolution 2019-002 submitted to its internal Voting System (only for Debian mantainers) existing around the «Startup Systems». This topic can be reinforced, by reading one of the many previous articles in the Ians personal article describin the right situation on this subject.
Its result can radically change the landscape of the most important distros derives from Debian, that is, the subject of this article is to raise awareness about a possible stain on the freedom of choice of advanced users and developers at the Startup Systems level (Init ), which is discussed in the future General Resolution to be taken.
We have the following problems about this situation that suggest the clear disadvantage of those interested:
In short, the content of the article to be read, there are 3 resolutions that eliminate the freedoms that guarantee diversity, leaving only the "Systemd", hence the one that most people hate "Systemd". All this is called "a healthy approach to PID1" in technical jargon. Its consequences: Death of other Distros derived through extra workload because there will only be "Systemd". For example, Devuan and MX-Linux could disappear.
Of the voting options (which we already said that although they are internally, we can make social pressure) we have 3 that destroy freedom and only two that protect them, the A, B, and C are the destructive ones and the E something flexible, only the D It is what allows real freedom. This is a resume and summary of https://www.debian.org/vote/2019/vote_002 as indicated in the previous section. Complete history are in the "linux post install" article at https://blog.desdelinux.net/resolucion-general-del-proyecto-debian-diversidad-del-sistema-init/ (spanish only)
Proposal A: startup diversity is important and IMMUable
Mention being able to run Debian systems with init systems other than systemd is still something that the project values. With the exception that all packages that owe it, must include scripts for the inits of the moment in use. It reinforces that the current policy says that packages should not include a service unit without a startup script. The problem is that the policy rules are confusing since they must include it but at the same time it is optional.
Proposal B: Systemd but we support the exploration of alternatives
This says that in summary (and that is the trigger) systemd is mandatory causing dependencies that are not necessary, that is to say, it allows other inits to coexist and support but what forces (without saying it) that software like elogind should include systemd dependency. In addition, this proposal is ambiguous and prone to change in the future.
Proposal C: focus on systemd for the system and everything
This is the most destructive proposal, it says that systemd will be mandatory and unique init and any other does not care, providing support for multiple startup systems or for alternatives to other interfaces provided by systemd is not a project priority at this time and that dependencies to systemd even if necessary are mandatory.
Proposal D: supports non-system systems, without blocking progress
THIS IS THE ONE THAT REALLY SOLVES THE PROBLEM, THE DETONANT IS THAT THE DEVELOPERS WHO ARE IN FAVOR OF SYSTEMD FORCED AND OBSTRUCTED THE PROGRESS OF OTHER SOLUTIONS, ESPECIALLY IN THE DESK OF THE ICAZA THAT AT SUCH DEGREE HAD TO BE DE-INSTALLED AND RETURNED.
Mention with particular emphasis that packages should be fully functional with all init systems. This means (for example) that daemons must send traditional startup scripts or use other mechanisms to ensure they start without systemd. It also means that the desktop software must be installable and ideally fully functional, without systemd.
Proposal E: initiation diversity is required but exclusive
Being able to run Debian systems with init systems other than systemd is still of great value to the project. All packages MUST work with pid1 dont care of Systemd, and if a upstream program are systemd only will be discarted and not included in Debian.
But it has something that is not entirely democratic: You should not consider software that only works with systemd simply because upstream does not provide, and / or will not accept, a startup script. This seems tyrannical and is not very democratic, although it makes sense because it provides extra work.
We all already know systemd are the most used init system, so then why the developer still try to sabotage the work of others in Debian?
The beginning of all this General Resolution begins with the mail of August 2019, First discution after systemd are standard but intrusive, under the sub-topic called “Init System Diversity” where Sam Hartman, leader of the DEBIAN Project, worried about the struggles between the Inits, noting the little space left by the “Systemd” packers and how they hindered the work of others, especially through forced dependencies.
Users who want to do what free software freedoms mention to derive and copy to improve software, are being curtailed by extra workload, systemd developers directly wish to kill the work of others by disturbing their inclusion in distributions. large linux.
Do not fool yourself .. groups and those small distros are super inactive about this by arguing "it does not affect us" but they are wrong .. if a project like elogind is not used enough, then its maintainer will not be right to continue in a struggle (development) without purpose. An example of this is the Hiawatta web server software where the developer paused the active development obviously given its web server is let's say not very used .. if it is not widely used so obviously he it was wasting its time.
As in the Soilet Green novel, the future will reach them if they just stay watching it….
Summarizing there are 3 resolutions that eliminate freedoms of diversity, leaving only the "systemd", hence the one that most people hate systemd, all this is called "a healthy approach to PID1" in technical jargon.
Its consequences: death / obstruction to the work of other distros through extra workload because there will only be systemd: Devuan and MXLinux among others.
We talked about the Debian General Resolution 2019-002 submitted to its internal Voting System (only for Debian mantainers) existing around the «Startup Systems». This topic can be reinforced, by reading one of the many previous articles in the Ians personal article describin the right situation on this subject.
Consequences and importance:
Its result can radically change the landscape of the most important distros derives from Debian, that is, the subject of this article is to raise awareness about a possible stain on the freedom of choice of advanced users and developers at the Startup Systems level (Init ), which is discussed in the future General Resolution to be taken.
We have the following problems about this situation that suggest the clear disadvantage of those interested:
- This is a proposal where the community has no place!
- Only the most internal members of Debian can vote!
- This content is not in any other language!!!, due it is an internal vote
- It is the second time that the systemd causes problems in other developers or works
- This could cause a new exodus (like the one that gave rise to Devuan)
In short, the content of the article to be read, there are 3 resolutions that eliminate the freedoms that guarantee diversity, leaving only the "Systemd", hence the one that most people hate "Systemd". All this is called "a healthy approach to PID1" in technical jargon. Its consequences: Death of other Distros derived through extra workload because there will only be "Systemd". For example, Devuan and MX-Linux could disappear.
 |
| We can see the notice at distrowatch but not right detailed.. so will be not understandable at all... |
Summary of the options: from Debian choices
Of the voting options (which we already said that although they are internally, we can make social pressure) we have 3 that destroy freedom and only two that protect them, the A, B, and C are the destructive ones and the E something flexible, only the D It is what allows real freedom. This is a resume and summary of https://www.debian.org/vote/2019/vote_002 as indicated in the previous section. Complete history are in the "linux post install" article at https://blog.desdelinux.net/resolucion-general-del-proyecto-debian-diversidad-del-sistema-init/ (spanish only)
Proposal A: startup diversity is important and IMMUable
Mention being able to run Debian systems with init systems other than systemd is still something that the project values. With the exception that all packages that owe it, must include scripts for the inits of the moment in use. It reinforces that the current policy says that packages should not include a service unit without a startup script. The problem is that the policy rules are confusing since they must include it but at the same time it is optional.
Proposal B: Systemd but we support the exploration of alternatives
This says that in summary (and that is the trigger) systemd is mandatory causing dependencies that are not necessary, that is to say, it allows other inits to coexist and support but what forces (without saying it) that software like elogind should include systemd dependency. In addition, this proposal is ambiguous and prone to change in the future.
Proposal C: focus on systemd for the system and everything
This is the most destructive proposal, it says that systemd will be mandatory and unique init and any other does not care, providing support for multiple startup systems or for alternatives to other interfaces provided by systemd is not a project priority at this time and that dependencies to systemd even if necessary are mandatory.
Proposal D: supports non-system systems, without blocking progress
THIS IS THE ONE THAT REALLY SOLVES THE PROBLEM, THE DETONANT IS THAT THE DEVELOPERS WHO ARE IN FAVOR OF SYSTEMD FORCED AND OBSTRUCTED THE PROGRESS OF OTHER SOLUTIONS, ESPECIALLY IN THE DESK OF THE ICAZA THAT AT SUCH DEGREE HAD TO BE DE-INSTALLED AND RETURNED.
Mention with particular emphasis that packages should be fully functional with all init systems. This means (for example) that daemons must send traditional startup scripts or use other mechanisms to ensure they start without systemd. It also means that the desktop software must be installable and ideally fully functional, without systemd.
Proposal E: initiation diversity is required but exclusive
Being able to run Debian systems with init systems other than systemd is still of great value to the project. All packages MUST work with pid1 dont care of Systemd, and if a upstream program are systemd only will be discarted and not included in Debian.
But it has something that is not entirely democratic: You should not consider software that only works with systemd simply because upstream does not provide, and / or will not accept, a startup script. This seems tyrannical and is not very democratic, although it makes sense because it provides extra work.
Overview of the situation: the trigger
We all already know systemd are the most used init system, so then why the developer still try to sabotage the work of others in Debian?
The beginning of all this General Resolution begins with the mail of August 2019, First discution after systemd are standard but intrusive, under the sub-topic called “Init System Diversity” where Sam Hartman, leader of the DEBIAN Project, worried about the struggles between the Inits, noting the little space left by the “Systemd” packers and how they hindered the work of others, especially through forced dependencies.
Users who want to do what free software freedoms mention to derive and copy to improve software, are being curtailed by extra workload, systemd developers directly wish to kill the work of others by disturbing their inclusion in distributions. large linux.
 |
| Ian's entry at Debian planet trying to describe the situation that trigger that debian voting.. can be detailed at https://diziet.dreamwidth.org/3482.html |
RESUME AND CONCLUSIONS we want to do... you can do someting.. just do it!
Do not fool yourself .. groups and those small distros are super inactive about this by arguing "it does not affect us" but they are wrong .. if a project like elogind is not used enough, then its maintainer will not be right to continue in a struggle (development) without purpose. An example of this is the Hiawatta web server software where the developer paused the active development obviously given its web server is let's say not very used .. if it is not widely used so obviously he it was wasting its time.
As in the Soilet Green novel, the future will reach them if they just stay watching it….
- ircs://irc.freenode.net/#devuan its main problem was think that are enough.. sorry guys.. future it right now here!
- https://t.me/alpine_linux Telegram alpine linux english group, openrc init based linux
- https://t.me/devuan_es Devuan en español telegram
- https://t.me/DevuanMX Devuan Mexico pero ahora mas internacional
- https://t.me/DebianLatinoamerica Debian latinoamerica
- https://mastodon.social/@proyectotictac Proyecto tic tac en Mastodon
- https://t.me/grupo_telegram_proyectotictac Grupo tic tac en telegram
- https://groups.google.com/forum/m/#!forum/venenuxsarisari Grupo Venenux Devel
Comentarios
Publicar un comentario
no stupid winbuntu users allowed!