Re: working on text mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- "Oron Peled" <oron@xxxxxxxxxxxx> wrote:

> On Tuesday, 27 בJanuary 2009, David Cantrell wrote:
> > Oron Peled wrote:
> > >  * A small/old-hardware server without enough RAM.
> > >    ...
> > >    In both cases X or vnc install was not possible,
> > How is VNC not an option here?  I assume you have another system at
> your 
> > disposal aside from the one you are setting up.  And if you are
> setting 
> > up a server, I assume it also has a network interface.  So again,
> how is 
> > VNC not an option?
> 
> It is about small hosts with little RAM. If it can't run
> an Xserver, would it be able running VNC server? (which is actually
> a modified Xserver).

The memory issue pops up *a lot*.  Surprisingly (or not) the most memory is not consumed by the Xserver.  The most memory consumption is located in the resolution of dependencies.  Also have in mind that ram is not the only memory that can be used at installation time.  If you have a swap partition it will be used and it actually helps a lot with memory use.  This swap approach can be used to mitigate any situation that eats up memory.

> 
> BTW, there are some modern hosts that don't have a lot of RAM
> (because
> they are not for desktop use). E.g: I consider to replace my
> aging firewall (old celeron machine) with
> http://www.pcengines.ch/alix.htm
> (no-fan, less power, small) or similar.
> 
> > > One last note about the difficulty of squeezing LVM definitions
> into
> > > a text UI. This looks hard if we assume everything should be put
> > > into the same dialog box. If we split it to steps (VG's, PV's for
> each VG,
> > > LV's for each VG), it should be easy (not the code, the UI design
> ;-)
> > 
> > The UI design isn't that easy for partitioning.  It's already very 
> > difficult in graphical installer.  Our current interface starts to
> break 
> > down and become useless when you have hundreds or thousands of
> disks.  I 
> > don't want to imagine what that would be like in text mode.
> 
> Do you actually install on so many disks? 

That is totally up to the user.  But you must be able to choose the ones you want.  Therefore you must, somehow, list them all.  Additional to the amount of disks is the amount of possibilities that need to be addressed in the UI (LVM (mirrored,striped,linear), Multipath, raid (software,"hardware"(linear,striped,mirrored)), crypt setups(the passphrases).  The fact that device-mapper devs can be stacke pretty much in any way, partitioning(partition tables, specific partition setups for each table type), Device (iscsi).  And this is just the tip of the iceberg.  All of these options need to handle the metadata that go with them.  Its just not viable in text mode.

> Or are they used as an
> added
> storage? In the later case, why should they be managed by the
> installer?
> [or does the disk selector list look horrible?]
> 
> > we don't want to do:
> > 
> > 1) Created an entirely different user interface.  Not just newt over
> 
> > gtk, but different screens and text.
> 
> Agreed.
> 
> > 2) Limited what you can do in text mode, so what's the point in the
> 
> > first place?
> 
> Text mode is useful. The real question is what functionality should
> exist in text mode install *without* having the big double
> maintenance
> problem you pointed about.
> 
> It's hard to implement all new features so they'll function
> transparently in text-mode. Therefore, my suggestion was to
> concentrate in the aspects that *cannot* be fixed after the install.
> 
> One such thorny problem is the partitioning and disk management.
> While I don't have a clear solution for this, the current partitioning
> UI
> isn't optimal:
>  - LVM (and later RAID) were an addition to existing DiskDruid and it
>    shows in the UI design.
>  - As you say, it's not easy to manage many disks (linear scrollbar
>    without incremental search/narrowing).
>  - Hard to cleanly represent in text mode.
>  - A special case code. Not used in day-to-day disk management. This
> is
>    bad, as daily used code is tested in a lot more cases.
>  - And than there's system-config-lvm which is nice in some ways, but
>    is another special case (LVM, nothing more, nothing less).
> 
> So maybe the issue isn't really anaconda support for text-mode, but
> rather
> the need for new disk-management UI for both day-to-day and anaconda?
> For F12?

this has been discussed a lot in irc, meetings.  This would be ideal.  Don't know if it will be done for F11, F12, if it will be done at all.  I also am not sure about necessarily having a text mode partitioning section in installer, just because we have it in system-config-storage.  I guess it all depends on how it is implemented.

> 
> -- 
> Oron Peled                                 Voice: +972-4-8228492
> oron@xxxxxxxxxxxx                  http://www.actcom.co.il/~oron
> "Your fair use of this book is restricted"
> "You may only read this book once"
> 
> _______________________________________________
> Anaconda-devel-list mailing list
> Anaconda-devel-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

-- 
Joel Andres Granados
Red Hat / Brno Czech Republic

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux