LWN: Comments on "Poettering: systemd for Administrators, Part XII"

Poettering: systemd for Administrators, Part XII

mfedyk — Wed, 15 Feb 2012 18:52:33 +0000

Excuse me, but the point of Fedora is to be bleeding edge and expose those nits. You need to use a distro that focuses more on stability and polish. Opensuse and debian stable would probably be two of the more popular choices available.

Yesterday...

dgm — Tue, 07 Feb 2012 15:01:15 +0000

Very accurate. But do not forget another of the consequences of the application-centric model: malware.

On a repository based system you have an additional layer of people reviewing the software that you will end running in your machine. Part of the responsibility for the excellent track record of desktop Linux with regards to malware is by this layer of people. A tightly controlled App Store, like Apple's, has a similar effect, but having access to the source code makes repositories much more effective.

Yesterday...

elanthis — Mon, 06 Feb 2012 07:20:09 +0000

It's mostly commonplace on Windows because upstream often gives us little choice. Even if I compiled something like TinyXML, where would I put it that it would be found? How would I version the DLL? How do I make sure that my app isn't relying on a broken modified version someone else installed? It's not hard or difficult to build redistributable packages for Windows DLLs, but most upstream developers just don't bother. Possibly the installer toolchain just needs to be nicely integrated with Visual Studio.

The Linux ecosystem solves this with ham-fisted militarized regulation of software via the distribution package repositories. Which in turn results in very slow update cycles, a constant churn and a need to follow the bleeding edge for the entire OS to get a bug in one app fixed, and an inability to get a lot of software packaged for enough users because that packaging work has to be done 1000x times over for every possible distribution.

Which way is better? It depends on the use case (server, embedded, desktop, etc.). The desktop and consumer device market seems to be leaning towards bundled libraries, via means like the iOS App Store, Steam, and soon Windows Store. Especially when the Web hyperlink capabilities are used properly, they allow users to find software that most natural way (the Web) and then install software with minimal of fuss. No need to dig through a package repository after already having found the software online. No need to find out the latest available version of the software requires a library version the OS hasn't packaged yet. No need to find out that the latest version of the software has a bunch of features and fixes that the OS bundled package doesn't include and won't include for another 6 months (in which case the entire OS must be upgraded, along with possibly getting a whole new UI and a new slew of bugs, just to get that one application update).

The primary issues of bundled libraries -- space and security -- are a lot less interesting than most people think. Disk space is certainly cheap these days, and even the memory costs of loading multiple versions of a library for different apps are easy to ignore in today's post-32-bit world. The library security issues are things to be concerned about, but less so than most think. Sure, getting a patched OpenSSL right away is important on Linux, but then Linux is primarily a server OS. Everything it's running is some Internet-facing risk, and quite a few libraries are processing data that is literally sent to the machine from any ol' random node on the Internet.

On a modern day desktop OS there's practically only app that ever even hits the wide open 'Net is the Web browser. Users don't have much need to care that Random Grandma-Friendly Family Geneaology Wizard 2008 doesn't have the latest patched libpng because frankly it doesn't matter if it does or not; it doesn't grab random PNGs off the Internet and it's not an attack vector for any plausible threat.

Of course the "consumer-friendly" Linux-based OS (Android) uses this same application-centric distribution model. Users install and update individual self-contained applications or entire OS updates, not individual components of an OS+Apps repository. Small wonder.

GNOME, KDE etc. ABI breakage

sorpigal — Tue, 31 Jan 2012 13:12:32 +0000

It was cdbakeoven, and as near as I can tell it was a kernel change that finally broke it beyond my willingness to repair. I gave up on the idea of leaving a goodly chunk of KDE2 in a separate directory tree just for one program.

Incidentally, have you tried using xcdroast lately? It's an adventure.

Have you tried the usual tricks?

khim — Sun, 29 Jan 2012 16:12:43 +0000

Have you tried to run setup in "Windows XP" compatibility mode? Corel Painter 11 works fine. You can find and start setup.exe directly. In general the appropriate help page can help you.

AFAICS from forum posts Corel Painter Essentials works fine with Windows 7... with the exception that it insists in scanning the whole system drive at each program start. Which is sloow as you can guess (45min startup time is not unheard of).

Yes, Windows tries to stay compatible very hard - but it can not fix all the bugs in all the programs.

That's funny. really...

halla — Sun, 29 Jan 2012 15:00:12 +0000

