Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs

[petah]

sand vs lube

Note that in result this allows installing not only multiple end-user applications into the same btrfs volume, but also multiple operating systems, multiple system instances

quotes like this are unhelpful; whatever effort I was making to form a reasonable opinion got shattered right there. That's a usecase of someone looking for trouble; not a problem worth solving. Maybe Lennart just got excited by the possibilities but it makes for a terrible pitch. Locking in on Btrfs early on is also distracting since it's really only about the concept of fs remaps.

"What the user wants" is pretty airy since Windows/OSX have their fair share of problems but then he talks about helping software vendors with runtime dependencies - which is it? Maybe there's a great project there to solve real problems but there's too much noise to see it. FOCUS please!

-- p

[RahulSundaram]

Why did it take so much effort to fix the hole? Was it not as simple as recompiling the distribution and to release the affected packages after the bug got fixed?

Look it up. It is well documented. The packaging guidelines from distributions that advise against static linking and bundling was born from such experiences. Note that this policy usually has several exceptions so the idea of striking a reasonable balance is already implemented. However shared libraries aren't the problem. The lack of standard runtimes across distributions is. Several distributions also patch and introduce their own library versioning downstream

[sdack]

The emphasis on shared libraries were brought on by the many man months it took to fix a security issue in zlib when static or bundling were more common.

That was clearly not the brightest of solutions.

Why did it take so much effort to fix the hole? Was it not as simple as recompiling the distribution and to release the affected packages after the bug got fixed?

[RahulSundaram]

Somebody claimed that there was not distribution neutral way to distribute software on Linux other than static linking, which is exactly the lame excuse I referred to.

Cheers,
_

I said, there is no good way to do it. I stand by that claim.

[anda_skoa]

So you are fighting against a claim that noone made.

Somebody claimed that there was not distribution neutral way to distribute software on Linux other than static linking, which is exactly the lame excuse I referred to.

Cheers,
_

[RahulSundaram]

I am just saying that I am extremely annoyed by the false claim that one absolutely has to do package manager packages to distribute software to Linux customers.
_

So you are fighting against a claim that noone made.

[RahulSundaram]

By making every possible piece of software a shared library have distros brought it onto themselves. This was clearly a bad idea and now they are drowning in dependencies. Why did nobody ever seek a reasonable balance between shared and static linking? Was everyone mesmerised by the thought of creating the largest pile of dependencies ever possible? I guess so ...

The emphasis on shared libraries were brought on by the many man months it took to fix a security issue in zlib when static or bundling were more common.

[anda_skoa]

There are dozens of ISV's who don't provide installers and who have plenty of customers. Again, this is a basic denial of the fact that there are real problems and you have provided no good solutions. Hint: Bundling is not a good solution for everyone.

I think I even wrote that earlier, but obviously I do not consider installers a good solution or one that cannot be aproved upon.

I am just saying that I am extremely annoyed by the false claim that one absolutely has to do package manager packages to distribute software to Linux customers.
If an ISV likes installers, e.g. because they use them on other platforms (quite likely on Windows for example), then they can very well use the same technique on Linux also.

Whining about Linux packages is like whining that app stores require different packaging.
Yes they do, but unlike some locked down mobile platforms, the package mechanism is just one of many options.

If an ISV has experience with installers, then bringing up packaging as a deterrent for Linux support is an excuse, a very lame one, and not a valid reason.

I will challenge that excuse whenever I encounter it, regardless of who perpetrates it

Cheers,
_

[sdack]

There are dozens of ISV's who don't provide installers and who have plenty of customers. Again, this is a basic denial of the fact that there are real problems and you have provided no good solutions. Hint: Bundling is not a good solution for everyone.

The problem has been in most parts created by the distributions themselves. Just the other day did I count the number of shared libraries to a program, which opens a window with a single "Hello World" GTK+ button in it. It was 68 libraries.

And in the other thread (on systemd) did I already explain to someone where /sbin and /usr/sbin originally came from. These used to hold static binaries, until distros started with the fixed idea of making absolutely everything dynamic apparently. The static versions of administrative commands were there intentionally and to be used in cases where libraries were broken or /lib could not be mounted. It even improves security, when not every command requires a shared libc. If you look at Windows might you know that DLLs are commonly used by malware to hook into software.

By making every possible piece of software a shared library have distros brought it onto themselves. This was clearly a bad idea and now they are drowning in dependencies. Why did nobody ever seek a reasonable balance between shared and static linking? Was everyone mesmerised by the thought of creating the largest pile of dependencies ever possible? I guess so ...

[RahulSundaram]

Those who want to have customers on the Linux platform do that indeed.

But there a lots of other who whine about packaging in order to have an excuse for not meeting their customers' demands.
_

There are dozens of ISV's who don't provide installers and who have plenty of customers. Again, this is a basic denial of the fact that there are real problems and you have provided no good solutions. Hint: Bundling is not a good solution for everyone.