[plug] Linux Desktop Market
John Knight
anarchist_tomato at hotmail.com
Thu Oct 27 18:40:06 WST 2005
>On Wednesday 26 October 2005 14:47, John Knight wrote:
> > But as OSS, we have security through transparency, so we
> > wouldn't have problems to the same extent.
>
>Mister Anarchist, you just contradicted yourself. You say that security
>through transparency works in the same post that you advocate
>downloading and installing random (ie opaque) _binaries_.
>
>Linux users in general (I'd even go so far as to claim "admins in
>general") would no more scrutinise the source code than MS-Windows
>users would, and if you download a binary you have no guarantee
>whatsoever that it was built from the source in the next archive
>across.
No argument there I 'spose, touche. But what's the difference between
downloading a deb or rpm from a site (not a repository), and an autopackage?
If we get up in arms about the security risk of autopackages, why not get up
in arms about these?
>That's why software branding is so highly regarded in the Windows world.
>Everyone packages their own stuff, and there is no serious way of
>verifying an .msi file or a random .exe; TuCows and its peers are a
>kind of compensation for that; it only takes a few hundred people
>getting burned, and TuCows will tear the download off its list.
And why not have autopackages on tucows?
>What I would like to see is a common _source_ package agreed upon, that
>RPMs, DEBs, Slack-TGZs etc could be quickly and automatically built
>from. Then you would get TuCows-like sites arising that build and offer
>the packages that the distros themselves miss. That would mostly keep
>both sides of this argument happy.
>
>To do that, some standardisation of package naming conventions needs to
>happen between distros, and they need to agree upon a common dependency
>format and stick to the LSB (FHS, at least) somewhat better than they
>typically are.
>
>Cheers; Leon
Seems like a re-invention of the wheel, and needlessly complicated when you
could just have the one package, instead of all its children.
More information about the plug
mailing list