[OpenWrt-Devel] uClibc-ng

[Florian Fainelli]

2014-07-21 11:42 GMT-07:00 Thomas Petazzoni
<thomas.petazzoni at free-electrons.com>:
> Dear Florian Fainelli,
>
> On Mon, 21 Jul 2014 11:23:46 -0700, Florian Fainelli wrote:
>
>> 2014-07-20 12:13 GMT-07:00 Waldemar Brodkorb <wbx at uclibc-ng.org>:
>> > Hello Embedded Linux Hackers,
>> >
>> > it seems there is no plan to release a new uClibc version.
>> > The current maintainer does not response on any public or private mails
>> > about a plan to do a needed release. Therefore most of you carrying a lot
>> > of patches against uClibc 0.9.33.2 to make it work in your project.
>> > A really ugly situation.
>>
>> Although I do welcome your action, and stepping in to offer a solution
>> to this, I feel like forking might have the potential of making this
>> situation worse, including, but not limited to:
>>
>> - creating confusion between uclibc and uclibc-ng
>> - pissing off Bernhard
>> - duplicating existing infrastructure instead of gaining access to it
>> - what if you end up in the same situation as uClibc, we all have busy lives?
>>
>> Thomas and I talked to Khem Raj about this uClibc situation during ELC
>> back in June, and Khem offered some help to see if we could:
>>
>> - make Bernhard aware of the lack of release situation
>> - use his uclibc.org access to facilitate a 0.9.34? release
>
> ELC was end of April, early May, and Khem told me he would act with one
> month. I've pinged him several times, and nothing happened. He might
> have been too afraid to piss off Bernhard.
>
> On my side, I fully support Waldemar's fork. The last uClibc release is
> more than 2 years old, and Bernhard has never been answering to *any*
> of the e-mails asking to do a release, sent since September 2013 or so.
> At this point, I think there is absolutely no hope to see any action
> being done by the existing uClibc community in terms of doing stable
> releases, and this case, the lever that open-source licenses provide is
> simple: fork. That's what Waldemar has done, and it's good.

To speak my mind, I think uClibc has no future in the next 2 or 3
years, musl is a much more active project, with multiple embedded
projects starting to use it, on the other end, (e)glibc has remedied
its own problems and its useful again.

No MMU architectures are becoming less and less popular, and the cost
for larger flash storage mediums keeps decreasing, so all these key
selling features (noMMU support and reduced memory footprint) that
uClibc has will soon no longer be any useful to it.

Bottom line is, I believe uClibc is a (relatively speaking) dead
project already, forking it might be useful to keep the existing user
base alive, but I expect all of them to transition to something active
and maintained, whether that's glibc or musl.
--
Florian
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel