Announcement

Collapse
No announcement yet.

Ubuntu Maker Canonical Pulls In Control Of LXD

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

  • #21
    Originally posted by edwaleni View Post
    the only "lxc" anything
    lxc != lxd.

    Comment


    • #22
      Originally posted by macemoneta View Post
      lxc for containers in vms?
      lxc != lxd.

      Comment


      • #23
        Remember there's systemd-nspawn/machinectl too

        Comment


        • #24
          Tbh the only part I'm worried about in the announcement is this:

          Image building for Linux Containers will no longer be relying on systems provided by Canonical, limiting image building to x86_64 and aarch64.
          It is one thing to want to consolidate your projects under your brand for marketing, but pulling infrastructure support for a community project that you also rely on is bad..

          Comment


          • #25
            Originally posted by tuxd3v View Post
            The truth is that canonical has not being treated with the respect they deserve...
            Ah yes, Canonical as the saviour of us poor users. For me that idea soured considerably after Mark Shuttleworth's authoritarian speeches about "having root", "you don't get to second guess us" and the blatant lie that they put the buttons on the left to open up the space on the right for innovation. The truth of that one was they were planning to use the Netbook remix interface as the Unity desktop environment later on, which is left aligned. Mark probably saw himself as a Jobsian messenger and wanted to do a big TADA moment, which nobody cared about.

            After the above I could have pledged for that Ubuntu phone, but didn't, because I didn't see them as my future forward. Convergence looked cool back then, but seeing how phones just don't have the oomph of bigger machines, I am happy that fell by the wayside.

            Mir the display server, that self-serving NIH project where Canonical thought to pull a Trolltech and give itself a leg up with a discriminatory CLA, giving Canonical the option for proprietary releases and the rest of us just the GPLv2. Also the lying about the "shortcomings" of Wayland... Swiftly debunked though. I am happy that Wayland prevailed. Less eggs in Canonical's basket is better in my book.

            I accept that you want a Canonical future. Go with Canonical. I will stay far away from them. I don't trust them. I don't like them. I will not support them.​

            Comment


            • #26
              We have been using many Canonical Technologies such as maas, lxd, and juju (charms and infrastrucutre) in our data centers with around 3000 nodes. So these are some of my observations considering that canonical is now trying to scale very fast the past couple of months:

              1. Canonical releases their source and they really listen to community, but they are very bad at creating a community where there are others. They do not contribute to outside open source projects, and they have a mentality of re-inventing their own wheel.
              2. Canonical doesn't play well with others. For orchestration, either use everything juju or go home, and you cannot mix it with kubernetes operators and terraform and ansible. This is their way to lock you in.
              3. Their paid support is very bad. I stopped all our payments to them and will make sure we will never have any contracts with them unless absolutely necessary.
              4. Due to their way of work, there are not many people around knowing canonical technologies, which makes hiring process hard for medium size data centers like ours.

              I might have been harsh, but I would love canonical to play better with outside communities. They do have potential and projects like MaaS and LXD are very interesting and unique. I would still use them but I will be more and more careful I use them because I know the team behind them and not because of canonical itself.

              Comment


              • #27
                Originally posted by mmrezaie View Post
                We have been using many Canonical Technologies such as maas, lxd, and juju (charms and infrastrucutre) in our data centers with around 3000 nodes. So these are some of my observations considering that canonical is now trying to scale very fast the past couple of months:

                1. Canonical releases their source and they really listen to community, but they are very bad at creating a community where there are others. They do not contribute to outside open source projects, and they have a mentality of re-inventing their own wheel.
                2. Canonical doesn't play well with others. For orchestration, either use everything juju or go home, and you cannot mix it with kubernetes operators and terraform and ansible. This is their way to lock you in.
                3. Their paid support is very bad. I stopped all our payments to them and will make sure we will never have any contracts with them unless absolutely necessary.
                4. Due to their way of work, there are not many people around knowing canonical technologies, which makes hiring process hard for medium size data centers like ours.

                I might have been harsh, but I would love canonical to play better with outside communities. They do have potential and projects like MaaS and LXD are very interesting and unique. I would still use them but I will be more and more careful I use them because I know the team behind them and not because of canonical itself.
                In summary they and their products are a total liability. As we are using Terraform, they'd be out of the game anyway.

                Comment


                • #28
                  Originally posted by lproven View Post

                  lxc != lxd.
                  What a confusing mess. What's lxc and what's lxd? I've been using lxd for a couple of years but now I don't know if I actually have been doing that. You install lxd on your system, but you then control it with a command called 'lxc', which describes itself as "Command line client for LXD".
                  Is there another lxc other than the lxc that comes with lxd?

                  Comment


                  • #29
                    Originally posted by taggon View Post
                    All this moral panic about Canonical "taking over" and "screwing up" LXD ignores the fact that Canonical was already by far the largest contributor to LXD. If their direction was going to screw up LXD, why didn't it do so in all the years since Canonical made LXD?
                    Yeah, honestly feels like a nothingburger. They created it, they are the largest contributors to it, having it under their org probably just streamlines stuff for them. (Also, having it under their org probably help the financial valuation of Canonical Ltd.)

                    There are plenty of projects under Canonical that a large portion of Linux users use on a day-to-day basis without realizing it's a Canonical project (e.g. LightDM), and believe it or not, their computer hasn't imploded

                    Comment


                    • #30
                      Originally posted by mmrezaie View Post
                      We have been using many Canonical Technologies such as maas, lxd, and juju (charms and infrastrucutre) in our data centers with around 3000 nodes. So these are some of my observations considering that canonical is now trying to scale very fast the past couple of months:

                      1. Canonical releases their source and they really listen to community, but they are very bad at creating a community where there are others. They do not contribute to outside open source projects, and they have a mentality of re-inventing their own wheel.
                      2. Canonical doesn't play well with others. For orchestration, either use everything juju or go home, and you cannot mix it with kubernetes operators and terraform and ansible. This is their way to lock you in.
                      3. Their paid support is very bad. I stopped all our payments to them and will make sure we will never have any contracts with them unless absolutely necessary.
                      4. Due to their way of work, there are not many people around knowing canonical technologies, which makes hiring process hard for medium size data centers like ours.

                      I might have been harsh, but I would love canonical to play better with outside communities. They do have potential and projects like MaaS and LXD are very interesting and unique. I would still use them but I will be more and more careful I use them because I know the team behind them and not because of canonical itself.
                      Bummer to hear given Red Hat's recent "violate the GPL as much as we possibly can with it still being just ambiguous enough to hopefully not land us in court" attitude. I wonder how SUSE's offerings are?

                      Comment

                      Working...
                      X