Announcement

Collapse
No announcement yet.

Canonical Releases LXD 5.17 With OpenZFS 2.2 Delegation Support

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

  • timofonic
    replied
    On the other hand, nobody talked LXD was forked some weeks ago as Incus https://linuxcontainers.org/incus/ https://github.com/lxc/incus​ Some reasons in the following link: https://stgraber.org/2023/07/10/time-to-move-on/

    Leave a comment:


  • chocolate
    replied
    Originally posted by paulocoghi View Post

    Since distrobox is based on docker, I would recommend LXD instead because its based on LXC and the container environment it provides is, by design, a complete OS environment. It's natural choice.

    Docker, on the other hand, provides containers made to run a single service on each of them and, IMHO, it seems like a workaround/kludge to make them running multiple services inside again.
    Thanks, much appreciated. I see what you mean. I'll need to give LXD a spin myself.
    Just for future reference, readers might be interested in these Distrobox documentation paragraphs:which, together, can give the same advantages of having a complete environment, although falling under the part of your comment I highlighted in bold.

    Leave a comment:


  • jaypatelani
    replied
    Why work on OpenZFS while there's aleady FreeBSD. Why waste more resources on OpenZFS? 😛

    Leave a comment:


  • skierpage
    replied
    Originally posted by justinkb View Post
    reined*
    Correct, King Chuck 3 reiGns. But the original remains unidiomatic
    [LXD]has been reigned into control by Canonical and maintainership being limited to Canonical engineers.
    You take the reins of a horse to rein it in, so "into control" is redundant. Better "[LXD] has been reined in by Canonical, which limited maintainership to Canonical engineers."

    Leave a comment:


  • paulocoghi
    replied
    Originally posted by chocolate View Post
    Canonical considerations aside, does anybody have experience using LXD for the same usecases Distrobox currently gets recommended everywhere (e.g. clean, ad hoc programming environments)? Would you recommend LXD? Why?
    Since distrobox is based on docker, I would recommend LXD instead because its based on LXC and the container environment it provides is, by design, a complete OS environment. It's natural choice.

    Docker, on the other hand, provides containers made to run a single service on each of them and, IMHO, it seems like a workaround/kludge to make them running multiple services inside again.

    Leave a comment:


  • Jakobson
    replied
    Originally posted by CommunityMember View Post
    Or the Linux kernel could change it's license. That is unlikely, but, as they say, it takes two to tango, and if either chooses not to partner up, there is no dance. There is no blame/wrong here, it is just different, and valid, points of view. To claim that Oracle is the only one able to fix this is simply wrong.
    Sure. However, obtaining explicit permission from all past kernel developers is essential. This includes individuals who have passed away and any inheritances they might have. In practice, this is an entirely unfeasible task.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by CommunityMember View Post

    Or the Linux kernel could change it's license. That is unlikely, but, as they say, it takes two to tango, and if either chooses not to partner up, there is no dance. There is no blame/wrong here, it is just different, and valid, points of view. To claim that Oracle is the only one able to fix this is simply wrong.
    FWIW, I immediately said afterwards that both GNU and the Linux Foundation could also change the situation from their ends but that either of them doing it would be even less likely than Oracle.

    Leave a comment:


  • chocolate
    replied
    Canonical considerations aside, does anybody have experience using LXD for the same usecases Distrobox currently gets recommended everywhere (e.g. clean, ad hoc programming environments)? Would you recommend LXD? Why?

    Leave a comment:


  • fallingcats
    replied
    Originally posted by CommunityMember View Post

    Or the Linux kernel could change it's license. That is unlikely, but, as they say, it takes two to tango, and if either chooses not to partner up, there is no dance. There is no blame/wrong here, it is just different, and valid, points of view. To claim that Oracle is the only one able to fix this is simply wrong.
    My understanding is that Oracle could change the license single-handedly, but since the linux kernel does not have a CLA it would take every single contributer over the last 30 years to agree to re-license their code.

    Leave a comment:


  • kylew77
    replied
    Originally posted by muncrief View Post
    I'm in the middle of converting my 4 home server disks, containing almost 12 TB of data, from ext4 to zfs. The sole reason is because I'm tired of getting hit by bit rot. I'm only using single disk zfs as I have both local and cloud backups, but now I'll finally be able to tell when a file is corrupted. Of course I also formatted my 2 local backup disks with zfs to protect them as well.

    My only concern is that Linus has this nonsensical prejudice against OpenZFS and simply will not allow it to be included in the kernel, apparently because Oracle has its own zfs with a restrictive license. But it goes beyond even that, as Linus uses a combination of complaints about licensing, and the insane assertion that OpenZFS is unsupported and could disappear any day. When the truth is that OpenZFS uses the CDDL license which allows distributing it as a binary module or source code, and OpenZFS is supported incredibly well and used in many enterprise and data center environments.

    For example, my home server runs Manjaro which distributes OpenZFS binary modules in its official repositories and keeps kernels and zfs in sync. However Arch, which I use for my main desktop workstation, distributes it as source code, with a dkms option that usually assures kernel version compatibility. But compatibility with various Arch kernels cannot be assured, so the lts kernel must always be installed as a backup option. However I always keep the lts kernel installed on any distro I use anyway, so it's not a problem.

    But things would be so much easier if Linus would simply stop with his irrational rejection of OpenZFS so it could be included in the kernel and become effortlessly compatible across all Linux distros just like ext4, btrfs, etc.
    Just run FreeBSD, or Illumos distros like OpenIndiana or Triblix, or heck even NetBSD has support for ZFS. Why run ZFS on something where it is not a first class citizen?

    Leave a comment:

Working...
X