On 20 March 2017 at 14:43, Reindl Harald <h.rei...@thelounge.net> wrote:
> you should try to understand what you quote and refer to - this options is > there *to break that compatibility which is otherwise implicit enabled* > Original claim which I've commented was about that Linux (kernel) does not changes anything in user<>kernel space interface. So I've presented something which shows that it is not truth. It was not about using such option on glibc build stage to break such compatibility. BTW. In case Linux glibc binary code is ballooned by the fact as long as you are not enabling source code configuration time option glibc code is ready to work probably even with kernels 2.0.x or at least 2.4/2.6. Other OSes distributions (not only Unixes) are assuming that kernel and base libraries are changing within system image as unbreakable resource so libc supports only supports current version of the kernel. Especially on Solaris such approach is possible as ZFS offers BEs (Boot Environments) in which may exist independent pairs of kernels<>libc. BSD* after incorporating ZFS into mainline uses exactly the same approach. THIS makes maintenance of the libc code dramatically simpler. In last ten years I heard many times BSD* and Solaris guys making jokes about glibc developers about supporting in single binary every possible kernel version. It does not mean that I share such point of view .. it is more that now I understand better from where it comes and why some other Unixes made move to which Linux still seems is not ready. As the same approach is possible to implement now on top of Linux with btrfs maybe some people will start thinking about similar changes (?) In recent years when I've been mentioning abut such possibility quite often. As an argument was usually used that ext or xfs code is smaller than btrfs. Surprisingly it is not true as code of these FSeses must handle quite long ladder of older version of ext and xfs file systems. IMO sooner or later some people will understand that some more radical changes needs to be done on top of the Linux as well. This fact is a bit unexpected as originally Linux was developed as well as king protest to keeping some legacy compatibility in other proprietary Unixes. Seems after 25 years Linux have now some significant legacy which is a bit weighting it down .. and BTW you are the only guy in the whole thread which converts each repoly > to HTML and it is *annoying* because you have no business to dedice in > which font and size others MUA render messages > Don't want to be rude but it means that you are still using email today like people +30 years ago. In the past I've invested few times personally time to adapt some email clients to be able handle correctly MIME. In other words you are trying to tell me that my past investment was pointless .. ;) Really it is time to move on because today email communication is about efficiency and speed, and not about still using plain SMTP messages. If your email client is not able to map font names to some other names it is not a feature but BUG in such client. Try to report this. There are already many OSS implementations showing how to handle such scenarios. Cannot find quickly how to disable HTML in replies. I promise that I'll find a way how to not send such emails here next time. kloczek -- Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
