Video Upload Options

References

1. "Roland McGrath bows out as glibc maintainer [LWN.net"]. 2017-07-07. https://lwn.net/Articles/727383/. 
2. "GNU's Bulletin, vol. 1 no. 4, February, 1988". https://www.gnu.org/bulletins/bull4.html. "Most libraries are done. Roland McGrath […] has a nearly complete set of ANSI C library functions. We hope they will be ready some time this spring." 
3. "GNU's Bulletin, vol. 1 no. 12". https://www.gnu.org/bulletins/bull12.html. "It now contains all of the ANSI C-1989 and POSIX.1-1990 functions, and work is in progress on POSIX.2 and Unix functions (BSD and System V)" 
4. Corbet, Jonathan (28 March 2012). "A turning point for GNU libc". LWN.net. https://lwn.net/Articles/488847/. "Of the nearly 19,000 commits found in the project's git repository (which contains changes back to 1995), over 12,000 were made by Ulrich." 
5. "History of glibc and Linux libc". http://freesoftwaremagazine.com/articles/history_of_glibc_and_linux_libc/. 
6. "Forking: it could even happen to you". 12 September 2008. https://www.linux.com/archive/feature/3874. "the split between GNU LIBC and the Linux LIBC -- it went on for years while Linux stabilized, and then the forks re-merged into one project" 
7. Lee, Elliot (2001). "A Technical Comparison of glibc 2.x With Legacy System Libraries". https://people.redhat.com/~sopwith/old/glibc-vs-libc5.html. 
8. "Fear of Forking essay, see "6. glibc --> Linux libc --> glibc"". http://linuxmafia.com/faq/Licensing_and_Law/forking.html. 
9. "glibc homepage". https://www.gnu.org/software/libc/. "In 2001 The GNU C Library Steering Committee …, was formed and currently consists of Mark Brown, Paul Eggert, Andreas Jaeger, Jakub Jelinek, Roland McGrath and Andreas Schwab." 
10. "Ulrich Drepper". LinkedIn. https://www.linkedin.com/in/ulrichdrepper. 
11. Drepper, Ulrich (2000-06-26). "RMS is at it again". sourceware.org. https://sourceware.org/ml/libc-hacker/2000-06/msg00180.html. "A few weeks ago RMS started the next attack on me (a single mail, followed by indirect tries to take influence, followed by another mail today). The essence is that he complains I am not following "GNU policies" and therefore have to be replaced by a steering committee of which I could be a part. Some of you (namely Roland and Andreas S.) probably know about this since he proposed both as other members of the committee. In addition there was Mark Brown listed (I know somebody of this name at IBM who would also fit in this group but I'm not sure whether it is really him.) Anyhow, I completely reject this. It is not helping at all, the opposite is true. First, I am not aware of any essential policies I'm violating. The only ones are that I'm not following orders from RMS which clearly have political intends (which is of course a sacrilege) and possibly that I do not care about Winblowz (if the latter counts at all). None of this will change in any way." 
12. Drepper, Ulrich (2001-08-15). "glibc 2.2.4". sourceware.com. https://sourceware.org/ml/libc-announce/2001/msg00000.html. "And now for some not so nice things. Stallman recently tried what I would call a hostile takeover of the glibc development. He tried to conspire behind my back and persuade the other main developers to take control so that in the end he is in control and can dictate whatever pleases him. This attempt failed but he kept on pressuring people everywhere and it got really ugly. In the end I agreed to the creation of a so-called "steering committee" (SC)." 
13. rms-accused-of-attempting-glibc-hostile-takeover on slashdot.com on August 19, 2001 https://slashdot.org/story/01/08/19/2039211/rms-accused-of-attempting-glibc-hostile-takeover
14. McGrath, Roland (26 March 2012). "glibc steering committee dissolving". Sourceware.org. https://sourceware.org/ml/libc-alpha/2012-03/msg01038.html. 
15. Myers, Joseph S. (26 March 2012). "GNU C Library development and maintainers". Sourceware.org. https://sourceware.org/ml/libc-alpha/2012-03/msg01040.html. 
16. Ulrich Drepper 2007-10-03 06:13:55 UTC "This has nothing to do with "x86 only". All ABIs designed by people who have a bit of understanding require no change. Any change will negatively impact well designed architectures for the sole benefit of this embedded crap. But your own version of the file in the add-on." https://sourceware.org/bugzilla/show_bug.cgi?id=5070#c5
17. Drepper, Ulrich (2005-05-25). "Dictatorship of the Minorities". udrepper.livejournal.com. https://udrepper.livejournal.com/7326.html. "Which architectures are worthwhile supporting? […]. Not only do we have to look for irrelevance (what percentage cares about Vax, PArisc) support, we also have to look at the level of added complexity the support requires. Some ABIs are just deliberately defined to be different from others (see IA-64) which requires huge amounts of effort to be spent. There are also significantly diverging capabilities (e. g., the lack of atomic operations in too many architectures). This far too often causes to unnecessarily crippled code since writing code in a way which allows optimal use in all situations is very difficult. The solution must be to restrict support to only a handful of architectures which are supported in the project. All other support must happen outside the tree and therefore all the work has to be done by the special interest groups. I don't want to say we follow all these points perfectly, but for a big project glibc certainly comes closest to this." 
18. Jarno, Aurélien (2009-05-05). "Debian is switching to EGLIBC". aurel32.net. https://blog.aurel32.net/?p=47. "More friendly upstream (especially with regard to embedded architectures): “Encourage cooperation, communication, civility, and respect among developers” (as opposed to this)." 
19. timothy (2009-05-06). "Debian Switching From Glibc To Eglibc". Slashdot. https://linux.slashdot.org/story/09/05/06/2050216/debian-switching-from-glibc-to-eglibc. 
20. Debian package changelog https://metadata.ftp-master.debian.org/changelogs/main/g/glibc/stable_changelog
21. "CosmicCuttlefish/ReleaseNotes - Ubuntu Wiki". https://wiki.ubuntu.com/CosmicCuttlefish/ReleaseNotes#Toolchain_Upgrades_.2B2D3e4P4P-. 
22. "Chapter 5. RHEL 8.0.0 release Red Hat Enterprise Linux 8". https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.0_release_notes/rhel-8_0_0_release#platform-tools. 
23. "Chapter 2. What's new in Debian 10". https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#newdistro. 
24. "Changes/GLIBC228". https://fedoraproject.org/wiki/Changes/GLIBC228. 
25. "Red Hat Bugzilla – Bug 1598403". https://bugzilla.redhat.com/show_bug.cgi?id=1598403. 
26. "sourceware.org Git - glibc.git/blob - NEWS". https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=de44ab67aa4eec369deea828733567c35a0611c0. 
27. "DiscoDingo/ReleaseNotes - Ubuntu Wiki". https://wiki.ubuntu.com/DiscoDingo/ReleaseNotes#Toolchain_Upgrades_.2B2D3e4P4P-. 
28. "Changes/GLIBC229". https://fedoraproject.org/wiki/Changes/GLIBC229. 
29. "Red Hat Bugzilla – Bug 1653403". https://bugzilla.redhat.com/show_bug.cgi?id=1653403. 
30. "sourceware.org Git - glibc.git/blob - NEWS". https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD. 
31. "EoanErmine/ReleaseNotes - Ubuntu Wiki". https://wiki.ubuntu.com/EoanErmine/ReleaseNotes#Toolchain_Upgrades_.2B2D3e4P4P-. 
32. "Changes/GLIBC230". https://fedoraproject.org/wiki/Changes/GLIBC230. 
33. "Focal (20.04) : glibc package : Ubuntu". https://launchpad.net/ubuntu/focal/+source/glibc. 
34. "Changes/GLIBC231". https://fedoraproject.org/wiki/Changes/GLIBC231. 
35. "The GNU C Library version 2.32 is now available". https://sourceware.org/pipermail/libc-announce/2020/000029.html. 
36. "The GNU C Library machine maintainers.". https://sourceware.org/glibc/wiki/MAINTAINERS#Machine_maintainers. 
37. Bartley, David; Spang, Michael. "GNU/kOpenSolaris (GNU libc/base + OpenSolaris kernel)". https://csclub.uwaterloo.ca/~dtbartle/opensolaris/. 
38. "Haiku Source". https://github.com/haiku/haiku/tree/master/src/system/libroot. "libroot.so is not part of GNU project and is included in Haiku source code." 
39. Torvalds, Linus (9 January 2002). "Posting to the glibc mailing list". http://ecos.sourceware.org/ml/libc-alpha/2002-01/msg00079.html. 
40. "OpenMoko components". http://wiki.openmoko.org/wiki/OpenMoko. "We will use glibc (not uClibC) … The alternatives may save more space and be more optimized, but are more likely to give us integration headaches" 
41. "Re: [Familiar] Which glibc for Familiar 0.8.4  ?". https://marc.info/?l=familiar&m=118666899424374&w=2. "Question: which version of the GLIBC was used to build the Familiar 0.8.4 ? Answer: 2.3.3"