Conversation

Notices

1. Embed this notice
   :umu: :umu: (a1ba@suya.place)'s status on Monday, 11-Nov-2024 19:58:15 JST :umu: :umu:
   to think about it, is there any actual reason use all these custom allocators like jemalloc or mimalloc?
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Monday, 11-Nov-2024 19:58:14 JST 翠星石

     in reply to
     @a1ba No, you should just use glibc malloc.
     
     jemalloc apparently is faster than glibc for memory-wasting multithreaded software (RAM is just as wasted if you fill it up to OOM than not using it), but glibc seems to be faster and use less memory if you aren't using all the memory and allow for other software.
     
     jemalloc seems to be used to compensate for poor programming and also since it has a weak license (as the power to take freedom must be granted).
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Monday, 11-Nov-2024 20:18:01 JST 翠星石

     in reply to
     @a1ba >in which case the licensing doesn't play any role (as GPL explicitly refers to it as "System Libraries").
     glibc is licensed under the LGPLv2.1-or-later and if you compile software against it, you need to meet the requirements of allowing the user to modify the library and debug their modifications (even via reverse engineering).
     
     The "system libraries" exception in the GPLv3 is a limited exception, allowing for a GPLv3+ program to be linked to an existing proprietary libc on a proprietary OS for example, without permitting the writing of proprietary derivative works.
     
     
     glibc malloc is not the fastest or most memory-efficient malloc, but it is the fastest malloc that is portable and also memory-efficient - it's all a tradeoff and glibc malloc makes the best tradeoffs.
   • Embed this notice
     :umu: :umu: (a1ba@suya.place)'s status on Monday, 11-Nov-2024 20:18:02 JST :umu: :umu:

     in reply to

     • 翠星石
     @Suiseiseki I personally do use whatever default malloc on target platform is, in which case the licensing doesn't play any role (as GPL explicitly refers to it as "System Libraries").
     
     However, I'm more interested in hearing the reasons why somebody decides not to rely on it and use thirdparty implementation. Having same algorithm, yeah, that could work. Even if GC but again, can't see how existing software written in C should even rely on that.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Monday, 11-Nov-2024 20:39:43 JST 翠星石

     in reply to
     @a1ba >because it's considered as a system library and goes into an exception.
     The LGPLv2.1 does not have a the "system library" exception, it has a different one;
     `For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
     
     It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute.`
     
     Such exception does not give unlimited permission to link to glibc - it merely allows compiling and linking glibc on a proprietary system.
     
     https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html
     
     >It's good that glibc is GPL licensed
     There is no such thing as "GPL licensed", there is the GPLv{1,2,3}, LGPLv{2,2.1,3} & AGPLv{1,2,3}, all of which differ in detail.
     
     >I wish GPL actually covered non-obfuscation case better because GNU people seem doesn't know how to write a readable code.
     The GPLv3 makes it clear that obfuscated code is object code and not source code; `The "source code" for a work means the preferred form of the work for making modifications to it. "Object code" means any non-source form of a work.`
     
     >GNU people seem doesn't know how to write a readable code.
     When I read GNU software, all I see is pure freedom, which is plenty readable.
   • Embed this notice
     :umu: :umu: (a1ba@suya.place)'s status on Monday, 11-Nov-2024 20:39:44 JST :umu: :umu:

     in reply to

     • 翠星石
     @Suiseiseki that's what I mean, I don't care about libc licensing because it's considered a system library and goes into an exception.
     
     It's good that glibc is GPL licensed and I looked into it's source code several times, however I wish GPL actually covered non-obfuscation case better because GNU people seem doesn't know how to write a readable code.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Monday, 11-Nov-2024 20:50:16 JST 翠星石

     in reply to
     @a1ba I love GNU/Macros.
   • Embed this notice
     :umu: :umu: (a1ba@suya.place)'s status on Monday, 11-Nov-2024 20:50:18 JST :umu: :umu:

     in reply to

     • 翠星石
     @Suiseiseki yeah, freedom of turning your codebase into a macros riddled spaghetti code.
   • Embed this notice
     :umu: :umu: (a1ba@suya.place)'s status on Monday, 11-Nov-2024 20:58:25 JST :umu: :umu:

     in reply to

     • nekonomicon
     @nekonomicon not a big deal if it's the default, but replacing it is different.
     
     Also, if Microsoft's mimalloc is so good why it's not the default in Microsoft's libc implementation? :troll:
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     nekonomicon (nekonomicon@suya.place)'s status on Monday, 11-Nov-2024 20:58:27 JST nekonomicon

     in reply to
     @a1ba the latest FreeBSD and Android versions already use jemalloc %)
     Mimalloc uses 2MB pages and can be faster in some cases, but eats many memory.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Monday, 11-Nov-2024 21:01:55 JST 翠星石

     in reply to
     @a1ba If I was to write a libc, I would license it AGPLv3-or-later.
   • Embed this notice
     :umu: :umu: (a1ba@suya.place)'s status on Monday, 11-Nov-2024 21:01:56 JST :umu: :umu:

     in reply to

     • 翠星石
     @Suiseiseki I liked working with musl code more
     
     If only it was LGPL too :)