Hm... Emboldened by this discussion I tried to install any of my collection of Corel Painter disks on my Windows 7 installation. None would start. Items tried range from a ten year old Corel Painter Essentials disk to a Corel Painter X trial -- we're now at Corel Painter XII, btw.

We can blame Corel, of course... Their products have never had a reputation for being solid, well-built applications, but then, wasn't the contention in this thread that on Windows that's not necessary, since Windows keeps everything running through amazing binary compability through the ages?

Neat

Darkmere — Sat, 28 Jan 2012 17:31:11 +0000

"Back in the day" , pkg-config used to ship an inline copy of glib (2.x) in case it needed to build on a system without glib, if it was built against this, it was linked in statically into pkg-config itself.

This was removed in early 2011.

Also, it's possible to build pkg-config without glib, simply by setting the environment variables for linking/including against glib by yourself.

Hot news, pkg-config is optional, export GLIB_CFLAGS, GLIB_LIBS, ZLIB_LIBS, ZLIB_CFLAGS.

And if you are one of those who think that pkg-config is "unnecessary bloat" (quite a few people thought that when it was included back in the day, autoconf could do that! ) then you can still just export the variables for all the libraries and be done with it ;)

Neat

alankila — Sat, 28 Jan 2012 04:37:52 +0000

So it takes pkg-config to build glib, but glib can't be build without pkg-config? Oh well, chicken-egg problems are unfortunately commonplace in software development. You need a compiler to compile a compiler, after all...

In the end, I'm not moved by arguments about sheer complexity or software size. What matters is that everybody runs the same software and therefore there exists certain fixed capability that can be used to build other software. I think it's called platformization.

Some solutions seem very popular such as dbus, and it appears to have made impressive amount of cooperation between programs possible. I also love pulseaudio for doing the impossible: reducing volume control problem to adjustment of a single slider and providing every application the capability to play audio together.

I think systemd and the /usr merge will again remove tons of useless complexity when it comes to managing services and deciding where to place the relevant files. I'm all for removing choice like this which doesn't seem to do anything else but hold the platform back. systemd appears very sophisticated to me and it's productized well, so it will make new and interesting capabilities available to all.

Poettering: systemd for Administrators, Part XII

zlynx — Sat, 28 Jan 2012 00:25:34 +0000

Yep. I am one of those people. I used Linux exclusively on my laptop from 2004 to 2008. Then I went to using OS X on a Macbook Pro.

In OS X it sure was nice that my WiFi always worked and always instantly reconnected after suspend resume. It was also very nice that suspend always suspended and resume always resumed. It was great having OpenGL that was both fast and reliable. It was amazing to have OS updates that didn't break anything.

In 2011 I went back to Linux. Fedora 15 (16 now), on a new PC laptop. Because it happens to use all Intel chips, it works pretty well. It still has a few big annoyances, like the fact that WiFi takes over 20 seconds to reconnect after resume. OpenGL is slow. Sometimes I have to unplug and replug the USB keyboard. Some Bluetooth mice just don't work (oddly Microsoft and Apple mice do). And the trackpad will sometimes completely freak out. And I need to use a few funky options on my kernel command line so it doesn't panic on reboot. And the update from F15 to F16 required me to hand-edit those same kernel options into the grub file. Oh, and I also had to manually fix a 32-bit required library that the update installed on the 64-bit system.

In a lot of ways OS X and Windows 7 are a much better desktop experience. Linux is mostly there, but has so many little nits.

Poettering: systemd for Administrators, Part XII

jeremiah — Fri, 27 Jan 2012 17:06:19 +0000

I write and design a fair number of APIs. The habit that I've tried to get into is to never release those APIs without first writing a reference implement and then seeing what part of the designed API is actually needed. It's always a balancing act for me between writing the RI, Using the RI (full test cases), and Cleaning up the API. I don't know how many times Ive put something out there that seemed complete and elegant at the time. And Once we tried to use it it was just a pile of char[]. I think people run into problems by depending on 1.0 APIs, not that they have any choice a lot of times. APIs, file formats etc, all seem to suffer from the standard write the code , then rewrite it all over problem. Things always seem to settle down after/during that third rewrite. <snark>Gnome 3 being the exception.</snark> At least writing software is fun right?

No, that's regression...

HelloWorld — Thu, 26 Jan 2012 20:22:44 +0000

> I've used RealVideo player in parallel to MP3 player with OSS in 1998, sorry.
Then the sound card you used then probably had a hardware mixer.

> ALSA broke this ability not just for OSS applications, native ALSA applications can not issue any sound if Adobe Reader hogs the device either.
It works perfectly fine if your sound card has a hardware mixer (as my Asus A7V880 did), and if it doesn't, you can use dmix.

> Exactly! They provide one version for Windows (85-90%+ market share), one version for Mac (5-10% market share) and eight versions for Linux (2-3% market share). Why? Because all these Linux versions have forsaken compatibility in the pursuit of pretty colors. And even then it does not work with all versions of Linux.
Which version of Linux does the statically linked binary not work on? And besides, this still isn't a backwards compatibility issue, but a cross-distro interoperability problem. I agree that having so many different distros sucks.

> There are hope: at least they can write "Ubuntu 10.4+ 32-bit." and are not forced to provide separate versions for Ubuntu 10.4, 10.10, 11.04, 11.10... but the fact that it's problematic to use 32bit version on 64bit Ubuntu is already quite aggravating
Yet again, this is not a backwards compatibility issue but a cross-architecture compatibility problem specific to one distro (i. e. debian and its derivatives). It's trivial on, say, Fedora.
Aside from that, it is trivial to make the 32-bit version run on a 64-bit machine: just use the statically linked version. But then, why would anybody do that, given that a 64-bit version exists? You keep mixing up different issues and whining about things that nobody cares about in the real world.

> Unless you'll run it in compatibility mode.
Do you think I'm stupid or something? I tried that of course, it just didn't help.

> Which is still possible if you install appropriate .dll files.
Err, no. I got it to start somehow, but it ran unplayably slowly and it had massive glitches in the menu and the HUD. It way unplayable.

That's funny. really...

HelloWorld — Thu, 26 Jan 2012 19:56:03 +0000

> I actually have the original C&C disks. I've tried to install C&C from them, but disks have become unreadable over the years. So I downloaded it from TPB and installed it just fine in Win7 in compat mode.
Well, it didn't work when I tried to install it from my disks. Perhaps this issue only applies to the german version or something.

Neat

wahern — Thu, 26 Jan 2012 19:28:17 +0000

It depends. If by easier you mean you can reuse more existing libraries and components, yes. But what matters far more is the design and complexity of the interface.

While PID file management is a PITA (something which a 128-bit getlpid()+lkill() would easily fix), all of the other stuff is trivial to do. You can daemonize, with a watchdog, by calling fork()+setsid()+fork()+chdir()+chroot()+setuid().

I recently tried to compile pkg-config the other day from scratch. It's basically a couple of .c files. Yet it has an insane circular dependency on glib; it uses glib's list implementation. Ignoring for the moment that <sys/queue.h> exists on all FOSS implementations and OS X (and is trivial to copy into your project anyhow), does it really make sense to reuse glib for a simple list implementation? glib is a monstrous piece of software. You would be effectively deleting a ton of code by rolling your own list implementation from scratch.

Now I'm not saying people should always roll their own daemon management code instead of using systemd. But consider that when you use systemd you're also using a gajillion other components, many of which reside in the Linux kernel. Do you really want to tie yourself to all that dead weight when you could get 80% of the features by using, e.g., inetd? Why not let the user decide whether to use systemd or something else? Most of the conveniences benefit the administrator, not the developer.

Poettering: systemd for Administrators, Part XII

wookey — Thu, 26 Jan 2012 18:13:55 +0000

The couple of users I know that have used office for a long time certainly bitch and moan about 'new office' and how much they hate the changes. I've not heard the same complaints about ooffice.

Users _do_ complain about formatting differences and doc format incompatibilities when switching back and forth or dealing with others. But there is nothing _wrong_ with what OO does, its just the network effect of many more office users and (so far as I know) current office still not supporting ODF out of the box.

Continuing the general anecdoates of 'normal users' switching to windows. I know two who used to be Ubuntu users but now have Windows laptops. That's mostly because their new machines came with Windows and they didn't have huge incentives to change it. Most of that was that its just easier to be doing the same as the majority (doc formats, general knowledge on how to fix things).

I help one get access to a mercurial repo a few days ago and she immediately recognised that this would be _so_ much easier on ubuntu because she could just do apt-get install mercurial; hg clone <repo>.
On windows it was a faff. She kept saying 'Windows is fine so long as you aren't trying to do anything more that browse and write docs'.

So users do understand, and it's not really about proprietary apps. It's largely inertia in terms of what comes with the machines, combined with the networks effects (at least in these cases).

That's funny. really...

Cyberax — Thu, 26 Jan 2012 18:12:10 +0000

