Announcement

Collapse
No announcement yet.

Devuan 2.0 As Debian Without Systemd Hits Release Candidate Stage

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by makam View Post
    Because then the Debian devs are imposing upon my freedoms. By avoiding systemd I am not imposing upon anyones freedom.
    This is bullshit, none imposes you to use Debian so whatever they choose will not impose you anything.

    But the real culprit is that the systemd devs chose an architecture that extends its tentacles to other pieces of software.
    How dare they to be making modular stuff to deal with various things and letting other projects choose freely to use them at their own convenience.

    Thus writers of other init systems often need to emulatefake systemd behaviour and other hacks to make software written with systemd in mind work on other init systems.
    Complain with the application developers that chose to use the daemons and frameworks provided, as it was THEIR choice, not upstream systemd project's.

    tl;dr should have been just a simple init script. And nothing else.
    This is the developer's choice, and they have chosen freely to use what they think is best for their own project.

    Very strangely, scripts have lost the battle, especially because there is no way in hell that you can even do half of what the systemd ecosystem offers (not just the init but also the other system daemons like logind) with scripts.

    Comment


    • #22
      Originally posted by nanonyme View Post
      Then again, what Devuan did is also fundamentally about using your freedom of choice the right way: you fork and sink your time in the project no matter whether it makes sense or not
      They added a large amount of chest-thumping and flaming to that though.

      Now that they are having fun with actually packaging stuff and fixing shit like all maintainers do they have calmed down.

      Others like Alpine or Void linux (or Gentoo for that matter) didn't do the same stunts and are still fine.

      Comment


      • #23
        Originally posted by kaprikawn View Post
        Flatpak doesn't impact the ability of package maintainers to maintain packages the way they've always done. How does the existence of Flatpak stop someone on Arch writing a PKGBUILD file for example? Flatpak doesn't suddenly mean that the source is no longer available and can't be compiled by the user or a package maintainer.
        All of this is right, as long as the sources or configure scripts aren't altered in a way that clearly checks for the dependency of the unterlaying flatpak core system. I can't say that this will happen. But this might happen!

        e.g. like a configure script that checks for a particular version of glibc, libpng etc. If everything is marching towards Flatpaks then the upstream developers might want to make it a mandatory requirements and may alter their configure scripts (of the sources) to explicit check for the existence of the underlaying Flatpak architecture to compile and link against.

        So if you take the sources and try to compile it on debian or arch or gentoo or whatever, then you may be getting an error from these configure scripts telling you that some XYZ mandatory requirements (like an underlaying Flatpak runtime) is missing. Locking the program down to only support that runtime.

        Not that this may be an issue, because you can patch all the sources and configure scripts. But this may end in becoming a maintainance nightmare.

        Again! This may not happen. But this might happen. So better think about it now than too late. Otherwise we will end up in having to support an Linux system inside a Linux system (e.g. Debian as Disto and Flatpak Core as Linux runntime ontop of Debian) with millions of links and sub depencencies.

        No one wants that.

        Comment


        • #24
          Originally posted by Candy View Post
          All of this is right, as long as the sources or configure scripts aren't altered in a way that clearly checks for the dependency of the unterlaying flatpak core system. I can't say that this will happen. But this might happen!
          Lol what?

          You have any fucking idea about how software development works and about what is the distro maintainer job?

          Each opensource application (any application really) already checks and specifies for whatever random compiler, library and tool and version the creator used/tested/developed it with.

          What the distro maintainers do to package applications for their distro is to test it out with the tools, compilers and libs they want to ship with their distro version and make sure all works fine (by fixing or working around any issue that may arise).

          Even if they started to check for flatpack stuff the job would remain the same.

          Comment


          • #25
            Originally posted by starshipeleven View Post
            Lol what?
            Keep a bookmark on this!

            We speak again in 2-3 years or earlier, once the entire discussion and shit-storm starts.

            Comment


            • #26
              Originally posted by Candy View Post
              Keep a bookmark on this!

              We speak again in 2-3 years or earlier, once the entire discussion and shit-storm starts.
              You let me down son. No other reason than "Candy strongly believes it" left?
              R U a quittah?

              Comment


              • #27
                Let me play devil's advocate.

                If I were Candy, I'd posit that developers providing Flatpaks of their own package provides a disincentive for package maintainers to maintain packages leaving Flatpak the only option. If I were the package maintainer for Gimp on Arch for example, I could say "There's a Flatpak of Gimp so there's no need for me to continue packaging Gimp, everyone can just use the Flatpak". And if that happens enough, package maintenance could die out over time and Flatpaks could become the norm.

                Comment


                • #28
                  Originally posted by Candy View Post
                  This may not happen. But this might happen.
                  Why would that happen?

                  That would make the application unportable to anything non-Linux, e.g. BSD, Solaris, macOS, Windows, Android or iOS.

                  Unless this is a very Linux specific application it doesn't make sense for the application developers to limit themselves that way.

                  Cheers,
                  _

                  Comment


                  • #29
                    Originally posted by anda_skoa View Post
                    That would make the application unportable to anything non-Linux, e.g. BSD, Solaris, macOS, Windows, Android or iOS.
                    That was already the case after systemd got adopted to most Linux distributions. Gnome started to depend on systemd (at least parts of it) and became unportable to e.g. BSD, Solaris etc. (speaking of that time back). I also recall some developers around systemd that said something like this: "We can't care for other non-Linux like operating systems e.g. BSD or Solaris" or something like this (google for it).

                    But one thing should be kept in mind:

                    Who brought us Gnome ?
                    Who brought us PulseAudio ?
                    Who brought us systemd ?
                    Who brought us Flatpaks ?

                    The same people! The same approach! The same big bang over night enforcement!

                    Why should this look different this time ?

                    But again: This is just my opinion. And don't ignore the part where I wrote "It may happen! It might not!". So chances are 50:50.

                    Comment


                    • #30
                      Originally posted by Candy View Post
                      That was already the case after systemd got adopted to most Linux distributions.
                      Excuse me?

                      Applications magically became non-portable due to systemd providing the system startup?

                      Can you list some examples?

                      Originally posted by Candy View Post
                      Gnome started to depend on systemd (at least parts of it)
                      As you say yourself: only some parts from a vendor with a huge portfolio.

                      Other vendors like KDE, Mozilla, LibreOffice and so on have non-linux specific applications as well.

                      No application depends on systemd "just because".

                      Originally posted by Candy View Post
                      So chances are 50:50.
                      I doubt that many of the main software vendors, e.g. Mozilla, XFCE, KDE, GNOME, LibreOffice, would suddenly go "Linux only" for their whole product space, let alone single-product vendors like Inkscape, Scribus, GIMP, VLC, etc

                      So an overall chance of 50:50 seems very unlikely

                      Cheers,
                      _

                      Comment

                      Working...
                      X