Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Debian Operating Systems Linux

Devuan Progress Report Published 184

Posted by Soulskill from the still-kicking-and-still-forking dept.
zdzichu writes: The group of anonymous Italians behind the recent Debian fork have published their first progress report. It covers a wide range of topics: the 4.5k€ of donations received so far, moving distro infrastructure from GitHub to GitLab, progress on LoginKit (which replaces systemd's logind), fraud accusations, logo discussions, and few more important points.
This discussion has been archived. No new comments can be posted.

Devuan Progress Report Published More

Devuan Progress Report Published

Comments Filter:

  • Nice progress! (Score:3, Insightful)

    by Anonymous Coward on Tuesday December 23, 2014 @03:00AM (#48658287)

    Totally beyond my previously (already good) expectations :)
    They will have a future much more promising than those who are afraid of choice would say.

  • Seems a bit rich as most of the vitriolic trolling was/still is the "anti-systemd" and "anti-LP" variety - what are they scared of now? I can't see anyone who is okay with systemd going to troll them, the only trolls they'll get will be the idiots who troll anything and everything because thats all they have to live for.

    Its good to see there are some people out there that are willing to put their money where their mouth is. I wish them luck with their endeavors.

    • I wish they would had put their efforts into Debian's kFreeBSD. It can't move to systemd and they downgraded it from an 'official' Jessie release.

      Personally it's a bit of the best of FreeBSD and the best of Debian (apt-get) in a nice package. There's no problem with ZFS being 'in' the kernel. The latest versions of FreeNAS and FreeBSD both have ZFS booting.

      Plus it still has all the debian server admin tools.

    • No one is scared of anyone, I am just sick of hearing bitching and complaining from the anti-poettering, and anti-systemd crowd about trolls. They are the trolls, and have gone as far as to issue poettering death threats. Once we fought back, like a typical reactionary bully, they cried of being oppressed. Fuck them

      Its good to see a few of them are actually putting their money where their mouth is. The beauty of open source is that it gives the loudmouth enough rope to hang himself. He doesn't get to bitc

  • SOAP vs Rest (Score:2, Interesting)

    by Tailhook ( 98486 )

    This reminds me of the early days of "web services." The "enterprise" folks were jetting around writing gobs of XML and SOAP specifications, making speeches at conferences and whatnot. Meanwhile, some thoughtful people pointed out that the combination of existing HTTP verbs and the natural namespace provided by URLs satisfied the same use cases without the mountains of esoteric specifications and staggering protocol overhead. One memory I have from that time has persisted; some SOAP standards body muckit

    • Re: (Score:1, Funny)

      by igloo-x ( 642751 )
      Your little SOAP vs. REST story is only memorable because it almost never happens. Debian has a tendency to eat it's children and I've yet to read a single compelling technical reason on Slashdot why systemd is a bad idea. Most anti-systemd people heard about it then decided they hate it because of its feng-shui or whatever, then retroactively invent bullshit technical reasons for it which are either ignorance or lies.

    • Re: (Score:2)

      by DrXym ( 126579 )
      I don't see many parallels. Working with systemd isn't exactly rocket science for admins or end users. Instead of typing one command to start or stop a service you type another. Systems even provide aliases or links to support the old notation, e.g. shutdown in FC21 is a link to systemctl which infers what to do from argv[0].

      Tenuous comparison aside, probably the main reason SOAP dropped out of sight was it wasn't suitable for the eventual problem domain. SOAP was fine for computer to computer (B2B) commu

  • Mid term devuan has just one chance: Make it easy for developers to provide solutions that work with multiple int systems. Systemd does bring quite a few improvements for developers. That is the reason why systemd becomes entrenched: Developers like it and start to depend on it since it makes their live easier.

    If devuan wants to keep a manageable distribution they need to make it similarly easy to tackle issues in a convenient and reliable way when using multiple init systems. If they manage that, then I am

    • Re: (Score:1)

      by Anonymous Coward

      That is the reason why systemd becomes entrenched: Developers like it and start to depend on it since it makes their live easier.

      Which is very debatable, if not just laughable. [reddit.com]

      • Re: (Score:2)

        by Anonymous Coward

        That is the reason why systemd becomes entrenched: Developers like it and start to depend on it since it makes their live easier.

        Which is very debatable, if not just laughable. [reddit.com]

        Systemd is Microsoft Event Viewer and data store for GNU/Linux. We do not want binary logs. If an operating system requires more than a text editor to view log files, there is a problem with the operating system and/or the log files. As an GNU/Linux since 1992 when SLS was "the distribution of choice" the current trend with the Debian GNU/Linux Project baffles my mind. What happened to the vision Deborah and Ian conceived so many year ago?

        • "We do not want binary logs." - not this boring load of shit again. You can have text logs if you configure systemd to use rsyslog

      • That consultation mongering in that link is indeed laughable.

  • It covers a wide range of topics: the 4.5k€ of donations received so far, moving distro infrastructure from GitHub to GitLab, progress on LoginKit (which replaces systemd's logind), fraud accusations, logo discussions, and few more important points.

    Was someone trying to sneak that one through in the middle of a dull-news sandwich?

    • Re: (Score:2, Informative)

      by Peter H.S. ( 38077 )

      It covers a wide range of topics: the 4.5k€ of donations received so far, moving distro infrastructure from GitHub to GitLab, progress on LoginKit (which replaces systemd's logind), fraud accusations, logo discussions, and few more important points.

      Was someone trying to sneak that one through in the middle of a dull-news sandwich?

      The problem is that all money donated to Devuan doesn't go directly into Devuan, but into a rather dubious organization, with no public oversight and no accountability.
      Here is a link to the org and their pre-Devuan Linux distro:
      http://www.dynebolic.org/ [dynebolic.org]
      Take a look around, and notice how a "donate" button never is far way from any project or web page.

      The foundation has a chairman called Denis Roio, AKA "Jaromil", and according to themselves, the foundation "helps them pay taxes", in other words, they pay the

      • Re: (Score:2)

        by jaromil ( 104349 ) *
        Thanks Peter! you are so kind! Hey wait a minute! the scammers are also on slashdot!! quick quick, close your wallet!

        • Re: (Score:2, Interesting)

          by Peter H.S. ( 38077 )

          Thanks Peter! you are so kind!

          Hey wait a minute! the scammers are also on slashdot!!

          quick quick, close your wallet!

          Well, I am right ain't I. You funnel the donated Devuan money into dyne org, and as CEO/Chairman of that small org with self elected people, with no public oversight of the money, you also pull money out of dyne org into your own pocket to "pay for taxes". Dress it all up as a non-profit org too.

          Make Devuan a proper org that directly receive the donated money you are begging for all the time, and have a proper elected committee with public oversight over the donated money and what they are spend on, and the

          • If dyne is a foundation, I don't see why there must be another entity for Devuan, since the objectives are the same. It's like 300â down the drain yearly for mere bureaucracy. If a bunch of devuan devs got elected to "lead" the distro and dyne.org staff did not respect their decisions, dyne would be a hindrance, but I'd wait for this to happen and or provide some substance to your fraud accusation. AFAIK, a foundation would need accounting tricks or no funds appropriation can take place.

  • The larger question is: what Devuan is really forking?

    Do they fork a distro?

    Or do they fork an organization?

    With some work, one can fork a distro. But to fork the organization, one need to win over the people. I doubt that they will win over many (Debian) people without actually changing something in the forked organization.

    Though many see the "systemd vs world" as the dividing force, in reality there is IMO problem with Debian organization. I have followed the debate for some time, and IMO, the pro

    • Re: (Score:3)

      by ruir ( 2709173 )
      The problem with Debian is that for whatever reason they ignored the power of linux, choice. At least in Debian 8, it is still trivial to make it use sysvinitrc instead of system. Why not let people choose, instead of forcing it upon new upgrades, and worse insult yet, make current systems upgrade to systemd by default?

      • Re:Forked the Debian? or the Debian? (Score:5, Insightful)

        by kthreadd ( 1558445 ) on Tuesday December 23, 2014 @05:34AM (#48658677)

        Choice is not a matter of just pressing a button and have it magically appear. Someone has to actually maintain it. The Devuan developers think that they can do that. If so then that's great. It's sad that they don't think that they can do the same thing within Debian though I understand their reasoning. It takes a lot of time and effort to get into Debian and they want to be more pragmatic.

        • The proposition to have multiple init system in Debian was promptly rejected with arguments ranging from infeasible to "who is going to make all these packages compatible with sysv init" (although they were compatible a few month ago).
          I don't think doing it anyway in Debian was a good choice in that ambience.

          • "who is going to make all these packages compatible with sysv init"

            Exactly. Did someone step up within Debian to do it?

            • I do not know the answer for the Debian, but if you did RTFA, you would notice that it is precisely what the Devuan is doing: creating and packaging software which provide the interface of systemd services without the systemd itself.

              The (retorical) question which I have already asked on difference occasions here is whether the Debian is a good place to do such development.

              One strong undertone from the CTTE's init system selection debate was that Debian doesn't want to do the development and wants to max

              • I do not know the answer for the Debian, but if you did RTFA, you would notice that it is precisely what the Devuan is doing: creating and packaging software which provide the interface of systemd services without the systemd itself.

                Yes, that's what they are doing.

                The (retorical) question which I have already asked on difference occasions here is whether the Debian is a good place to do such development.

                One strong undertone from the CTTE's init system selection debate was that Debian doesn't want to do the development and wants to maximize the reuse of the code from the other distros. This turned into a weird attitude when systemd vs. upstart was evaluated. The upstart devs and maintainers have committed themselves to implement whatever Debian needs. The systemd devs and maintainers committed to literally to nothing, basically saying "if it is good for Fedora is should do the job for Debian too; no Debian specific patches are going to be accepted even into the Debian systemd package". And that was later respun by a couple of CTTE members as "upstart still needs development while systemd doesn't".

                That is also why I raise the question about changes to the Debian organization in Devuan: How could Devuan be more software developer friendlier? At the moment the barrier to entry is very high, leaving developers at mercy of the respective Debian packager. Or leaving the developer basically out if it has something to do with the low-level stuff like init system.

                You're talking about Debian and Devuan like it's two monolithic organizations. It's not. It's people. And and if you want "Debian" to do something then real human Debian developers will have to do the job. It doesn't matter what any committee decides if no one is interested in actually doing the work.

                The Devuan developers are obviously up for the task. That's great. They do what they want to do. It's just too bad that they for whatever reason couldn't do it in Debian. I don't

                • You're talking about Debian and Devuan like it's two monolithic organizations. It's not. It's people. And and if you want "Debian" to do something then real human Debian developers will have to do the job. It doesn't matter what any committee decides if no one is interested in actually doing the work.

                  Hu?

                  This very topic was laundered during the init system selection on the debian-ctte for very long time: it makes no sense to invest time into developing systemd if upstart is picked, and vice versa.

                  There might be people willing to do the work - but there is little more demotivational than a project declaring that they are taking a different path.

                  But the most demotivational is when people are told that they can't even have an alternative systemd implementation/fork - of which there are already couple

                  • Re: (Score:2)

                    by Damouze ( 766305 )

                    But the most demotivational is when people are told that they can't even have an alternative systemd implementation/fork - of which there are already couple - because GNOME demands the systemd, not just any systemd.

                    Anyone remember AARD [wikipedia.org]?

                  • GNOME demands the systemd, not just any systemd.

                    No. Gnome demands libpam-systemd or consolekit. libpam-systemd demands either systemd or systemd-shim.

                    So either work on consolekit/consolekit2 or work on systemd-shim.

                    • GNOME demands the systemd, not just any systemd.

                      No. Gnome demands libpam-systemd or consolekit. libpam-systemd demands either systemd or systemd-shim.

                      So either work on consolekit/consolekit2 or work on systemd-shim.

                      I was basically quoting Debian's GNOME maintainer, from the times of the Debian's CTTE debate.

                      At least at the time, Debian's GNOME package had a hardcoded dependency on the systemd package, not a feature/virtual package which provides the services. And GNOME DDs were refusing to change that, because they didn't like the systemd-shim.

                    • At least at the time, Debian's GNOME package had a hardcoded dependency on the systemd package, not a feature/virtual package which provides the services. And GNOME DDs were refusing to change that, because they didn't like the systemd-shim.

                      Whether that was the case then it isn't now.

                      gdm3 depends on libpam-systemd.

                      libpam-systemd depends on systemd-sysv | systemd-shim.

                      There is exactly one package in current Jessie or Sid that depends on systemd -- gummiboot.

                  • Technical aspects of init system replacement are very easy - compared to the establishment of an organizational structure of the Debian.

                    Ha ha ha ha ha. The best way to kill the project would be to set up the "organizational structure of Debian". Once you remove from Debian the ftp-masters political intrigues, the bureaucratic red-tape "freeze" phases, the militant feminist lobbying group, and the unnecessary and technically incompetent divergences from upstream (see "Debian openssl"), there's not much "organizational structure" to Debian left.

              • .... The systemd devs and maintainers committed to literally to nothing, basically saying "if it is good for Fedora is should do the job for Debian too; no Debian specific patches are going to be accepted even into the Debian systemd package".

                That is simply wrong. Please notice that several long time systemd developers with commit access to the systemd git tree, are in fact Debian Developers. So there is a lot of "Debianism's" in where files placed etc.

                Sure, the main branch of systemd wants to have as few distro specific patches as possible, but they do accept them if there is no other solution.

                Here is a Debian specific patch that predates Debians adoption of systemd as default init-system:
                http://cgit.freedesktop.org/sy... [freedesktop.org]

                • Sure, the main branch of systemd wants to have as few distro specific patches as possible, but they do accept them if there is no other solution.

                  I was just quoting the (ex-)maintainer of the systemd, from his e-mails from the CTTE discussion.

                  Debian feedback would be submitted to mainline - but if it is rejected, he wouldn't even carry a custom Debian patch for it, because he doesn't want to deviate from the mainline. And he, as the maintainer of the systemd, would not consider it a bug. As such somebody else would have to fix somewhere else.

                  If you are willing to grep through the 1K emails [debian.org] - you would definitely find that being repeated several t

                  • Re: (Score:3, Insightful)

                    by Peter H.S. ( 38077 )

                    I was just quoting the (ex-)maintainer of the systemd, from his e-mails from the CTTE discussion.

                    Without source or citation. I think your representation of what was said is rather biased.

                    Debian feedback would be submitted to mainline - but if it is rejected, he wouldn't even carry a custom Debian patch for it, because he doesn't want to deviate from the mainline. And he, as the maintainer of the systemd, would not consider it a bug. As such somebody else would have to fix somewhere else.

                    If it isn't a bug, why patch it? Sure, some people have tried to drop some turd patches into systemd, eg. ripping out security features in order to support some obscure glibc variant. The right thing of course is to patch the glibc variant to support the proper security functions, not patching systemd.

                    No package maintainer wants to support non-trivial, non-mainline patches without very good reasons. The whole point of

                    • If it isn't a bug, why patch it?

                      And this is a clear systemd bias (and GNOME attitude).

                      If systemd says it is not a bug, then it is not. And if something doesn't work - well, somebody opened a ticket about something NOT working - then something does NOT work. And if the systemd refused to fix it - who's going to?

                      The whole position of systemd implementors in Debian was and probably still is: we change how the whole system works, but we are totally not responsible if something breaks, because it is, duh, mainline systemd.

                      The whole probl

                    • If it isn't a bug, why patch it?

                      And this is a clear systemd bias (and GNOME attitude).

                      If systemd says it is not a bug, then it is not. And if something doesn't work - well, somebody opened a ticket about something NOT working - then something does NOT work. And if the systemd refused to fix it - who's going to?

                      Not every bug filed is an actual bug, even though the submitter feels it is. Saying no to bad patches and closing non-bugs with a "not-a-bug" is the daily grind of developers and package maintainers.

                      The "Heartbleed" bug is a prime example on how bad things can go when you accept patches that circumvent security measures in order to support obscure user cases.

                      Really, systemd developers accept a huge amount of patches from hundreds of different non-systemd developers each year, suggesting that they won't accept patches is simply contrary to reality. I have yet to see a reasonable patch being rejected on the systemd-mailing list.

                      The whole position of systemd implementors in Debian was and probably still is: we change how the whole system works, but we are totally not responsible if something breaks, because it is, duh, mainline systemd.

                      I really don't see the Debian systemd maintainers that way at all. They seem to be hard working and serious to me. I have yet to see a example of them accepting breakage because mainline systemd. As I said, there are Debian developers with commit access to the systemd git tree, so they obviously have a lot of influence on systemd as a upstream project.

                      Tollef Fog Heen was pretty clear that he is not going to do anything special for Debian. (He is (or was at the time) a Fedora user already anyway.)

                      I have seen no examples or evidence of this. Really, what specific non-trivial patches could Debian need that couldn't go into mainline systemd? Can't think of any, nor have I ever seen it on the mailing list.

                      Huh?

                      If you can't tell what the hell the trivial commit does, then you are obviously not a software developer.

                      It is trivial, but it is Debian distro specific and in upstream systemd. There are a lot more examples in the git tree, and also of Debian influence in the general design of systemd. You assertion that systemd developers doesn't care or won't accommodate the Debian distro is therefore unfounded.

                      That systemd actually accepts trivial distro specific patches, shows that they are accommodating their users. Since it is trivial, it could have been carried by the distro maintainer.

                      That was a great PR move on part of the systemd developers: to flood the mail lists with the buzz words. Users have no idea what they mean - but they sure sound cool - so systemd must be cool too.

                      Really, trying to pass off systemd as a "fad" that Debian accepted because of "buzzwords" on a mailing list is outright pathetic; systemd is real improvement over SysVinit in every aspect, and the Debian CTTE choose it because of its technical merit. That the Debian developers agree with this, was demonstrated at the latest Debian GR.

          • The proposition to have multiple init system in Debian was promptly rejected

            No it wasn't.

            What was rejected was the proposition that packages that didn't support all init systems should be removed from Debian, violating the Debian constitution:

            2.1.1 Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them.

            Deboian does have multiple init systems, and

      • Re: (Score:2, Interesting)

        by Peter H.S. ( 38077 )

        The problem with Debian is that for whatever reason they ignored the power of linux, choice. At least in Debian 8, it is still trivial to make it use sysvinitrc instead of system. Why not let people choose, instead of forcing it upon new upgrades, and worse insult yet, make current systems upgrade to systemd by default?

        Every choice has a cost and a consequences. In this case, supporting multiple init-systems dramatically increase the maintenance complexity. Every Debian Developer would need to run both a stable and unstable/testing version of both init systems, and some packages would have to be maintained in two different versions (talk about dependency hell).

        But that isn't even the most problematic part; that is the fact that all non-systemd development have more or less collapsed the last couple of years; "ConsoleKit"

        • I had the impression your post had an agenda, and then I read, at the end, you confirmed it:

          When FreeBSD changes to a modern init-system (they will probably clone systemd)

          • I had the impression your post had an agenda, and then I read, at the end, you confirmed it:

            When FreeBSD changes to a modern init-system (they will probably clone systemd)

            Sure, my agenda is to show that supporting multiple init systems is very difficult.

            That FreeBSD (and other BSD's) will change to a systemd-like init system is a given thing too. Even the founder of FreeBSD has publicly said it is in the future for FreeBSD.

            The fact is that the way people uses computers have changed dramatically the last decade; virtualization, OS containers, instantiated services, mobile devices etc. SysVinit and similar legacy style script based init systems simply aren't up to working with

  • Linux worked better - or rather it really worked - before systemd. Why to develop anything? Just keep the old proven and _working_ daemons.
  • then i will see how much i like Devuan
  • I see another good project starting, Modular Debian, that aims to integrate the pid 1 freedom in the main distribution, without forking https://www.freelists.org/arch... [freelists.org]

Slashdot Top Deals

"If I do not want others to quote me, I do not speak." -- Phil Wayne

Close