Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs

[RahulSundaram]

Well, that then settles my question: obviously the people at BlackBerry are geniuses.
Not only have they a working installer for a whole set of programs, they even managed without static linking.

Unfortunately it is likely that they'll guard this knowledge fiercly as it is apparently nowhere else to be found and gives them great advantage over all other ISVs

Cheers,
_

As I tried to hint earlier with my example, blackberry's requirements and resources are not the same as other small ISV's and the typical solution from ISV's is to bundled everything they need within their "installers". Hardly something worth advocating for.

[anda_skoa]

As I tried to hint earlier with my example, blackberry's requirements and resources are not the same as other small ISV's and the typical solution from ISV's is to bundled everything they need within their "installers". Hardly something worth advocating for.

That's how it works on other platforms and I don't have to read again and again how bad that is for ISVs.

Sure, integrating into a central distribution mechanism like an app store has some advantages, but it also requires more work.
Hence not all software available in app stores on platforms that don't require going through the app store, e.g. Windows.

I don't understand why ISVs seem to have some kind of selective amnesia that makes them forget all their knowledge and experience about installers if the platform at hand is Linux. It is not one of the platforms that require an app store, is it?

Don't get me wrong, I find traditional installers that bundle apps and their dependencies also less the ideal, but I fail to see what gain ISVs think they get by totally ignoring that option.

There are even installer builders that can create Windows and Linux (and probably also OS X) installers from the same input file, for $deity's sake!

Cheers,
_

[RahulSundaram]

Don't get me wrong, I find traditional installers that bundle apps and their dependencies also less the ideal, but I fail to see what gain ISVs think they get by totally ignoring that option.

There are even installer builders that can create Windows and Linux (and probably also OS X) installers from the same input file, for $deity's sake!

Cheers,
_

They don't ignore it. It just doesn't work as well on Linux because everything other than kernel and maybe glibc has to be bundled in. In Windows or Mac, they have more well defined interfaces and runtimes. The so called cross platform installers make it even more harder when you want to say fix heartbleed for your customers. The first step in solving such problems is acknowledging that they exist.

[ryao]

Not really. It is being proposed by the same set of people and they would notice that kind of overlap if it exists Sandboxing doesn't solve the problem since I would be forced to bundle a private copy of the library I need and even if sandboxing is fool proof (and history of such technologies have shown that it isn't), it only solves the security problem and doesn't solve the waste of resources (including but not limited to memory and disk space) problem. In other words, this is sweeping the problem under the rug and pretending that it doesn't exist as opposed to finding a systematic solution.

Would you define the problem? If the problem involves bundled libraries, I believe that proper use of dpkg solved that problem on Linux distributions about 20 years ago. The solution has since been reinvented by every package manager that has been made since then. This all predates the day that I receved my first computer, so I am not that familiar with the specifics of why RedHat went with its own solution. As someone outside of RedHat, it seems that Redhat wants to reinvent this again without a clear problem statement. Lennart was quite clear that CoreOS already does all of this for servers, so it would seem reasonable to extend CoreOS for desktop users. The package manager used in CoreOS is Gentoo Portage, which is already used on desktop systems with relatively good success. Alternatively, there is always the ports concept from the BSD forks where you have a userland package manager manage /usr/local.

[RahulSundaram]

Would you define the problem? If the problem involves bundled libraries, I believe that proper use of dpkg solved that problem on Linux distributions about 20 years ago. .

You believe wrong since we are talking about ISV's. Distribution specific tools solve some portions of the problem for one distribution. From an ISV perspective, they cannot force all customers to run one specific distribution. Typically you have some CentOS, some Debian, Some RHEL, Ubuntu and perhaps even SUSE and Arch thrown into the mix. OBS has been used recently in some places to solve the delivery piece of it but it doesn't solve the exploding test matrix with distributions using slightly different libraries which cause enough subtle bugs that you want to bundle everything again and of course when you bundle everything, you want to make sure security fixes etc can be handled for your customers which means you are partially managing the OS stack instead of the distributions handling it for you. The solution for some ISV's is to just rely on or or two vendors (say Red Hat and SUSE) and ignore everybody else as unsupported. That works well for long term slow moving commercial vendors like say Oracle or Blackberry. It doesn't work well when you are using say Node.js and Mongodb and cannot rely on enterprise distributions as much to handle the fast moving stack for you.

[anda_skoa]

They don't ignore it.

It certainly looks that way

In Windows or Mac, they have more well defined interfaces and runtimes.

Sure, if you are using the "system toolkit of the day", but if you are using something like Qt, which is very likely if you consider Linux additonally to Windows for example, then you'll already have to ship everything.

The so called cross platform installers make it even more harder when you want to say fix heartbleed for your customers.

Because you have to release a new version of the software? At least on Windows I see that for most programs, since the platform does not provide any update mechanism for third party vendors.

Sure it is not as nice as having updates triggered and managed centrally, but basically only Linux distributions do that, even the heralded app stores require an update release.

The first step in solving such problems is acknowledging that they exist.

Sure, but ignoring existing solutions one has great experience with, as ISVs have with installers, is not helping either.

Cheers,
_

[RahulSundaram]

Sure, but ignoring existing solutions one has great experience with, as ISVs have with installers, is not helping either.

Cheers,
_

"Great experience"? That is silly. If the solutions you suggest work so well for them, they will already be using it. It is not like they haven't tried it out already. The only solution that has any traction for hosted model is Docker but the management tools around it are only barely maturing. Not everyone has the resources of Google or Blackberry.

[sdack]

All this fuss makes me wish someone would invent a new interpreter language. A language capable of executing perl, python, java, bash, gawk and lua scripts, is on average 95% compatible to all of them and optimizes itself with the help of LLVM's jit compiler, but also just as lua is missing the "continue" statement, and all for the sole purpose of replacing /bin/sh. Well, it still would be better than the idea of replacing all the proteins in your food with genetically enhanced soybeans, but presenting it as a vision also makes it feel like a threat, which is being presented with a smile.

[gens]

"Great experience"? That is silly. If the solutions you suggest work so well for them, they will already be using it. It is not like they haven't tried it out already.

sorry if i missed the topic, too much to read

check out the savagexr's installer, loki installer (UT2k4) and ati binary installer
also check out Ryan Gordon porting games to linux speech where he clearly notes how "targeting multiple distros" is not really a problem and has never been
(without the LSB FSH standard it would be a small problem, but those days are past)

proprietary programs usually go with a short list of dependencies for a user to install, clearly listed when you dl it
that list of dependencies can also be sent to the package manager to do automatically (ofc you would need to input your password)
so using the loki installer or making a, similar, simple one and releasing it under idk the MIT license and problem solved

and no, it is not better on windows
remember 98-xp days when games were asking you if you want to install directx and such ?
was that a problem ?

problem is it is new for companies and they don't have people that know linux good enough to make accurate assumptions
so it's just an imaginary problem; good Ryan is here to let the companies know

[RahulSundaram]

problem is it is new for companies and they don't have people that know linux good enough to make accurate assumptions
so it's just an imaginary problem; good Ryan is here to let the companies know

"Imaginary problem"? You might want to let Linus know that he is just ignorant and doesn't know Linux enough when he mentions that his dive log program doesn't have a Linux executable because it is a hard problem and he doesn't want to deal with it but he is willing to make a Windows and Mac OS X executable.