Hi Bernhard,
We have the following observations & suggestions about the mock-up
screenshots. Sorry about the long mail and taking some time in
replying.
We would also like to suggest changes in the kdump user scripts
(kdump initrd) and based on that the yast kdump configuration
screens will need changes.
**************************************************************
1) General Settings
===================
We liked the three way enable/disable settings and they are at
the right place, but the other portions like kernel command line
or kdump commandline should be part of the expert settings as
generally user should be provided with default set of kernel
command line options and rarely one has to change them.
Instead of command line settings, it would be useful to have
the setting related to reserving memory for kdump kernel. The
tool can have display like
----------------------------------------------------------------------------
Total system Memory (MB): 4096 (just informative)
kdump Memory (MB): (A list box with a minimum memory value like 128, and
option to increase should be there)
Usable Memory (MB): 3968 (this is also informative)
----------------------------------------------------------------------------
2) Dump Settings
================
This should capture the settings about dump target and other misc settings
about daump saving. Apart from this, "the dump filtering" options for
the "makedumpfile" utility can also be integrated here. So,
Dump Target
-----------
(a radio button to select either of the three targets like
o Local filesystem
- here we can have a list box with list of valid disk partitions
with supported filesystems
- path location
o Network
- This is for possible future extention of dump saving mechanism using
which we can save the dump over network ie over NFS or scp, through
the kdump initrd. For this we will need following settings
- a radio button for selecting NFS or SCP
- IP address of the server
- path (exported path for NFS or target path for scp)
o Raw disk
- here we can have list of available paritions without any
filesystem on them
Default dump path (ie relative to the dump target)
-----------------
[ /var/log/dump ] (select directory button)
Dump filtering options
-----------------------
- This should capture settings for options for using the dump fitering
tool "makedumpfile". I am not sure right now if we need a separte
screen for this or "Dump settings" is ok.
3) Expert Settings
==================
- kdump kenrel command line options
[ ]
- path to custom kdump kernel
[ /boot/vmlinuz-my-kdump-kernel ]
- path to custom kdump kernel initrd
[ /boot/initrd-my-kdump.img ]
- Note: The current approach is to provide user a distro built kdump
kernel. But some users would like to use their own kernel to minimize the
reserve memory requirement. Also. the kdump initrd might be different if
the user is trying to save dump thruough initrd in soe unsual envirnment
like multipath IO etc.
*************************************************************************
These might be confusing but please let me know if I can elaborate more.
The kdump initrd related changes I was taking about are probably not the
right stuff for this mailing list but please bear it here.. so that we
can have the right context for discussions
1. The current approach in of using a _dedicated_ disk partition somewhat
defeats the purpose of kdump flexibility. This mandates that use has
to have a separte disk parition allocated just for kdump. The alternative
is to have initrd based solution. In past we have done a prototype for
such approach
http://lse.sf.net/kdump/patches/automation/sles9-sp2-mkinitrd-1.2-27.9-auto…
Here using initrd we copy the dump directly to the disk filesystem
and avoid the intermediate step of copying to a raw partition and then
to target path. This approach does make initrd somewhat bigger in size but
it doesn't need user to have a dedicated disk partition just for kdump.
2. As of now there is no support for saving the dump over network using
NFS or scp. The network dump can also be done using the kdump initrd
once the user has specified right config parameters. So, overall kdump
initrd should be able to copy the dump to all possible targets depending
upon the user settings.
3. As of now the dump filtering tool is not integrated with kdump user scripts
so we can get that also integrated in the initrd and have smaller size
dumps based on options given to "makedumpfile" tool.
Thanks
Maneesh
----- Forwarded message from Bernhard Walle <bwalle(a)novell.com> -----
Date: Thu, 12 Apr 2007 00:32:22 +0200
From: Bernhard Walle <bwalle(a)novell.com>
To: Maneesh Soni <maneesh(a)in.ibm.com>
Cc: tiwai(a)suse.de
Subject: Fwd: Mockups pre kdump
Hello,
as you may remember you wanted some discussion about the new kdump
YaST module. Here I got some early screenshots. I think we should
continue the discussion about on the yast-devel(a)opensuse.org mailing
list. See http://en.opensuse.org/Communicate how to subscribe.
Thanks,
Bernhard
--
SUSE LINUX Products GmbH Tel. +49 (911) 74053-0
Maxfeldstr. 5 GF: Markus Rex
90409 Nürnberg, Germany HRB 16746 (AG Nürnberg)
OpenPGP DDAF6454: F61F 34CC 09CA FB82 C9F6 BA4B 8865 3696 DDAF 6454
From: Jiri Srain <jsrain(a)suse.cz>
To: bwalle(a)novell.com, tiwai(a)novell.com
Subject: Mockups pre kdump
Date: Wed, 11 Apr 2007 15:23:41 +0200
Hi Bernard and Takashi!
I already have some mockups for the YaST dialogs for kdump, find them attached
to this mail. I hope that the desired functionality of the module is obvious
form them, even though some of the widgets may need better labels.
Please, comment on them, also feel free to forward them to IBM.
Jiri
BTW: How should the module be called? Is yast2-kdump OK with you?
--
Regards,
Jiri Srain
YaST Team Leader
---------------------------------------------------------------------
SUSE LINUX, s.r.o. e-mail: jsrain(a)suse.cz
Lihovarska 1060/12 tel: +420 284 028 959
190 00 Praha 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz
----- End forwarded message -----
--
Maneesh Soni
Linux Technology Center,
IBM India Systems and Technology Lab,
Bangalore, India
(i'm afraid this mail might get quite long)
i just get home from a party, and read an announcement that yast is
now 'community'. the party was good though.
well..
i loved suse, but not anymore. mainly because of yast. to me a distro
is 3 things:
- a good package manage system
- an integrated product
- some sane defaults everywhere
suse from 10 onward was (imho) lacking all. yast basically didn't
change; it also was not very 'community'.
now there is the *ubuntu family that kind of save all of us by being
the cool debian, and all of a sudden yast is not longer a 'strategic
advantage' but a large disadvantage.
it already became a problem when suse got some strong gnome forces on
board. toolkits are a religious discussion; i agree. ;) yast is a more
kde'ish app that stands bad in a gnome environment (true).
so yast is a problem, and ZEN* is apparently not the solution. so now
suse tries to go 'community' with yast.
and i think that is the logical next thing to do.
i think novell understands that people will not write the core of
their distro for them. so some investment is needed.
the problem is old: the desktop linux user community needs a standard
way configure their computer (the configuration/ system settings
windows on other OSes). and preferably we also want console access
(besides the GUI) to some of the features (like y as).
the solution can be new: why not do the configuring from a webpage
(that at the same time has a command line interface)?
reasons why:
- no gnome/kde/whatever dilemma
- today with AJAX we can make very good looking interfaces.
- webpages are easier to 'fix' (usability wise)
- more people can help
- ...
features:
- plugin based
- written in ruby (or python) ((biased? who, me?))
- stylesheets can be used for theme creation
- a command line interface (new to the locally served web page)
- runs on gecko/khtml (with the accompanying javascript engines)
- put in a specially crafted browser, to look very clean
- ...
strategic:
- try to cooperate with other distributions
- share the development
- seek cooperation with openusability.org
- uniformize linux configuration -- users benefit
- novell shows that it is really interested in the community as a
whole (sorry guys, you kind-of let the free software community --
besides your own userbase -- down by signing that MS deal: you could
have know)
- ...
conclusion:
obvious to me: re-write.
please think big!
p.s.: although i think novell let the free software community down by
signing the MS deal; i don't mind they did it -- actually i'm glad!
they showed a hole in the GPL that can will now be closed in GPLv3!
"what does kill it makes it stronger"
p.p.s: did i mention that it might also be a good moment to drop RPM
in favor of DEB? (this might even create a strong cooperations between
suse and the debian/ubuntu/etc.)
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
For additional commands, e-mail: yast-devel+help(a)opensuse.org
Benjamin Weber has been writing about his metapackage project a few times
recently but hasn't received much feedback.
So I thought I'd try to help promoting it a bit, since I think it has the
potential to solve some very common issues, like the never ending debate
about multimedia codecs. Of course we won't be able to include the codecs,
but with Benjamins project in the distro we could make such things as
installing those codecs ridiculously simple.
You'll find a package of the metapackage yast2-module here:
http://bw.uwcs.co.uk/mp/yast2-mpp-0.0-0.suse102.noarch.rpm
I've set up a quick proof of concept web page to show some examples of how
this metapackage handling can help users:
http://suse.linuxin.dk/ymp
The page is optimized for Konq only, which doesn't matter much, as this is
just a proof of concept, and currently only konqueror has support for the
metapackages in the abovementioned package anyway.
Here are some screenshots of what happens when the user clicks a link to a
metapackage:
http://suse.linuxin.dk/ymp/catalogue.pnghttp://suse.linuxin.dk/ymp/packages.pnghttp://suse.linuxin.dk/ymp/settings.pnghttp://suse.linuxin.dk/ymp/status.png
The "metapackage" (*.ymp) itself is an xml file, with information about
repositories and packages to install, the syntax is very self explanatory,
try downloading this file and opening it with your favourite text editor:
http://suse.linuxin.dk/ymp/kde.ymp
The metapackage handler can do much more than what has been described above.
It could pontentially also be used to add repos only, without installing any
packages.
It can be used to install packages instantly when you find them in the package
search, also developed by Benjamin. See:
http://benjiweber.co.uk:8080/webpin/index-test.jsp
(hint: look for the "install now" links in search results).
I'm sure Benjamin would be happy with any testing and comments. And it would
be nice to have some sort of official comment as to whether this is something
we have a chance of seing included in the distro.
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
For additional commands, e-mail: yast-devel+help(a)opensuse.org
Hi Bernhard,
I had discussion with my colleagues about UI and about usability.
The result is some widgets are not clear for understanding their main goals.
I would like to change some of them.
,---- Enable/Disable Kdump ---------------------------------,
| |
| (o) Enable kdump |
| ( ) Disable kdump |
| ( ) Disable kdump (Remove the Kernel Parameter) |
| |
.............................................................
The frame "Enable/Disable Kdump" looks good but...
The better is split removing kernel parameter and enable/disable kdump
service.
,---- Enable/Disable Kdump ---------------------------------,
| |
| (o) Enable kdump |
| ( ) Disable kdump |
| |
.............................................................
,---- Boot Option (crashkernel) for Kdump ------------------,
| |
| (o) Add Boot Option |
| ( ) Remove Boot Option |
| |
.............................................................
What is your opinion? I interested in option "Enable kdump" from the
frame "Enable/Disable Kdump".
I am not sure if it is good idea enable kdump service without booting with
kernel parameter for kdump.
Could you write me something about dependencies between "kdump service"
and "kernel parameter" for kdump? What happen if machine boots without
crashkernel parameter and user enable/disable kdump service etc.?
Next there is the frame for switching between options KDUMP_COMMANDLINE and
KDUMP_COMMANDLINE_APPEND.
,---- Command Line -----------------------------------------,
| |
| Kdump Command Line ( ) Append |
| [_____________________] (O) Replace |
| |
| |
.............................................................
Radiobuttons Append and Replace are good solution but radiobutton Replace has
wrong name. It is not clear what the radiobutton Replace means. Probably
better name for radiobutton will be "Normal". Maybe longer description for
radiobuttons will be better too. (Append kdump Commandline / Normal kdump
Commandline)
I prefer solution with 1 checkbox:
,---- Command Line -----------------------------------------,
| |
| Kdump Command Line |
| [_______________________] ( ) Append kdump Commandline |
| |
| |
.............................................................
If user select checkbox "Append kdump Commandline" the frame "Command Line" is
changed:
,---- Command Line -----------------------------------------,
| |
| Kdump Command Line Append |
| [_______________________] (X) Append kdump Commandline |
| |
| |
.............................................................
My final question is about KDUMP_KEEP_OLD_DUMPS. Could you write me the
maximum value for this options from /etc/sysconfig/kdump?
-------------------------------------------------------------
I accept that name of push buttons will be "[Browse]".
Using tabs or left-handed-tree:
I am sure that final version of UI will has 4 dialogs maybe 5.
(There are still some open points)
It is not problem transfer left-hand-tree to the tabs.
If final version has 4 dialogs I transfer UI to the tabs.
I will continue with left-hand-tree. After clearing all options and settings
for kdump we can start discussion about using tabs or left-hand-tree.
I will delete unclear options from module. It doesn't mean that the deleted
parts are lost. :) I only temporary delete parts which are not clear now.
You will find new mock-ups on the wiki soon.
(http://en.opensuse.org/YaST/yast-kdump)
Finally thank you all for their hints, comments and suggestions.
best regards
jozef
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
For additional commands, e-mail: yast-devel+help(a)opensuse.org
Greetings all,
I thought I'd send an email out summarising some of the things I have
been working on recently, to obtain some feedback, and maybe even some
help.
= Package Search =
- This is back up for the time being, although I am not confident of
it staying up for long, if it's down or slow when you read this email
I apologise. adrianS has kindly offered to help with hosting when they
have some more resources.
- Set up a design page at http://en.opensuse.org/PKGSearch-design
- Having spent some time reviewing how people were trying to use the
search, I found a large proportion were searching for phrases, not
just package names/contents. Therefore I made the package summaries
searchable too. eg you could find konversation now with:
http://benjiweber.co.uk:8080/webpin/index.jsp?searchTerm=kde+irc+client
or
http://benjiweber.co.uk:8080/webpin/index.jsp?searchTerm=bin%2Fkonversation
or
http://benjiweber.co.uk:8080/webpin/index.jsp?searchTerm=konversation
- There was a performance problem with people searching for very
common and short terms such as "qt" or "kde", this should be fixed
now.
- I've made some slight modifications to the design based on some suggestions.
- I've been working on improving the performance of the trawler, I can
now from a clean database locate, download, parse, index the metadata
for the main official/community & build service repositories in under
half an hour on my desktop. (That's ~900 repositories, ~110,000
packages including summaries/descriptions, ~16,000,000 files),
incremental updates where only some repositories have changed are much
faster.
- Integration with the simple software installation (explained below)
that I've been proposing, with "Install now" links on
http://benjiweber.co.uk:8080/webpin/index-test.jsp
= Simple Software Installation =
The vast majority of the questions we face when there are not serious
things wrong with the distribution are related to issues such as
installation of third party software, multimedia codecs etc.
Explaining to new users the concept of package repositories, how to
add these, and subsequently install software is not trivial.
Furthermore, users should not be forced to grasp these concepts in
order to easily install software, in my opinion.
To solve this we could have a simple file handler that can handle
links in web pages or files on distributable media which automates the
process of adding repositories and installing software.
- I've set up a wiki page outlining the concept at
http://en.opensuse.org/MetaPackage-design
- I've created a functional prototype yast module, Pascal has kindly
made a package which you can try at:
http://bw.uwcs.co.uk/mp/yast2-mpp-0.0-0.suse102.noarch.rpm
After installing this you can try out some demo uses at
http://bw.uwcs.co.uk/test.html
The "install now" links on http://benjiweber.co.uk:8080/webpin/index-test.jsp
Currently the above will only work with konqueror, unless you create
the associations manually for firefox/opera in the same way as they
are configured in konqueror (this is possible, but difficult to
package without having the configuration in the upstream distribution
package)
Martin Schandler is creating a demo page to show how this could be
used to simplify codec installation, for now hopefully you can use
your imagination.
- In the above package there is also a demo yast client to the search
service, you can run with "/sbin/YaST2 PackageSearch" as a normal
user, and search for and install packages from the build service in
the same way as the "Install now" links on the webpin page.
= What I would like help with =
- Please could people try out the demo prototype metapackage handler
described above, and comment on the concept.
- I know ycp only a little, and perl not at all, so if someone could
fix the above into a releasable quality that would be awesome. (source
is also at http://bw.uwcs.co.uk/mp)
= Future =
- Search service joint hosting Novell/Community, adrianS is looking into this.
- Migration of the frontend to the search to opensuse-community.org
- Fix ycp/perl to a releasable state. (someone who knows what they're doing)
- Improve the "Install now" functionality of the search service, by
calculating the repositories each package depends on (it isn't always
just the one the package is located in).
I am currently investigating either a simple method looking at the
repository dependencies in the build service and manual setup for
repositories outside the build service, and a far more complicated
method using the rpm requires & depends.
- Integration with new build service features such as statistics,
using the search service statistics to improve results.
- Using search service to enrich client side software.
That's all I can think of for now.
_
Benjamin Weber
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
For additional commands, e-mail: yast-devel+help(a)opensuse.org
Hi,
We still have some version numbers of YaST modules that are not
appropriate for openSUSE 10.3. It should be ^2.15.X, please fix your
packages.
Of course, some packages don't make sense for openSUSE, some of them
have been dropped. I'm asking maintainers of these modules to decide:
autofs/VERSION:2.13.1
boot-server/VERSION:2.14.0
ca-management/VERSION:2.14.5
control-center-gnome/VERSION:2.13.2
control-center/VERSION:2.14.5
devtools/devtools/skeletons/agent/VERSION:2.13.0
devtools/devtools/skeletons/config/VERSION:2.13.0
devtools/devtools/skeletons/trans/VERSION:2.13.0
ipsec/VERSION:2.13.0
iscsi-client/VERSION:2.14.10
iscsi-server/VERSION:2.14.3
liby2util/VERSION:2.14.0
mail-server/VERSION:2.13.10
nfs-client/VERSION:2.14.0
nis-server/VERSION:2.14.1
packagemanager/VERSION:2.13.17
pam/VERSION:2.14.0
phone-services/VERSION:2.14.0
printer/VERSION:2.14.23
profile-manager/VERSION:2.14.1
registration/VERSION:2.14.4
slp-server/VERSION:2.14.1
slp/VERSION:2.14.1
testsuite/VERSION:2.14.0
tftp-server/VERSION:2.14.0
y2pmsh/VERSION:2.13.3
you-server/VERSION:2.13.4
Thanks
Lukas
--
Lukas Ocilka, YaST Developer (xn--luk-gla45d)
-----------------------------------------------------------------
SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic
Hi guys,
So JP found a bug in update.ycp when run with yast2-gtk, I stopped this
crashing yast2-gtk (which was daft), but it looks like there is an
underlying issue:
We create a Wizard dialog, and we add steps to it, but surely we should
do:
Wizard::OpenNextBackStepsDialog();
update.ycp:35 instead ?
Of course, that rather changes the look, but we can at least see the
steps :-)
HTH,
Michael.
--
michael.meeks(a)novell.com <><, Pseudo Engineer, itinerant idiot
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
For additional commands, e-mail: yast-devel+help(a)opensuse.org
I wrote some ideas on the discussion page, is that the expected
wayout? copy below
jdd
Hello,
Good idea to open this page. Some essential though, for the beginning:
It's essential to keep the ncurse UI with complete functionality.
openSUSE is probably the only distribution giving an intelligent
complete interface, very pleasant through ssh and low bandwith connection.
second, YaST is two parts: first time install and system
configuration. help is important at install time, but _on paper_ we
_must_ keep YaST small to be able to install on oldfashionned hardware
with minimal ram (for example). 10 years old computers are today
perfectly usable and used even in our countries by money disabled
people, very interested by the freeness of Linux.
third, I personnally think the way YaST is showing the config at
install time is must better than the way it shows it at system config
time. I speak of the summary page with all the components in a window
with links (and the "change" box at bottom)
fourth, the YaST control center is un-consistent at least for the
network devices. Why are them separated from the other hardware?
fith, the most ennoying YaST lack is the systematic failing of network
detect for the printers. I think I have never seen YaST detect an
existing printer on my Linux+Windows net (I have from one to three
printers available, depending on the period), and the wording is very
difficult to understand (I know of "samba" protocol, not about the others)
thanks jdd 05:08, 17 April 2007 (UTC)
--
http://www.dodin.net
Lucien Dodin, inventeur
http://lucien.dodin.net/index.shtml
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
For additional commands, e-mail: yast-devel+help(a)opensuse.org
Hi folks,
Opened a wiki page for people to drop some thoughts and ideas with
regard to Yast interface. Stop by, and drop yours. :)
http://en.opensuse.org/Yast_UI_Future
You may notice reply-to is set to the yast-devel mailing list. Please,
reply there.
Cheers,
Ricardo
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
For additional commands, e-mail: yast-devel+help(a)opensuse.org
