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.
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.
+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.
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.
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.
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.
+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.
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.
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…