-
Notifications
You must be signed in to change notification settings - Fork 104
chore: updates to glibc vs musl #2902
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: tdunlap607 <[email protected]>
✅ Deploy Preview for ornate-narwhal-088216 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
matthewhelmke
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for handling this update, @tdunlap607, based on the feedback from @catherinejones, who deserves a special shout out!
The deletions make sense and the changes are clear. So, LGTM and approved!
|
|
||
| The *portability* of an application refers to its ability to run on various hardware or software environments without requiring significant modifications. Developers can encounter portability issues when moving an application from one libc implementation to another. That said, [Hyrum's Law](https://www.hyrumslaw.com/) reminds us that achieving perfect portability is tough. Even when you design an application to be portable, it might still unintentionally depend on certain quirks of the environment or libc implementation. | ||
|
|
||
| One common portability issue is the [smaller thread stack size](https://ariadne.space/2021/06/24/understanding-thread-stack-sizes-and.html) used by musl. musl has a default thread stack size of 128k. glibc has varying stack sizes which are determined based on the resource limit, but usually ends up being 2-10 MB. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could I suggest keeping the ariadne.space links and moving them to a references section? I believe they’re effective at explaining why applications built for glibc have issues with musl
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that idea
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM to me too! @tdunlap607: Could you please add in those links to a references section with a quick note that these links explain why applications built from glibc have issues with musl?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call :) added. Let me know if that works
Signed-off-by: tdunlap607 <[email protected]>
matthewhelmke
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the new section and retaining the discussed link in it. Thanks!
jspeed-meyers
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thank you, @tdunlap607, for the PR and @catherinejones for the feedback and expertise.
After discussions with @catherinejones on the
glibc-vs-musl.mddocumentation, I removed several portions of the doc and focused more on speed/compatibility.The changes removed the buffer overflow, DNS issues (outdated), experimental warnings, and unsupported debug features. Old outdated references were pruned throughout the documentation as well.
Thank you @catherinejones for your thoughtful feedback. Please review at your convenience. Thank you!
cc @cartyc