YaST Development February 2011

yast-devel@lists.opensuse.org

19 participants
10 discussions

[yast-devel] RFC: Google Summer of Code 2011 ideas
by Martin Vidner 01 Mar '11

01 Mar '11

Hi, prompted by Miska, Pavol, and Stano, I've been thinking how YaST can take part in GSoC, under the openSUSE umbrella. This is not finished, but I am being distracted by bugs so here is what I have so far for inspiration and discussion. Google starts accepting organization applications on Monday. For http://en.opensuse.org/openSUSE:GSOC_2011_Ideas == YaST === Template: Idea Name Abstract '''Required knowledge:''' '''Skill level:''' '''Mentor:''' [[User:foo|Foo Bar]] '''Student:''' STUDENT NEEDED === Use Augeas in YaST back-end [http://augeas.net/ Augeas] is a library to parse and write configuration files, using a generic mechanism driven by grammars ("lenses"). YaST has been using "agents" for this task, some of them also configurable, though in a more limited way. ==== Ambitious goal: replace all parser agents by Augeas lenses. ==== Medium goal: replace the major agents by Augeas The major agents include ag_ini and ag_any. ==== Small goal: replace a couple of agents by Augeas Choose some agents for the pilot. The majority of the project would be infrastructure: binding Augeas to the YaST library so that it can be easily used from the YCP language. '''Required knowledge:''' C++ for binding A to Y (? maybe unnecessary, could go via py/rb/pl); learn a little YCP '''Skill level:''' '''Mentor:''' [[User:Mvidner|Martin Vidner]] (feel free to replace me) '''Student:''' STUDENT NEEDED === Separate libyui yast2-libyui is still coupled to YaST too much. Make it a truly standalone project. === Do the whole Amaranth (But we want to work on that too at the same time. What part is well separated?) -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu

2 2

[yast-devel] yast2-core clean up and refactoring
by visnov＠suse.cz 25 Feb '11

25 Feb '11

This is a bunch of patches for yast2-core. Some are pure clean up, but there is also a removal of genericfrontend.cc and replacing it with non-generic scr and y2base binaries. -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

4 14

[yast-devel] Does YaST accidentally overwrite files?
by Thomas Goettlicher 16 Feb '11

16 Feb '11

Hi all, Once upon a time there were a few YaST modules which overwrote manually edited configuration files. Instead of changing only certain configuration options YaST overwrote all entries of the specific configuration file. In this case values were lost which had been manually changed before running YaST. YaST doesn't accidentally overwrite configuration values anymore! If it does it's a bug. If you know any YaST module that still destroys manually changed configuration files. please report a bug (and cc me). We want to get rid of the myth that YaST accidentally overwrites files. Thank you Thomas -- Thomas Goettlicher SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] WebYaST will help the openness
by Martin Vidner 16 Feb '11

16 Feb '11

Hi, I've just talked with Michal Svec, a product manager, about YaST and WebYaST. (Not knowing about our discussion, he wanted to know how hard it is to "copy" YaST features to WebYaST.) I noted that in the short term we instead want to work on opening the project, and he had these insights: Motivation: removing barriers to entry like I proposed is fine, but YaST already includes everything and the kitchen sink, so people have little motivation to contribute by adding new features. On the other hand, WebYaST is small feature-wise, so we could take advantage of that and of the current demand for the web stuff and make sure contributing to WebYaST is easy. YaST on other distributions: ZYpp is a community project thanks to libzypp and zypper being actually used by other distros. Can we do the same for YaST? It is much bigger so it is hard. How about porting a smaller part like WebYaST? -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu

8 17

[yast-devel] A Plan for YaST: Project Amaranth
by Martin Vidner 14 Feb '11

14 Feb '11

A Plan for YaST: Project Amaranth ================================= Why --- YaST as a platform has been stagnant for the past few years. Half of the original team has been busy with WebYaST and other web projects. Since relicensing to GPL in 2004 we got very few contributions - Benjiman's One Click Install being a notable exception - Oracle contacted us with their patches (based on a previous version of SLE), but we did not follow up. Much of the code has no tests, patching it is risky. Linux around evolves, a recent example being systemd, so YaST must keep up. If we don't provide a direction for YaST, it will rot and die. What ---- Amaranth is a project to open up YaST and realize its potential: Deprecate YCP, a custom YaST language, in favor of Ruby(*), a widespread one. Thus gain contributors from openSUSE and possibly other distro communities. *) see a followup mail about the language choice How --- Take the existing unfinished attempts yast2-ruby-bindings, yast2-libyui, ruby-yui, bind libstorage to ruby. - loudly state the intent to make them usable, including a timeline (see When) - provide good and up-to-date documentation - integrate with the Ruby ecosystem: -- document in form usual for Ruby developers (rdoc/yard) -- get found at rubygems (if only as a stub to point to the real package) - move from Subversion to Git (host at Gitorious, Github, or both) (see Why Git) - give good examples of usage, by converting a couple of production YaST modules to the new platform When ---- Have it all ready by the release of openSUSE 12.0 (November 2011) at the latest. Better, do it for an earlier milestone and have 12.0 feature independent contributions. Don't try hasty fixes for 11.4, now we still can't guarantee the API. Possibly do a backport. Who --- The long term goal is "hackers from around the Tux world". For now, it's myself, looking for you, the YaST hackers, to join, and for the team leads, project and product managers to give us time for it. Why Git ------- Git enables fearless hacking, power to the people, easy merging. Code Name --------- Amaranth is a purple (read .py.rb.pl) flower whose name means 'unwithering'. The tool is still branded YaST. Amaranth is the project to make the transition to world domination. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu

7 11

[yast-devel] Why the " Direction of YaST Architecture?" thread will be infinite
by Duncan Mac-Vicar P. 14 Feb '11

14 Feb '11

I am trying to follow the thread, but the discussion it is getting too abstract. Everyone is defending concepts but at the end because the level of abstraction of the discussion everyone may be talking the same. Architecture, design and layering is fine, as long as you don't lose focus from the important: ZYpp never got the small community it has because its design/architecture (libzypp still has bad stuff) or the language (it is still very advanced C++) but because: - it got really fast (solved its main showstopper) - zypper got really good (improved over the competition) - it got more universal (as it could be used via PackageKit) So I recommend to focus on what this new module will look like, how fast it will be, how the command line will look like, the documentation, etc. From there the language/architecture part is important, but secondary. Don't forget the architecture depends a lot on the language/ecosystem you choose, so create it as you envision the end user experience. For example, if you choose Ruby, the thing you call "lib" which is giving you understanding headaches in the discussion, may look like a set of ActiveRecord models, representing nouns, all implementing CRUD and reusables across UI, cmdline and web controllers. But in Python it may look completely different. Then do it!. Then refactor. If you got the experience you aimed for, do a second module, refactor the infrastructure to reflect the new use cases, and iterate. Just my 0.02€. -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] Direction of YaST Architecture?
by Arvin Schnell 11 Feb '11

11 Feb '11

Hi, in a recent telco the question about the direction of the YaST architecture was raised. In the pase a lot of things have been tried. E.g. integrate different languages (Perl, Python, Ruby), try different build systems (cmake), automatic generation of bindings for C/C++ libraries (libstorage) or simply use common technologies (e.g. CIM). This is not necessarily bad but from my point of view quite a few ideas are stuck halfway (Python integration) or are simply of bad quality (generation of bindings). Even usage of Perl seems to be considered to be no improvement. But instead of removing failed approches we keep them and often do not even look at better ways. As a result the YaST architecture is on one hand more complex and confusing then required and on the other hand lacks quality and features. So now that we have minimal recourses to improve the YaST Architecture we should concentrate on a few improvements instead of dissipate our energies again. So what seems desirable and feasible? Some ideas: 1) Replace YCP with some common language? With more that 100 modules this looks impossible. 2) Allow a common language next to YCP? A good integration seems difficult. 3) Improve YCP (at least fix bugs)? Do we want that? 4) Better bindings of C/C++ libraries for YCP? Other suggestion? Of course we already have a list of ideas (only few about the architecture), see: http://old-en.opensuse.org/YaST/Development/Research Discussion is opened. ciao Arvin -- Arvin Schnell, <aschnell(a)suse.de> Senior Software Engineer, Research & Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

19 118

Re: [yast-devel] Features of the YCP successor
by Terje J. Hanssen 11 Feb '11

11 Feb '11

On Thu, 03 Feb 2011, Duncan Mac-Vicar P. wrote: > On 02/02/2011 09:33 PM, Patrick Shanahan wrote: > > * Birger Kollstrand<birger.kollstrand@xxxxxxxxxxxxxx> [02-02-11 > 13:20]: > ... > > Also something to consider is in which platforms it should be > usable. > Gnome, KDE, +++ and also which HW platforms. Server? Desktop? > Netbooks, Pads, appliances, mobile phones? > > > I was of the opinion (?mistakenly?) that YaST# was an openSUSE > tool, not a > desktop specific application. > > Only considering Gnome/KDE and Server/Desktop would limit the > possible > userbase tremendously. > > > > This is a very important part because as Linux evolved and YaST stayed > the same, the needs for YaST are different. > > Look at the desktop: > > Who needs sound configuration? In 2003 it was pretty useful, but > nowadays I only used the module to enable or disable pulseaudio, which > is a thing the user should not care about as this switch exists only > because pulseaudio was broken. > > Printer? I don't remember configuring a printer since long time. They > just show up. > > Network. I only use yast2 lan when I break my factory system's > networkmanager. > > Package Management? See how beautifully integrated package management > is in the KDE-4 user-mode control center. No root, simple interface. > For something more advanced you have zypper, for something more > friendly there is an appstore coming. > > The only parts I see relevant in _my_ laptop to setup via YaST is > fingerprint reader because they don't work out of the box (why?). I > also create users because there is some extra magic in the way YaST > does it. May be firewall. > > However all the above could be done directly from the desktop, because > you need app integration: ie, install P2P program, it should be able > to open a port from the application. > > So what is really YaST role in the desktop? Hi all, As I've just jumped on this list; shortly my background was first Unix since SVR5v.1, next SunOS/Solaris and third Linux since SUSE v.8.x, primary as user, secundary as administrator, but not as developer. Currently I also try to help with some openSUSE testing. IMO YaST tools has been the sole of SUSE, and YaST is what makes SUSE better and easier to configure than some other popular distributions I've had a look at. Indeed I felt only SUSE/YaST Linux was really better, easier, more advanced options and comprenhensive than the Solaris/Solstice gui admin-tools I had used in the nineties. I agree the YaST Control center and system admin tools must evolve and be revised according to what evolves as standard gui admin tools on the Linux desktops. Personal related desktop tools have already been collected as in the Gnome Control Center. As other Linux users and reviewers sometimes claim that YaST is unknown, confusing or difficult to be used with, it should be looked at if the YaST menu integration, task overview and user access can be designed even better. YaST's role on the desktop? Possibly not a directly answer or some off-topic, here is yet my opinion and user experience. First I like YaST as the common SUSE tools between all DE on openSUSE and SLE workstation as well as servers. Though Gnome is my primary desktop, I prefere to set it up with the qt interface, of course using YaST itself: YaST2 > System > Sysconfig_Editor > System > YaST2 > GUI > Wanted_GUI = qt I use DE and YaST on both networked laptop, workstation and combined workstation/server at home. As all my machines use local disks. networked mounted file systems and contain redudant and distributed data, file sharing, SSH/SFTP login and file transfer are used both for clients and servers. Even our SLES/OES2 server on my office has Gnome DE and YaST as standard installation available for the Xen dom0 console. How to remotely access the common known YaST tools may optionally vary through 'NX' or 'SSH -X' access. Here is my YaST grouped list of common used tools, sometimes in parallell with command line tools, which I feel complement each other: Hardware: *Hardware information *Scanner (easy setup for my Epson SCSI scanner, which has been difficult on other distros) *Printer (easy setup for our office network printer, as iPrint won't work for me on SUSE desktops) *Sound (previously for older hardware) Network devices: *Network setting (as backup if NM is broken and for VM with bridged network card) Networked services: *NFS, client and server *Samba, client and server *SSHD configuration (useful addon for easy setup of SSH/SFTP after initial OS installation) *xinetd security and users: *User and group management *Security center and hardening (typical predefined security for networked workstations) *Firewall Software: *Addon products *Software Management (software patterns, single packages and solving dependices, and else zypper up/dup) *Software repositories or Management (to add/edit repositories easier than with zypper) *Online Update (less used option) *Package search (webpin) system: */etc/sysconfig Editor (switch GDM/KDM, autologin, YaST with qt) *Partitioner (for overview and easy edit mount partions instead of /etc/fstab) *System services (Run level) Virtualization: *Create VM (Xen and install OS) *VM Manager (easy start/stop of Xen VMs) Terje J. Hanssen -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 2

[yast-devel] Amaranth: Why Ruby
by Martin Vidner 11 Feb '11

11 Feb '11

Amaranth: Why Ruby ================== Robert suggested a survey to choose the language, but that would omit the reasoning, the criteria. The implied criterion is: - popularity among current and potential contributors where Ruby wins the SUSE WebYaST people and other SUSE web/Rails developers Let me add other ones I could think of: - existing code base We have YaPI and User in Perl We want to interface with WebYaST in Ruby - the above two combined: libraries and contributors of other distros' yast-like tools Fedora, Ubuntu, Pardus use Python - runtime efficiency it matters for installation RAM requirements I don't have the data. Anyone? So far I found http://eigenclass.org/R2/writings/object-size-ruby-ocaml which basically says that rb 1.8 has bloated @members so use 1.9 or structs. In the end I think that barring a veto by another criterion, the most important one is the availability of developers to make the transition. That results in Ruby, but I may be wrong and maybe there are five of you who will say "Yes! As long as it's Intercal!" Please reply with insights into the criteria already mentioned, your preferences, or other criteria. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu

10 23

[yast-devel] Git branching model
by Josef Reidinger 09 Feb '11

09 Feb '11

Hi, this article[0] show quite interesting branching mode (with respect to develop new features, hot fixes (PTFs), maintenance branches and remerging fixes in maintenance back to master). Of course it is possible to do it also in svn, but I think that when you compare how easy it can be done in git and imagine what you need to do in svn, then you see one of git strength. Pepa [0] http://nvie.com/posts/a-successful-git-branching-model/ -- Josef Reidinger Appliance Toolkit team maintainer of perl-Bootloader, yast2-bootloader and parts of webyast and SLMS -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

YaST Development February 2011