dalias

8 ms·

1.
by dalias 6y ago
5kloc is about 10x larger than musl's existing (old) malloc in source lines. I suspect lots of that is low code density, comments, etc. I have to lookup what exactly mimalloc is/does every time someone mentions it, because the rea
2.
by dalias 6y ago
We'd be happy to address specific problems on the mailing list. I believe it's a known issue that the Rust compiler is making really heavy use of rapid allocation/freeing cycles, and would benefit from linking a performance-o
3.
by dalias 6y ago
The justifications are partly the same as what Daniel Micay has written extensively on in the rational for hardened_malloc ( https://github.com/GrapheneOS/hardened_malloc ) - unsynchronized per-thread state inherently sa
4.
by dalias 10y ago
There is no excuse for shell escaping bugs like this. 100% safe and reliable shell escaping is trivial: s/'/'\''/g s/^/'/ s/$/'/
5.
by dalias 11y ago
Nice to see firm getting noticed. It's a really promising project.
6.
by dalias 11y ago
To clarify, the numbers in my tweets are measured on Linux, comparing musl libc's posix_spawn (with CLONE_VM) to plain fork+exec (which should be independent of libc). I just posted the test program on our mailing list: http:/&#x
7.
by dalias 11y ago
The biggest problem with Cygwin is that programs linked with Cygwin inherit global state from from a Cygwin installation on the system they're running on. If you want to produce a Windows program that just runs on any system you instal
8.
by dalias 11y ago
These are some good observations. Note that on modern POSIX, calling anything but async-signal-safe functions after forking in a multi-threaded process results in undefined behavior. I think it's totally reasonable to consider any prog
9.
by dalias 11y ago
No, fork is only one path that can lead to overcommit. Allocation of new memory as COW references to a zero page, and COW writable MAP_PRIVATE mappings of files (such as the writable LOAD segments of any executable or library file) also lea
10.
by dalias 11y ago
No, OOM killer is completely orthogonal to this and is a consequence of not doing correct commit accounting. With strict commit accounting turned on (vm.overcommit_memory=2) fork will correctly fail when there is not sufficient physical bac
11.
by dalias 11y ago
Yes, this is the really big deal that everyone focused on fork and mmap semantics and other details is overlooking. Having midipix as the means of producing Windows versions of cross-platform software like Firefox should make it possible to
12.
by dalias 11y ago
Interix is a lot different because it requires installing a system component, which requires administrator privileges. Midipix produces applications that (at least as I understand it) run on basically any NT-based Windows with no special pr
13.
by dalias 11y ago
I have a sequence of tweets here summarizing basic measurements I did on musl's posix_spawn versus fork+exec: https://twitter.com/RichFelker/status/602313644026761216 There are still plenty of applications th
14.
by dalias 12y ago
The choice isn't between 30sec or 15sec boot times. It's between 30sec, 15sec, or 1sec boot times, the latter coming from dropping all of the crap and writing a flat linear /etc/rc file.
15.
by dalias 12y ago
If your boot time was bad before and decent now, this is not thanks to the goodness of systemd but rather the badness of whatever hideous system your distro was using before, and/or because your distro is starting a bunch of useless ju
16.
by dalias 12y ago
Both forking and double-forking are completely wrong behavior for supervised daemons run as part of any automated system. Forking makes sense for small systems which lack any automated supervision and where a human admin is responsible for
17.
by dalias 12y ago
There are plenty of viable alternatives: s6, runit, OpenRC, and so on. I'm not really convinced uselessd is a viable alternative - it keeps way too much of the badness of systemd, but I guess that makes it viable if you were willing to
18.
by dalias 12y ago
People actually _want_ the logging behavior of systemd? My impression is that it's the most widely hated part; I've heard endless stories of journald thrashing the filesystem forever, losing logs completely on corruption, etc. And
19.
by dalias 12y ago
Systems which do not use systemd simply do not have these problems because there is no analogous component. If syslogd goes down, the worst that happens is you don't get logs. Init doesn't go down because it essentially has no inp
20.
by dalias 12y ago
Whether it's all in pid 1 or not is irrelevant. What matters is that it has a monolithic architecture, whereby breakage in any one part or their communication channels can bring down the whole system. This is not just a theoretical con
21.
by dalias 12y ago
Is there any proper information on this issue? The patches do not apply cleanly against the latest stable kernel (3.14.5) and there's no indication I can find as to what version they're intended to be applied to.
22.
by dalias 13y ago
At the time the project was started, Ulrich Drepper was the maintainer of glibc and the official response to any bug report was "STFU". So, no. Aside from that, while a more permissive license was not part of my original goal or v
23.
by dalias 13y ago
LD_PRELOAD alone wouldn't do it because glibc's dynamic linker is closely tied to glibc. In particular thread-local storage requires close cooperation between them. Likewise, musl needs its own dynamic linker. What could be done i
24.
by dalias 13y ago
Fairly easily. A relatively small number of syscalls are used as part of implementing other functions. Most if not all of these are made via macros that expand to inline syscalls; by replacing them with a call into your own function that im
25.
by dalias 13y ago
musl actually has very little in the way of optimization, premature or otherwise. Most functions are written to be as simple and direct as possible. Often but not always this gives near-optimal size and speed too. The places where more comp
26.
by dalias 13y ago
The original idea goes back to around 2005 and frustration at the ever-growing size of glibc and poor (slow) support for UTF-8. At the time I made a prototype and used it personally. In 2010 I relaunched the project with a goal of doing it
27.
by dalias 13y ago
Some of these things are covered on the comparison page I did at http://www.etalabs.net/compare_libcs.html In regards to fts.h, the version in glibc is not even usable because it only works in 32-bit off_t mode, and stat()
28.
by dalias 13y ago
Hi all. I'm the original author and maintainer of musl, and I'm happy to answer any questions anyone might have about the project. Glad to see so much interest!
29.
by dalias 13y ago
Yet, there are quite a few. See the wiki: http://wiki.musl-libc.org/wiki/Projects_using_musl A few big names are in the process of adding musl-based variants or switching entirely to musl, but most of these are still e
30.
by dalias 13y ago
It started out that way, but these days we have several other developers who are pretty active. You can see from our stats on ohloh: https://www.ohloh.net/p/musl/contributors?query=&sort=commit... Also, withou

More ›