▲ 151 ▼ Canonical lifts lid on more Ubuntu Core Desktop details (www.theregister.com) submitted 2 years ago by Patch@feddit.uk to c/linux@lemmy.ml 52 comments fedilink hide all child comments
[–] woelkchen@lemmy.world 1 point 2 years ago (1 child) I know that it's possible to change the one entry but adding additional ones is not possible and that's by design. permalink fedilink source parent hideshow 2 child comments replies: [–] wmassingham@lemmy.world 1 point 2 years ago (1 child) Is that an artificial limitation that could be resolved by third-party clients? permalink fedilink source parent hideshow 2 child comments replies: [–] Patch@feddit.uk [S] 1 point 2 years ago (2 children) It's all open source so there's no reason you couldn't fork it and add that functionality. Although it'd probably be a fairly involved piece of work; it wouldn't be a simple one-line change. permalink fedilink source parent hideshow 4 child comments replies: [–] ExLisper@linux.community 1 point 2 years ago Who knows? Maybe it's just "#define STORES_LIMIT 1"? permalink fedilink source parent [–] woelkchen@lemmy.world 0 points 2 years ago (1 child) It's not all open source. Canonical merely made available a super simple reference implementation of the Snap server but the actual Snap Store is proprietary. permalink fedilink source parent hideshow 2 child comments replies: [–] Patch@feddit.uk [S] 1 point 2 years ago* I was referring to snapd, which is the thing that actually has the hard limit on a single repository. That's fully open source (and there's one major fork of it out in the wild, in the form of Ubuntu Touch's click). The tooling for creating snap packages is also all open source. The APIs which snapd uses to interact with its repo are also open source. While there's no turnkey Snap Store code for cloning the existing website, it's pretty trivial to slap those APIs on a bog standard file server if you just want to host a repo. Not open-sourcing the website code is a dick move, but there's nothing about the current set up that would act as an obstacle for anyone wanting to fork snap if that's what they wanted to do. It's just with flatpak existing, there's not a lot of point in doing so right now. permalink fedilink source parent
[–] wmassingham@lemmy.world 1 point 2 years ago (1 child) Is that an artificial limitation that could be resolved by third-party clients? permalink fedilink source parent hideshow 2 child comments replies: [–] Patch@feddit.uk [S] 1 point 2 years ago (2 children) It's all open source so there's no reason you couldn't fork it and add that functionality. Although it'd probably be a fairly involved piece of work; it wouldn't be a simple one-line change. permalink fedilink source parent hideshow 4 child comments replies: [–] ExLisper@linux.community 1 point 2 years ago Who knows? Maybe it's just "#define STORES_LIMIT 1"? permalink fedilink source parent [–] woelkchen@lemmy.world 0 points 2 years ago (1 child) It's not all open source. Canonical merely made available a super simple reference implementation of the Snap server but the actual Snap Store is proprietary. permalink fedilink source parent hideshow 2 child comments replies: [–] Patch@feddit.uk [S] 1 point 2 years ago* I was referring to snapd, which is the thing that actually has the hard limit on a single repository. That's fully open source (and there's one major fork of it out in the wild, in the form of Ubuntu Touch's click). The tooling for creating snap packages is also all open source. The APIs which snapd uses to interact with its repo are also open source. While there's no turnkey Snap Store code for cloning the existing website, it's pretty trivial to slap those APIs on a bog standard file server if you just want to host a repo. Not open-sourcing the website code is a dick move, but there's nothing about the current set up that would act as an obstacle for anyone wanting to fork snap if that's what they wanted to do. It's just with flatpak existing, there's not a lot of point in doing so right now. permalink fedilink source parent
[–] Patch@feddit.uk [S] 1 point 2 years ago (2 children) It's all open source so there's no reason you couldn't fork it and add that functionality. Although it'd probably be a fairly involved piece of work; it wouldn't be a simple one-line change. permalink fedilink source parent hideshow 4 child comments replies: [–] ExLisper@linux.community 1 point 2 years ago Who knows? Maybe it's just "#define STORES_LIMIT 1"? permalink fedilink source parent [–] woelkchen@lemmy.world 0 points 2 years ago (1 child) It's not all open source. Canonical merely made available a super simple reference implementation of the Snap server but the actual Snap Store is proprietary. permalink fedilink source parent hideshow 2 child comments replies: [–] Patch@feddit.uk [S] 1 point 2 years ago* I was referring to snapd, which is the thing that actually has the hard limit on a single repository. That's fully open source (and there's one major fork of it out in the wild, in the form of Ubuntu Touch's click). The tooling for creating snap packages is also all open source. The APIs which snapd uses to interact with its repo are also open source. While there's no turnkey Snap Store code for cloning the existing website, it's pretty trivial to slap those APIs on a bog standard file server if you just want to host a repo. Not open-sourcing the website code is a dick move, but there's nothing about the current set up that would act as an obstacle for anyone wanting to fork snap if that's what they wanted to do. It's just with flatpak existing, there's not a lot of point in doing so right now. permalink fedilink source parent
[–] ExLisper@linux.community 1 point 2 years ago Who knows? Maybe it's just "#define STORES_LIMIT 1"? permalink fedilink source parent
[–] woelkchen@lemmy.world 0 points 2 years ago (1 child) It's not all open source. Canonical merely made available a super simple reference implementation of the Snap server but the actual Snap Store is proprietary. permalink fedilink source parent hideshow 2 child comments replies: [–] Patch@feddit.uk [S] 1 point 2 years ago* I was referring to snapd, which is the thing that actually has the hard limit on a single repository. That's fully open source (and there's one major fork of it out in the wild, in the form of Ubuntu Touch's click). The tooling for creating snap packages is also all open source. The APIs which snapd uses to interact with its repo are also open source. While there's no turnkey Snap Store code for cloning the existing website, it's pretty trivial to slap those APIs on a bog standard file server if you just want to host a repo. Not open-sourcing the website code is a dick move, but there's nothing about the current set up that would act as an obstacle for anyone wanting to fork snap if that's what they wanted to do. It's just with flatpak existing, there's not a lot of point in doing so right now. permalink fedilink source parent
[–] Patch@feddit.uk [S] 1 point 2 years ago* I was referring to snapd, which is the thing that actually has the hard limit on a single repository. That's fully open source (and there's one major fork of it out in the wild, in the form of Ubuntu Touch's click). The tooling for creating snap packages is also all open source. The APIs which snapd uses to interact with its repo are also open source. While there's no turnkey Snap Store code for cloning the existing website, it's pretty trivial to slap those APIs on a bog standard file server if you just want to host a repo. Not open-sourcing the website code is a dick move, but there's nothing about the current set up that would act as an obstacle for anyone wanting to fork snap if that's what they wanted to do. It's just with flatpak existing, there's not a lot of point in doing so right now. permalink fedilink source parent