>Yeah, except that it doesn't, because Windows really isn't all that backward-compatible either. Command & Conquer for Windows 95 wouldn't work on Windows XP (the installer crashes). And I didn't get Unreal II to work on Windows 7 either.

I actually have the original C&C disks. I've tried to install C&C from them, but disks have become unreadable over the years. So I downloaded it from TPB and installed it just fine in Win7 in compat mode.

There's a good story about Windows compatibility - they've actually made a special-purpose memory allocator for Win95 to work around a bug in Sim City.

Read it here: http://www.joelonsoftware.com/articles/APIWar.html - that's how much MS cared about compatibility.

No, that's regression...

khim — Thu, 26 Jan 2012 16:29:20 +0000

What you're asking for has nothing whatsoever to do with compatibility. You're asking for new features that exceed the ones that OSS provided in the first place, not for compatibility.

I've used RealVideo player in parallel to MP3 player with OSS in 1998, sorry. ALSA broke this ability not just for OSS applications, native ALSA applications can not issue any sound if Adobe Reader hogs the device either. And support was only reintroduced in 2008. That's 10 years, give or take.

In fact, they do, e. g. Skype provides packages for various distros and a statically linked binary, in case all else fails.

Exactly! They provide one version for Windows (85-90%+ market share), one version for Mac (5-10% market share) and eight versions for Linux (2-3% market share). Why? Because all these Linux versions have forsaken compatibility in the pursuit of pretty colors. And even then it does not work with all versions of Linux. For most ISVs this mess just does not make sense.

There are hope: at least they can write "Ubuntu 10.4+ 32-bit." and are not forced to provide separate versions for Ubuntu 10.4, 10.10, 11.04, 11.10... but the fact that it's problematic to use 32bit version on 64bit Ubuntu is already quite aggravating and the need to provide eight packages to cover most (but not all!) distributions is just wrong.

Yes, and that's the reason why nobody really cares about OSS compatibility (except for trolls like you).

I don't care either at this point. OSS compatibility was sore point five years ago, but today it's thing of the past. Sadly linux desktop developers invent something new to break almost every year.

Command & Conquer for Windows 95 wouldn't work on Windows XP (the installer crashes).

Unless you'll run it in compatibility mode. I know: right-click and Run this program in compatibility mode is ubercomplicated trick and not all Windows users can do that. But it says something about expectations, too.

And I didn't get Unreal II to work on Windows 7 either.

Which is still possible if you install appropriate .dll files. Yes, Unreal II is rare case where Microsoft decided that small piece of API is not worth supporting in future versions of Windows thus you need to hunt down and install Windows Server 2003 DirectMusic Patch with proper versions of DirectMusic .DLLs. Somehow such activity is perceived as simple (some even say trivial) in Linux, yet when you hit the same trouble in Windows you've given up immediately. Don't it say something about your expectations?

Please

corbet — Thu, 26 Jan 2012 15:31:22 +0000

Can we please aim for a slightly higher level of discourse here?

This is aimed at everybody, not just the immediate parent post. Disagreements are fine, but we do not need to fling personal insults at each other. If you think somebody is a troll, then don't feed them! If you must respond, please find a way to do so without turning LWN into some sort of elementary school playground, OK?

That's funny. really...

HelloWorld — Thu, 26 Jan 2012 15:10:23 +0000

> It's one thing to have something called "emulation layer". It's something else entirely to support old programs. For years said emulation layer was buggy and basically unusable. When I start Adobe Reader I should not lose the ability to watch YouTube videos - even if both use "obsolete" OSS interfaces.
What you're asking for has nothing whatsoever to do with compatibility. You're asking for new features that exceed the ones that OSS provided in the first place, not for compatibility.

> Ah, so to make them work you only need to give up your freedom and stop choosing your software for yourself - you should just use what your distribution offers you. This is good band-aid, but it does not solve the problem. ISVs are still out of the loop and this means Linux is still unsuitable for a desktop.
This is, again, just bullshit. Using a package manager has *nothing* to do with giving up freedom, it is simply the most common and convenient way to install software on Linux, and nothing stops ISVs from adopting it. In fact, they do, e. g. Skype provides packages for various distros and a statically linked binary, in case all else fails.

> That's because there are none.
Yes, and that's the reason why nobody really cares about OSS compatibility (except for trolls like you).

> Correlation looks quite striking - but one-sided.
Yeah, except that it doesn't, because Windows really isn't all that backward-compatible either. Command & Conquer for Windows 95 wouldn't work on Windows XP (the installer crashes). And I didn't get Unreal II to work on Windows 7 either.

