This is the heart of the problem
This is the heart of the problem
Posted Feb 13, 2014 5:10 UTC (Thu) by dlang (guest, #313)In reply to: This is the heart of the problem by rodgerd
Parent article: The Debian technical committee vote concludes
I also don't see any of the existing glibc maintainers doing anything similar.
In the kernel discussion there is frequently the statement "provide the mechanism, don't force a policy". Glibc development seems to follow this as well.
This statement isn't just that policy belongs in userspace, it means that policy belongs under the control of the distro and/or admin of a system and that there are multiple policies that make sense under different conditions, no one Grand Plan will fit every condition.
I avoid Gnome because they have a similar attitude to systemd, and I'm concerned about Wayland because I'm afraid that they are slipping into that mode (X11 arguably went overboard in the mechanism not policy direction but I'm concerned that they may be overcorrecting with Wayland)
Posted Feb 13, 2014 5:51 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (32 responses)
The latter actually causes quite a LOT of pain for binary-only publishers.
Posted Feb 13, 2014 15:52 UTC (Thu)
by madscientist (subscriber, #16861)
[Link] (31 responses)
And I see absolutely no point in having glibc support compiling for older versions (and I've done embedded and cross development work for most of my career). It would add a lot of maintenance headache, AND it's completely trivial to get the same results without all that complexity and _much_ more reliably: you simply have to provide the --sysroot flag to your builds and point it to an older set of libraries and headers. Done.
Heck, I was implementing this years ago before GCC had decent support for it and it required an obscure set of flags, but it still worked then. Now it's a no-brainer.
I don't think we can call recommending that people use entirely more suitable, reliable, and maintenance-free methods to achieve the same goals "leveraging policy".
Posted Feb 13, 2014 20:40 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (30 responses)
> And I see absolutely no point in having glibc support compiling for older versions (and I've done embedded and cross development work for most of my career).
How do I compile a binary for RHEL5?
> It would add a lot of maintenance headache, AND it's completely trivial to get the same results without all that complexity and _much_ more reliably: you simply have to provide the --sysroot flag to your builds and point it to an older set of libraries and headers. Done.
Posted Feb 13, 2014 20:55 UTC (Thu)
by dlang (guest, #313)
[Link] (3 responses)
This is your answer to the RHEL 5 question above. glibc is the least of your worries, every other library you use is a problem as well.
the thing is that you don't have to do this for every distro you want to use, you just do it for the oldest one and newer ones almost always work.
this is backwards compatibility of the systems, things build for older systems keep working on newer systems.
I know that you praise the ability of the windows monoculture to set a flag and have the resulting binary work for that old version, but with multiple competing vendors it's not that easy to point at an arbitrary 'old' version of some other companies work.
Posted Feb 13, 2014 21:26 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
But not glibc. It can't be packaged or avoided.
Posted Feb 16, 2014 2:55 UTC (Sun)
by dlang (guest, #313)
[Link] (1 responses)
but even if you use glibc, the glibc developers can't implement policy in your apps by implementing some new function, they can only do it if they change an existing function.
so while they can break or change something they currently do, they can't take over other functions at a whim
Posted Feb 16, 2014 5:11 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Feb 13, 2014 22:42 UTC (Thu)
by madscientist (subscriber, #16861)
[Link] (25 responses)
Nevertheless, writing a strlcpy() is trivial. There are even lots of free implementations available for you. If you want versions that take advantage of all the performance tweaks for your particular hardware platform, that is much more work, sure.
> I have Ubuntu 14.04. How do I compile a binary for RHEL5?
Very simple. I've done it many times. You go get copies the RPMs or an installation ISO (if you don't want to pay for RHEL licensing you can get CentOS instead: it's binary compatible). You extract the RPMs into some directory on your system (this is simple because rpm is packaged for Debian and Ubuntu). Then you add "--sysroot=<extractdir>" to your compile and link lines.
Done and done.
> No, not done. It requires to create a completely separate build environment with all the required libraries. It's easier to install a complete OS in a chroot at that point.
That's just not true. In fact, I think chroots are a pain the ass because they require root privileges etc. I never use them. Even for creating RPMs (which ostensibly do require root access) I use fakeroot which is just the bees knees.
I have a complete build environment with my own GCC/binutils/make/flex/bison/m4/gdb, all the latest versions, and various different sysroots, and I can build my code soup to nuts including generating .deb and .rpm files with no special privileges (sudo etc.) and zero reliance on the underlying distribution: I may use Mint 14, someone else uses CentOS 6.4, someone else uses Ubuntu 13.10, and they all generate the same code and it works on any distribution RHEL 5.5 or up (or earlier, if I wanted it to). The entire thing can be tarred up and sent around and requires NO special packages installed on or configuration added to the build systems. And a further advantage is that I always know exactly what my system dependencies are (because I have to put them into the sysroot, which, since it's just for compiling/linking, doesn't need any other libraries to run a real system): no opportunities for accidentally pulling other libraries.
Now. My code is more system-level and so doesn't rely on GNOME libraries, etc. However, glibc is actually the LEAST problematic library, because while the glibc folks don't add the ability to generate code that runs on older releases, they DO very carefully and strictly maintain the ability to run code that was compiled for older releases on newer ones. This is a lot of effort on their part but it's hugely important. I can build a single binary that runs on versions of glibc that shipped with distributions 8 years old, or more, and all the ones in between.
If only the OpenSSL people cared so much :-/.
Posted Feb 13, 2014 22:45 UTC (Thu)
by madscientist (subscriber, #16861)
[Link]
Posted Feb 14, 2014 0:38 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (17 responses)
> Very simple. I've done it many times. You go get copies the RPMs or an installation ISO (if you don't want to pay for RHEL licensing you can get CentOS instead: it's binary compatible).
Then there's CMake which helpfully tries to find packages from the usual include/library directories. At least, the recent versions of pkg-config got better than they used to be.
It's easier to simply do a complete chroot installation (perhaps with fakeroot).
> Now. My code is more system-level and so doesn't rely on GNOME libraries, etc. However, glibc is actually the LEAST problematic library
I can trivially package all other libraries along with my application. ALL of them (well, except maybe some libcrazy that does something perverted with ld).
Let me tell you how I'm developing applications for Windows XP on Win 8.1 (that's 12 years distance in time). I take MSVS 2012, setup a project, set the compatibility level to WinXP and that's it. All the unavailable system functions are automatically masked by WINVER guards and I can trivially bundle the new MSVCRT libraries along with my application.
Posted Feb 14, 2014 8:55 UTC (Fri)
by khim (subscriber, #9252)
[Link] (10 responses)
Really? How well libGL packaged with your application works? How about libasound? Or may be libcups? How well they work on different distributions if bundled? GLibC is one of the least problematic libraries: if you exclude purely-computatiuonal libraries which you can bundle with your app then you'll find out that GLibC is in fact one of the most stable and most well-supported libraries. Then it must be fixed, right? It's hard to blame GLibC for bugs in some separate, totally unrelated package. I admit that Microsoft does better job, but then again: it, too, recommented to use old version of it's product to target old versions of Windows not too long ago, right? In reality to support XP “under the hood” MSVC does the same thing GLibC recommends to do BTW. It's called multitargeting there. The only advantage is that in Windows world these things are well-integrated and rarely bite while in Linux world everyone does this in their own separate fashion and there are rough edges everywhere. But this is problem if Linux fragmentation, not GlibC design.
Posted Feb 14, 2014 10:12 UTC (Fri)
by mchapman (subscriber, #66589)
[Link] (6 responses)
Bad examples. Plenty of proprietary Linux games are packaged exactly like this.
Posted Feb 14, 2014 17:51 UTC (Fri)
by khim (subscriber, #9252)
[Link] (5 responses)
Posted Feb 14, 2014 18:32 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link]
Posted Feb 14, 2014 23:52 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Of course, packaging libGL that depends on hardware is not really a good idea. But you certainly _can_ do it.
Posted Feb 15, 2014 11:58 UTC (Sat)
by khim (subscriber, #9252)
[Link] (1 responses)
Posted Feb 15, 2014 19:01 UTC (Sat)
by nix (subscriber, #2304)
[Link]
Posted Feb 15, 2014 2:07 UTC (Sat)
by mchapman (subscriber, #66589)
[Link]
You are correct. I got mixed up between my GL libraries.
Posted Feb 14, 2014 12:18 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
>How about libasound?
>Or may be libcups? How well they work on different distributions if bundled?
>I admit that Microsoft does better job, but then again: it, too, recommented to use old version of it's product to target old versions of Windows not too long ago
> In reality to support XP “under the hood” MSVC does the same thing GLibC recommends to do BTW.
And I stand by my statement - glibc is literally the worst library in Linux. Bar none.
Posted Feb 14, 2014 17:45 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
Not even close. MSVC 2012 RTM had no support for XP at all. Have you actually tried to read said blog post? Later this fall, Microsoft will provide an update to Visual Studio 2012 that will enable C++ applications to target Windows XP means “you can target Windows XP just yet”, you know. Well, Ok. Since by now we know that you are all too ready call black white and even ready to “stand by your statements” by adding links which state that black is indeed black and white is indeed white further discussion is completely useless. Because it's quite hard to discuss anything with someone who blatantly ignores logic.
Posted Feb 14, 2014 23:48 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
>Well, Ok. Since by now we know that you are all too ready call black white and even ready to “stand by your statements” by adding links which state that black is indeed black and white is indeed white further discussion is completely useless. Because it's quite hard to discuss anything with someone who blatantly ignores logic.
Posted Feb 14, 2014 16:46 UTC (Fri)
by madscientist (subscriber, #16861)
[Link] (2 responses)
I don't understand. Why do you think that the glibc implementation of strlcpy() would have all that stuff in it? Did someone write that implementation and contribute it and it was rejected? If so then you can just use that yourself. If not, then most likely if strlcpy() _was_ added to glibc it would just be the simple, unoptimized version you would write yourself. The _fact_ is that there's absolutely nothing preventing anyone from using strlcpy() in their program, any time they want. There's no need for glibc to include it. And even if some newer version of glibc DID include it, how many years would it be before you could rely on it being present on your target systems and remove your own implementation?
> Now try to compile the recent Boost library with this. I know because I did - it's not trivial.
We use Boost 1.53. I don't know if you consider that "recent" or what might have broken in Boost since then, but I don't remember having any particular problem when I built it (for third party stuff like this we build it once then use the results). We also use ICU, MPIR, google coredumper, unixODBC, etc.: we also compile all our build tools like this so we don't have to worry about the version of Linux on our build systems, so GCC, gdb, binutils, bison, flex, make, m4, cmake, git, python, etc.
> I can trivially package all other libraries along with my application. ALL of them (well, except maybe some libcrazy that does something perverted with ld).
I never pack system libraries with my software. If I did, then I'd be on the hook for tracking and providing security updates any time _any_ of those libraries has a flaw. That's too much work, and no matter how good we are at it, it's still not as good as using the upstream distro's security updates.
I admit, as I said before, I rely on a relatively modest set of low-level system libraries that are fairly stable: no Qt, GTK, etc. But we're talking about glibc here anyway. Glibc uses weak binding, versioned symbols, etc. to avoid having to change the major soversion which makes it completely painless to support. Libraries like libcrypto, libssl, libcurl, etc. just bump the major soversion and so are a SERIOUS pain in the rear end.
> Let me tell you how I'm developing applications for Windows XP on Win 8.1 (that's 12 years distance in time).
Lord. Windows is by FAR our most difficult port. For a DLL we build that we need to work with older versions of PHP we have to actually install MSVC 2008 and perform a completely different build with that. Not to mention all the effort needed to install software onto every Windows build machine by hand, set obscure system configuration options to deal with crashes on the headless/unattended build systems, etc. etc. And of course there's all the frustration, expense, and annoyance with getting licensing for all of it.
> Wrong. glibc is THE most problematic library in the Linux stack. Bar none.
You're wrong. Simple as that.
This will be my last post on the matter since we obviously cannot make progress here. I'm going back to using my straightforward environment that requires no chroot, su, or sudo, is 100% relocatable wherever you want to install it, can be bundled into a tarball and copied to a different system without extra packages or configuration, and generates the same result, where that result runs on every Linux system from Red Hat EL 5 or newer and does not require any statically-linked libraries and does not ship any system libraries and still works fine, and which I've been using to ship enterprise products to real customers for years.
Posted Feb 14, 2014 20:20 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
glibc does load-time resolution of symbols based on CPU capabilities. I call memcmp in my code, but it is resolved to __memcmp_sse4_1 at runtime. Sure, a compat/strlcpy.h works, but it wouldn't be as fast as __strlcpy_ssse3. Looking at my glibc, it seems that there would be optimized versions of strlcpy:
0000000000103cf0 T __strcpy_chk
Posted Feb 14, 2014 20:34 UTC (Fri)
by madscientist (subscriber, #16861)
[Link]
Yes, I definitely know that. But my point is that the existence of these highly optimized versions of strcpy() doesn't magically get you a highly optimized version of strlcpy(). There are plenty of functions in glibc which have not been optimized in this way, and there is no particular reason to believe that strlcpy() would magically get this support just by being included.
Someone needs to do that work, and even if the glibc developers could be convinced to add strlcpy() etc. to the library that's no guarantee they'd be motivated to generate highly-optimized versions.
And if someone WAS motivated to generate highly-optimized versions, then those could be used external to glibc just as easily (in fact, possibly more easily since you wouldn't have to worry about which glibc version you were using).
Posted Feb 14, 2014 21:35 UTC (Fri)
by jimparis (guest, #38647)
[Link] (2 responses)
Joey Hess seems to claim that shipping glibc with your application is also not hard: https://joeyh.name/blog/entry/completely_linux_distributi...
Posted Feb 14, 2014 23:50 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Feb 17, 2014 21:52 UTC (Mon)
by jimparis (guest, #38647)
[Link]
Posted Feb 14, 2014 17:28 UTC (Fri)
by hummassa (subscriber, #307)
[Link] (5 responses)
would you please be so kind and teach us how you do that?
Posted Feb 14, 2014 23:00 UTC (Fri)
by madscientist (subscriber, #16861)
[Link] (4 responses)
I build GCC et.al. by running configure and make, as per the README. I have a fancy makefile I wrote that does this. I create the sysroots as described in my previous posts: I get the RPMs and use rpm2cpio to unpack them into a directory, then when I compile and link my code I add the --sysroot=<dir> flag pointing to that directory. You might have to go through the sysroot and replace absolute symlinks with relative symlinks; I have a little Perl script that does this but it's easy enough to do by hand. You only need to do it once (or anyway, once every time you change your base operating system).
Posted Feb 15, 2014 13:22 UTC (Sat)
by hummassa (subscriber, #307)
[Link] (3 responses)
IOW, do you already, and if not, would you/ could you PLEASE (pretty please with chantilly and a cherry on top) publish your specialized makefile and perl script that enables you to do all those things authomagically? :D
I can throw in the promise of a beer (or other appeasing beverage/ edible with one hour of my arguably agreeable companionship and conversation) whether and whenever we are geographically close...
Posted Feb 15, 2014 14:44 UTC (Sat)
by madscientist (subscriber, #16861)
[Link]
Posted Feb 15, 2014 19:03 UTC (Sat)
by nix (subscriber, #2304)
[Link]
Posted Feb 16, 2014 18:36 UTC (Sun)
by liw (subscriber, #6379)
[Link]
Beware: I wrote this for myself. It's not designed to be clean or
Basically: a) a VM that runs Jenkins b) a VM for each environment (stable vs unstable, i386 vs amd64) where builds happen c) an apt repository (using reprepro) to hold packages built by CI d) successfully built packages get uploaded to the repo automatically e) builds use the repo in addition the Debian once and so groups of dependent packages can be built within the CI system.
Some day I may have time (or someone to pay me to hvae time) to make
Posted Feb 13, 2014 8:14 UTC (Thu)
by rodgerd (guest, #58896)
[Link] (13 responses)
> I also don't see any of the existing glibc maintainers doing anything similar.
Guess that incident refusing to add BCD types to the standard libraries as part of a huge dummy spit about a C standards update never happened then.
Not that that's the point, anyway. If you have a principle, it ought to apply everywhere. When you only invoke it as you find convenient, and ignore it otherwise, it's not really a principle any more, is it?
If you have a principled objection to systemd on the grounds it may wield unreasonable power in the userland, then your principle applies equally to any key plumbing, and you should be championing parallel implementations of other key infrastructure.
Posted Feb 13, 2014 11:14 UTC (Thu)
by dlang (guest, #313)
[Link] (12 responses)
refusal to add something is part of the 'hard to get along with' issue, but that's very different from using their position to force changes in policy across all distros.
Especially since for glibc, if you want to create patches that add those functions, you can do so and maintain such patches with very little impact on the rest of the glibc codebase, nothing else needs to change,
while glibc is on every system, unless the glibc maintainers start changing how existing library calls work, they aren't going to be exercising the type of control that the systemd maintainers have already demonstrated that they consider routine and a good thing.
where the glibc maintainers have refused to implement the strlcpy function, what we are talking about here would be more like them deciding to redefine strcpy to be strlcpy and eliminating the old capability entirely (after all, you can always make your own library, fork it, or LD_PRELOAD something to override it...)
What we are talking about here is the package mantainers mandating that ALL distros change how they act in some farily fundamental ways, due to the release of a new version of the package. And don't forget the stated plan of taking over more things in the system going forward.
Posted Feb 13, 2014 12:08 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
Posted Feb 13, 2014 12:29 UTC (Thu)
by dlang (guest, #313)
[Link] (10 responses)
but again, you are (possibly deliberately??) missing the point. the problem isn't a single library or tool be used across multiple systems, the problem is the abuse of power that results if the authors of said tool choose to use it.
again, look at the quote I'm replying to:
> Well, the *whole* point of systemd is to have a way to have leverage over the policy of ALL distributions and ALL userland, to allow to implement innovations that are instantly adopted on all Linux systems (being an "init system" is merely incidental).
the glibc transition was not 'instantly adapted' and the glibc developers have not been pushing disruptive changes. the worst they can be accused of is reluctance to implement changes that some other people want.
glibc also has trouble forcing policy, it can provide new capabilities, but it can't force them to be used. Unless it breaks existing functionality, it isn't forcing anything.
Posted Feb 13, 2014 14:15 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (9 responses)
Posted Feb 13, 2014 14:58 UTC (Thu)
by dlang (guest, #313)
[Link] (8 responses)
There was no discussion or feedback on it before it was announced, and a huge amount of FUD and misinformation spewed about the 'horrors' of syslog that it was replacing (as well as a lot of misleading at best claims about it's capabilities)
or, what about udev? that wasn't part of systemd, and as others have noted, they have made it hard for people to continue to use udev without sucking in the rest of systemd. this happened long after udev was standard on many distros.
Posted Feb 13, 2014 15:51 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (7 responses)
It does do things that syslog does not do (such as querying for related info from the kernel, early boot logging, fast filtering, color, FSS, etc.). I think rsyslog has picked up some of these things, but still not all. I also think that even if the journal were just a shim between systemd and syslog, it'd still be wanted to ensure capture of bits from the kernel before shuttling off to syslog (which is a supported mode). Also, if rsyslog implements the journal API to systemd, you probably could use it instead (though journalctl might be high-and-dry then).
For udev, the udev developers were amenable to it. The systemd developers didn't just clone and merge the repo and tell them "we own it now" (it was an upstream decision to make anyways). IIRC, it was that the two were too interdependent (hardware triggered startup, .mount targets, etc.) and it was making collaboration harder.
Posted Feb 13, 2014 19:46 UTC (Thu)
by dlang (guest, #313)
[Link] (5 responses)
rsyslog gathers the early boot logs from the kernel after it starts. the journal would need to do the same thing if it starts at the same time as rsyslog (and if it starts earler to gather more, why don't you start rsyslog earlier as well)
I don't think you have any idea of the amount of filtering that rsyslog can do. I know that LP didn't when the journal was added. color is a display thing, not part of the log. FSS didn't do what it claimed, and rsyslog now has the equivalent that actually works.
there is no need to have journal as a shim between the app and rsyslog other than the fact that the systemd developers mandate it.
rsyslog does implement the published API to the journal. however this does not allow rsyslog to replace the journal, because the internal API to the journal is not stable, running without the journal is 'unsupported'
as far as udev goes, the fact that distros are still using udev without using systemd indicates that your claim that they have to be used together is false. The problem is that the developers have repeatedly opposed the idea of making it possible to build udev without building all of systemd. I don't think people have submitted patches to do so (but I wouldn't be surprised if they had) because they have been so vocal in saying that they would reject any such patches.
Posted Feb 13, 2014 21:50 UTC (Thu)
by paulj (subscriber, #341)
[Link] (1 responses)
Can you expand on it not doing what was claimed? How serious is the discrepancy?
Posted Feb 16, 2014 3:20 UTC (Sun)
by dlang (guest, #313)
[Link]
It requires interaction with an outside system to make a tamper-proof log, either to send signatures elsewhere or to get a token that cannot be recreated with only data on the local system.
Posted Feb 13, 2014 21:57 UTC (Thu)
by peter-b (guest, #66996)
[Link]
Yeah, that'll be a [citation needed], please.
Posted Feb 14, 2014 9:25 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (1 responses)
You can tell the thing to be totally transparent if you don't like it.
Also, I don't want rsyslog to filter output for the simple reason that I won't know whether I'll need it before the fecal matter has actually encountered the rotating air circulation facilitator.
Also², rsyslog is just text, so there's exactly one sort criterion when all is said and done (the file name). The journal has so many ways to filter for the output you're actually interested in it's not funny, shows you possible values for fields …
I do wonder what's going on here. I mean, "the output from daemons gets lost when you use sysv-rc, so that's The Unix Way. systemd captures that stuff and doesn't even use an externel helper for that, so it's not Unix, so it's Monolithic Evil" is not a technical argument, it's religious.
Posted Feb 16, 2014 3:44 UTC (Sun)
by dlang (guest, #313)
[Link]
so start it earlier
>You can tell the thing to be totally transparent if you don't like it.
well, I haven't messed with the journal personally, but the people who have that I trust tell me that it doesn't actually work, and it's still a performance problem.
to be fully transparent, the journal would need to lookup all the trusted properties from SCP_CREDENTIALS, then forge them for the message to rsyslog that's a pretty significant amount of work to do for high log rates.
> Also, I don't want rsyslog to filter output for the simple reason that I won't know whether I'll need it before the fecal matter has actually encountered the rotating air circulation facilitator.
well, that's up to you. you were talking about filtering capabilities, rsyslog can send everything as-is, split it to different destinations, normalize the messages, reformat them, etc.
If you want everything in one place you can do that, if you want things splitup or put into any of a bunch of different types of datastores, you can do that as well.
> Also², rsyslog is just text, so there's exactly one sort criterion when all is said and done (the file name). The journal has so many ways to filter for the output you're actually interested in it's not funny, shows you possible values for fields …
You keep saying that "syslog is text only", what data is it that actually needs to be binary?
rsyslog will deliver the messages to many different things, including the systemd journal if that's where you want it, but it can do that in addition to everything else.
> I do wonder what's going on here. I mean, "the output from daemons gets lost when you use sysv-rc, so that's The Unix Way. systemd captures that stuff and doesn't even use an externel helper for that, so it's not Unix, so it's Monolithic Evil" is not a technical argument, it's religious.
the output from daemons gets lost if you want it to get lost.
random garbage from stderr is not log data, and mostly it's absolutely useless (look at the apache error log for example), having an option to feed it into a logging system is great, pretending that it is all good log data is showing inexperience.
systemd has a lot of things that would be great if they were options to be used when they make sense. But they cause problems when they are made mandatory under all conditions.
There are companies out there that take the attitude that they know better than their customers what the customers want, and they can be very successful if pushing customers to buy what they offer, but that is not what Open Source or Free Software is supposed to be about.
Free and Open Software is supposed to be about empowering the users, and that includes making it possible for the users to do things differently from what the developers imagined. Unless there is a lot of configurablity (like the Linux Kernel has), "Monolithic Evil" is less a religion than it is an observation.
Posted Feb 13, 2014 19:54 UTC (Thu)
by dlang (guest, #313)
[Link]
This is the heart of the problem
Really? Do you remember the strlcpy() debacle? Or maybe refusal to add versioning mechanisms that could allow newer glibc to be used to compile binaries for earlier glibc versions?
This is the heart of the problem
This is the heart of the problem
Look at glibc's implementation of string functions. They are not trivial.
I have Ubuntu 14.04
No, not done. It requires to create a completely separate build environment with all the required libraries. It's easier to install a complete OS in a chroot at that point.
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
We are not talking about 2-line version of strlcpy(), we're talking about optimized SSE-using version with automatic CPU detection. Like the other stuff in glibc.
Now try to compile the recent Boost library with this. I know because I did - it's not trivial.
Wrong. glibc is THE most problematic library in the Linux stack. Bar none.
This is the heart of the problem
I can trivially package all other libraries along with my application. ALL of them (well, except maybe some libcrazy that does something perverted with ld).
Then there's CMake which helpfully tries to find packages from the usual include/library directories.
This is the heart of the problem
Really? I've seen quite a few of them and they never include libGL. libGLU? Sure. libGLEW? Yes, sometimes. libGL? Never.This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
If you want to play such a crazy tricks then yoy can distribute GLibC, too. We don't distribute GLibC with our programs here, but we do have a GLibC packages here which are distributed independently from distributions we are using them on and which are used by most of the software developed in house thus I know it's quite possible to do.
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
Works just fine.
Ditto.
Haven't tried that.
AFAIR, that was a beta bug. I distinctly remember using the newest MSVS to compile binaries for WinXP SP2. Ah, here's a blog post that confirms this: http://blogs.msdn.com/b/vcblog/archive/2012/06/15/1032064...
Nope. Multitarteting is --sysroot analog, but it's rarely necessary.
This is the heart of the problem
AFAIR, that was a beta bug.
Ah, here's a blog post that confirms this: http://blogs.msdn.com/b/vcblog/archive/2012/06/15/1032064...
Nope. Multitarteting is --sysroot analog, but it's rarely necessary.
Well, Microsoft claims that it is necessary if you want to target WIndows XP. You can use some clever tricks to target Windows XP without doing that but they are even more fragile than multitargeting.And I stand by my statement - glibc is literally the worst library in Linux. Bar none.
This is the heart of the problem
Look at the date. It was in 2012 and the update with XP support was issued in 2013. It was true that initially MSVC12 did not support XP.
It's a matter for another thread, but I have other arguments (like schizophrenic API).
This is the heart of the problem
This is the heart of the problem
00000000000930d0 T __strcpy_small
0000000000086070 t __strcpy_sse2
0000000000098ae0 t __strcpy_sse2_unaligned
0000000000153250 t __strcpy_ssse3
This is the heart of the problem
This is the heart of the problem
>
> I can trivially package all other libraries along with my application. ALL of them (well, except maybe some libcrazy that does something perverted with ld).
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
http://git.liw.fi/cgi-bin/cgit/cgit.cgi/jenkinstool/ if you want to
have look.
easy to setup, and I don't particularly want to support it, but you
can have a look.
that easier for others to do.
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
So the libc->glibc transition is already forgotten? How swift the time passes...
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
This is the heart of the problem
Though I wonder why you'd want to – "systemctl status FOO" prints the last couple of a job's journal entries. Which is something I never expected I'd *not* want to do without.
This is the heart of the problem
This is the heart of the problem