Re: More RAM - a bad trend for m68k debian
On Tue, Mar 28, 2006 at 10:40:18AM -0600, Stephen R Marenka wrote:
> On Tue, Mar 28, 2006 at 06:22:28PM +0200, Wouter Verhelst wrote:
> > On Thu, Mar 23, 2006 at 11:51:19AM -0600, Stephen R Marenka wrote:
> > > The partitioner also sets up fstab and such and it's already a hog by
> > > the time it's loaded up (bear in mind, we're talking about a hog by
> > > lowmem standards). Yes, it'd be nice to have a workaround, but I don't
> > > know that anyone is working on one. It does do a lot of cool stuff for
> > > you like raid and lvm.
> >
> > Hmm. How about something that uses libparted which just checks whether
> > any "useful" partitions have already been created, prompts the user
> > whether it's okay to use those partitions, and pulls in the partitioner
> > if it's not? I'd think such an application would not require as much RAM
> > as the full-blown partitioner, though I'm not sure.
>
> I think the trick would be integrating that with the partitioner so that
> you didn't have to do the same thing twice.
Hmm, could be nice indeed.
> partman could use some work anyway -- it's dog slow on m68k. Having
> used it on modern x86 hardware, I see why they aren't concerned.
>
> It might me nice not to download all those partman modules unless you
> needed them too. Partitioning seems to be what needs the most memory.
Yes, that's exactly what I wanted to suggest. The idea would be that
this would be some udeb which would be on the initial image, checking
for partitions, and marking the partman stuff for addition if it is
necessary (and not if it isn't). I don't think this would be much of a
loss -- after all, for an installation on most m68k hardware, you need
to (or can) do the formatting on the native OS anyway.
I'll have a look at that later today. If I remember ;-)
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Reply to: