[yast-devel] what about a web interface?
(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@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 4/27/07, cies <cies.breijs@gmail.com> wrote:
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.
No, yast is a development platform, the modules developed on it can be displayed using any of the available toolkits without modification. Currently this includes Qt, Ncurses, and GTK+.
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).
We have ncurses widget set for yast2, it is also possible to expose functionality of yast modules to a true command line interface.
the solution can be new: why not do the configuring from a webpage (that at the same time has a command line interface)?
We could in theory have a web-widget set for YaST, which would give web access, whether this happens depends whether anyone is interested enough to do it I suppose. iirc a web widget set for YaST using Wt was even suggested as a SoC project.
reasons why: - no gnome/kde/whatever dilemma
This doesn't exist at present, yast is toolkit independent.
- today with AJAX we can make very good looking interfaces. - webpages are easier to 'fix' (usability wise) - more people can help
Easier to fix perhaps, depends how the pages are generated, also it introduces a whole load of problems, like how it looks in different browsers.
features: - plugin based
Already have this
- written in ruby (or python) ((biased? who, me?))
- stylesheets can be used for theme creation I believe YaST has some limited themability already, more could be be
(eww;) at the moment yast modules can be written in YCP or Perl provided if there were a web interface.
- a command line interface (new to the locally served web page)
YaST already has this in addition to the ncurses widget set.
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
All laudable goals.
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)
I won't comment on this, other to say that I won't comment on it, as it has been discussed to death elsewhere.
conclusion: obvious to me: re-write.
Obvious conclusion to me, this doesn't require a re-write
please think big!
Please realise how great and extensible the YaST platform already is.
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.)
LOL _ Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 4/27/07, Benji Weber <b.weber@warwick.ac.uk> wrote:
On 4/27/07, cies <cies.breijs@gmail.com> wrote:
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.
No, yast is a development platform, the modules developed on it can be displayed using any of the available toolkits without modification. Currently this includes Qt, Ncurses, and GTK+.
i didnt know about GTK+... i have the (unfounded) believe that is might be due to yeast supporting so many backends that it is a little user-unfriendly. but i dont know this for sure -- and maybe with some fixes (on all the back ends) it might end up very user friendly ;) with user-unfriendly i mean: many dialogs, many popups, no search, help function is not very integrated with the tool, little or no use of wizards (which would help out a lot)
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).
We have ncurses widget set for yast2, it is also possible to expose functionality of yast modules to a true command line interface.
i know and knew and think this is a very important feature.
the solution can be new: why not do the configuring from a webpage (that at the same time has a command line interface)?
We could in theory have a web-widget set for YaST, which would give web access, whether this happens depends whether anyone is interested enough to do it I suppose. iirc a web widget set for YaST using Wt was even suggested as a SoC project.
i still think a solution with web/command-line i'faces only would be less hassle and can end up more polished that yast.
reasons why: - no gnome/kde/whatever dilemma
This doesn't exist at present, yast is toolkit independent.
why are the GTK-only replacements for yast funtionality then? and why have these replacements been pushed so hard (i think i can say against the will many users)
Please realise how great and extensible the YaST platform already is.
i did (suse pre 10 dayse), but then (suse post 10 days) i started to dislike it. anyway, you gave me a bit more hope for yast in its current shape. thanks!
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.)
LOL
yep, funny. still i have much better overall experience with DEB, an i truly wonder: why? it seems so much faster, and more clever... maybe my perception is a little distorted. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 4/28/07, cies <cies.breijs@gmail.com> wrote:
yep, funny. still i have much better overall experience with DEB, an i truly wonder: why? it seems so much faster, and more clever... maybe my perception is a little distorted.
Perhaps so, since APT is notoriously dumb with decisions and the libapt interface is meant to be pretty horrible, this is part of the reason why Ubuntu even considered switching over to the 'Smart' Package Manager. Thing is, most likely case whenever a _user_ thinks that DEB is superior to RPM for a given reason, it's probably quite baseless. With regard to YaST, it is truly wonderful and still -- after so many years -- _still_ something that no other distributions have even a remote match to. Kind thoughts, -- Francis Giannaros Web: http://francis.giannaros.org IRC: apokryphos on irc.freenode.net -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
I forgot to include some links: YaST architecture (NB there's a GTK+ widget set as well as Qt and Ncurses since time of writing): http://targnum.penguin.org.il/presentations/BrainShare2006/YaST%20Architectu... The Wt widget set is proposed on http://en.opensuse.org/Summer_of_Code_2007 Also see http://forgeftp.novell.com//yast/doc/SL10.2/ for other FAQs and how to develop modules that will work with any of the available widget sets. _ Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
thanks, _c. On 4/27/07, Benji Weber <b.weber@warwick.ac.uk> wrote:
I forgot to include some links:
YaST architecture (NB there's a GTK+ widget set as well as Qt and Ncurses since time of writing): http://targnum.penguin.org.il/presentations/BrainShare2006/YaST%20Architectu...
The Wt widget set is proposed on http://en.opensuse.org/Summer_of_Code_2007
Also see http://forgeftp.novell.com//yast/doc/SL10.2/ for other FAQs and how to develop modules that will work with any of the available widget sets.
_ Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
-- "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson (Nintendo, Inc), 1989 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
cies wrote:
the solution can be new: why not do the configuring from a webpage (that at the same time has a command line interface)?
I'm writing just to add some more pieces of information into this shaker :)
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
We were doing some research in web-based technologies for YaST web-interface and I'd like to present it here just to avoid the same mistakes we did. All of the following comes from myself (and my experience) and SUSE/Novell is not responsible for the flame-war that could be started by some of my thoughts :) This is a reply to the initial mail, that's why the text has a form of a reply... reason why not: - we don't have any dilemma concerning GNOME/KDE/whatever but we had a dilemma which browsers would be supported because we had realized that every single browser supports CSS/JavaScript/HTML in its own way and even the same browser (Firefox) might differ from Linux to Windows. - It's true that AJAX can help creating very cool-looking web-interface but consider the high price we would have to pay: AJAX is very insecure and very unreliable when used for development by non-super-web-hackers. Some links: * AJAX Vulnerabilities Could Pose Serious Risks http://www.eweek.com/article2/0,1895,1998795,00.asp * Fortify identifies JavaScript vulnerability in AJAX apps http://www.networkworld.com/news/2007/040207-javascript-ajax-applications.ht... * http://www.owasp.org/index.php/Testing_for_AJAX_Vulnerabilities http://www.owasp.org/index.php/Testing_for_AJAX_Vulnerabilities * Ajax Exploit Threatens Web 2.0 Security http://www.profy.com/2007/04/06/ajax-exploit-threatens-web-20-security/ * Google http://www.google.com/search?q=ajax+vulnerabilities - AJAX also causes quite high network traffic and quite high server load - Web-pages might be better-understandable for common people than currently YaST is because browsing web is something that people do all the day ;) But a saw a lot of people confused and lost in AJAX-driven web-pages, particularly because of the slower server response. - More people can help wit development, but on the other hand, more people can do more security errors. That's the very same with PHP - it's such an easy programming language for web-interfaces that so many people try developing with it. PHP is not dangerous when developers know what they are doing, but a very high percent of them certainly don't know even if they think they know. - Consider the fact that we need, at least, some part of the web-server running with root privileges. That's what actually all clever web-administrators refuse to do ;) - Authentication a connection must be encrypted (SSL) otherwise you would have to use the web-interface only locally. So where is the advantage of web now? Web makes sense for remote administration. (And YaST allows a secure remote administration, ssh+YaST in ncurses or ever in ssh+forwarded_X(Qt/GTK). - Actually I could image installation process through a web-server but I can't see any advantages of it, rather disadvantages. If you still want to install using Firefox with JavaScript, try VNC installation: http://en.opensuse.org/Linuxrc (VNC, VNCPassword)
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
feature problems: - Ruby / Python or even Perl doesn't provide so much controllability as YCP does. It rarely happens that YaST is killed by some exception that is not handled properly, it's mainly because YCP has a very good syntax checker and doesn't allow you to make mistakes. If only I could say that about web-scripting languages :( How often an 'Internal Server Error' happens if you think that everything goes smooth? - Stylesheets (CSS) si the problematic part of almost all web-browsers (almost all, because some of them just don't support CSS at all). Actually you can't find two web-browsers that would support CSS the same way as another one does. That's why using CSS might become rather a disadvantage. Yes, I know, that's life and we have to deal with it, CSS are cool :) - YaST already has a commandline interface for the most important modules, even for the majority of less-important ones ;) - Putting all this into a specially-crafted browser can be a feature. That would be two disadvantages at least: 1.) Very limited usage (only one browser) 2.) Somebody would have to maintain such a big package just for one purpose
strategic: - try to cooperate with other distributions - share the development - seek cooperation with openusability.org - uniformize linux configuration -- users benefit
- I saw a lot of articles about openSUSE and it seems that YaST is loved for its usefulness. - We pro-actively seek cooperation with opensuse.org - Other distributions (RedHat, Debian, ...) tried / are trying to port YaST and we actually offered them our help. - CIM or something similar seems to be better for unifying Linux configuration. Almost all web-based technologies have problem to distinguish between web-interface and logic-layer. YaST has even three layers: SCR (works with system), Logic (API), UI. I've tried a simple example of using YaST libraries connected via Perl to the web-based UI handled by apache (using FCGI). It was a YaST-Firewall in web and worked well :) Moreover, we had/have an OpenExchange Server having quite nice and useful web-interface. http://images.google.com/images?q=suse%20linux%20openexchange%20server Conclusion? Do we need any just now :)? -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic
On Friday 27 April 2007 10:06, Lukas Ocilka wrote:
- YaST already has a commandline interface for the most important modules, even for the majority of less-important ones ;)
... and if some module is lacking such support, it is most likely a bug. If you find some, report it via bugzilla :-) Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Friday 27 April 2007 10:06:23 Lukas Ocilka wrote:
feature problems: - Ruby / Python or even Perl doesn't provide so much controllability as YCP does. It rarely happens that YaST is killed by some exception that is not handled properly, it's mainly because YCP has a very good syntax checker and doesn't allow you to make mistakes. If only I could say that about web-scripting languages :( How often an 'Internal Server Error' happens if you think that everything goes smooth?
Why not Wt, Wt is C++ and has the same classes as Qt.
- Stylesheets (CSS) si the problematic part of almost all web-browsers (almost all, because some of them just don't support CSS at all). Actually you can't find two web-browsers that would support CSS the same way as another one does. That's why using CSS might become rather a disadvantage. Yes, I know, that's life and we have to deal with it, CSS are cool :)
That is handled in part by the toolkit. -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Duncan Mac-Vicar Prett wrote:
On Friday 27 April 2007 10:06:23 Lukas Ocilka wrote:
feature problems: - Ruby / Python or even Perl doesn't provide so much controllability as YCP does. It rarely happens that YaST is killed by some exception that is not handled properly, it's mainly because YCP has a very good syntax checker and doesn't allow you to make mistakes. If only I could say that about web-scripting languages :( How often an 'Internal Server Error' happens if you think that everything goes smooth?
Why not Wt, Wt is C++ and has the same classes as Qt.
- Stylesheets (CSS) si the problematic part of almost all web-browsers (almost all, because some of them just don't support CSS at all). Actually you can't find two web-browsers that would support CSS the same way as another one does. That's why using CSS might become rather a disadvantage. Yes, I know, that's life and we have to deal with it, CSS are cool :)
That is handled in part by the toolkit.
Yes, of course, Wt library used just as another optional UI (additionally to Qt/ncurses/GTK+) might work, but dropping all YaST and replacing it with something else doesn't make any sense. By the way, even when using that library, we would/will have to deal with more security problems than we do now. Web is very insecure by default. I wasn't talking about CSS from the toolkit/server side but from the client side - a browser. Every single browser handles CSS differently, some of them even don't support CSS at all. -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic
On Friday 27 April 2007 11:19:08 Lukas Ocilka wrote:
I wasn't talking about CSS from the toolkit/server side but from the client side - a browser. Every single browser handles CSS differently, some of them even don't support CSS at all.
Again, most of the web toolkits provide an abstraction layer over css and js generation, and perforrm browser negotiation when the app is created. there will be always quirks, but I dont think it is an issue. -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Fri, Apr 27, 2007 at 11:19:08AM +0200, Lukas Ocilka wrote:
I wasn't talking about CSS from the toolkit/server side but from the client side - a browser. Every single browser handles CSS differently, some of them even don't support CSS at all.
CSS isn't that incompatible. Sure IE had the margin bug and there are other problems but altogether it's mature. Browsers laking CSS support are simply unusable nowadays. Try to view any decent page in Firefox and turn CSS of - it's simply a nightmare. ciao Arvin -- Arvin Schnell, <aschnell@suse.de> Software Engineer, Research & Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Lukas Ocilka <lukas.ocilka@suse.cz> [Apr 27. 2007 10:06]:
- It's true that AJAX can help creating very cool-looking web-interface but consider the high price we would have to pay: AJAX is very insecure and very unreliable when used for development by non-super-web-hackers.
Otoh, a lot of internet sites deployed solutions including ajax technology quite successful.
Some links:
We could also post some links why internet, kernel, life, whatever is extremely risky ;-) Security threats exists everywhere. But we should not limit our thinking by such doubts in the first place.
- AJAX also causes quite high network traffic and quite high server load
Ajax done right causes the opposite since it only transfer whats really needed and not the whole dialog.
- Consider the fact that we need, at least, some part of the web-server running with root privileges. That's what actually all clever web-administrators refuse to do ;)
And they're right in doing so. Requiring the web server running as root is broken design. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Klaus Kaempf wrote:
* Lukas Ocilka <lukas.ocilka@suse.cz> [Apr 27. 2007 10:06]:
- It's true that AJAX can help creating very cool-looking web-interface but consider the high price we would have to pay: AJAX is very insecure and very unreliable when used for development by non-super-web-hackers.
Otoh, a lot of internet sites deployed solutions including ajax technology quite successful.
And I would bet that they can be hacked through it -- This might start a flame-war ;) :)
Some links:
We could also post some links why internet, kernel, life, whatever is extremely risky ;-)
Security threats exists everywhere. But we should not limit our thinking by such doubts in the first place.
I didn't want to say: Hey, life is risky, don't try that at home ;) My intention was: Hey, there is a security risk, so if you want to create something using AJAX, think twice (or rather more). Comparing to Internet, life, and everything: Some hobbies are just more risky than other ones. Mountain climbing is more risky than collecting post-stamps, even if you can passionately argue which stamp is nicer. More development possibilities == more security risks you have to care about.
- AJAX also causes quite high network traffic and quite high server load
Ajax done right causes the opposite since it only transfer whats really needed and not the whole dialog.
It depends on the load on the server ad the distance between the client and the server. In some cases, a working solution would block work using a slower connection.
- Consider the fact that we need, at least, some part of the web-server running with root privileges. That's what actually all clever web-administrators refuse to do ;)
And they're right in doing so. Requiring the web server running as root is broken design.
Yes, nobody needs to run the server as 'root' but you still somehow need to authenticate and get 'some' higher rights in 'some' layer to change the system, otherwise you couldn't do anything (again, flame war, $everything is possible). Anyway, again, I don't want to argue. Web or web-interface is a nice idea however there are many ways how to do it and also how NOT to do it. I will not laugh at anybody who tries AJAX+Ruby instead of YaST ;) L. -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic
I think ths discussion is flawed because everything concentrates in the UI which is not a real issue. The real question is, is YaST a monouser application or a server service? that is the real difference that has made it a challenge. Do you keep YaST running listening for connections? or you do dirty hacks to launch the service and the browser at the same time (remember the web-updater local version crap) ? When you ignore the model, then issues start to show up. IMHO, if you turn it into a webmin-like stuff, then the web interface has lot of value. But just to replace the local toolkit in a monouser application like YaST behaves now, it is just waste of time and resources. Perhaps you can provide a good experience if YaST would handle the browser itself. Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 4/27/07, Duncan Mac-Vicar Prett <dmacvicar@suse.de> wrote:
I think ths discussion is flawed because everything concentrates in the UI which is not a real issue.
i started this thread ;) my problems with yast are basically the UI and the slow-as-hell package manager.
The real question is, is YaST a monouser application or a server service? that is the real difference that has made it a challenge.
that question is a real as any other questionmarked sentence. it might be a different question, fit for a different thread.
IMHO, if you turn it into a webmin-like stuff, then the web interface has lot of value. But just to replace the local toolkit in a monouser application like YaST behaves now, it is just waste of time and resources. Perhaps you can provide a good experience if YaST would handle the browser itself.
thanks for the input! -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hi Cies, I was very interested in your E-mail and I hope we can discuss it a little :-)
i just get home from a party, and read an announcement that yast is now 'community'. the party was good though.
:-)
i loved suse, but not anymore. mainly because of yast.
Glad you tell us :-)
- a good package manage system
Actually we started working on this this week :-)
- an integrated product
In which ways do you lack integration?
- some sane defaults everywhere
Can you please provide some examples?
suse from 10 onward was (imho) lacking all. yast basically didn't change; it also was not very 'community'.
I see your point.
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.
In what ways?
so yast is a problem
I wouldn't go that far :-)
the solution can be new: why not do the configuring from a webpage (that at the same time has a command line interface)?
We are discussing that internally.
please think big!
We will! :-)
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.)
What would be the advantage of it? Why are we using RPM instead of DEB? As you probably got from my answers, we are currently discussing and start working to change some issues but I it good to have some additional input to them as well. Thanks and enjoy, Martin -- Martin Schmidkunz User Experience Specialist martin.schmidkunz@novell.com +49 (0) 911 740 53-346 ------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ------------------------------------- Novell, Inc. SUSE® Linux Enterprise 10 Your Linux is ready http://www.novell.com/linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
- a good package manage system
Actually we started working on this this week :-)
ok.
- an integrated product
In which ways do you lack integration?
well basically it boils down to that im a kde user, and slowly i got more and more gtk based apps running by default. i dont mind gtk, for gimp or inkscape, or whatever. but i do mind beagles and updaters and ZEN-stuff that comes in, falling from the sky, hurting my system performance, not integrated with my desktop. i dont need mono running. i dont need 2 toolkits loaded. i just want an integrated desktop 'experience'.
- some sane defaults everywhere
Can you please provide some examples?
like have the apps i just talked about running by default. they made my system useless. this is quite bad: i upgrade -- system gets too slow to use. of course i can turn that off... as i did. i dont know what caused it (i just moved on from suse that week), but installing a simple packages from yast took like 15 minutes (okay i like to have a lot of package repositories). 15 minutes to install a 15k package! i can do it faster by compiling it from source.
suse from 10 onward was (imho) lacking all. yast basically didn't change; it also was not very 'community'.
I see your point.
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.
In what ways?
i way that yast was suse's property, its asset like a webserver/database/kernel/webbrowser user to be a nice product to 'have' as a company. now we have apache/mysql/linux/mozilla (just examples) so selling your webserver/database/kernel/webbrowser gets much harder. same for yast i think. there are quite solid open source 'community' replacements for yast, so it becomes a burden to maintain it inhouse as it has little added value -- so it gets open sourced.
so yast is a problem
I wouldn't go that far :-)
i understand your point. but maybe i can say 'burden' then. a burden to suse.
please think big!
We will! :-)
good.
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.)
What would be the advantage of it? Why are we using RPM instead of DEB?
it seems so much faster, and more clever... maybe my perception is a little distorted. with kubuntu i'm now installing a 15k package in less than 15 seconds; in yast it was 15 minutes -- and i still like to have many package repositories. thanks! _c. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Sáb, 2007-04-28 às 11:40 +0200, cies escreveu:
- an integrated product
In which ways do you lack integration?
well basically it boils down to that im a kde user, and slowly i got more and more gtk based apps running by default. i dont mind gtk, for gimp or inkscape, or whatever. but i do mind beagles and updaters and ZEN-stuff that comes in, falling from the sky, hurting my system performance, not integrated with my desktop. i dont need mono running. i dont need 2 toolkits loaded. i just want an integrated desktop 'experience'.
Currently, KDE uses opensuse-updater, instead of zen-updater, and Beagle is both provided via Suse's custom KDE menu and Kerry. About Beagle's daemon using Mono, that probably doesn't impact performance much, since it is a low priority process and is disk bound. I'm sure those folks have considered it when designing it. You can disable it anyway.
i dont know what caused it (i just moved on from suse that week), but installing a simple packages from yast took like 15 minutes (okay i like to have a lot of package repositories). 15 minutes to install a 15k package! i can do it faster by compiling it from source.
Yeah, that's a serious problem. Its not mostly Yast faults as it is just a frontend. The startup can't be improved, but the post-scripts could be run at background. Maybe something nice as well would be that when the user hits the button to apply its changes, it would just show a progress bar installing/removing the packages, instead of going all the way to a new screen. And allow the user to keep looking at and selecting packages. I can't be the only one that has forgotten to install something, only to have to wait the all time to be able to go install another package. That ending dialog "Install more packages? [yes] [no]" has also triggered me to press "no". (I'm used to an application that says "Really quit? [yes] [no]" heh). I can't see the use of such dialog anyway; you can just click the close button of Yast (or hit the cancel button, or through the menu, or alt+f4/ctrl+q or whatever). Cheers, Ricardo -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hi Cies, As stated, Yast is modular, so that would be an addition, not a replacement. Btw, is remote system administration useful? I mean, it would only be good for a subset of the modules. But I guess it could open doors to diagnostic tools, and be really helpful to help someone on the site. On the concerns, according to their features pages, it seems Wt has been tested on all major browsers, and it can communicate through HTTPS. With regard to authentication, I think that's work for the server side framework we would need to work on anyway. One possible problem is the layout. According to them, Wt differs from your usual toolkit and operates more similar to CSS here; obviously, we can't have YUI doing the layout for us. Like, yast-gtk we can do the layout on the interface, but even for yast-gtk containers had to be implemented to shape the thing to fit both sides; we need to see if this would be doable for Wt. I think that just honoring the relative positioning of the widget would be good enough; relative stretching would just be a bonus. About ditching YCP for Python, yeah, I would like to see that. ;) Cheers, Ricardo Sex, 2007-04-27 às 05:20 +0200, cies escreveu:
(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!
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Friday 27 April 2007 17:44:58 Ricardo Cruz wrote:
About ditching YCP for Python, yeah, I would like to see that. ;)
Last time I had to look for a Python class, it gave me the impression the Python people are not so diciplined and care much about consistency like the Ruby ones. Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (10)
-
Arvin Schnell -
Benji Weber -
cies -
Duncan Mac-Vicar Prett -
Francis Giannaros -
Jiří Suchomel -
Klaus Kaempf -
Lukas Ocilka -
Martin Schmidkunz -
Ricardo Cruz