Anyway, I'm really tired of wasting my time with your stupid trolling attempts. Have a nice life.

That's funny. really...

khim — Thu, 26 Jan 2012 14:44:17 +0000

Please, stop spreading bullshit. ALSA has had an OSS emulation layer ever since it was merged into the kernel.

It's one thing to have something called "emulation layer". It's something else entirely to support old programs. For years said emulation layer was buggy and basically unusable. When I start Adobe Reader I should not lose the ability to watch YouTube videos - even if both use "obsolete" OSS interfaces.

Linux desktop finally got good, usable OSS emulation in 2008 - years after switch from ALSA to OSS.

> As I've said: situation is slowly improving, but it's still far from perfect. You continue to say that you've run gtk2 and gtk3 applications side-by-side, that you've run Qt3 applications, etc but you forget to say what you needed to do to make them work.
Nothing.

Hardly.

I use ekiga (gtk2) and pavucontrol (gtk3). Both are shipped with debian, the package manager pulls in the required dependencies.

Ah, so to make them work you only need to give up your freedom and stop choosing your software for yourself - you should just use what your distribution offers you. This is good band-aid, but it does not solve the problem. ISVs are still out of the loop and this means Linux is still unsuitable for a desktop.

The only "application" I use that only supports OSS is Unreal Tournament, which works just fine. And I don't know many other people who use applications of similar age. I can't think of anyone, actually.

That's because there are none. Unreal Tournament is remnant of the brief era in which it looked like Linux is gearing to be real contender for a desktop. Then "great desktop designers" started breaking stuff repeatedly and ISVs abandoned their Linux efforts.

Besides, I'd like to see some kind of backup for your claim that compatibility is as important as you seem to think it is.

Well, it's kinda hard to do proper scientific experiment in this area, thus we only have one observation - but it's damning. We've had lots of OSes created for user-facing devices (desktops, mobile phones, tablets). Some of them cared about ABI stability (Windows/WindowsCE, MacOS/iOS, Palm, Symbian, etc), some have not (WindowsCE, Linux, Palm, etc). Note that couple of OSes are in two categories at once (WindowsCE and Palm). That's because they had two distinct phases: in one phase they cared about backward compatibility very much and in the next - they dropped it to create "greater, more popular platform". In all cases these attempts led to disaster: platform either died altogether or went below 1% market share for many years (most died, WindowsCE become incompatible Windows Phone 7 and while it's not technically dead yet it's market share collapsed catastrophically).

Correlation looks quite striking - but one-sided. There are plenty of OSes which had good backward-compatibility yet failed anyway, but we have no widely used OSes which treat backward-compatibility as cavalierly as Linux does. Even MacOS does it better: it gives ISVs short time (just a few years) till they are forced to do major changes to the programs - but at least in this short period old programs still work just fine and neither users nor developers are forced to search for the solution on forums. Start PowerPC program in Intel Mac - and it works, no question asked. Believe me, difference between PowerPC binary and Intel binary is much larger then difference between OSS and ALSA.

Sorry, but you are wrong...

Cyberax — Thu, 26 Jan 2012 12:17:02 +0000

You're confusing two issues. You DO need a manifest to bind with the correct MSVCRT.

However, you can ship MSVCRT DLLs along with your app by simple copying without any installation. That's called "Private Assemblies": http://msdn.microsoft.com/en-us/library/aa375674.aspx

Let me quote this: http://msdn.microsoft.com/en-us/library/ms235299.aspx

>To deploy Visual C++ redistributable files, you can use the Visual C++ Redistributable Package (VCRedist_x86.exe, VCRedist_x64.exe, or VCRedist_ia64.exe) that is included in Visual Studio, or use Redistributable Merge Modules, or you can directly install specific Visual C++ DLLs to the application local folder. An application local folder is a folder that contains an executable application file. DLLs must be deployed to the application local folder.

As I've said, I've done this personally. It works.

That's funny. really...

HelloWorld — Thu, 26 Jan 2012 11:28:10 +0000

> Nope. Not well. In fact it makes all the difference in a world. All the compatibility layers were afterthoughts and they were often added to the system later, often years later.
Please, stop spreading bullshit. ALSA has had an OSS emulation layer ever since it was merged into the kernel. PulseAudio has supported OSS and ALSA compatibility for ages.

> In cases where they were added from the start (V4L) they were often buggy
[citation needed]

> As I've said: situation is slowly improving, but it's still far from perfect. You continue to say that you've run gtk2 and gtk3 applications side-by-side, that you've run Qt3 applications, etc but you forget to say what you needed to do to make them work.
Nothing. I use ekiga (gtk2) and pavucontrol (gtk3). Both are shipped with debian, the package manager pulls in the required dependencies. And I've used Xilinx ISE, which shipped with Qt3 included (and even if it hadn't, there'd be no problem, as debian still ships Qt3 packages).

Besides, I'd like to see some kind of backup for your claim that compatibility is as important as you seem to think it is. The only "application" I use that only supports OSS is Unreal Tournament, which works just fine. And I don't know many other people who use applications of similar age. I can't think of anyone, actually.

Poettering: systemd for Administrators, Part XII

dlang — Thu, 26 Jan 2012 09:17:12 +0000

note that what I was replying to seemed to imply that people are being hypocritical by criticizing Lennart because the same people praise Steve Jobs and the two are doing the same thing.

I agree they are doing the same thing, but I disagree that the same people are criticizing Lennart and praising Jobs

Poettering: systemd for Administrators, Part XII

anselm — Thu, 26 Jan 2012 09:06:12 +0000

It's telling that a lot of the criticism of Lennart is that he is blindly copying things from windows or OS/X.

I don't think the idea behind systemd (for example) is to make Linux more like OS/X – systemd takes some inspiration from OS/X because launchd is fundamentally a reasonable concept, but I wouldn't describe systemd as »blindly copied«. Actually it seems to me that quite a considerable amount of independent creativity went into making the idea work well on Linux. So this »criticism« does not appear to be grounded in fact – it sounds like propaganda.

Anyway, what else did St. Steve do in his life but copy stuff from others and refine it?

That's funny. really...

khim — Thu, 26 Jan 2012 08:18:10 +0000

That posting you've linked to is full of FUD and lies

Hardly. Instead it includes bitter truth - which nicely explained why Linux is constantly losing battle for desktop.

you can find the details in my response to that posting (which I had written before realizing I was responding to a 3-year-old posting. Oh well).

Nope. Not well. In fact it makes all the difference in a world. All the compatibility layers were afterthoughts and they were often added to the system later, often years later. When users have cried themselves hoarse and developers have left. In cases where they were added from the start (V4L) they were often buggy - and response from the driver developers was often "just stop using this obsolete interface", which is insulting for developers (who have other plans besides the need to chase random changes in Linux ABI) and absolutely unsuitable for users (who have no way to "stop using the obsolete interfaces").

As I've said: situation is slowly improving, but it's still far from perfect. You continue to say that you've run gtk2 and gtk3 applications side-by-side, that you've run Qt3 applications, etc but you forget to say what you needed to do to make them work. Usually you need to find some libraries or modules and install them, use LD_LIBRARY_PATH or other tricks. Nothing works out of the box. This is what I call nobody cares: "naïve" developers think that backward compatibility is OS developers responsibility first and theirs second if at all (most think OS developers should solve everything without them), "naïve" users think that they don't care who's responsible - but they do know they are not (especially if they paid for the application and OS... since OS is often free and "you can't get much for free" developer is usually one who's drowned in complains) and "self-righteous" Linux desktop architects "know" it's not theirs problem. The end result? 1% on desktop, lost mobile platform, etc.

BTW current 1% is actually good result: at least you still have hardware which you can use to play your power games. Don't count on it to be available forever, though.

Poettering: systemd for Administrators, Part XII

dlang — Thu, 26 Jan 2012 08:15:48 +0000

> That would also be a pretty fair description of what Steve Jobs did in his life. People like to diss Lennart Poettering while Steve Jobs is basically on the fast track to sainthood. It's a strange world.

Actually, I suspect that the overlap of the people who want to cannonize Jobs and the people who have even heard of Lennart is very small.

It's telling that a lot of the criticism of Lennart is that he is blindly copying things from windows or OS/X. that hardly sounds like the same people who are Apple fans

There are huge difference, however...

halla — Thu, 26 Jan 2012 08:11:21 +0000

"The interesting question happens after you've managed to write working installer."

After having created the installer, I write the next version of the application which means I'll have to write update installers, and on windows, figure out some way of semi-automatically updating the existing installed base. Which is always fun, if you've got half a million users.

And after having created the installer, I get bug reports, often about obscure incompatibilities between the development and testing systems and the user's windows system. For which I, sometimes, have to actually buy the actual hardware the user uses so I can figure out that the problem is related to the particular version of the Intel graphics driver Asus installs on that particular laptop model.

Or (ten years ago) that the application crashes Windows because the font the user has installed has some broken truetype code embedded that causes a kernel panic when hyphenating.

We have to face it: all operating systems suck, all hardware sucks and there is no such thing as a free lunch. Arguing that Windows makes life easier for a software developer than Linux is an exercise in futility.

Neat

alankila — Thu, 26 Jan 2012 02:56:32 +0000

It's technically easier to deliver a working, sophisticated solution in a monoculture. Here's why. On monoculture's side, you have two pieces of software: systemd and the linux kernel.

On heteroculture, you'd have systemd + stable API which it must use + the kernel of user's choice. The API component would be adjusted per kernel.

What happens now is that you need to maintain this intermediate kernel-specific API, which is actually pure overhead relative to the monoculture solution, and you can't expose any features in systemd which are not supported in all of the api+kernel combinations. (If you make kernel-specific features, you are becoming a monoculture again: you have this API thing there but it is actually useless because stuff only works against certain specific kernel.) So the more kernels there are, the more likely it is that your new awesome software actually can do what anything new and interesting.

The point is, this thinking you have there is one of the primary problems. There's always been too much flexibility historically, or as I put it, open source programmers are scared to delete code. The code which they should delete is all this intermediatory API glue.

There are huge difference, however...

HelloWorld — Thu, 26 Jan 2012 01:34:03 +0000

> On Linux... nobody cares.
Yeah, except that they *do* care. That posting you've linked to is full of FUD and lies, you can find the details in my response to that posting (which I had written before realizing I was responding to a 3-year-old posting. Oh well).

GNOME, KDE etc. ABI breakage

HelloWorld — Thu, 26 Jan 2012 00:57:49 +0000

What stops you from putting the required libraries in the program directory (and set LD_LIBRARY_PATH accordingly) and be done with it? After all, if the program (xcdroast?) hasn't been maintained for 8 years, who cares if the libraries it uses are?

There are huge difference, however...

khim — Wed, 25 Jan 2012 21:27:20 +0000

Frankly, having produced software for Windows for twenty years, Linux for fifteen years and OSX for three years, I find there's precious little to advocate one platform over another. All have peculiarities, pitfalls and idiosyncrasies that are consume roughly the same amount of time when making end-user software ready for installation.

The interesting question happens after you've managed to write working installer.

On Windows compatibility is big deal™ - this means that next versions of Windows will include bunch of hacks which will try to keep your software from breaking. They will not always work (it's not really possible), but it'll try to guess what to do with your program to make it usable (for example Windows Vista will automatically ask for administrator privileges for programs named install.exe or setup.exe - unless they include manifest which disabled such requests: this way old installers work and new installers may decide to not request admin provileges by default).

On MacOS the same happens - but for limited time only. For example when Mac was transitioned from PowerPC to x86 it only supported old binaries for pathetic five years. Developers were forced to recompile (and sometimes rewrite) everything in this short period.

On Linux... nobody cares. Beauty os the desktop is paramount and if it requires breaking the ABI - nobody will think twice. Libraries are added and removed in each revision of OS (sometimes even minor security updates change SO versions), files are moved around without any kinds autodetection, etc. And it looks like temporary stabilization I've talked about back then was short-lived: in last 3-4 years almost everything was broken on desktop (on level above libx11/glibc).

Sorry, but you are wrong...

halla — Wed, 25 Jan 2012 20:10:34 +0000

"Nope. msvcrt.dll (the old one from MSVC 6.0) does. Newer ones just complain bitterly "R6034 An application has made an attempt to load the C runtime library incorrectly". You can only install them as Shared Side-by-Side Assemblies (as explained here)."

And certain version(s) of Visual Studio would actually create the side-by-side assembly wrong, which meant we had to patch some xml files when delivering our application on Windows. That was quite a bit of an eye-opener.

Frankly, having produced software for Windows for twenty years, Linux for fifteen years and OSX for three years, I find there's precious little to advocate one platform over another. All have peculiarities, pitfalls and idiosyncrasies that are consume roughly the same amount of time when making end-user software ready for installation.

Free software on Linux has the advantage that as a volunteer developer I can leave most of that to the distributions, though. Makes life easy and lets me focus on coding...

Sorry, but you are wrong...

khim — Wed, 25 Jan 2012 19:05:45 +0000

Not true. MSVCRT DLLs work just fine if you put it beside the application.

Nope. msvcrt.dll (the old one from MSVC 6.0) does. Newer ones just complain bitterly "R6034 An application has made an attempt to load the C runtime library incorrectly". You can only install them as Shared Side-by-Side Assemblies (as explained here).

It's just that they have special 'magical' hooks into SxS.

Not only that. They are always shared (real private installation is no longer an option) and they must be installed in the system, not just dropped in the directory with your binary.

I'm thinking about binary patching executable file to make it look like it requires older version of glibc.

Will not work™. Linux does not even store the version of GLibC needed to run your application in binary linked with GLibC. What it does store is version of library function called from your program. And if you call new function not available in old version of GLibC (because you are using headers with redirect "open" to "__open_2") then you really need GLibC (or some other library) which will actually include these functions.

What you can do is to create library which will provide such symbols (as weak alias, probably) for older versions of GLibC. But this sounds like an SDK - and if you are doing an SDK then you can just use older version of GLibC in it...

Actually this is the case which is absolutely identical in Windows world.

Cyberax — Wed, 25 Jan 2012 18:06:22 +0000

Windows is like that. Over the years the famous DLL Hell problem led to a lot of "solutions" which are worse than problems they try to solve.

Yet it all somehow clunks along...

Linux desktop market share

sorpigal — Wed, 25 Jan 2012 18:05:38 +0000

I run old Windows games via wine with mostly great success. Often times the experience is far better than friends who try them under Windows 7.

Actually this is the case which is absolutely identical in Windows world.

jrn — Wed, 25 Jan 2012 17:49:49 +0000

Might be worth trying lsbcc first.

Actually this is the case which is absolutely identical in Windows world.

Cyberax — Wed, 25 Jan 2012 17:32:09 +0000

>Absolutely the same thing as in Windows world. Hint: recent versions of MVCR*.dll just flat out refuse to work if you don't install them properly.

Not true. MSVCRT DLLs work just fine if you put it beside the application. It's just that they have special 'magical' hooks into SxS.

But you can bundle them with your app. MS even recommends it: http://support.microsoft.com/kb/326922 and I've done it personally.

>On Linux it means using older version of GLibC

Which means that I have to find the most ancient distro, replicate all the toolchain (hey, do you know what fun it is to compile GCC 4.7 on CentOS 4?) and then build your app.

That is a very real pain point. And Something Must Be Done.

I'm thinking about binary patching executable file to make it look like it requires older version of glibc.

Actually this is the case which is absolutely identical in Windows world.

raven667 — Wed, 25 Jan 2012 17:29:54 +0000

That article is pretty funny, at every point the author has to say "wait, it's actually more complicated than that" and then drop another level down the rabbit hole. It's amazing Windows works as well as it does because what goes on under the hood is just ridiculous.

Actually this is the case which is absolutely identical in Windows world.

khim — Wed, 25 Jan 2012 17:21:52 +0000

Well, I've just built an executable on recent Ubuntu. And now I want to run it on RHEL 6.2. Guess what happens?

Absolutely the same thing as in Windows world. Hint: recent versions of MVCR*.dll just flat out refuse to work if you don't install them properly. To make portable application you need jump trough hoops. On Linux it means using older version of GLibC, on Windows you need specially crafted project. And you should not use features not available in older version of your OS (or you can use them conditionally when they are available). This is not such a big deal. Lack of forward compatibility is [relatively] easy to handle, but the fact that Linux constantly breaks backward compatibility is complete disaster.

Yesterday...

Cyberax — Wed, 25 Jan 2012 17:14:22 +0000

Well, I've just built an executable on recent Ubuntu. And now I want to run it on RHEL 6.2. Guess what happens?

Static linking of glibc would be nice if it were supported.

Yesterday...

nybble41 — Wed, 25 Jan 2012 17:11:12 +0000

I'll grant that glibc is an exception. Among other things, it's closely tied into the dynamic loader (ld-linux), the path to which is hard-coded into every executable, so setting LD_LIBRARY_PATH isn't sufficient here. The glibc team recommends a chroot environment, though you might be able to get away with specifying the proper loader explicitly. (It can be run as a normal program, with the dynamic executable path as an argument.)

Out of curiosity, why would you *want* to bundle glibc? They actually do a very good job of ensuring backward-compatibility, versioning the symbols where necessary. The fact that many Windows developers seem to feel it necessary to bundle their version of the C runtime with their application feels more like a handicap than a feature by comparison; on UNIX, the C runtime is traditionally considered a system component, not part of the application. If you're going so far as to bundle glibc, I don't see why you wouldn't just statically link the entire executable. That would certainly be much simpler from a distribution point-of-view.