Serving Two Master Libraries

I don’t mind telling you that I’m a little nervous about this business of Debian switching to EGLIBC. I know, it’s supposed to be binary compatible and it shouldn’t matter to application developers. Does that include developers of closed source binaries? In developing the Flash Player, we’ve seen problems with C library compatibility before, and that was just in trying to support a single C library across multiple distributions. So now I’m worried about subtle API or binary incompatibilities that may arise between the 2 C libraries.

So far, this is a Debian move. But that may influence other distributions. From reading various sources and bug trackers, it looks like more distributions are evaluating the idea (or perhaps just fielding questions from users who are not up to speed on the issues but who have read the headlines).

There are already enough challenges in trying to produce a single binary that runs across as many Linux distributions as possible. But who knows? Maybe this will whole episode blow over like so many audio APIs.

75 Responses to Serving Two Master Libraries

  1. jldugger says:

    Unless you have evidence to the contrary, I’d just as well assume Ubuntu is following suit.

  2. I have the same kind of worries about the ABI compatibility (and you probably know that since I expect you to be reading my blog ;)). [ Indeed. That’s why I knew that users were already questioning Gentoo maintainers about a possible switch. -Mike M. ] I _hope_ it’s going to be just a way to keep a general patchset over glibc, that would be helpful especially if all the distributions decided to merge their patchsets together in a single one.I am worried that people will soon start feeling like “oh but I’ll just add this” or “just adding that”. Maybe I lost trust in software developers… [ It’s going to take strong leadership to make this effort work. -Mike M. ]

  3. Richard says:

    I suppose a source release is imminent then? Nah, didn’t think so πŸ™‚

  4. Shish says:

    eglibc is just a set of bug-fixing patches on top of standard glibc, not a fork or reimplementation; the only change you would notice is if flash supported embedded architectures, in which case the change would be “it’s not broken any more” πŸ™‚

  5. Dave Taylor says:

    I always did wonder why in the later stages it was only closed source vendors supporting OSS (Audio screwed again in Kubuntu 9.04, keeps dropping out (need reboot), but thats the mess that pulse audio is creating not yourselves). I believe this could be much worse as their is a real disparity in libraries being used between major distributions (not self created like using an unused library like OSS) I have faith in Debian, they wouldn’t touch it if there were real ABI issues as of all the distributions they are probably the most stable and least likely to throw caution to the wind.

  6. stupid question says:

    Hi!This might be a stupid question but have you considered using Qt:s Phonon ( for the audio problem? Don’t know at all if this is suitable to use in your project but I really like the idea of a library which brings multiple different services under a single API.

  7. MarkyJ says:

    Well, Debian also said they be keeping the “original” glibc for compatibility reason.I think we and you should wait happens and don’t panic so early.

  8. hannes says:

    to make this more understandable to a noob like me: flash player is dynamically linked against glibc, if binary incompabilities arise, the flash player would have to be compiled seperately for each libc and because you’re distributing a binary, that can’t be done by the user (or Linux distributor), but you’d have to provide two different binaries (or handle the problem inside that one binary by introducing ugly indirections). Am I right? [ Yeah, it goes something like that. -Mike M. ]

  9. Vadim says:

    They better not break Flash.

  10. Sbroker says:

    The bible is being developed more quickly than flash player for linux.Adobe is forgeting the linux users.

  11. BiTmAsTeR says:

    64-BIT NOW!!!1!!

  12. Esebrouquer says:

    Silverlight, Mono, goes better in Linux than flash plugin.Adobe should be ashamed of that piece of shit named flash plugin for linux.

  13. DrSuSE says:

    Mike!!! You’re still alive and employed! [ No one else will take me. -Mike M. ]

  14. Dima says:

    Why don’t you make Flash work with normal libc first, and worry about elibc later?Perhaps support browsers other than Firefox?Why does Flash still use Xt, if it’s a Gtk+ app?? It’s not like it supports old browsers, anyway.I haven’t gotten a single response here:

  15. urrite says:

    Or you could go and release the binary open source or collaborate with ongoing open source alternatives to flash, and you won’t have to deal with all this awful issues of libraries, distributions, browsers and compatibility.Yeah, I know, third party issues and so… but it’s not necessary to open all the plugin code. The community will be pleased to make your job!

  16. Johan says:

    Why or how did the episode about audio APIs blow over? Did someone cleanup the mess? [ No, most just faded into irrelevance. -Mike M. ]

  17. Anonymous says:

    Instead of creating a single binary for as many distributions as possible, why not create local distribution package. It is a lot easier to maintain.

  18. LIS says:

    I still don’t understand why you support Linux at all. [ You’re not alone. -Mike M. ]

  19. Michael says:

    I still don’t understand why you support Linux at all.[ You’re not alone. -Mike M. ]

    Sigh.What a lovely comment. If you don’t care for Linux then why don’t you just drop it?One of flash’s strong points to us is that is supported across Windows, Mac, and Linux. If Linux drops out, then I guess we can always move towards Moonlight/Silverlight.

  20. oyvind says:

    Ridiculous decision by Debian (“boo-hoo”, so the glibc-maintainer can be a bit blunt sometimes, deal with it instead). I just hope this won’t affect Ubuntu in a negative way.. Linux does *NOT* need more incompatibility across the board, god da**it.

  21. Harkai says:

    Maybe Adobe should create their own turbo C library for 32bit & 64bit.Than the Linux user can choose what he likes.GLIBCEGLIBCor Adobe C library for Linux that can be installed on Linux if the native C library sucks

  22. Jason says:

    Any chance of an update on what you have been working on for the last 6 months? Surely some progress must have been made on the flash plugin in the 6months since the last update…

  23. Zor says:

    The question is not “why you (read Adobe) support Linux at all”. It’s obvious to me, so much embedded systems use linux nowadays, you wouldn’t let Silverlight win on those, right ?The real question is … “why you (read Mike M.) support Linux at all”. I don’t get it really, you complain all the time so I guess you really hate developing for linux. So tell your manager to move you to another project and find a more enthusiastic replacement for you.As for audio API, you’ve been told all along to either go for Gstreamer or PulseAudio but wouldn’t listen. Don’t blame others.

  24. TellMeWhy says:

    Adobe, please fire those amateurs responsible for linux flash player. They made a broken product. Hire somebody, who know his s**t. Thank you. [ I’ll see what I can do. -Mike M. ]

  25. Jens Knutson says:

    Wow. I wonder if many of the comments here are actually satire, or if your blog really is that great of a magnet for the deepest, darkest depths of the bottom of the Linux community barrel. I’m kind of perversely impressed with the level of abuse and retardation.That said, I think you’re right about eglibc – it will probably just blow over. Further, thanks to you and your team for enduring all this garbage. I’m not fond of Flash being closed source, but I understand it, and while the player certainly isn’t perfect, it’s plenty servicable, and I’m impressed that it gets as much attention from Adobe as it does right now.

  26. OhHai says:

    Oh hai!When are you going to deliver my 64BIT Flash, sack all the people responsible for 32BIT Flash, send me a million Euros and a pony?Mike, the sense of entitlement you have to suffer on this blog, from certain members of the GNU/Linux community, is astounding.I just wanted to say: thanks for the work so far, Flash on Linux has come a long way since the Beta days. πŸ™‚ And that not all of us GNU/Linux users are this bad, honestly!Also, you’re right to worry about this eglibc thing, although I do expect it to all blow over. Not even FOSStards are stupid enough to develop two versions of the C library concurrently.If the worst comes to the worst — even though there’ll be a great wailing and gnashing of teeth in these comments — you could just pick whichever library is used in the most popular desktop distro(s) and support only that library, Adobe has more clout in the GNU/Linux community — on the desktop anyway — than many people give you credit for. After all, it’s not your fault if some FOSStards want to have a hissy-fit.

  27. jack says:

    Debian also made HAL a dependency in unstable. I think they will not last long if that crap hits stable.People wan’t Linux and not a badly re-invented Windows (HAL).

  28. Sunny Chan says:

    I never really understand why people would want to run a 64bit browser if 32bit browser works fine on 64bit platform? don’t they realise a 64bit browser would use up more memory (pointers are 64bit) and not necessarily faster?I use 64bit Linux all the time but I stick with 32bit browser, 32bit Java Plugin and of course 32bit flash, and no problem at all.

  29. Hi Mike,I think the move toward eglibc is actually one that is meant to improve your situation, not worsten it.If you try to figure out WHY the ABIs don’t match between the distributions, I think you’ll find that glibc’s maintainer’s lack of response to downstream requests and patches has a lot to do with it. With upstream not accepting patches, each distribution has no choice but to apply whatever patches they happen to think are necessary to their own distribution. My guess is that the difference between those patches is what created your ABI problems to begin with. The more distributions switch to eglibc, the more likely it is that you will have FEWER ABI problems, not more.OF course, life being life, it is possible that things will only be worse for the transition. Hopfully, this will be just a transitional period, and things will settle, but the best of intentions sometimes don’t produce a good result.The thing to remember is that this is meant to make your life easier.Shachar

  30. Decade says:

    Have you considered doing like nVidia, and producing an open source wrapper? It’s not like anybody will notice a performance degradation.

  31. keitai says:

    Notice that Nokia is already using eglibc on their internet tablets with maemo and flash. So flashplayer is already known to work with eglibc.The eglibc idea is very much not to break compat. Considering you are are dealing with mozilla (which doesn’t guarantee compatablity cross-version), eglibc/glibc is a nonexisting issue.

  32. fosco says:

    what’s the problem?eglibc should maintain binary compatibility, but more important, it is source compatible.If you software was Free Software, there will be no problem at all, and the packaging / porting work would be the task for the distributions.You complains about binary compatibility, but instead you should just provide your software under a free software licence, as as the thousand other softwares in Debian and other distributions.Or else, just don’t whine about something that is _not_ a problem, or maybe a problem linked to your crappy licencing model.

  33. xilun says:

    Given that the debian glibc packaging already used a huge set of patches, it’s difficult to understand why using eglibc could be “worse” ?I think indeed the risk of tricky binary incompatibility could decrease, because eglibc is not debian specific and it’s possible that some debian patches go in eglibc where they arguably can get more reviews.

  34. xilun says:

    Also, you’re right to worry about this eglibc thing, although I do expect it to all blow over. Not even FOSStards are stupid enough to develop two versions of the C library concurrently.Given that Microsoft has never been able to provide binary compatibility for mscrt and even told for years everybody to redistribute it with every program, it is hard to understand what is the GNU/Linux problem with binary compatibility of the glibc, when precisely there _IS_ binary compatibility here…So it that just FUD from MS zealots or what?

  35. Georgio says:

    For me, the browsing experience, particularly flash, is the one thing that holding me back from using Linux exclusively. It’s not only flash that is to blame for this, I believe the Firefox developers also treat Linux as an afterthought. It’s the age old chicken and egg problem, the businesses are waiting for a larger Linux user base before devoting more $$, but what average person is going to make the switch when web browsing is so lackluster.Mike… best of luck with your Linux plugin. Hope it works as well on Linux one day as it does on the other OSs.

  36. DRH says:

    Mike – I know I had to search pretty hard to find it, but why not point everyone bitching about not having a 64-bit flash to the beta that was produced a while ago ?As for the rest of it… From what I can tell, eglibc is just a collection of patches to fix bugs that Ulrich Drepper doesn’t like to admit are bugs. And the Linux Sound problem… For a decently modern Linux system there is the “Interface API” – ie: Phonon/ARTS/etc… – layers one step below them (PulseAudio/gstreamer/etc…) – and all the way at the bottom of the heap are ALSA and OSS. You should be able to support PulseAudio or gstreamer and cover 99% of the installations.Anyway, keep up the good work and thanks for your hard work!

  37. Wolfgang Draxinger says:

    Well, you don’t have to use glibc or eglibc or any other libc preinstalled on the end user’s system.The only thing important is the proper implementation of the syscalls, which are pretty much the same for all Linux versions. The details, namely how syscalls work, only differ between CPU architectures.So here’s a suggestion: Use a lightweight libc designed to be compiled into the programm statically. There are two lightweigt libcs:* dietlibc only drawback with dietlibc is, that it’s pure GPL, i.e. one can’t use it in closed source software.* uClibc under the LGPL and therefore suitable for CSS. It’s small enough that one can compile it statically into one’s program/plugin.

  38. J Rodman says:

    Right, like how every distribution ships a different linux kernel and it’s a HUGE binary compatability problem.Perhaps you should talk about a topic you have some comprehension of.

  39. oiaohm says:

    Audio fairly simple forget all the low level support gstreamer. Let gstreamer deal with the differences of the lower level also provides access to codecs you would not have other wise. Also it make development of that area simpler you don’t have problems just in your application. Something breaks you can share the resources to fix.Closed source markers need to get there act in order. Linux supports multiable dynamic loaders. So support multiable runtimes. Linux sys-calls are stable. The complete libc and a lot of other runtime problems could be solved in close source makers just released a combined runtime.Basically a finger to distributions. DRI2 alterations will allow going as far as own video drivers.Basically why in hell are you putting up with crap. Focus what you need have it made joint ship.Until then you will have to put up with fragmented.

  40. Wes says:

    This is one of the reasons I went to FreeBSD a decade ago. All of the BSDs do an amazing job maintaining compatibility and have all the code under one roof, so you simply don’t have to worry about this stuff.Still, Linux has more shiny things to play with!

  41. Mike, I wouldn’t worry about the eglibc/glibc issue. If the main purpose it was set up because Debian had a hissy-fit about its multitude of embedded platforms and upstream not wanting to support them, it is likely that the only real places affected by this change is everything that isn’t i586, x86_64, or ppc(64).Debian, being the most flexible distribution available, has to put up with some stringent requirements. Sounds like a contradiction, but it makes sense when you think about it. For Debian to be able to provide stable support for the many platforms it supports, they need to have a good level of cooperation with the upstream. Their packaging format actually reflects this attitude. Debian packages are generally built through secondary Makefiles integrated into a source tree.Ubuntu will undoubtedly switch to eglibc, but it won’t cause any issues. Or minimal issues, at best.I feel your pain though. Heck, even Bryan Lunduke feels your pain.The Flash Player 10 is great, though I wish Adobe offered its authoring tools for Linux, since they don’t work on Wine (at least, the trials didn’t).Heck, use Winelib to speed up the port if you have to! Just please give us Linux users more to work with when we want to make Flash enriched sites!That said, Fedora doesn’t seem to be leaning towards eglibc, so at least one huge chunk of distros will not be affected by this fork. And yes, it is a fork. It integrates code elsewhere and has a different name. It is a fork, like it or not.Fedora, RHEL, CentOS, Mythdora, and others that are Fedora-based will not be likely to switch, so you should be safe there.OpenSUSE might, considering Novell’s interest in low power platforms, and possibly even embedded ones.Gentoo and other source based distros are more likely to, since they stand to benefit more from eglibc over glibc.I hope this helps a bit, Mike!

  42. Michael Brown says:

    The idea that you could ever get one binary to run across all distros is just going to run into all kinds of problems if you ever want to do anything more complicated than ‘hello world’. One binary to rule them all == FAIL.The best way to reliably run across distributions is to compile on the target distro.OpenSUSE Build Service == WIN.

  43. foo says:

    I hope they break flash, fuck you Adobe.

  44. Anonymous says:

    The 64bit Flash-plugin for Firefox is too buggy ! Please fix it or abandon it.

  45. invalid says:

    2 possible solution:1, Don’t make one package for all distros, you never have actually met this requirement anyway.2, Open source flash player, I mean seriously, what could Adobe gain from keeping it closed? It is not like there are unique features that others cannot replicate, see silverlight for example… the cash cow of Flash really comes from the Flash maker and its player’s dominance of the market, why not open source it and let people port it to every platform for you, for free? Then you have the advantage that developers may take it for granted that a flash player is available for any platform.

  46. Mostly says:

    Why does it have to be a single binary for all linux platforms? Opera seem to have no trouble automatically generating some 50+ install packages for several different distributions, which has the added advantage of allowing users to use a platform’s native package management. There’d be an initial investment setting up a compile+test farm (presumably using virtual machines) but after that it could save you a lot of trouble…

  47. cpghost says:

    Well, as a FreeBSD/amd64 user, I couldn’t care less, as Adobe doesn’t care AT ALL to support us.But it’s interesting that even a slight variation of glibc is already causing problems for Flash Player. It shows how difficult that player is to support across platforms. [ The proposed variation hasn’t caused a problem for Flash Player yet. I’m just voicing my certainty that it will. -Mike M. ]

  48. Craig Ringer says:

    Honestly, this will probably be a win for compatibility.Currently, distros patch glibc – in particular they backport lots of bug fixes and some features. They also tend to introduce their own additional fixes and sometimes features not yet accepted upstream.Each distro has a different patch set.Hopefully the distros will all move over to eglibc, and in the process consolodate their patch sets because it’s much easier to get patches upstream, and upstream accepts backports of bug fixes.Honestly, I’d say this is a positive move.By the way, I’m fully with you on some of the stupidities of Linux and the whole distro system. I see how it came about, why it continues to exist, and how it’s highly benificial in many ways, but it sometimes just drives me nuts. Config file locations. Multiple GUI toolkits. Etc. Grr.

  49. Anonymous says:

    Hey guys, when can we expect Flash on FreeBSD? πŸ™‚

  50. Jonathan says:

    You asshats need to STFU and stop talking shit about Adobe.I will say I am a Linux enthusiast and I appreciate the things you are doing to better the Linux desktop Mike. Don’t pay attention to these assholes.

  51. OhHai says:

    @May 30, 2009 2:53 PMSo it that just FUD from MS zealots or what?Wow. I didn’t mention Microsoft in that earlier post at all. I don’t even use or like Microsoft products.Can’t you FOSStards understand that it’s possible for someone to point out faults in GNU/Linux without being Microsoft supporters?Oh, and for all the people calling for the freeing of Flash player: please provide a cost/benefit analysis that shows why Adobe should do this. It’s you who want Adobe to do something for you not the other way around.

  52. Anonymous says:

    @Jonathan, yes Mike may appear to be doing a flavour for Linux users, but you got to wonder what’s the next thing he is going to complain, that developers fixing a bug that his code relies on? [ I’m doing a WHAT for Linux users? -Mike M. ]

  53. ffelix says:

    Make 2 layers, similar to ati or nvidia, and compile the user interface to comunity make a patch for your distro

  54. Ricardo Ramalho says:

    Hi Mike!Don’t listen to these half-minded retards… You’re doing an wonderful job, and flash player is really usable, and serviceable. So, just forget the moaning of some people. These people don’t represent most Linux users!You have a concern with eglibc, but i don’t think it’ll be a problem. At least, that’s what I hope…Greetings! :)Keep up the good work! πŸ™‚

  55. no flash on linux says:

    But it’s interesting that even a slight variation of glibc is already causing problems for Flash Player. It shows how difficult that player is to support across platforms.Not surprising to me, Adobe is one of the worst software development companies out there.I haven’t been able to run flash on linux, the most recent version that worked ok was 7.From reading Mikes comments, I’m no longer surprised that flash on linux is so bad. He seems to be pretty stupid.

  56. Karl says:

    Salary? Work for it.Slave to the library(s)!

  57. Zbigniew L. says:

    Adobe and NVIDIA Announce GPU Acceleration for Flash Player. chance to have real acceleration on Linux? Flash is eating my Phenom 4 core CPU just on few pages with flash content. This is awful. Flashblock will stay favorite extension if Flash will keep eating all CPU power.If not please start using Cairo library for 2D vector drawing/text rendering. Why:-Firefox3 uses it for www page rendering both on Linux and Windows. Code once use everywhere.-Cairo library is hardware accelerated: via XRender or OpenGL on Linux. GDI+ on Windows

  58. Ricardo says:

    I think going open source would be better for Flash Player going after the technology changes.

  59. Nille says:

    About the people that doesn’t understand the need for 64bit when there’s an 32bit working, have you ever heard of pure 64bit?But we have an working 64bit flash player. (thanks Mike)About the audio jungle i can’t understand why you all want gstreamer or pulsaudio support?The best is to support ALSA since it also has oss support.That will cover as many users as possible and not add an extra audio layer or deps.I don’t use gstreamer or pulseaudio because they don’t add anything usefull only bugs.And there are many distrobutions without pulseaudio or gstreamer but i think all comes with alsa and what advantage would pulseaudio or gstreamer bring over alsa since they talk to the hardware through alsa.So Mike did the right choice.

  60. mike says:

    Any idea when flash will finally be able to play youtube videos without using 60% cpu. Fullscreen is about 5 frames a second and jumpy. Mplayer seems to be able to play 720p at full speed with less CPU. Come on, we have had hardware video overlays for years!Iceweasel 3, Flash Alpha AMD64, Intel 945GM. [ Read the literature: -Mike M. ]

  61. OhHai says:

    @ June 1, 2009 11:13 AMOh yes, of course, you’re so right! Thank you for making the rest of us realise!Lucky that GNASH has come along and made Flash on GNU/Linux a reality, good job we got some clever Free software developers on the job isn’t it?! It’s so good that people like you no longer have to whine and plead for a decent Flash implementation in the comments of the Adobe Flash blog.Seriously though, why is video (YouTube for example) a bit resource-hogging in Flash, when video in mplayer or vlc is not? If it’s not the GPU, then what is it? Oh, and if you can’t answer this, just put: ‘I could tell, but then I’d have to kill you.‘ Which is fair enough.Tangentally: Sorry if you’ve heard this before, but instead of trying to appease all these FOSStards, why not just create a simple library, which takes a SWF stream and outputs audio and video to callback functions? Then the o-so-clever people who frequent this blog can build their own damn interfaces, using whatever borked libraries they like. How big would a statically compiled library, like this, need to be? It could just be downloaded by the distro the first time someone visits a page with Flash on it.I can understand, from a corporate point-of-view, that you may need to control the ‘Flash’ experience, so your corporate image is not tarnished. In this case, you could just forbid developers from using the name ‘Adobe’ or ‘Flash’ in the names of their players. Anway, just a thought.

  62. bobertdos says:

    Well, I’m running 64-bit Jaunty (Ubuntu) with the 64-bit alpha of flash player 10. EGLIBC just got installed today and the alpha still functions just as well as it did before.

  63. OhHai says:

    Oh, and while I think of it, thanks for the good job on Adobe AIR for Linux.Works wonderfully!

  64. Artem S. Tashkinov says:

    Please, help investigating this bug: [ Reproduced. -Mike M. ]

  65. Jim says:

    I guess Adobe’s idea of a Linux flash player developer is someone that clearly doesn’t care for Linux, clearly doesn’t understand how to develop software on the platform, and someone that enjoys taking every opportunity to put down both the platform, its users and the FOSS community while failing to fix Adobe’s problems. What a joke. How about fixing long-standing issues on your buggy, poor performing little browser plug-in before criticising stuff that your clearly don’t understand.And Mike and his sympathisers wonder why Adobe gets the responses they do on this blog…LOL

  66. Joe says:

    I think a lot of the comments are quite spiteful and narrow minded. I would like to think that they were authored by immature children, but the truth is probably that such were made by some really sad, bitter, and pathetic adults. To them I say “Get a Life” and “Grow Up”.

  67. kris says:

    and now flash crashes the browser when switching to fullscreen on ff 3.5.

  68. why are we waiting? says:

    It’s now over 8 months since the flash 10 64bit beta. Is it too much to ask for to have even a small update to fix some of the critical bugs out there? or atleast an update as to what is going on with development?In the time elapsed since the alpha release most of software products I use have released a major version update. All that the flash team needs to do is polish bugs and finish a few features… Yet we haven’t even had a status update on what’s going on with the next version. Just what on earth has everybody at Adobe been doing for the last 8 months?You’d probably find you got a lot less angry posts here if you actually posted updates that said something about actually what was going on rather than rants about things in Linux you don’t like.People can understand and accept waiting for a new release if they know the reason for it but waiting 8 months with dozens of bugs that aren’t being fixed and not even getting an explanation as to why would tend to make most people rather frustrated.

  69. lol says:

    people use linux ?could have fooled me.

  70. andre says:

    I don’t understand how flash for linux is so inefficient I don’t understand how it is even possible, how? I don’t want to abuse anyone like many of the other people leaving comments but I simply don’t understand how any app can possibly be so inefficient..surely it has to….hmmm, it’s all very depressing. good luck to making a breakthrough.

  71. Josep says:

    I just seen that Adobe upgraded Flash Player plugin to even for the Alpha Linux 64 bits build.

  72. Zbigniew L. says:

    VERY IMPORTANT SECURITY UPDATE IS AVAILABLE FOR LINUX!!! PLEASE UPDATE to release.32bit: link on page)64bit: link at the bottom of page)These patched releases close important security hole already exploited by bad guys.

  73. Flash plugin side bar links out of date says:

    Just a fyi to anybody reading the comments who hasn’t noticed. The links to the side of the blog to the flash player downloads list are out of date. They list but the latest version is actually

  74. bobo says:

    If debian use it, ubuntu shall use it too, and this is about 90% of desktop users!Why worry for other 10%???

  75. Tudor Ciocan says:

    This is one of the reasons I went to FreeBSD some time ago. You don’t have to concern about anythimg because all the code is made by them .