Re: CD.

[Michael Schmitz <SCHMITZ@LCBVAX.CCHEM.BERKELEY.EDU>]

Hi,

> Pish. Use the same boot disks as for Atari, and boot with a fat kernel without
> modules. The kernel that's installed to /boot is irrelevant if you use 
>
>And with which floppy should I read in those disks? There is no way to 
>read 1.4 MB disks with an dd floppy drive. Also the fd0 can't read 720 
>K disks it seems but only 880 K disks. It's not that simple as just
>takeing some dummy disks. On the CD the images could be used, but
>thats not the right thing to do. 

Did you think I was suggesting to actually use floppies on Amiga?? Lots of
people have complained about floppies on Amigas, being unreliable or in crazy 
formats etc. 
What I meant is using the floppy _images_. That's definitely the right
thing to do, not only from CD. The kernel has loopback support, why not
mount floppy images loopback and avoid duplicating the effort of packaging
install files?? The dinstall script does right that, if you specify 'install
from disk'. That's what I did, many times now. 
And getting 2x 1.4 MB to the machine can't be more difficult than getting base
there.
 
>> >Also only one Network device is suported and that only during installtation.
>> 
>> ???? What the hell do you need a network device for, during installation? 
>> I might have missed the point, but 'install from FTP/NFS' wasn't among the 
>> choices ?? The network config is only done after installing the base system. 
>
>The slip and ppp isn't configured, which is easy to fix, yes. But
>thats not the point. It's not easy to configure them for a newbie,

Even a newbie should be able to read three config files and change the info
that's clearly marked for change. If /dev/modem is set right, it's only one
file IIRC.

>also its not easy to configure further network devices, in case one has 
>more than one, or to change the configuration of the network setup.

System administration in special cases isn't easy anyway. That's the price for
running Linux (or any Unix). People should be made aware of a few differences 
between Linux and their favourite native desktop OS, one of which is that
not properly administrating Linux is dangerous, at best.

>> I don't see the point. Ethernet is configured OK (all it takes for that
>> is ifconfig, and that's done by the ramdisk). And I think configuring SLIP or
>> PPP doesn't belong in the install disk. YMMV, as usual, but if you're producing 
>> a CD, why provide for NFS installs??
>
>Base could be installed via nfs or ftp. Think about a computer pool
>with a server containing all the files. After installing the server
>you create a boot disk and put that into the clients. They boot up,
>install and configure themself completley without any further
>questions. That would be the best and easiest way. We won't go that
>far, but we are taking the first steps in that direction.

Sure, lots of things _could_ be done by NFS or such. But if you're not
going all the way, why bother? And I'm questioning the feasibility of 
'same install for all machines'. No questions asked?? How do you assigning
IP addresses?? Hostnames?? 

>> Thanks for pointing that out. To me, it seems what you did is build a
>> modularized kernel, added network config stuff to the ramdisk and call that
>> a vastly improved installation tool. I'm still wondering why none of this 
>> was fed back into Debian/68k?? (Actually, I'm only half wondering, but why 
>
>Nothing was fed back, because nothing is finished yet. The network
>script is pretty (98%) finished so that could be made public soon. I
>would like to improove Debian/68k (and other archs), but Eagle has to
>get a Distribution out. We have to make decisions and get stuff done
>without waiting for Debian to solve Problems or to adapt ideas. If

I wasn't asking you to wait for Debian to adapt your ideas. I was asking 
for information what you did add. We could have avoided a lot of that
discussion and misunderstandings if Eagle had been present in the discussion
from the beginning, instead of handing out information only after excessive
bugging on the list.

>Debian takes the ideas up or makes something better out of it,
>fine. If Debian/m68k were stable the Eagle linux would be Debian
>Linux. Also several People have discouraged firms to do an unstable
>Debian distribution so Eagle wont do that eigther. 

But you're doing exactly that, in fact. You might add the installer, you might
add some kind of warranty resulting from your tests while preparing the 
dostribution, but it still is the set of unstable Debian packages that we asked
you not to release as Debian distribution. All I can see is that the label
will be different.

>> The only trouble I saw lately (Dec. 20 packages) was missing net support for
>> dpkg-ftp. If you solved that problem, it would only be fair to share the 
>> solution. I've not had problems with dselect or dpkg at all, except for
>> the stupid Mac HFS stuff and that was solved by running dpkg on each
>> binary-m68k subdirectory in turn, manually. Precisely what dselect does to
>> install, on all subdirs at once. No problem whatsoever.
>> And slattach is broken, patch sent to the maintainer - did you fix slattach?? 
>What about dpkg downgrading a package when an newer version is
>unpacked but not configured? What about dselect not complaining about
>nonexisting files which are needed for dependencies. What about the
>speed of dselect or the inability to search or filter certain infos.

As I said: never encountered these problems. Might have been to bogus
dependency declarations (=broken package: unstable, don't use, yada yada) or
a broken Packages.gz (again: unstable, don't use, yada yada) but fact is I
installed the 'snapshot' from Dec. 20 (messing up a few file names due to
using HFS, never mind) and it just didn't happen.

Blaming it all on dselect is a cheap shot (well, I'm doing that myself half of
the time). But I used dselect all the way until I had to run the pesky 
dpkg -iGROEB manually spread over the subdirs (and I used the precise command 
dselect tried to use). As soon as I've fixed dpkg (new build problem, James)
I'll repeat the whole thing to make sure it wasn't doing the subdirs separately
that made it work.

>> Or do you ship a defective product?
>
>As soon as the fix is out we will use it (probably already is out). We 

I don't know if it's already fixed in the official source packages. I sent
the diff around xmas and it make take awhile.

>Thats why I wrote 'depending on the parts of source we used'. We used
>a gpl source in one case, so that source will be gpl. Other things we
>wrote completly ourself, so that could come under Berkley. The
>specific Licenz isn't decided yet, but I'm certain that Debian can
>learn from it. We don't wan't to make life difficult for Debian or
>Linux, that just doesn't make sense. 

It wouldn't make sense, no. But I've seen a lot of things happen that didn't
make any sense to me. And you're still being vague - we'll wait until your
distrubution is released before we judge about 'sense' I guess. 

>> And I'm not raging against the fact that someone makes Debian/68k (that's 
>> what it is, call it any way you like) available on CD before the fact, though 
>> I still think that's not a bright idea. You will have ironed out install and 
>> upgrade glitches, and users will be happy, and that's a Good Thing. 
>> The way this whole business was a one-way road is what's making me mad.
>
>The best think would be to have an Official Debian m68k Linux
>distribution sold by Eagle, but thats the future. At the moment we
>iron out the glitches and we haven't released anything yet. The main
>reason is that it's not ready and foolprove. Lets wait until we think
>the stuff is ready for release and then start complaining. Maybe the
>complete source will be gpl, maybe not. It's not my point ot decide
>that and it's in no way decided yet. Everything I wrote so far
>contains a gpl copyright, and thats probably what it will have at the
>end, but don't sue me for it.

I won't sue anybody - don't worry about _that_. I'm complaining about the way
business deals with Debian or free software in general. You just confirmed my
opinion on that point. Debating who should do the official Debian release
in future is moot, and I still hold the point that your distribution won't be 
too much different than the unstable Debian stuff, to the best of my knowledge.

	Michael


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-68k-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .