We do provide the data for vulnerabilities, at secdb.alpinelinux.org. The security tracker is a tool for the security team to remediate vulnerabilities. The data provided by it is not particularly useful nor intended…
We have contributed the majority of our improvements in such a way that other APK distributions, including Alpine, can make use of them, and the original plan was to just leverage Alpine for all of this. Indeed, we even…
For one, you refer to me as "a guy." I am, in fact, not a guy. Secondly, the issue you opened was against an internal project used by the security team to do continuous CVE triage of the distribution. It is not meant to…
that is why the article mentions it as an honorable mention :P
I was only evaluating hardware I actually own. I don’t own any of the PINE64 SBCs or laptops. And while I have a PinePhone, I rarely use it, it sits in my junk drawer basically.
Strictly from a hardware POV. That wasn’t intended to be praise for Apple, but rather an indictment of the industry at large that Apple designed hardware that is easier to extend trust to.
It would, but I don’t have an Unmatched board so I didn’t evaluate it. Same reason why I did not mention the Pine64 stuff: I don’t own any of it.
The only reason I took any position at all on this issue is because other partners in the Alpine / Cloud Native ecosystem requested that we clarify our position on mixing musl and glibc runtimes. You ignore the point I…
The issue is not the package. Obviously Sasha is allowed to publish whatever packages he wishes. The problem is that third parties take his package and then describe the combination of Alpine with his package in such a…
Yes, there's several of them. The problem isn't your package, but the distribution of "alpine" images that integrate the package. Those images should describe themselves more appropriately.
+1 for a glibc-based Alpine-ish distribution. a few Alpine folks have made them over the years, but they never gained traction.
I was not aware that publicly setting boundaries on what is a supportable configuration and what wasn't one was somehow equivalent to white nationalist syndicalism, but thanks for letting me know.
Not the same argument. Combining musl and glibc runtimes into a single system is known to result in instability. Whether it gets documented as part of a "don't do weird things" system or this update gets accepted, it…
I'm glad to know that free software maintainers exist to do whatever you want us to do, and that we don't get to set our own boundaries. Cool, cool.
The problem is the people who use Docker but don't know anything about it. Or don't know that mixing libcs is a problem. They use this glibc package, break their containers and then blame Alpine for the breakage.
The `dnsfunnel` resolver has been added to Alpine to solve that issue. Additionally, musl will gain TCP support for situations like DANE where individual records may be very large.
We did not communicate with Sasha because bluntly, we have no objection to the existence of this package itself, but rather third parties distributing the combination to others without disclosing the many caveats about…
alternatively you could just use a dedicated local resolver
I am proposing that we encode something that is already factually accurate: glibc and musl generally do not mix in any way that results in a stable system. Do you not think that distributions should make even a little…
correct: we do not want to get stuck with having to deal with angry people who have unstable environments caused by this. and, the conflict option is one of a few options being considered. part of what lead up to this…
the only thing the proposed change does is encode something that is already factual: if you install that glibc package, you have a high likelihood of breaking your system. it's not like we are blocking it in apk-tools,…
Alpine runs on all sorts of small platforms. It is possible to run it on OpenWRT type devices.
That is certainly a take. Storing small data, like function-local ints, pointers, etc, on the stack is beneficial due to L1$ prefetching semantics, but storing a 512KB scratchpad on the stack (which is what the article…
We do provide the data for vulnerabilities, at secdb.alpinelinux.org. The security tracker is a tool for the security team to remediate vulnerabilities. The data provided by it is not particularly useful nor intended…
We have contributed the majority of our improvements in such a way that other APK distributions, including Alpine, can make use of them, and the original plan was to just leverage Alpine for all of this. Indeed, we even…
For one, you refer to me as "a guy." I am, in fact, not a guy. Secondly, the issue you opened was against an internal project used by the security team to do continuous CVE triage of the distribution. It is not meant to…
that is why the article mentions it as an honorable mention :P
I was only evaluating hardware I actually own. I don’t own any of the PINE64 SBCs or laptops. And while I have a PinePhone, I rarely use it, it sits in my junk drawer basically.
Strictly from a hardware POV. That wasn’t intended to be praise for Apple, but rather an indictment of the industry at large that Apple designed hardware that is easier to extend trust to.
It would, but I don’t have an Unmatched board so I didn’t evaluate it. Same reason why I did not mention the Pine64 stuff: I don’t own any of it.
The only reason I took any position at all on this issue is because other partners in the Alpine / Cloud Native ecosystem requested that we clarify our position on mixing musl and glibc runtimes. You ignore the point I…
The issue is not the package. Obviously Sasha is allowed to publish whatever packages he wishes. The problem is that third parties take his package and then describe the combination of Alpine with his package in such a…
Yes, there's several of them. The problem isn't your package, but the distribution of "alpine" images that integrate the package. Those images should describe themselves more appropriately.
+1 for a glibc-based Alpine-ish distribution. a few Alpine folks have made them over the years, but they never gained traction.
I was not aware that publicly setting boundaries on what is a supportable configuration and what wasn't one was somehow equivalent to white nationalist syndicalism, but thanks for letting me know.
Not the same argument. Combining musl and glibc runtimes into a single system is known to result in instability. Whether it gets documented as part of a "don't do weird things" system or this update gets accepted, it…
I'm glad to know that free software maintainers exist to do whatever you want us to do, and that we don't get to set our own boundaries. Cool, cool.
The problem is the people who use Docker but don't know anything about it. Or don't know that mixing libcs is a problem. They use this glibc package, break their containers and then blame Alpine for the breakage.
The `dnsfunnel` resolver has been added to Alpine to solve that issue. Additionally, musl will gain TCP support for situations like DANE where individual records may be very large.
We did not communicate with Sasha because bluntly, we have no objection to the existence of this package itself, but rather third parties distributing the combination to others without disclosing the many caveats about…
alternatively you could just use a dedicated local resolver
I am proposing that we encode something that is already factually accurate: glibc and musl generally do not mix in any way that results in a stable system. Do you not think that distributions should make even a little…
correct: we do not want to get stuck with having to deal with angry people who have unstable environments caused by this. and, the conflict option is one of a few options being considered. part of what lead up to this…
the only thing the proposed change does is encode something that is already factual: if you install that glibc package, you have a high likelihood of breaking your system. it's not like we are blocking it in apk-tools,…
Alpine runs on all sorts of small platforms. It is possible to run it on OpenWRT type devices.
That is certainly a take. Storing small data, like function-local ints, pointers, etc, on the stack is beneficial due to L1$ prefetching semantics, but storing a 512KB scratchpad on the stack (which is what the article…