201–210 of 375 posts
1) Why don't distros replace the glibc allocator with one of the better ones?
2) Why don't distros allow for making server-specific builds for only a few packages? You don't have to pay the compilation cost for everything, just a list of 2 or 3 packages.
Earlier quoted context omitted.
Agree for most short running apps. I updated my comment to reflect issues with apps that are constantly reallocating, and running for longer that 60 seconds. But you are absolutely correct for most short running apps, 99% recommended to replace glibc. However, there is an app or two where glibc stability doesnt trigger a pathological use cases, and you have no choice. Hence why its the default, since there are less c…
Looked at your updated post and it looks like you’re operating under wildly incorrect assumptions. 1. Fragmentation: MIMalloc and the newest TCMalloc definitely handle this better than glibc. This is well established in many many many benchmarks. 2. In terms of process lifetime, MIMalloc (Microsoft Cloud) and TCMalloc (Google Cloud) are designed to be run for massive long-lived services that continually allocate/deal…
Reading this, I wonder a few things that seem distro quick wins: 1) Why don't distros replace the glibc allocator with one of the better ones? 2) Why don't distros allow for making server-specific builds for only a few packages? You don't have to pay the compilation cost for everything, just a list of 2 or 3 packages.
Some of the other things disabled might be useful for distros in general, like ndebug assertions or compiling with debig symbols.
Should probably work for Debian and RedHat too. For this particular package.
Edit: based just on the title i initially thought this is an article about turning Ubuntu into Linux From Scratch.
> What happens if you grab the jq source code from Launchpad, then configure and rebuild it with no flags at all? Even that is about 2-4% faster than the Ubuntu binary package. Why wouldn't that be identical?
Because instead of using the Debian build, I just used `./configure; make`
It's a while since I had to deal with this kind of thing, but my memory was that as soon as you go beyond the flags that the upstream developers use (just to be clear, I mean the upstream developers, not the distro packagers) you're buying yourself weird bugs and a whole lot of indifference if they occur. I haven't used a non-libc malloc before but I suspect the same applies.
I've been building my own emacs for a long time, and have yet to hit any weird bugs. I thought that as long as you avoid any unsafe optimizations, you should be fine? Granted, I also thought that -march=native was the main boost that I was seeing. This post indicates that is not necessarily the case. I also suspect that any application using floats is more likely to have rough edges?
The article doesn't seem to even consider that option and I don't see any comment here mentioning this either. Am I missing something?
Earlier quoted context omitted.
If it wasn't for performance, what was gained in using it over something like Slackware and building only the packages you needed to?
USE flags. You can build packages with specific features enabled or disabled, which can further reduce your dependency tree.
Earlier quoted context omitted.
Portage on top of Fuchsia, probably. There's not all that much more to Gentoo all things considered.
Zircon is miles apart from linux. It’s like saying you’d run Portage on top of Windows. You and what army?
https://en.m.wikipedia.org/wiki/Microsoft_POSIX_subsystem
The Zircon kernel does not support signals, so basic C is not going to work well.
"It is heavily inspired by Unix kernels, but differs greatly. For example, it does not support Unix-like signals, but incorporates event-driven programming and the observer pattern."
https://en.m.wikipedia.org/wiki/Fuchsia_(operating_system)#K...