Re: [Cooker] Installer suggestion

[Pixel]

David Walser <[EMAIL PROTECTED]> writes:

> Given that, it seems to me the best thing for services
> we don't want enabled by default on installation, is
> to just have them not run _post_service in the SPEC
> file.  They'll get chkconfig --add run when they're
> enabled, and they don't lose the list of runlevels
> they should be run in.

agreed (i don't see any pb doing so, except having rpmlint whining,
but that's ok :)

for example, packages that don't a working default config file should
do this..

Re: [Cooker] Installer suggestion

[David Walser]

--- Pixel <[EMAIL PROTECTED]> wrote:
> David Walser <[EMAIL PROTECTED]> writes:
> 
> > > maybe we could disable nfs by default, agreed.
> > > 
> > > for the others, i don't know :-/
> > > if you are right, I do agree they should not be
> > > running by default,
> > > and it's a bug. And you should report to the
> > > maintainers.
> > 
> > So the package decides not drakx?  What do the
> > packagers have to do to change it?
> 
> % grep chkconfig /etc/init.d/*
> ...
> /etc/init.d/portmap:# chkconfig: 345 11 89
> ...
> /etc/init.d/ypserv:# chkconfig: - 16 84
> ...
> 
> - portmap will run by default at runlevels 3, 4 and
> 5
> - ypserv will not run by default (notice the "-")

I was just looking into this again, and I'm not sure I
see why that's the best way to not have something
start by default when it's installed, as opposed to
just having the SPEC file not run _post_service.

By changing the first part of the chkconfig line to -,
you lose that information: what runlevels should the
service be started in if it is used.

All _post_service does anyway is run chkconfig --add,
but when you enable a service in drakxservices, it
runs that anyway.  If the init script has the -, it'll
just enable the service for runlevels 3 and 5.

Given that, it seems to me the best thing for services
we don't want enabled by default on installation, is
to just have them not run _post_service in the SPEC
file.  They'll get chkconfig --add run when they're
enabled, and they don't lose the list of runlevels
they should be run in.

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: [Cooker] Installer suggestion

[David Walser]

--- Pixel <[EMAIL PROTECTED]> wrote:
> David Walser <[EMAIL PROTECTED]> writes:
> 
> [...]
> 
> > > % grep chkconfig /etc/init.d/*
> > > ...
> > > /etc/init.d/portmap:# chkconfig: 345 11 89
> > > ...
> > > /etc/init.d/ypserv:# chkconfig: - 16 84
> > > ...
> > > 
> > > - portmap will run by default at runlevels 3, 4
> and
> > > 5
> > > - ypserv will not run by default (notice the
> "-")
> > 
> > And that won't break chkconfig?  If you in the
> future
> > chkconfig --add whatever by hand (or
> drakxservices),
> > how will it know what runlevels to add it to?
> 
> redhat has "-" for most of its services, and in that
> case they use
> "chkconfig --level 35 the_service"

So I guess it doesn't break drakxservices.

> > Is this really the correct way to not have a
> service
> > activated automatically after installation? 
> 
> it is!

Thank you Pixel!

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Cooker] Installer suggestion

[Pixel]

David Walser <[EMAIL PROTECTED]> writes:

[...]

> > % grep chkconfig /etc/init.d/*
> > ...
> > /etc/init.d/portmap:# chkconfig: 345 11 89
> > ...
> > /etc/init.d/ypserv:# chkconfig: - 16 84
> > ...
> > 
> > - portmap will run by default at runlevels 3, 4 and
> > 5
> > - ypserv will not run by default (notice the "-")
> 
> And that won't break chkconfig?  If you in the future
> chkconfig --add whatever by hand (or drakxservices),
> how will it know what runlevels to add it to?

redhat has "-" for most of its services, and in that case they use
"chkconfig --level 35 the_service"

> 
> Is this really the correct way to not have a service
> activated automatically after installation? 

it is!

Re: [Cooker] Installer suggestion

[David Walser]

--- Pixel <[EMAIL PROTECTED]> wrote:
> David Walser <[EMAIL PROTECTED]> writes:
> 
> > > maybe we could disable nfs by default, agreed.
> > > 
> > > for the others, i don't know :-/
> > > if you are right, I do agree they should not be
> > > running by default,
> > > and it's a bug. And you should report to the
> > > maintainers.
> > 
> > So the package decides not drakx?  What do the
> > packagers have to do to change it?
> 
> % grep chkconfig /etc/init.d/*
> ...
> /etc/init.d/portmap:# chkconfig: 345 11 89
> ...
> /etc/init.d/ypserv:# chkconfig: - 16 84
> ...
> 
> - portmap will run by default at runlevels 3, 4 and
> 5
> - ypserv will not run by default (notice the "-")

And that won't break chkconfig?  If you in the future
chkconfig --add whatever by hand (or drakxservices),
how will it know what runlevels to add it to?

Is this really the correct way to not have a service
activated automatically after installation?  Or what
what Buchan suggested right, to just not use
%_post_service (remember if the daemon is running it
still has to be restarted on package upgrade)?

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Cooker] Installer suggestion

[Nick Brown]

http://lisa-home.sourceforge.net/src/lisa.mandrake
has init scripts for lisa. This is mandrake specfic (though it was written for 
8.0)
Thre are also init scripts for redhat (7.2, 7.3) and suse (7.1 )listed at
 http://lisa-home.sourceforge.net/download.html

Perhaps Madrake could include this init script (or a updated one) for lisa, so 
that as you said it works on startup. (it did take me a while to figure out 
why konqueror did not work to browser lans and how to fix it)
If mandrake included a init script for this it would make it much easier for 
people.

thanks,
Nick

Gary Greene wrote:

> On Friday 16 August 2002 05:58 pm, David Walser wrote:
>> --- Mark Piper <[EMAIL PROTECTED]> wrote:
>> > And perhaps we should have LISa AT LEAST LISTED in
>> > the services, if not
>> > on by default, so that an inexperienced user will be
>> > able to see
>> > something aside from an error message when clicking
>> > on Konqueror's LAN
>> > browser.
>> >
>> > It has a useful default.  Turn off the port
>> > scanning.  Enable the search
>> > using nmblookup only.  Then you'll see computers
>> > like you would in
>> > Windows.
>>
>> Can you write an init script that would do this?  If
>> so, maybe Laurent would be willing to include it.
> 
> SuSE has an init script for this. If I had my SuSE box here I'd get it to
> you...
> 

-- 
<[EMAIL PROTECTED]> IOS Development, Cisco Systems UK.

Re: [Cooker] Installer suggestion

[Gary Greene]

On Friday 16 August 2002 05:58 pm, David Walser wrote:
> --- Mark Piper <[EMAIL PROTECTED]> wrote:
> > And perhaps we should have LISa AT LEAST LISTED in
> > the services, if not
> > on by default, so that an inexperienced user will be
> > able to see
> > something aside from an error message when clicking
> > on Konqueror's LAN
> > browser.
> >
> > It has a useful default.  Turn off the port
> > scanning.  Enable the search
> > using nmblookup only.  Then you'll see computers
> > like you would in
> > Windows.
>
> Can you write an init script that would do this?  If
> so, maybe Laurent would be willing to include it.

SuSE has an init script for this. If I had my SuSE box here I'd get it to 
you...

-- 
Gary 
 
Sent from seele.gvsu.edu
  6:32pm  up  1:23,  2 users,  load average: 0.64, 0.28, 0.20
 
=
Founder GVLUG.   
Chief Systems Architect, S4, Inc. - OS Department.   
 -==-
Project Lead for the Sentinel Linux OS Project (KOMODO)  
Chairman and Project Lead of the E-media Committee of AltReal.   
PHONE : 331-0542 
EMAIL : [EMAIL PROTECTED]   
[EMAIL PROTECTED] 
[EMAIL PROTECTED] 
 
--changing the code of the Virtual Human Brain FS Driver...  
Mounting /dev/brain0 is still causing problems...
 
Here's the error:
 
#mounting local filesystems[   OK   ]
#Virtual Human Brain Driver v0.0.5 (EXPERIMENTAL) R/W fs module  
#Virtual Nerve Node Driver v0.4.1 (EXPERIMENTAL) R/W FS module   
#Insmod Adaptive Technology Device module..[   OK   ]
#Writing Sync state to Journalled VHBFS[   OK   ]

Kernel Sys Oops.. Flushing registers.. Back-trace follows..  
=

Re: [Cooker] Installer suggestion

[David Walser]

--- Mark Piper <[EMAIL PROTECTED]> wrote:
> And perhaps we should have LISa AT LEAST LISTED in
> the services, if not
> on by default, so that an inexperienced user will be
> able to see
> something aside from an error message when clicking
> on Konqueror's LAN
> browser.
> 
> It has a useful default.  Turn off the port
> scanning.  Enable the search
> using nmblookup only.  Then you'll see computers
> like you would in
> Windows.

Can you write an init script that would do this?  If
so, maybe Laurent would be willing to include it.

__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

Re: [Cooker] Installer suggestion

[Mark Piper]

On Thu, 2002-08-15 at 18:09, Buchan Milne wrote:
> 
> 
> [EMAIL PROTECTED], [EMAIL PROTECTED] wrote:
> >
> >David Walser <[EMAIL PROTECTED]> writes:
> >> > - only services that have a useful default
> >> > configuration are on by
> >> > default
> >>
> >> Wrong, apcupsd, dhcpd, jabber, named, nfs, ntpd, smb,
> >> ypbind, and maybe mysql and ldap (can't remember) are
> >> on by default if you install them, and they need to be
> >> configured before they're useful.
> 
> But what are the chances that you're going to install apcupsd and not use it? And
> ntpd can be configured during install.
> 
> >hum, smb has a useful default configuration, no? (home exported)

And perhaps we should have LISa AT LEAST LISTED in the services, if not
on by default, so that an inexperienced user will be able to see
something aside from an error message when clicking on Konqueror's LAN
browser.

It has a useful default.  Turn off the port scanning.  Enable the search
using nmblookup only.  Then you'll see computers like you would in
Windows.

Re: [Cooker] Installer suggestion

[Pixel]

David Walser <[EMAIL PROTECTED]> writes:

> I thought that field let chkconfig know what runlevels
> to enable the service for with chkconfig service on. 
> How does it know then?

well it's quite ugly but that's redhat you've done it so.

they have decided to put "-" everywhere, and they use 
"chkconfig --level 35 on" to enable a service

Re: [Cooker] Installer suggestion

[David Walser]

--- Pixel <[EMAIL PROTECTED]> wrote:
> David Walser <[EMAIL PROTECTED]> writes:
> 
> > > maybe we could disable nfs by default, agreed.
> > > 
> > > for the others, i don't know :-/
> > > if you are right, I do agree they should not be
> > > running by default,
> > > and it's a bug. And you should report to the
> > > maintainers.
> > 
> > So the package decides not drakx?  What do the
> > packagers have to do to change it?
> 
> % grep chkconfig /etc/init.d/*
> ...
> /etc/init.d/portmap:# chkconfig: 345 11 89
> ...
> /etc/init.d/ypserv:# chkconfig: - 16 84
> ...
> 
> - portmap will run by default at runlevels 3, 4 and
> 5
> - ypserv will not run by default (notice the "-")

I thought that field let chkconfig know what runlevels
to enable the service for with chkconfig service on. 
How does it know then?

__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

Re: [Cooker] Installer suggestion

[Pixel]

David Walser <[EMAIL PROTECTED]> writes:

> > maybe we could disable nfs by default, agreed.
> > 
> > for the others, i don't know :-/
> > if you are right, I do agree they should not be
> > running by default,
> > and it's a bug. And you should report to the
> > maintainers.
> 
> So the package decides not drakx?  What do the
> packagers have to do to change it?

% grep chkconfig /etc/init.d/*
...
/etc/init.d/portmap:# chkconfig: 345 11 89
...
/etc/init.d/ypserv:# chkconfig: - 16 84
...

- portmap will run by default at runlevels 3, 4 and 5
- ypserv will not run by default (notice the "-")

Re: [Cooker] Installer suggestion

[David Walser]

--- Pixel <[EMAIL PROTECTED]> wrote:
> David Walser <[EMAIL PROTECTED]> writes:
> 
> > > - only services that have a useful default
> > > configuration are on by
> > > default
> > 
> > Wrong, apcupsd, dhcpd, jabber, named, nfs, ntpd,
> smb,
> > ypbind, and maybe mysql and ldap (can't remember)
> are
> > on by default if you install them, and they need
> to be
> > configured before they're useful.
> 
> hum, smb has a useful default configuration, no?
> (home exported)

Ok.

> maybe we could disable nfs by default, agreed.
> 
> for the others, i don't know :-/
> if you are right, I do agree they should not be
> running by default,
> and it's a bug. And you should report to the
> maintainers.

So the package decides not drakx?  What do the
packagers have to do to change it?

__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

Re: [Cooker] Installer suggestion

[Pixel]

David Walser <[EMAIL PROTECTED]> writes:

> > - only services that have a useful default
> > configuration are on by
> > default
> 
> Wrong, apcupsd, dhcpd, jabber, named, nfs, ntpd, smb,
> ypbind, and maybe mysql and ldap (can't remember) are
> on by default if you install them, and they need to be
> configured before they're useful.

hum, smb has a useful default configuration, no? (home exported)

maybe we could disable nfs by default, agreed.

for the others, i don't know :-/
if you are right, I do agree they should not be running by default,
and it's a bug. And you should report to the maintainers.

Re: [Cooker] Installer suggestion

[andre]

On Tuesday 13 August 2002 04:04, Austin Acton wrote:
> Thanks for your support.
> You have good ideas, but some of them won't fly.
>
> We NEED rpm to keep things uniform.  Easy to upgrade, easy to replace,
> (not-so)easy to build, and the same for every package.  Seriously.  If
> there is ANYTHING that linux needs to survive it's a bit of
> standardization (even WITHIN each distro).  Having two package systems
> could be a nightmare.
>
> Also, you CAN just download ISO1 and do the rest via ftp/http.  I've
> done it many times.  You can even just download one floppy and install
> everything by ftp!  (Thanks to rpm...)
>
> It would be nice to have a "semi-network" install option on CD1 though.
> You boot CD1, pick some sort of hybrid install with VERY few options and
> menus and such.  This installs basesystem, X, a window manager, and the
> "draks" and lets you select a mirror, and CONFIGURES the mirror in urpmi
> BEFORE rebooting.  Then you reboot and install the rest from you new
> super-speedy Mandrake system.
>
> Great idea.
>
> Austin
>

I think the idea is something like http://www.virtual-linux.org/. Which is 
AFAIK just a standard and not so basic Mandrake installation which is tarred 
up from a harddisk installation and put on a cd and with some foo works. If 
you would untar it on a harddisk and removed the foo you couldn't tell the 
difference between it and a normal way of installing

Re: [Cooker] Installer suggestion (one more)

[Pixel]

[EMAIL PROTECTED] writes:

> Cheers Pixel. Does this mean the screen is gone or do you simply "tick" the
> groups of packages you want to upgrade and if they are installed it adds up
> the upgrade size and compares it to the size available??

it computes the size as done in 8.2, ie it does:
  sum(new_packages) - sum(upgraded_packages)

and compares it to the size available. (which must be what you said,
but i'm not completly sure :)

Re: [Cooker] Installer suggestion (one more)

[newslett]

Cheers Pixel. Does this mean the screen is gone or do you simply "tick" 
the groups of packages you want to upgrade and if they are installed it 
adds up the upgrade size and compares it to the size available??

Hasta~~

Jason

Pixel wrote:
> [EMAIL PROTECTED] writes:
> 
> 
>>And I have one more suggestion. I ran into this while upgrading via CD from
>>9.0 B1 to B2...when doing an "expert upgrade" and it comes to package
>>selection time it gets VERY confusing. If you select all the groups of
>>packages you want to upgrade by ticking next to them (and turn off individual
>>package selection) the installer ADDS the space needed to that for the space
>>needed to upgrade the already installed packages often making the amount
>>calculated more that the partition size.
> 
> 
> bug fixed in cooker
> 

Re: [Cooker] Installer suggestion

[David Walser]

--- Pixel <[EMAIL PROTECTED]> wrote:
> - RedHat has (very) few packages which explain why
> "Install All" is no
> such big deal for them (hell, they don't even have
> "rxvt" anymore!)

Yeah, I noticed that.  RedHat sucks!  No xlockmore
either!

> - only services that have a useful default
> configuration are on by
> default

Wrong, apcupsd, dhcpd, jabber, named, nfs, ntpd, smb,
ypbind, and maybe mysql and ldap (can't remember) are
on by default if you install them, and they need to be
configured before they're useful.

__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

Re: [Cooker] Installer suggestion (one more)

[Pixel]

[EMAIL PROTECTED] writes:

> And I have one more suggestion. I ran into this while upgrading via CD from
> 9.0 B1 to B2...when doing an "expert upgrade" and it comes to package
> selection time it gets VERY confusing. If you select all the groups of
> packages you want to upgrade by ticking next to them (and turn off individual
> package selection) the installer ADDS the space needed to that for the space
> needed to upgrade the already installed packages often making the amount
> calculated more that the partition size.

bug fixed in cooker

Re: [Cooker] Installer suggestion

[Pixel]

Austin Acton <[EMAIL PROTECTED]> writes:

> I only have one request to add to v9.0 in the installer. I want an
> "Install All" button - ala Redhat. Disks are cheap. The time required to
> get the system fully operational isn't. Having an install all capability
> would be a real productivity enhancer for one-off configurations.

- installation time is not linear with the size to install. It grows
slower with big installs.

- moreover many packages are dangerous, doing various things you would
not want.

- if you really want a "Install All", you can have it quite easily
after install.

- RedHat has (very) few packages which explain why "Install All" is no
such big deal for them (hell, they don't even have "rxvt" anymore!)

> It would be even nicer if all extra services beyond those required to
> normally operate the system are OFF by default when installed. That way,
> you don't soak up memory and add more security holes. (At least until
> the software is configured

- we've trolling on the choice to have services on by default. Cf
cooker archives

- only services that have a useful default configuration are on by
default

Re: [Cooker] Installer suggestion (and a modest proposal about that)

[allen]

Quick additional thought...

Maybe now IS a good time to bring this up...

DVD...

That would give enough room to have one of more base images, kernel selection,
plus everything that needs installing while you're already up and running...

Don't forget though some HDD needs available for run-time so a minimal base
must partition, fmt, and install some basic goodies so the running image has
a place for things to write.

Hmn...

Double hmn...

-AEF


On Monday 12 August 2002 11:45 pm, allen wrote:
> On Monday 12 August 2002 11:15 pm, Leon Brooks wrote:
>
>  minimal install cd1 with base file system that has rpm database of
> what is "rpm -ivh'd in advance into the base file system so it is rpm
> -Uvh-able"...

Re: [Cooker] Installer suggestion (and a modest proposal about that)

[allen]

On Monday 12 August 2002 11:15 pm, Leon Brooks wrote:

 minimal install cd1 with base file system that has rpm database of 
what is "rpm -ivh'd in advance into the base file system so it is rpm 
-Uvh-able"...

> If I did it that way (or the following way), I'd install a minimal amount
> of RPM information on/from the CD and nice -19 rebuild the indexes and
> stuff after the install.

rpm verify perhaps. The base file system should be "binary" diff match with
what is on the cd.  Either it worked or it didn't.  There should be no rebuild
stuff.  

Granted, some things would HAVE to be put on via RPM, but not the whole
dang thing that is common everywhere, and only where differences warrant... 
which X, which video, scsi, no scsi, which additional kernel, etc.,

Extreme difference can happen via rpm --erase... ;)  Easier to destroy than
to create...

 nice'd rpm install of everything else in the background

Hmn...

> Maybe it also caches reads from the CD onto the HDD so that as you pull
> your most-used stuff off the CD in the course of actually using it, it
> makes it to the HDD and doesn't need re-reading next time.

Not enough detail to know "why" exactly...   kinda sounds a little like 
sorcerer...  which I enjoy using, but has its own set of problems...
Not that it is a bad idea...  It's not what you do... but how you do it...

> Knoppix is already useful for offices wherein the entire place has been
> trashed with a virus. If Mandrake could install this way, you could walk in
> with a Mandrake CD and have people up and running within minutes, and
> permanently Mandrake'd within the hour.

Market study.  How likely, how much market share will this gain vs. will
it loose any ?  What is the cost justification ?  
"What cost, it is open source !" ?

> This could be done as a separate project to the `standard' Mandrake CD
> sets, released a month or two after 9.0, and take the world by storm.

What exactly ?  The idea about fixing up a whole virus nailed network ?  Or
the "distribution server" ?

> Additional wishlist items:
>
>  * Ability to configure a single workstation and use its RPM selection
>for all following.

There is supposed to be a create a floppy thing. I think I tried it before
and I think it worked.  Floppy has the package selection so when you
boot up another install cd on another machine, put the floppy in, you
just walk away and come back later...  ?

You mean this, but from sort of "network registry" / "install/update server" ?

>Imagery: power up virussed Windows box. 30 seconds later it is a
>working Mandrake machine. Walk to next machine, power it up. By the
>time you've powered up the 20th machine, the first is a fully
>installed standalone workstation.

So earlier you meant actually boot and actually RUN from CD until the
HDD is complete... ?   Heh...  are you a systems/software architect too ?

We're on the save wamelength methinks...

There would need to be either a selection mechanism what to boot
to support what wildly different hardware, or a few different CD1 
images...

> How say you? The perfect time to bring this up? 

I don't know when is a good time to bring up stuff like this...  Better to do 
it and beg forgiveness... I hope...

-AEF

Re: [Cooker] Installer suggestion (and a modest proposal about that)

[Leon Brooks]

On Tue, 13 Aug 2002 11:45, allen wrote:
> On Monday 12 August 2002 09:05 pm, Ryan Little wrote:
>>> 1.  Say CD1 is a minimal installer and a file system, rudimentary,
>>> ready to go.  ( And yes, I've actually created such a thing on contract
>>> for a company in the Northwest so I know this pretty well... )

>>> 2.  You do the "install" and partition, and format, and BL !

>> The only problem I could see with not having it in an RPM is if for some
>> reason it needed to be upgraded (i.e. a release upgrade on which the fs
>> changed, or a bug fix.) It's much easier to upgrade things with RPM (If
>> it's done correctly).

> Are you assuming there would be no rpm database of what is on the base
> file system IN the base file system ?

If I did it that way (or the following way), I'd install a minimal amount of 
RPM information on/from the CD and nice -19 rebuild the indexes and stuff 
after the install.

What I'd _really_ like to see is a CD that boots like Knoppix, autodetects 
everything in sight, asks enough questions to get a user up and your LAN etc 
running (and/or filches it from an existing Windows or Linux system), and 
then you just start using it.

When the system's been idle for a few seconds, it starts (niced) partitioning 
and copying stuff across from the running filesystem on the CD. If the user 
hits a key, moves the mouse, or has a busy app, the copying process is 
SIGSTOPped until shortly after all falls quiet again.

Maybe it also caches reads from the CD onto the HDD so that as you pull your 
most-used stuff off the CD in the course of actually using it, it makes it to 
the HDD and doesn't need re-reading next time.

This could easily be done with a temporary bitmap file on the HDD so it 
survives a reboot. When `stealth installation' is complete, the HDD 
partitions are remounted, pivotrooted or whatever so that the system is now 
running from the HDD, and the CD is ejected.

Knoppix is already useful for offices wherein the entire place has been 
trashed with a virus. If Mandrake could install this way, you could walk in 
with a Mandrake CD and have people up and running within minutes, and 
permanently Mandrake'd within the hour.

Another useful feature would be to nominate a machine as Keeper of the 
Install, so after it's installed and up (or before!) it offers an RO NFS 
share with an image of the CD on it, asks for each RPM CD in turn, and adds 
them to its collection. Then individual machines could be booted from a CD, 
remounted pretty much instantly on the NFS share, startup/install continues 
on NFS as from the CD, and the CD is ejected for use in the next machine. The 
RPMs are then available to both the `server' and newborn workstations for 
adding packages as required.

This could be done as a separate project to the `standard' Mandrake CD sets, 
released a month or two after 9.0, and take the world by storm.

+-+
| |
|  Do you like me enough to keep me?  |
| |
|   [ install ]   [ nag later ]   [ i'll call you ]   |
| |
+-+

Additional wishlist items:

 * Ability to configure a single workstation and use its RPM selection
   for all following.

 * Ability to deduce network card drivers from their ARP signature or
   MAC address, and either offer boot images for them to do all of the
   above, or make boot floppies to do same in case they don't have PXE
   or EtherBoot ROMs. As well as simplifying installation, you could
   make a whole trashed office functional (LTSP style RO from your
   server, with the option of making it permanent) in about ten
   minutes. (-:

   Imagery: power up virussed Windows box. 30 seconds later it is a
   working Mandrake machine. Walk to next machine, power it up. By the
   time you've powered up the 20th machine, the first is a fully
   installed standalone workstation.

How say you? The perfect time to bring this up? 

Cheers; Leon

Re: [Cooker] Installer suggestion

[Igor Izyumin]

On Monday 12 August 2002 09:04 pm, Austin Acton wrote:
> Thanks for your support.
> You have good ideas, but some of them won't fly.
>
> We NEED rpm to keep things uniform.  Easy to upgrade, easy to replace,
> (not-so)easy to build, and the same for every package.  Seriously.  If
> there is ANYTHING that linux needs to survive it's a bit of
> standardization (even WITHIN each distro).  Having two package systems
> could be a nightmare.

Are there any official specifications for Mandrake-compatible RPMs?  I wanted 
to make some once (Club, etc.), but the only thing I could find was the 
Mandrake RPM howto which seemed fairly vague and outdated.  Is anyone 
planning on updating that?
-- 
-- Igor

Re: [Cooker] Installer suggestion

[allen]

On Monday 12 August 2002 09:05 pm, Ryan Little wrote:
> > 1.  Say CD1 is a minimal installer and a file system, rudimentary, ready
> > to go.  ( And yes, I've actually created such a thing on contract for a
> > company in the Northwest so I know this pretty well... )
> >
> > 2.  You do the "install" and partition, and format, and BL !

> The only problem I could see with not having it in an RPM is if for some
> reason it needed to be upgraded (i.e. a release upgrade on which the fs 
> changed, or a bug fix.) It's much easier to upgrade things with RPM (If it's
> done correctly).


Um...

Are you assuming there would be no rpm database of what is on the base
file system IN the base file system ?

???

;)

-AEF

Re: [Cooker] Installer suggestion

[Austin Acton]

Thanks for your support.
You have good ideas, but some of them won't fly.

We NEED rpm to keep things uniform.  Easy to upgrade, easy to replace,
(not-so)easy to build, and the same for every package.  Seriously.  If
there is ANYTHING that linux needs to survive it's a bit of
standardization (even WITHIN each distro).  Having two package systems
could be a nightmare.

Also, you CAN just download ISO1 and do the rest via ftp/http.  I've
done it many times.  You can even just download one floppy and install
everything by ftp!  (Thanks to rpm...)

It would be nice to have a "semi-network" install option on CD1 though. 
You boot CD1, pick some sort of hybrid install with VERY few options and
menus and such.  This installs basesystem, X, a window manager, and the
"draks" and lets you select a mirror, and CONFIGURES the mirror in urpmi
BEFORE rebooting.  Then you reboot and install the rest from you new
super-speedy Mandrake system.

Great idea.

Austin

On Mon, 2002-08-12 at 21:39, allen wrote:
> 
> I would like to 2nd this concept.
> 
> 
> Also I would like to add a little something for some day in the future, 
> maybe...
> 
> Follow the thought, it would be too hard to describe otherwise...
> 
> 1.  Say CD1 is a minimal installer and a file system, rudimentary, ready to 
> go.  ( And yes, I've actually created such a thing on contract for a 
> company in the Northwest so I know this pretty well... )
> 
> 2.  You do the "install" and partition, and format, and BL !
> 
>  Your whole entire basic file system is copied over ready to go.
> 
> 3.  Reboot.
> 
> 4.  Now add the things you want.
> 
> How hard is that ?  
> 
> I don't want to start a flame thing, but compared to this sort of capability, 
> initially, I do not like rpm's.
> 
> This sort of "install" is a LOT faster, a LOT LOT faster.
> 
> Heck, you could even fit a few more architecture specific base file systems
> on there...  Maybe just X needs to "go on" the rpm way initially...
> 
> Is the rpms thing really so necessary all the way "from the beginning" ?
> 
> ( Humble and sincere question )
> 
> The other thing is that perhaps you really don't need to download a whole
> bunch of ISO's.  Maybe just part of one.  The rest can install itself as 
> needed over the net...  uprmi.addmedia (somewhere)  urpmi.finishinstalling ;)
> 
> ?
> 
> -AEF
> 
> 
> On Monday 12 August 2002 08:18 pm, Austin Acton wrote:
> 
> 
> 
> > Hello!
> >
> > I only have one request to add to v9.0 in the installer. I want an
> > "Install All" button - ala Redhat. Disks are cheap. The time required to
> > get the system fully operational isn't. Having an install all capability
> > would be a real productivity enhancer for one-off configurations.
> >
> > It would be even nicer if all extra services beyond those required to
> > normally operate the system are OFF by default when installed. That way,
> > you don't soak up memory and add more security holes. (At least until
> > the software is configured
> 

Re: [Cooker] Installer suggestion

[Ryan Little]

> 1.  Say CD1 is a minimal installer and a file system, rudimentary, ready to 
> go.  ( And yes, I've actually created such a thing on contract for a 
> company in the Northwest so I know this pretty well... )
> 
> 2.  You do the "install" and partition, and format, and BL !
> 
>  Your whole entire basic file system is copied over ready to go.
>/Snip/
> 
> This sort of "install" is a LOT faster, a LOT LOT faster.
I like your idea, install all the "base" system stuff in one shot, (ala a 

slackwareish tarball).

The only problem I could see with not having it in an RPM is if for some reason it 

needed to be upgraded (i.e. a release upgrade on which the fs changed, 

or a bug fix.) It's much easier to upgrade things with RPM (If it's done correctly).


Ryan
 

Re: [Cooker] Installer suggestion (one more)

[newslett]

And I have one more suggestion. I ran into this while upgrading via CD 
from 9.0 B1 to B2...when doing an "expert upgrade" and it comes to 
package selection time it gets VERY confusing. If you select all the 
groups of packages you want to upgrade by ticking next to them (and turn 
off individual package selection) the installer ADDS the space needed to 
that for the space needed to upgrade the already installed packages 
often making the amount calculated more that the partition size. To 
avoid this, you must untick everything then it calculates only the 
amount of space needed to upgrade the installed packages. I would 
venture to say this screen is not even necessary when doing an update as 
once installed packages are detected and updates on the CD are found to 
be available shouldn't it just start updating them??

I had to figure out what the heck the installer was doing before I could 
proceed. NOT good for newbies.

Cheers,

Jason

allen wrote:
> I would like to 2nd this concept.
> 
> 
> Also I would like to add a little something for some day in the future, 
> maybe...
> 
> Follow the thought, it would be too hard to describe otherwise...
> 
> 1.  Say CD1 is a minimal installer and a file system, rudimentary, ready to 
> go.  ( And yes, I've actually created such a thing on contract for a 
> company in the Northwest so I know this pretty well... )
> 
> 2.  You do the "install" and partition, and format, and BL !
> 
>  Your whole entire basic file system is copied over ready to go.
> 
> 3.  Reboot.
> 
> 4.  Now add the things you want.
> 
> How hard is that ?  
> 
> I don't want to start a flame thing, but compared to this sort of capability, 
> initially, I do not like rpm's.
> 
> This sort of "install" is a LOT faster, a LOT LOT faster.
> 
> Heck, you could even fit a few more architecture specific base file systems
> on there...  Maybe just X needs to "go on" the rpm way initially...
> 
> Is the rpms thing really so necessary all the way "from the beginning" ?
> 
> ( Humble and sincere question )
> 
> The other thing is that perhaps you really don't need to download a whole
> bunch of ISO's.  Maybe just part of one.  The rest can install itself as 
> needed over the net...  uprmi.addmedia (somewhere)  urpmi.finishinstalling ;)
> 
> ?
> 
> -AEF
> 
> 
> On Monday 12 August 2002 08:18 pm, Austin Acton wrote:
> 
> 
> 
>>Hello!
>>
>>I only have one request to add to v9.0 in the installer. I want an
>>"Install All" button - ala Redhat. Disks are cheap. The time required to
>>get the system fully operational isn't. Having an install all capability
>>would be a real productivity enhancer for one-off configurations.
>>
>>It would be even nicer if all extra services beyond those required to
>>normally operate the system are OFF by default when installed. That way,
>>you don't soak up memory and add more security holes. (At least until
>>the software is configured
> 
> 
> 

Re: [Cooker] Installer suggestion

[allen]

I would like to 2nd this concept.


Also I would like to add a little something for some day in the future, 
maybe...

Follow the thought, it would be too hard to describe otherwise...

1.  Say CD1 is a minimal installer and a file system, rudimentary, ready to 
go.  ( And yes, I've actually created such a thing on contract for a 
company in the Northwest so I know this pretty well... )

2.  You do the "install" and partition, and format, and BL !

 Your whole entire basic file system is copied over ready to go.

3.  Reboot.

4.  Now add the things you want.

How hard is that ?  

I don't want to start a flame thing, but compared to this sort of capability, 
initially, I do not like rpm's.

This sort of "install" is a LOT faster, a LOT LOT faster.

Heck, you could even fit a few more architecture specific base file systems
on there...  Maybe just X needs to "go on" the rpm way initially...

Is the rpms thing really so necessary all the way "from the beginning" ?

( Humble and sincere question )

The other thing is that perhaps you really don't need to download a whole
bunch of ISO's.  Maybe just part of one.  The rest can install itself as 
needed over the net...  uprmi.addmedia (somewhere)  urpmi.finishinstalling ;)

?

-AEF


On Monday 12 August 2002 08:18 pm, Austin Acton wrote:



> Hello!
>
> I only have one request to add to v9.0 in the installer. I want an
> "Install All" button - ala Redhat. Disks are cheap. The time required to
> get the system fully operational isn't. Having an install all capability
> would be a real productivity enhancer for one-off configurations.
>
> It would be even nicer if all extra services beyond those required to
> normally operate the system are OFF by default when installed. That way,
> you don't soak up memory and add more security holes. (At least until
> the software is configured

[Cooker] Installer suggestion

[Austin Acton]

Someone on the club had a cool and easy suggestion, so I just wanted to
make sure you heard it.
Austin

(quoting)

Hello!

I only have one request to add to v9.0 in the installer. I want an
"Install All" button - ala Redhat. Disks are cheap. The time required to
get the system fully operational isn't. Having an install all capability
would be a real productivity enhancer for one-off configurations.

It would be even nicer if all extra services beyond those required to
normally operate the system are OFF by default when installed. That way,
you don't soak up memory and add more security holes. (At least until
the software is configured

Yours,
Jason