Re: Re: [Zynot-pkgmgr] Repoteus: Zynot Tree Vision

--===============81919378294100653==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="=-zVLPEkzHlDLnXNwi81vi"


--=-zVLPEkzHlDLnXNwi81vi
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2003-07-14 at 19:13, Will Reid wrote:
> On Monday 14 July 2003 15:37, Mark Guertin wrote:
> > On 7/14/03 4:24 PM, "jesse" <[email protected]> wrote:
> > > If they are isgned by our devs who are on your keyring .. then you
> > > should be able to trust. Esp if it's got 2 or more valid sigs.
> > >
> > > Over any  distrib medium a package that had this requirement would be
> > > considered pristine. You would be able to check those sigs agains
> > > keyservers as well as your local copy of the pubkeys.you could trust
> > > that package if all those check were ok.
> > >
> > > If random joe-schmo  builds a binary and pops it on p2portage signed.=
 It
> > > doesnt give it any more credability in the eyes of porteous. ( not pa=
rt
> > > of or keysystem ).
> >
> > That given I would still never allow this on my system, signed or not
> > signed.  Also this would divert a lot of dev attention from working on =
the
> > distro proper.. Instead they would be building (and yielding TONS of em=
ails
> > from users if they signed the builds as good and they are not).  I know
> > this from experience doing this stuff with Gentoo.
> >
> > IMO this is something we should still avoid for now.
> >
> > If you haven't noticed I have problems with the whole concept of p2p
> > distribution of anything for an operating system, and I am not alone on
> > this stuff.
> >
> > If p2p ever gets implemented I for one will want HUGE guarantees that t=
he
> > option not only be able to be disabled, but that there also be a versio=
n of
> > the pkgmgr that this option literally does not even exist in.  One user
> > turning on something like this unchecked can have massive repercussions=
 on
> > a large LAN.  It goes against the grain in corporate environment in a v=
ery
> > big way here.
> >
> > Potentially this could make M$ email virii look tame from a security
> > standpoint...if one signed pkg gets compromised and distributed as trus=
ted
> > (signed) into a p2p system.  With p2p you have zero control after it ha=
s
> > gotten into nodes, that compromised build could live forever, revoking =
or
> > no.  At least on (semi) controlled mirrors we can properly revoke it if=
 the
> > need should ever arise.
> >
> > Mark
> >
> >
> > _______________________________________________
> > Zynaut mailing list
> > [email protected]
> > http://lists.zynot.org/mailman/listinfo/zynaut
>=20
> 	Just gonna add my thoughts.  I have a feeling that p2p implementation wi=
ll be=20
> so much extra design, coding, and implementation getting it to work that =
it=20
> should be put off for now.  And I agree there should be an option to disa=
ble=20
> the filesharing when p2p source file sharing is implemented.  Being on di=
alup=20
> I suffer whenever I have to upload a file.  Normally I end up lagging out=
,=20
> the file stalls, and all the time was wasted anyway.  My internet connect=
ion=20
> would be virtually unusable if multiple cable users tried to download X o=
r=20
> KDE from me (even in part).  And they'd likely never know, and I wouldn't=
=20
> have fun trying to figure out why google's front page takes 5 minutes to=20
> load. =20
>=20
> 	I would REALLY like to see binary packages available.  Not for every pac=
kage=20
> in the tree, but the base install (X and a few common WM also) at the lea=
st. =20
> Also it would be nice to have different CFLAGS for them.  Again, not=20
> everything.  i586, Pentium2, and Athlon for x86 would make many people ha=
ppy. =20
> You can always run `nice -n 19 emerge -e world` in a screen or VC once yo=
u're=20
> in X and going about your thing and want "better" CFLAGS and never notice=
=20
> your box was working.  A 6 hour base install on the average speed box is=20
> enough to scare a lot of users away when they find out that's without Xfr=
ee. =20
> Basically the run down of how I think things will/should/could look soon:
> Stage1 - Build it all yourself.
> Stage2 - You have a compiler and a few libraries.
> Stage3 - Working Non-X box (sans kernel)
> Stage4 - Working X box with your choice of WM available as a seperate bin=
ary=20
> to keep the stage tarball size down (also no precompiled kernel)
> Stage5 - Quick Install, bloated, bubblie crap that people new to the dist=
ro=20
> want to give it a quick try.  X, KDE/Gnome, desktop apps a plenty, prebui=
lt=20
> modularized kernel.  Basically whatever the devs can stuff in a 640/700MB=
=20
> ISO. =20
>=20
> 	Yes, the "stage5" I recommend will be very large and use up much bandwid=
th,=20
> but most users will likely avoid ever downloading it.  Only those that ne=
ed=20
> it to just get their box up and running quickly to try out Zynot (or what=
ever=20
> it will be called then) will pick this install method.  We could even loo=
k at=20
> something like jidgo (which debian uses to make CD-r and DVD-r ISOs) to=20
> create the "stage5" installer CDs on the fly from multiple source servers=
. =20
> The problem with jidgo is its complicated usage.  Ok  I'm starting to ran=
t,=20
> so I'll stop on this unless anyone requests more out of me. :)
>=20
> 	This is probably getting way off-topic, but the last thing I'd like to=20
> suggest is a GUI installer.  If anyone can point me to the right place to=
=20
> read up and learn how to code widgets I'd like to get involved in a gtk2=20
> installer project that will make people think they're installing somethin=
g=20
> officially better than RedHat because it's prettier and even easier ;) to=
=20
> install.
>=20
> --Will (Sif/SanityInFlux - if you didn't know)
>=20
dialog and sh make for really quick gui installers ( think redhat 5.2
6.2 )=20

Im doing a dialog installer for a contract right now. Its really pretty
simple to do once the helper functions are written, but unfortunatly it
wont be OSS..=20

Gtk/kde installers IMHO are just eyecandy.. :P
=20
> _______________________________________________
> Zynaut mailing list
> [email protected]
> http://lists.zynot.org/mailman/listinfo/zynaut

--=-zVLPEkzHlDLnXNwi81vi
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQA/E43c4rKvBkfUvb0RAgrwAJwLdEnAt55g9LS3X1CLIqjiwUj/ewCcD1F2
PAV9XnRe/l/OSQ4a2FD9A4k=
=j4sl
-----END PGP SIGNATURE-----

--=-zVLPEkzHlDLnXNwi81vi--


--===============81919378294100653==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Zynaut mailing list
[email protected]
http://lists.zynot.org/mailman/listinfo/zynaut

--===============81919378294100653==--