Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
I've been meaning to write this for a week, but I wanted to do some research first. The more I read and thought on it, the issue became broader, the subject line kept changing and this message starting looking like an article. I will try to choose my words carefully; I do not intend to offend anyone nor do I want to appear biased.
I hadn't used any graphical package manager on fedora for almost a decade (yumex was the last one) because I had been burned too many times and I don't trust them, but after doing a little work in the AppData area, I thought I'd take a look at gnome-software. It is one of the most beautiful UIs I have ever seen. It is elegant, simple yet functional, tidy, gorgeous to look at and it manages to stand out from all the other "market" or "store" applications. It incorporates some of the competition's best features, while avoiding their pitfalls (try living with Ubuntu's software center for a couple of days). I wholeheartedly agree with Richard Hughes in that software centers compliant with the AppStream specification help promote applications and are beneficial to both the users and the developers.
About a week ago, while wondering why MATE applications do not appear in gnome-software, Richard was kind enough to point to a blog post from September 2013:
http://blogs.gnome.org/hughsie/2013/09/19/gnome-software-on-mate-and-xfce/
I thought that developers and users might find it useful, so to quote Richard:
*tl;dr:* If you want to run GNOME Software on MATE or XFCE you need to set an environment variable like GNOME_SOFTWARE_COMPATIBLE_PROJECTS=MATE,GNOME,XFCE
This might have gone unnoticed since then, but I think it is an issue worth (re)visiting.
I can understand and defend the design choices that have been made; allowing a user to mix and match packages from different DEs with different aesthetics, compiled against different/incompatible libraries or having three different applications appear as "Text Editor" or "Dictionary" would lead to a sub-optimal user experience. From that standpoint it makes sense to hide from the user packages tied to other DEs, especially if the same functionality is provided by Gnome packages. Of course, a user might install an application e.g. compiled against gtk2 and the result would be the same.
I have not tested this much in other Fedora versions, only in F22 with GNOME. There, the default value in org.gnome.software compatible-projects is set to 'GNOME', 'KDE', 'XFCE'. (see https://mail.gnome.org/archives/commits-list/2013-November/msg00656.html) I do not understand this particular choice to include some DEs and exclude others. Why not enable or disable all of them? LXDE and MATE developers might be prone to attribute this to malice. Personally, on almost every machine I use, I have mixed packages from various sources - some due to personal preference, others because they offer unique functions.
Then again, does gnome-software aspire to be a "universal" package manager on Fedora? If it does, then why not offer packages from every DE and metapackages for other environments? If gnome-software aims to be novice-user-friendly, at least the latter should definitely be an option. Let's not forget that Gnome is a modern desktop environment, that requires fairly modern hardware to run on and that is not always available. Also, can gnome-software be the distro-wide default package manager while adhering to the HIG?
Allow me to digress a bit. Sometime in 2000, my professor told me that in order to use some molecular modeling packages and to modify their FORTRAN source code, I had to get linux, so after some searching, I went to a local bookstore and bought SuSE 5.3 or 6.0, can't remember any more (on a 56k analog modem at the time, downloading the iso or doing a network install was out of the question). The box came with two massive manuals (and some cute stickers) from which I learned the concept of the window manager or desktop environment. The choices I had been given got me really excited (almost as much as when I got my mouse wheel working) and after some weeks of playing with each DE, I routinely switched from KDE to enlightenment or to fvwm, according to the requirements of the task at hand, or just my mood. For years I kept the habit of alternating between almost every environment that was packaged for my distro, until I did not have the time to keep up with every change, so I settled with GNOME (mostly). Then came GNOME 3 and in the ensuing upheaval I gave every other DE another try. These days I use GNOME on my workstation, MATE on a netbook I take with me whenever I have field work (which sometimes literally means working in a field) and on an ancient dual Athlon MP workstation. On some other systems I manage or have lying around, I run E19, XFCE, MATE and GNOME.
I have converted many friends and acquaintances over to linux, but for the past 2-3 years I don't think I have pointed anyone to anything but Ubuntu and I feel some guilt about it. For a number of reasons I can't quite put my finger on, Fedora does not "feel right" for newcomers. The upgrade process, software management and support time-frame are certainly among them. Most of these otherwise bright people have their IQ drop to the value of its logarithm when they sit in front of a computer screen and they all seem to suffer from a natural aversion towards the terminal and towards RTFM. I'm sure you are all well aware of them. When you tell them to go to fedoraproject.org and download the iso, you can be certain that a phone call is imminent, asking for step-by-step instructions, even though everything is well-documented. Explaining to them the difference between linux and distribution is hard and if you start talking about spins, they lose you. If they decide to search for a solution to an issue by themselves, they have no problem executing any commands they may find in a blog post from 2005, ignoring all the error messages that inevitably come along and then they will look genuinely surprised because something broke. Last week I upgraded my old workstation to F21. It has a GeForce 6800 that whenever I had used nouveau instead of nvidia's driver, seriously overheated and the computer sounded like the vacuum cleaners of yore. After the upgrade, I couldn't get to gdm, but entering MATE manually worked, so after a little digging, I found out about an issue with mutter and nvidia's driver. I tried a newer version of the driver from rpmfusion's build system, that didn't work, so I switched to lightdm. Now imagine one of those people, being faced with the same issue right after the adrenaline rush of upgrading with fedup. Even I have kept my main system on F20 because I need CUDA and I can't switch to OpenCL.
Many of these people however exhibited an excitement far greater than mine, when after complaining about Unity for various reasons, I presented them with the alternatives. They were happy to spend time trying out other DEs, pointing out what felt right and what wrong. Some of them tried all of KDE, Cinnamon, MATE, LXDE, XFCE, GNOME and Enlightenment, for weeks even, before deciding what worked for them and their workflow. To my semi-surprise, some of those on higher-spec machines ended up on GNOME, which I thought had a steeper learning curve compared to most of the others (I still had to tell them about hidden stuff like gnome-session-properties or to get gnome-tweak-tool and look in extensions.gnome.org for extensions).
Having said all that, I hear a lot of people complaining about losing users to Ubuntu, Mint and others, or why things like project Sputnik http://www.dell.com/learn/us/en/555/campaigns/xps-linux-laptop don't involve our community. The biggest issue here is which is the targeted user base of Fedora, if there is one? And what are the use cases we want fedora to cover? Can we have "Freedom" and be "First" and still cater to everyone's needs?
Well, that's it. Happy holidays everyone!
On Fri, Dec 26, 2014 at 3:32 PM, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
This is a great post and there are a lot of points worthy of discussion. I'm going to focus my reply on the ending (though there are several threads that could spawn from this).
The biggest issue here is which is the targeted user base of Fedora, if there is one? And what are the use cases we want fedora to cover?
Prior to Fedora 21, I'm not sure we could really claim to have a targeted user base. The products (or whatever name we settle on, see the council-discuss thread) are a great start to defining more specific target audiences. They're still relatively broad, but I expect that as they mature, we'll see that they better define what the target is and we'll be better at understanding who is actually using Fedora and for what.
Can we have "Freedom" and be "First" and still cater to everyone's needs?
No, and that's okay. We could get rid of either of those and still not cater to everyone's needs. The important thing is to meet the needs we're trying to meet. I personally consider "first" to be the most flexible of the foundations, in the sense that we could offer the occasional release with longer support without compromising it. I doubt we'll get a large share of the non-savvy user base in the same way that Ubuntu did, but we don't have to.
2014-12-26 23:45 GMT+02:00 Ben Cotton bcotton@fedoraproject.org:
This is a great post and there are a lot of points worthy of discussion.
And I was certain people would dismiss it saying "someone had too much eggnog this year"...
Prior to Fedora 21, I'm not sure we could really claim to have a targeted user base. The products (or whatever name we settle on, see the council-discuss thread) are a great start to defining more specific target audiences. They're still relatively broad, but I expect that as they mature, we'll see that they better define what the target is and we'll be better at understanding who is actually using Fedora and for what.
Well, the cloud product is a bit narrow in scope, the server is broader and the workstation is too broad. Yet still there are use cases that fall somewhere in between. The council's idea about a survey sounds good, but if it ever manages to get off the ground, implementing it will face a lot of problems.
Can we have "Freedom" and be "First" and still cater to everyone's needs?
No, and that's okay. We could get rid of either of those and still not cater to everyone's needs. The important thing is to meet the needs we're trying to meet. I personally consider "first" to be the most flexible of the foundations, in the sense that we could offer the occasional release with longer support without compromising it. I doubt we'll get a large share of the non-savvy user base in the same way that Ubuntu did, but we don't have to.
Actually we do have a VLTS (Very Long Term Support) release, CentOS, especially now that they've joined the family, but the connection is not immediately apparent. On the other hand, a rolling release might be better suited for the users who do not want to perform a clean install or full upgrade every six months. However we couldn't supplant Ubuntu and remain Fedora... In my view "First" is the defining characteristic of Fedora, but it wouldn't matter without the other three. A couple of years ago, I tried as an experiment to keep a Gentoo system on par with Fedora, installing almost every keyworded package as soon as it became available, but I gave up after a week; it was too much work for one person to keep track of changed dependencies, upstream patches etc.. While Gentoo is still very dear to me, there aren't enough people involved to do that kind of work and bring it all together as a whole in a six month time frame.
As far as "Freedom" goes, there is a fine balance to be kept. It would be nice to have tighter collaboration with hardware vendors, but not to the point where they dictate what and when should be shipped (nVidia and AMD come to mind). But seeing the same thread -"Black screen after upgrading to Fxx"- resurrected every six months in the forum is getting tiring.
I know I'm sort of reinventing the wheel here and probably every single point I have mentioned has been discussed before in a meeting, a particular mailing list, a wiki page, a SIG, etc., but the truth is that there is a daunting amount of bureaucracy and compartmentalization. To an outsider, or even to Fedora members belonging to a specific group it seems like we're flying on autopilot. There is also some difficulty for those who want to get involved and it's equally difficult to contribute without stepping on someone's toes. I've met people who wanted to contribute to Fedora, but chose to work on upstream projects because they had a hard time trying to grasp and fit in the organizational structure.
On Sat, 2014-12-27 at 15:57 +0200, Alexander Ploumistos wrote:
Actually we do have a VLTS (Very Long Term Support) release, CentOS, especially now that they've joined the family, but the connection is not immediately apparent.
CentOS is not a release of Fedora. It is a separate distribution which has Fedora as its upstream.
On 27 December 2014 at 21:53, Adam Williamson adamwill@fedoraproject.org wrote:
On Sat, 2014-12-27 at 15:57 +0200, Alexander Ploumistos wrote:
Actually we do have a VLTS (Very Long Term Support) release, CentOS, especially now that they've joined the family, but the connection is not immediately apparent.
CentOS is not a release of Fedora. It is a separate distribution which has Fedora as its upstream.
Minor correction, CentOS is unbranded RHEL and Fedora is not RHEL upstream (so far as I am aware anyway).
On Mon, Dec 29, 2014 at 8:26 PM, Rahul Sundaram metherid@gmail.com wrote:
Hi
On Mon, Dec 29, 2014 at 7:36 PM, Ian Malone wrote:
Minor correction, CentOS is unbranded RHEL and Fedora is not RHEL upstream (so far as I am aware anyway).
That is incorrect. Fedora is upstream for RHEL and therefore upstream for CentOS as well albeit, one step removed.
Rahul
CentOS is also "branded" in that it has trademarks, copyrights, and other legal existence. The relation is fascinating, especially because at least some of the CentOS developers are now Red Hat employees and Red Hat is publishing their free software at https://git.centos.org/. It's much like that when Red Hat used to publish its full binary distributions up until Red Hat 9. Their efforts there, and especially in funding and supporting Fedora development as a testbed for RHEL projects, has been an extremely effective business model for free software development.
On 30 December 2014 at 01:26, Rahul Sundaram metherid@gmail.com wrote:
Hi
On Mon, Dec 29, 2014 at 7:36 PM, Ian Malone wrote:
Minor correction, CentOS is unbranded RHEL and Fedora is not RHEL upstream (so far as I am aware anyway).
That is incorrect. Fedora is upstream for RHEL and therefore upstream for CentOS as well albeit, one step removed.
I stand corrected then. Anyone know when this changed?
* Ian Malone [30/12/2014 13:09] :
On 30 December 2014 at 01:26, Rahul Sundaram metherid@gmail.com wrote:
That is incorrect. Fedora is upstream for RHEL and therefore upstream for CentOS as well albeit, one step removed.
I stand corrected then. Anyone know when this changed?
This has always been the case. What made you think differently?
Emmanuel
On 30 December 2014 at 13:13, Emmanuel Seyman emmanuel@seyman.fr wrote:
- Ian Malone [30/12/2014 13:09] :
On 30 December 2014 at 01:26, Rahul Sundaram metherid@gmail.com wrote:
That is incorrect. Fedora is upstream for RHEL and therefore upstream for CentOS as well albeit, one step removed.
I stand corrected then. Anyone know when this changed?
This has always been the case. What made you think differently?
Thought I'd been told otherwise at some point in the past, but must have been a misunderstanding. Had thought they weren't that closely coupled, i.e. not direct forks, but looks like I was wrong.
On 26 December 2014 at 20:32, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
why not offer packages from every DE and metapackages for other environments?
I don't see how this addresses the multiple "Calculator" application problem I clearly outlined in my original blog post. Offering choices and configuration options in applications is not zero-cost, and people more qualified and eloquent than me have written why.
If gnome-software aims to be novice-user-friendly, at least the latter should definitely be an option.
I don't see the logic there, sorry. Novice users don't understand the fine nuances of the design choices of different desktop environments.
Can gnome-software be the distro-wide default package manager while adhering to the HIG?
It's the software application installer for GNOME, and GNOME just happens to be our chosen desktop environment. I don't think you can ask if GNOME software maybe isn't a suitable Fedora application installer because it doesn't give equal priority to MATE (a hostile fork of an old version of GNOME). GNOME Software even prioritizes GNOME software when running under KDE, and I'd hope Apper does the same for KDE apps on KDE.
I do suggest MATE ship their own software centre, or use gnome-software and just set an session-wide environment variable like I suggested a long time ago.
Richard
Am 27.12.2014 um 23:26 schrieb Richard Hughes:
On 26 December 2014 at 20:32, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
why not offer packages from every DE and metapackages for other environments?
I don't see how this addresses the multiple "Calculator" application problem I clearly outlined in my original blog post. Offering choices and configuration options in applications is not zero-cost, and people more qualified and eloquent than me have written why.
having choices and options is the reason why people switch to Linux, otherwise they can stay at OSX or Windows - protect people from having choices is a bad attitude and frankly if that would have been widespreaded around 2006 i would never became a Linux and network professional
If gnome-software aims to be novice-user-friendly, at least the latter should definitely be an option.
I don't see the logic there, sorry. Novice users don't understand the fine nuances of the design choices of different desktop environments.
if you hide anything you can they will stay novice users forever
On 27 December 2014 at 23:17, Reindl Harald h.reindl@thelounge.net wrote:
having choices and options is the reason why people switch to Linux,
http://www.islinuxaboutchoice.com/
Richard
Am 28.12.2014 um 13:57 schrieb Richard Hughes:
On 27 December 2014 at 23:17, Reindl Harald h.reindl@thelounge.net wrote:
having choices and options is the reason why people switch to Linux,
you can't dictate as developer the reason why users are making their decisions, you can ignore it, dislike it and what not, but you can't change it
On 28 December 2014 at 07:57, Richard Hughes wrote:
On 27 December 2014 at 23:17, Reindl Harald wrote:
having choices and options is the reason why people switch to Linux,
Oh please, no need for provocation... I was silently following this thread but I couldn't keep it that way after this post. There rant collection on the site lists the prime symptoms of "Gnome disease" and it is just too much for this mailing list.
I still think that Fedora should be the last place on earth to build an OS based on acquiescence of users as illiterate idiots.
I still have hope. Please don't crush my dreams.
Best, Orcan
Am 28.12.2014 um 22:13 schrieb Orcan Ogetbil:
On 28 December 2014 at 07:57, Richard Hughes wrote:
On 27 December 2014 at 23:17, Reindl Harald wrote:
having choices and options is the reason why people switch to Linux,
Oh please, no need for provocation... I was silently following this thread but I couldn't keep it that way after this post. There rant collection on the site lists the prime symptoms of "Gnome disease" and it is just too much for this mailing list.
I still think that Fedora should be the last place on earth to build an OS based on acquiescence of users as illiterate idiots.
I still have hope. Please don't crush my dreams
+1
and the page above is out of context crap beause it talks about developer ressources while the "software center" architecst talk about *hide* already existing software from users
WTF - just add a tab for "non so beautiful promoted but usefull and present packages" and *first* stop to talk about using a terminal in a hostile way all the time just because you don't realize that you *can not* place any useful operatin in a nice graphical interface
trying to keep users away from a terminal is *hostile* and *user unfriendly* because there are millions of operations you can do within seconds in a terminal for decades and will never be able to do in any graphical crap application
you want to hide all that capabilities from new users? than don't pretend to design a unix like operating system
2014-12-28 0:26 GMT+02:00 Richard Hughes hughsient@gmail.com:
On 26 December 2014 at 20:32, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
why not offer packages from every DE and metapackages for other
environments?
I don't see how this addresses the multiple "Calculator" application problem I clearly outlined in my original blog post. Offering choices and configuration options in applications is not zero-cost, and people more qualified and eloquent than me have written why.
I noted that a little earlier, I was asking about the available packages if the aim of gnome-software on fedora is to be the default graphical package manager. And of course that beautiful interface comes at the cost of choice. I can't remember on which distro I had this happen to me (perhaps Mandrake?), I wanted to install k3b and krename and I got all of KDE, including some games!
An interesting side-effect of having multiple packages with the same name: I accidentally opened xfce's dictionary on my girlfriend's laptop, and I saw that it had a speed reader! I had never used one before, so there was some enthusiasm in the discovery. There could be a silver lining in that cloud (though admittedly, having three of the basic apps is sometimes frustrating, I don't know how she manages to find the right one every time).
If gnome-software aims to be novice-user-friendly, at least the latter
should definitely be an option.
I don't see the logic there, sorry. Novice users don't understand the fine nuances of the design choices of different desktop environments.
However they do understand when their system is sluggish, say with Unity, or that this or that DE looks ugly, or is dysfunctional etc.. Using my friends as lab rats showed me that much and I was happy when each of them found the DE that worked best for them and their hardware. In light of that, maybe it would be a reasonable idea to have metapackages for other DEs in gnome-software with screenshots, descriptions and the occasional warnings, so people like them won't need someone over their heads reciting arcane incantations. Gnome's fallback mode is a shame, in that it's like having the engine of a 2CV in a sports car chassis (or maybe the other way around, I'm not sure).
Can gnome-software be the distro-wide default package manager while
adhering to
the HIG?
It's the software application installer for GNOME, and GNOME just happens to be our chosen desktop environment. I don't think you can ask if GNOME software maybe isn't a suitable Fedora application installer because it doesn't give equal priority to MATE (a hostile fork of an old version of GNOME). GNOME Software even prioritizes GNOME software when running under KDE, and I'd hope Apper does the same for KDE apps on KDE.
I do suggest MATE ship their own software centre, or use gnome-software and just set an session-wide environment variable like I suggested a long time ago.
I don't mind if gnome-software favors GNOME apps, or if Apper does the same. I have no interest in promoting any DE over another, I am only partial to echo $SHELL returning bash and while I kept my distance at the time of the fork, I am well aware of the harsh words that had been going back and forth. I am not expecting either side to forgive and forget, but I would like everyone to take the hostility down one notch (or even two, if possible), at least on this neutral ground. Such animosity is saddening. In retrospect, perhaps it was a mistake on my part to drag you into a conversation with a developer from the other side and I would like to apologize to you both for that. Should the need occur in the future, I will just convey the gist to and fro and filter out any jabs or innuendos.
With that out of the way, the AppStream specification has certainly made it possible for every DE to have an aesthetically satisfying software center. But what about the rest of the distribution and how is a terminal-averse or terminal-ignorant, new Fedora user supposed to install something like let's say p7zip, which has no GUI? I don't know if Archive Manager pulls it in as a dependency, but I think you can understand where I'm going with this example. Should Fedora build another program as a package manager (or have yumex installed by default) or do we say to our users that they should not touch Fedora if they are not willing to type a few commands every now and then - hence my other question about our targeted user base. I'm comfortable with either option, I would just like to know which one it is.
Cheers
On Sat, Dec 27, 2014 at 6:23 PM, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
I don't mind if gnome-software favors GNOME apps, or if Apper does the same. I have no interest in promoting any DE over another, I am only partial to echo $SHELL returning bash and while I kept my distance at the time of the fork, I am well aware of the harsh words that had been going back and forth. I am not expecting either side to forgive and forget, but I would like everyone to take the hostility down one notch (or even two, if possible), at least on this neutral ground. Such animosity is saddening. In retrospect, perhaps it was a mistake on my part to drag you into a conversation with a developer from the other side and I would like to apologize to you both for that. Should the need occur in the future, I will just convey the gist to and fro and filter out any jabs or innuendos.
I think the use of the term "hostile fork" was more of a technical note -- the MATE project disagrees with the direction of the GNOME project and has forked it into something very different, with no intention of future unification of the two projects -- than a comment on the tone of either project. I've never seen any mudslinging from a MATE developer directed at a GNOME, or vice versa. Things have been more or less amicable between developers from the two communities.
With that out of the way, the AppStream specification has certainly made it possible for every DE to have an aesthetically satisfying software center. But what about the rest of the distribution and how is a terminal-averse or terminal-ignorant, new Fedora user supposed to install something like let's say p7zip, which has no GUI? I don't know if Archive Manager pulls it in as a dependency, but I think you can understand where I'm going with this example. Should Fedora build another program as a package manager (or have yumex installed by default) or do we say to our users that they should not touch Fedora if they are not willing to type a few commands every now and then - hence my other question about our targeted user base. I'm comfortable with either option, I would just like to know which one it is.
This has been discussed at length on this list in the past, but not to a satisfactory resolution for those who feel that typical users will need to install packages.
* GNOME Software is not a package manager, and it is unlikely to become a package manager. It's just for installing applications. In GNOME 3, command line tools are not applications. * The current operating theory is that "normal users" will never need to install a package, and that exposing them to the package management layer by including a graphical package manager would be unnecessarily confusing. (Please accept my definition of "normal user" to be someone who doesn't use the terminal. Yes, that's a massive oversimplification, maybe not correct at all, and probably not representative of most Fedora users. Yes, Workstation targets developers, but not exclusively, and also developers who use fancy IDEs and who don't work with the terminal. I just don't want this thread to degenerate into a discussion of this lousy definition, since it's not important. What's important is that we want Workstation to be excellent for users who never touch the terminal.) * p7zip, being a command-line tool, is something "normal users" should never need. If Archive Manager needs it as a plugin, it can install it with PackageKit if it's not detected, or it should be a dependency in the RPM if Archive Manager doesn't support that. Hunting down a magic package name to install is not an acceptable user experience, and not something we should encourage or optimize for. Alternatively, it could include an appdata file so that it's listed as an Archive Manager plugin in GNOME Software, but I think that would be non-ideal in this case, since users should never have to worry about having the right packages installed to unzip an archive. * But if we're wrong, and normal users really do need to install packages, then we should probably include a graphical package manager so that users can actually find packages. I submit that improving GNOME Packages (aka gpk-application, the thing we installed by default until F20), something that's already used by other distros (notably Debian), would be a better use of our time than working on a Fedora-specific solution like yumex. Especially considering that yum is not going to be installed by default in F21. * I have to install packages all the time, and I'd much rather use a graphical package manager to find packages than to use yum or dnf. But I'm a (relatively) experienced user and I know how to navigate a graphical package manager. I expect that if a novice user were to open a graphical packager manager, he would become very confused very quickly, and we don't want any confusing software to be installed by default.
The question is: is it more confusing for novice users to include a graphical package manager by default, or to not include it? We're only talking about novice users here: an experienced user can always take 20 seconds to install his preferred graphical package manager with GNOME Software, so we don't care about what the experienced user wants for himself.
Michael
2014-12-28 15:02 GMT+02:00 Richard Hughes hughsient@gmail.com:
GNOME PackageKit is still available (and maintained upstream) and is what I use for installing things like mingw packages that I need for development. Just type "Packages" into the dash and gnome-software will install it for you :)
Oh, that was so nice! After typing the root password to install software, I got another prompt with "The software is not from a trusted source". Is that a rawhide issue?
How are user queries correlated to the package suggestions in the dash? I do not always get what I would expect, e.g. when I type IDE, I get Anjuta, Gnote and Rosegarden, with 3gp I get Frogr, Banshee, Xnoise and mpc yields nothing.
And a third, irrelevant question: has the "hot corner" been disabled or is it because I run f22 in a VM?
2014-12-28 4:15 GMT+02:00 Michael Catanzaro mcatanzaro@gnome.org:
- GNOME Software is not a package manager, and it is unlikely to become a
package manager.
I get that now, thank you.
- p7zip, being a command-line tool, is something "normal users" should
never need. If Archive Manager needs it as a plugin, it can install it with PackageKit if it's not detected, or it should be a dependency in the RPM if Archive Manager doesn't support that. Hunting down a magic package name to install is not an acceptable user experience, and not something we should encourage or optimize for. Alternatively, it could include an appdata file so that it's listed as an Archive Manager plugin in GNOME Software, but I think that would be non-ideal in this case, since users should never have to worry about having the right packages installed to unzip an archive.
So this means that a default Workstation installation should have a large number of non-graphical programs installed by default, or that the various applications will be compiled with every possible dependency, e.g. Archive Manager will pull in every possible compression/decompression back end?
- But if we're wrong, and normal users really do need to install packages,
then we should probably include a graphical package manager so that users can actually find packages. I submit that improving GNOME Packages (aka gpk-application, the thing we installed by default until F20), something that's already used by other distros (notably Debian), would be a better use of our time than working on a Fedora-specific solution like yumex. Especially considering that yum is not going to be installed by default in F21.
And that could lead to more confusion, at least from the "normal user" perspective, having both a package manager and a software center...
I just checked and there is now a yumex version based on dnf.
- I have to install packages all the time, and I'd much rather use a
graphical package manager to find packages than to use yum or dnf.
De gustibus non est disputandum. I find it easier to use yum, but when I need to check a lot of similarly named packages to identify the one I want or browse through a certain software category for programs, a graphical package manager is faster and less fussy.
The question is: is it more confusing for novice users to include a graphical package manager by default, or to not include it? We're only talking about novice users here: an experienced user can always take 20 seconds to install his preferred graphical package manager with GNOME Software, so we don't care about what the experienced user wants for himself.
This is not an easy question to answer. When I set up a computer for a "normal user" I ask them what they want to do with it, so I configure third-party repositories, install all the packages that offer the functionality they expect, which usually includes several proprietary applications and drivers as well. Finally I explain to them how package management on linux differs to that of windows and how to use a graphical package manager, searching either for the package name, or its definition (e.g. audio editor) and what sort of packages they should download from online sources (.deb/.rpm, x86_64/i686) when they aren't available in distro repos. Depending on their computer literacy, sometimes I show them how to install software from the terminal. Of the hundred or so linux installations I've done for others in the last few years, only two users stayed with my initial configuration and that is because they performed a limited set of tasks.
With all the others, the results were mixed. Most (but certainly not all) users have managed to install software successfully using package managers, namely yumex, GNOME PackageKit, an old version of YaST, Synaptic and Ubuntu's software center, but at times there was some confusion and frustration. A small number of users have tried to install windows executables and quite a few succeeded in doing that, because somehow WINE got pulled in. An equally small number have installed packages for the wrong architecture or for an older distro version. Then there were some surprises, with people compiling programs from source or installing commercial applications by following the vendor's instructions, but they seem to be the exception. The overwhelming majority of users that had to use the terminal to perform package management tasks because something broke along the way, struggled with the concepts of commands, flags, arguments and paths. They needed me to explicitly state where whitespace and slashes should be inserted, even if they had been regularly using the same or similar commands, albeit mostly via copy & paste. All of these people had different backgrounds, skills and, interests, but I wouldn't consider my sample representative.
I vaguely remember filling out a wizard-like questionnaire on the first run of a distribution, that collected some hardware and user information. There were questions like "Do you know what a window manager is?", "Do you compile your own programs and if yes how often?", etc.. Perhaps we could put together something similar to help us answer that sort of questions and combine it with the council's survey proposal. I could help with that and I could also reach out to some of my "test subjects".
On Sun, Dec 28, 2014 at 11:08 AM, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
2014-12-28 15:02 GMT+02:00 Richard Hughes hughsient@gmail.com:
GNOME PackageKit is still available (and maintained upstream) and is what I use for installing things like mingw packages that I need for development. Just type "Packages" into the dash and gnome-software will install it for you :)
Oh, that was so nice! After typing the root password to install software, I got another prompt with "The software is not from a trusted source". Is that a rawhide issue?
Yes, all packages in rawhide are unsigned, so that warning is expected. Don't use rawhide if you need your packages to not be malicious.
Note that the root password was only requested because the software was unsigned -- if it was signed by Fedora, the installation would have been seamless.
How are user queries correlated to the package suggestions in the dash? I do not always get what I would expect, e.g. when I type IDE, I get Anjuta, Gnote and Rosegarden, with 3gp I get Frogr, Banshee, Xnoise and mpc yields nothing.
Sounds like a bug. When I type mpc I get Kid3-qt, Banshee, and Pogo.
I know it searches the appdata file description and desktop file keywords at least.
And a third, irrelevant question: has the "hot corner" been disabled or is it because I run f22 in a VM?
It's because you're using a VM.
- p7zip, being a command-line tool, is something "normal users"
should never need. If Archive Manager needs it as a plugin, it can install it with PackageKit if it's not detected, or it should be a dependency in the RPM if Archive Manager doesn't support that. Hunting down a magic package name to install is not an acceptable user experience, and not something we should encourage or optimize for. Alternatively, it could include an appdata file so that it's listed as an Archive Manager plugin in GNOME Software, but I think that would be non-ideal in this case, since users should never have to worry about having the right packages installed to unzip an archive.
So this means that a default Workstation installation should have a large number of non-graphical programs installed by default, or that the various applications will be compiled with every possible dependency, e.g. Archive Manager will pull in every possible compression/decompression back end?
No, I think it just means that applications should not be broken by default. Apps have the choice of pulling in every possible compression/decompression backend (good for commonly-used backends and backends that require few dependencies), installing them on-demand with PackageKit (the correct choice for uncommonly-needed backends, or backends with a large dependency tree), or expecting the user to magically figure out what package to install (always the wrong choice).
- But if we're wrong, and normal users really do need to install
packages, then we should probably include a graphical package manager so that users can actually find packages. I submit that improving GNOME Packages (aka gpk-application, the thing we installed by default until F20), something that's already used by other distros (notably Debian), would be a better use of our time than working on a Fedora-specific solution like yumex. Especially considering that yum is not going to be installed by default in F21.
And that could lead to more confusion, at least from the "normal user" perspective, having both a package manager and a software center...
Yup. :( A good argument for not including GNOME Packages by default.
The question is: is it more confusing for novice users to include a graphical package manager by default, or to not include it? We're only talking about novice users here: an experienced user can always take 20 seconds to install his preferred graphical package manager with GNOME Software, so we don't care about what the experienced user wants for himself.
This is not an easy question to answer.
Yup. :(
When I set up a computer for a "normal user" I ask them what they want to do with it, so I configure third-party repositories, install all the packages that offer the functionality they expect, which usually includes several proprietary applications and drivers as well.
I think that's past the line of what we can reasonably expect a novice user to handle. Proprietary apps are always going to be tough to install on Fedora, since they're not welcome in our software center. And novices who install proprietary graphics drivers are quite likely to wind up with a completely broken system. This is a hard problem.
Your closing story, which I won't quote, was helpful. I'd argue it makes a good case for shielding the user from normal packages with GNOME Software, but I don't have a good answer for what happens when you really need to install a package that's not a graphical application (when did your users need to do this?), nor for proprietary or patent-encumbered software (which we probably need to accept will always be difficult).
I vaguely remember filling out a wizard-like questionnaire on the first run of a distribution, that collected some hardware and user information. There were questions like "Do you know what a window manager is?", "Do you compile your own programs and if yes how often?", etc.. Perhaps we could put together something similar to help us answer that sort of questions and combine it with the council's survey proposal. I could help with that and I could also reach out to some of my "test subjects".
Hm, this would help us understand our current users better. That's valuable (no reason to not do it), but I don't think it's likely to sway opinions -- we all have our own idea about the type of users we should optimize for. I'd like to optimize for the hapless users in your examples.
Whether we include a graphical package manager or not (and I suspect the status quo will prevail), Fedora will still be great either way.
- p7zip, being a command-line tool, is something "normal users"
should never need. If Archive Manager needs it as a plugin, it can install it with PackageKit if it's not detected, or it should be a dependency in the RPM if Archive Manager doesn't support that. Hunting down a magic package name to install is not an acceptable user experience, and not something we should encourage or optimize for. Alternatively, it could include an appdata file so that it's listed as an Archive Manager plugin in GNOME Software, but I think that would be non-ideal in this case, since users should never have to worry about having the right packages installed to unzip an archive.
So this means that a default Workstation installation should have a large number of non-graphical programs installed by default, or that the various applications will be compiled with every possible dependency, e.g. Archive Manager will pull in every possible compression/decompression back end?
One more note here: if you try to run a command line program that isn't installed, PackageKit will search for it in all enabled repos, offer to install it for you if found, and then run the command. It's really a nice user experience, and it's what I use to install executables that I don't have. This only helps for executables, of course, and it doesn't help users who first attempt to find the package some other way.
On 12-28-14 11:46:09 Michael Catanzaro wrote:
One more note here: if you try to run a command line program that isn't installed, PackageKit will search for it in all enabled repos, offer to install it for you if found, and then run the command.
No real need when you can do:
$ sudo dnf install /usr/bin/missing-executable
(I erased PackageKit. :)
On 12/28/2014 06:46 PM, Michael Catanzaro wrote:
One more note here: if you try to run a command line program that isn't installed, PackageKit will search for it in all enabled repos, offer to install it for you if found, and then run the command. It's really a nice user experience,
I respectfully disagree. I consider this to be an utterly harmful feature, which could be enabled in a "noob-spin", but should be blocked from being installed in any room any other spin.
Ralf
Am 28.12.2014 um 18:39 schrieb Michael Catanzaro:
On Sun, Dec 28, 2014 at 11:08 AM, Alexander Ploumistos
How are user queries correlated to the package suggestions in the dash? I do not always get what I would expect, e.g. when I type IDE, I get Anjuta, Gnote and Rosegarden, with 3gp I get Frogr, Banshee, Xnoise and mpc yields nothing.
Sounds like a bug. When I type mpc I get Kid3-qt, Banshee, and Pogo
but you have no clue what mpc is
A client for MPD, the Music Player Daemon. mpc connects to a MPD running on a machine via a network.
http://www.musicpd.org/ https://koji.fedoraproject.org/koji/buildinfo?buildID=591118
2014-12-28 19:39 GMT+02:00 Michael Catanzaro mcatanzaro@gnome.org:
I think that's past the line of what we can reasonably expect a novice user to handle. Proprietary apps are always going to be tough to install on Fedora, since they're not welcome in our software center. And novices who install proprietary graphics drivers are quite likely to wind up with a completely broken system. This is a hard problem.
Even the lazy developer will at least expect to be able to watch flash videos and listen to mp3s. So they will have to deal with repositories and packages. Many people I know agree with FSF's core values, but they feel left out when they can't use what other people on other platforms are using.
Your closing story, which I won't quote, was helpful. I'd argue it makes a good case for shielding the user from normal packages with GNOME Software, but I don't have a good answer for what happens when you really need to install a package that's not a graphical application (when did your users need to do this?), nor for proprietary or patent-encumbered software (which we probably need to accept will always be difficult).
The most recent example I can think of, is the youtube-dl script.
When it comes to building from source, more often than not, it involves programs like this: http://www.cryst.chem.uu.nl/platon/pl002000.html
2014-12-28 20:04 GMT+02:00 Reindl Harald h.reindl@thelounge.net:
but you have no clue what mpc is
A client for MPD, the Music Player Daemon. mpc connects to a MPD running on a machine via a network.
http://www.musicpd.org/ https://koji.fedoraproject.org/koji/buildinfo?buildID=591118
Hmm, that's interesting. Although I was thinking of musepack audio files.
2014-12-28 21:10 GMT+02:00 Alexander Ploumistos alex.ploumistos@gmail.com:
2014-12-28 19:39 GMT+02:00 Michael Catanzaro mcatanzaro@gnome.org:
Your closing story, which I won't quote, was helpful. I'd argue it makes a good case for shielding the user from normal packages with GNOME Software, but I don't have a good answer for what happens when you really need to install a package that's not a graphical application (when did your users need to do this?), nor for proprietary or patent-encumbered software (which we probably need to accept will always be difficult).
The most recent example I can think of, is the youtube-dl script.
This just in: A friend had to use alsamixer to unmute a channel that got muted after an update and was not visible in sound settings.
On Sun, Dec 28, 2014 at 1:10 PM, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
2014-12-28 19:39 GMT+02:00 Michael Catanzaro mcatanzaro@gnome.org:
I think that's past the line of what we can reasonably expect a novice user to handle. Proprietary apps are always going to be tough to install on Fedora, since they're not welcome in our software center. And novices who install proprietary graphics drivers are quite likely to wind up with a completely broken system. This is a hard problem.
Even the lazy developer will at least expect to be able to watch flash videos
The workflow we have in F21 is this:
* Firefox asks if you want to install the Flash plugin. * Firefox takes you directly to Adobe's download page for Flash. * The user magically knows to select YUM for Linux (YUM) and downloads the provided RPM. * The user magically knows that he can double-click on the RPM (what's an RPM?) to open GNOME Software and install Flash.
I guess the magic leaps are somewhat unfortunate, but it's still easier than dealing with packages, I hope.
and listen to mp3s.
This is more difficult, since we cannot even point users towards where they might possibly find an MP3 codec. I don't think we can fix this without a super PAC or some form of regime change.
The workflow we have in F21 is this:
* Rhythmbox/Totem/Music/whatever tells you that you need a new codec to play the audio. * The graphical codec search looks in all enabled repositories for the proper plugin. * It fails because it's broken.
The expected behavior is for it to link to a wiki page that hints at the existence of rpmfusion, but we can't legally do more than that. Now, if the user somehow does manage to find the rpmfusion web site, download the repo RPM, and double click on it (and if codec installer gets fixed), then the codec installer should automatically find and install the codecs he needs when he tries to play the music, so no need for the user to know about gstreamer1-plugins-asdf-fugly et. al. (Of course, none of this works if you try to use random video players that don't know about PackageKit.)
So the experience should be 100% graphical. Finding the right RPM to enable the external repository on the Adobe or rpmfusion website is a pain and we need to improve that, but once you've done that you just double click on it and don't need to worry about packages. I think the biggest step we could improve here is the rpmfusion web site. They really need to replace their homepage with [1], and explain that Fedora apps will find the codecs you need automatically, so that users don't have to keep asking for help with this.
2014-12-28 21:38 GMT+02:00 Michael Catanzaro mcatanzaro@gnome.org:
The workflow we have in F21 is this:
- Firefox asks if you want to install the Flash plugin.
- Firefox takes you directly to Adobe's download page for Flash.
- The user magically knows to select YUM for Linux (YUM) and downloads the
provided RPM.
- The user magically knows that he can double-click on the RPM (what's an
RPM?) to open GNOME Software and install Flash.
I guess the magic leaps are somewhat unfortunate, but it's still easier than dealing with packages, I hope.
Why not throw in the first run help screen a couple of mentions to yum and rpm with big, bold letters? Yum is tasty and easy to remember!
and listen to mp3s.
This is more difficult, since we cannot even point users towards where they might possibly find an MP3 codec. I don't think we can fix this without a super PAC or some form of regime change.
Someone should have pitched this idea to Colbert before the elections, now it's too late... Is it reasonable to expect that mp3 codecs and libraries will make it to the main repos sometime in 2017?
So the experience should be 100% graphical. Finding the right RPM to enable the external repository on the Adobe or rpmfusion website is a pain and we need to improve that, but once you've done that you just double click on it and don't need to worry about packages. I think the biggest step we could improve here is the rpmfusion web site. They really need to replace their homepage with [1], and explain that Fedora apps will find the codecs you need automatically, so that users don't have to keep asking for help with this.
Or yet another first run screen...
On Sat, Dec 27, 2014 at 7:15 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
The question is: is it more confusing for novice users to include a graphical package manager by default, or to not include it?
tl;dr Oh absolutely it's confusing as well as incredibly frustrating. I think software installations should only happen through an application installer (e.g. GNOME Software, or OS Xs' App Store); or through drag and drop copy to install. That method of installation on OS X (I think it's actually a NeXT inheritance, we didn't have this on OS 9 and older) is fantastic as it uninstallation: drag and drop into the trash, empty trash.
Superfluous anecdote: The first time I ran GNOME Package years ago, you should have seen the WTFITS expression on my face. And that reaction wasn't about the UI, it was the hours long process of coming to grips with part of the software sausage making factory. I was surprised that this wasn't abstracted from me.
The natural explanation is that I was coming from Candy Land OS. But neither OS X nor Windows have a package manager. OS X does have a package installer that executes .mpkg and .pkg file installs, but there's no listing of what's installed or what can be installed and no concept of a repository. App Store can do those things but both App Store and GNOME Software post-date my first experience with a graphical package manager - which was, I'd have preferred getting sick. At least that'd have lasted two or three days and I'd be done with it. Package management is the gift that keeps on giving.
But insofaras this is what we're stuck with, I really like what Software has done to the UX, even though I had no choice but to first grok packages and package management before it came along. These days I don't mind yum and actually kinda like dnf. But still my preference would be to see packages obliterated from user domain for sure.
On 28 December 2014 at 00:23, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
Should Fedora build another program as a package manager
GNOME PackageKit is still available (and maintained upstream) and is what I use for installing things like mingw packages that I need for development. Just type "Packages" into the dash and gnome-software will install it for you :)
Richard
On 27/12/14 23:26, Richard Hughes wrote:
On 26 December 2014 at 20:32, Alexander Ploumistos
If gnome-software aims to be novice-user-friendly, at least the latter should definitely be an option.
I don't see the logic there, sorry. Novice users don't understand the fine nuances of the design choices of different desktop environments.
Possibly. But isn't there quite a difference between the "novice user" and the Fedora Workstation target user i. e., developers?
If so, it doesn't need to be bad - Gnome is is certainly not Fedora. But wouldn't it raise questions about the Gnome Software application's role in the workstation product?
Cheers!
--alec
On Sun, Dec 28, 2014 at 9:48 AM, Alec Leamas leamas.alec@gmail.com wrote:
Possibly. But isn't there quite a difference between the "novice user" and the Fedora Workstation target user i. e., developers?
Not necessarily. I wrote:
"Yes, Workstation targets developers, but not exclusively, and also developers who use fancy IDEs and who don't work with the terminal. I just don't want this thread to degenerate into a discussion of this lousy definition [of normal/novice users], since it's not important. What's important is that we want Workstation to be excellent for users who never touch the terminal."
Fedora currently suffers from the impression that it is a complicated OS for advanced users only, and that novices (including novice developers) should use Ubuntu instead.
On 28/12/14 18:05, Michael Catanzaro wrote:
On Sun, Dec 28, 2014 at 9:48 AM, Alec Leamas leamas.alec@gmail.com wrote:
Possibly. But isn't there quite a difference between the "novice user" and the Fedora Workstation target user i. e., developers?
Not necessarily. I wrote:
"Yes, Workstation targets developers, but not exclusively, and also developers who use fancy IDEs and who don't work with the terminal. I just don't want this thread to degenerate into a discussion of this lousy definition [of normal/novice users], since it's not important. What's important is that we want Workstation to be excellent for users who never touch the terminal."
Hm... developers which never touches the terminal?! Seems like a really narrow group (?)
Fedora currently suffers from the impression that it is a complicated OS for advanced users only, and that novices (including novice developers) should use Ubuntu instead.
I have full sympathy for this goal. Question is if it aligns with the developer target for the workstation?
On Sun, Dec 28, 2014 at 2:42 PM, Alec Leamas leamas.alec@gmail.com wrote:
Hm... developers which never touches the terminal?! Seems like a really narrow group (?)
Not really. At a previous workplace, we used two different IDEs for the two programming languages we needed to work with, and wrote GUI apps to handle whatever we might otherwise need a terminal to handle. We even had a GUI for git. (git was a great blessing.) If we needed to run a script (which was rare), we would double click on it. I used a terminal because I never bothered to learn the git GUI and because one of the IDEs was terrible, but I'm legitimately uncertain if I ever saw anyone else working with a terminal. We were using Windows. I think it was a relatively typical workplace.
Power users will always be able to use the terminal to great effect, but if most developers have to use it to get work done, that's a pretty damning statement as to the quality of our developer experience.
On 12/29/2014 12:58 AM, Michael Catanzaro wrote:
On Sun, Dec 28, 2014 at 2:42 PM, Alec Leamas leamas.alec@gmail.com wrote:
Hm... developers which never touches the terminal?! Seems like a really narrow group (?)
Not really. At a previous workplace, we used two different IDEs for the two programming languages we needed to work with, and wrote GUI apps to handle whatever we might otherwise need a terminal to handle.
May-be it's my age which gradually going to show, but I would not call these people "developers" but would call these folks "IDE-operators".
Ralf
On 28 December 2014 at 17:32, Ralf Corsepius rc040203@freenet.de wrote:
On 12/29/2014 12:58 AM, Michael Catanzaro wrote:
On Sun, Dec 28, 2014 at 2:42 PM, Alec Leamas leamas.alec@gmail.com wrote:
Hm... developers which never touches the terminal?! Seems like a really narrow group (?)
Not really. At a previous workplace, we used two different IDEs for the two programming languages we needed to work with, and wrote GUI apps to handle whatever we might otherwise need a terminal to handle.
Maybe it's my age which gradually going to show, but I would not call these people "developers" but would call these folks "IDE-operators".
It is your age, and there has been nothing gradual about it.. Look the world has moved a lot in the last 30 years, and we have gone past the point where current developers are humouring us old folk for making jokes about IDE-operators. It is not a joke as much as a "wow those people are pathetic" in the same way when we were younger and wondered why "old" people still wore double polyester flare bottom pants in the late 1980's.
The world has moved on... and Fedora is moving with it. I realize that a lot of us grognards have been trying to keep Fedora the Unix of 1987 when X11 was cool and NNTP was the way things got communicated. However its not going to happen.. and we either are going to have to get out of the way of the steamroller or get rolled over it.
Ralf
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 12/29/2014 04:28 AM, Stephen John Smoogen wrote:
On 28 December 2014 at 17:32, Ralf Corsepius <rc040203@freenet.de mailto:rc040203@freenet.de> wrote:
On 12/29/2014 12:58 AM, Michael Catanzaro wrote: On Sun, Dec 28, 2014 at 2:42 PM, Alec Leamas <leamas.alec@gmail.com <mailto:leamas.alec@gmail.com>> wrote: Hm... developers which never touches the terminal?! Seems like a really narrow group (?) Not really. At a previous workplace, we used two different IDEs for the two programming languages we needed to work with, and wrote GUI apps to handle whatever we might otherwise need a terminal to handle. Maybe it's my age which gradually going to show, but I would not call these people "developers" but would call these folks "IDE-operators".It is your age, and there has been nothing gradual about it.. Look the world has moved a lot in the last 30 years, and we have gone past the point where current developers are humouring us old folk for making jokes about IDE-operators.
I am well aware this is what these people believe in and what marketing folks are spreading to hype their tools. To me IDEs are "just tools" - Additional tools, additional to terminals and editors.
I.e. a Linux distro, which is not supporting terminals/editors as part of a "developer oriented distro" has not done its homework. I'd even go one step further: Developing under Red Hat's default desktop (Gnome3) is impossible without an IDE.
Ralf
On Mon, Dec 29, 2014 at 3:00 AM, Ralf Corsepius rc040203@freenet.de wrote:
I.e. a Linux distro, which is not supporting terminals/editors as part of a "developer oriented distro" has not done its homework.
We should support both terminal-oriented and IDE-oriented workflows. Right now, we have a terminal that works fine, but our IDE story is very poor.
I'd even go one step further: Developing under Red Hat's default desktop (Gnome3) is impossible without an IDE.
Have you ever tried to develop an app for GNOME? The truth is the complete opposite. Until about three days ago, my development environment was gedit and gnome-terminal, not because I prefer developing with a terminal, but because we have no non-terrible IDEs. I recently started using gnome-builder, which is an IDE in the very early stages of development. It's currently a gedit replacement -- I still need gnome-terminal open to do anything -- but it looks very promising.
Ever tried to make a GUI program with Glade, our "IDE" for creating user interfaces? It's too hard for me. I gave up and nowadays write XML UI files by hand with a text editor. I'm pretty sure almost all GNOME developers do the same.
On 29 December 2014 at 03:28, Stephen John Smoogen smooge@gmail.com wrote:
we either are going to have to get out of the way of the steamroller or get rolled over it.
...and the people trying to keep up are getting eggs thrown at them. I know lots of Red Hat developers worn down by the low-level harassment on this mailing list, so much so, that they just stop pushing the boundaries and go work on something else cool, e.g. ChromeOS.
Linux isn't UNIX. The desktop doesn't revolve about command line tools anymore. If you can't accept that, you probably need to change industry. Sorry to be blunt.
Richard
Am 29.12.2014 um 10:50 schrieb Richard Hughes:
On 29 December 2014 at 03:28, Stephen John Smoogen smooge@gmail.com wrote:
we either are going to have to get out of the way of the steamroller or get rolled over it.
...and the people trying to keep up are getting eggs thrown at them. I know lots of Red Hat developers worn down by the low-level harassment on this mailing list, so much so, that they just stop pushing the boundaries and go work on something else cool, e.g. ChromeOS.
Linux isn't UNIX. The desktop doesn't revolve about command line tools anymore. If you can't accept that, you probably need to change industry. Sorry to be blunt.
it does not need to revolve around - but a "software manager" *completly ignoring* non-GUI apps is a broken by design crap
sorry to be blunt too and the attitude you show repeatly like in the second paragraph is the reason for a lot of harassment on this list because a lot of this "cool new developers" don't give a damn about their existing userbase or about expierience of others and only try to catch new users which i do not need to be honest because if that attitude don't stop i sit in front of a MacOSX clone designed for idiots not able to make their own decisions
*nobody needs* that users, your attitude should be handholding them learning to make decisions on their own and what are you doing is the opposite, frankly you sound sometimes like the users not rely on GUI only are dumb in your eyes because they don't realize the beauty of a GUI app
On 29/12/14 10:50, Richard Hughes wrote:
On 29 December 2014 at 03:28, Stephen John Smoogen smooge@gmail.com wrote:
we either are going to have to get out of the way of the steamroller or get rolled over it.
[cut]
Linux isn't UNIX. The desktop doesn't revolve about command line tools anymore. If you can't accept that, you probably need to change industry. Sorry to be blunt.
2014-12-28 21:38 GMT+02:00 Michael Catanzaro mcatanzaro@gnome.org:
What's important is that we want Workstation to be excellent for users who never touch the terminal.
Great. But what if the design decisions based on this leads to a system which becomes needlessly complicated for other users, which also uses CLI tools?
Frankly, I think it's easier to alienate current devs (some of which using CLI tools) than to attract new ones. So, pushing this goal too hard might have consequences.
On 28/12/14 10:50, Richard Hughes wrote:
on 28 December 2014 at 00:23, Alexander Ploumistos
alex.ploumistos@gmail.com wrote:
Should Fedora build another program as a package manager?
GNOME PackageKit is still available (and maintained upstream) and is what I use for installing things like mingw packages that I need for development.
This certainly works, but is it really a reasonable trade-off in a developer context where things like compilers and interpreters are part of the very core? What role does Gnome Software play here? How fruitful is the idea to hide packages in this context?
Note that I have full respect for your goals. I use Gnome myself, and I didn't find 3.0 to painful :) It's just that I don't really see how the priorities for Gnome Software aligns with developer realities (while they make perfect sense for other types of users)
That said, everything is fine if the Fedora Workstation target user is a developer just using GUI tools. But I don't see this in the PRD.
Cheers!
--alec
On 29/12/14 04:33 AM, Alec Leamas wrote:
This certainly works, but is it really a reasonable trade-off in a developer context where things like compilers and interpreters are part of the very core? What role does Gnome Software play here? How fruitful is the idea to hide packages in this context?
Compiler and interpreters i.e.Glade having GUI and implements app-data (supposedly mandatory starting on Fedora 22) will be displayed on Gnome Software. Gnome Software is to abstract the package concept to only focus on applications accessible to desktop. The recent inclusion of add-on on Gnome Software brings useful solution like installing Eclipse and select add-on like Java Development Tools.
On 30/12/14 20:57, Luya Tshimbalanga wrote:
On 29/12/14 04:33 AM, Alec Leamas wrote:
This certainly works, but is it really a reasonable trade-off in a developer context where things like compilers and interpreters are part of the very core? What role does Gnome Software play here? How fruitful is the idea to hide packages in this context?
Compiler and interpreters i.e.Glade having GUI and implements app-data (supposedly mandatory starting on Fedora 22) will be displayed on Gnome Software.
Glade is neither a compiler nor an interpreter, it's an IDE.
Gnome Software is to abstract the package concept to only focus on applications accessible to desktop.
Agreed. And I can see some usecases where this makes a lot of sense.
But the question then becomes if this is the proper thing to do for the Workstation target user which is a developer. As such, she will in many cases want to install things like gcc, different python stacks using collections, text processing tools and so on. None of which with a GUI. She will also sometimes be interested in multiple desktops for testing etc., causing the "MATE apps not visible" problem.
Bottom line: isn't there is a mismatch between Gnome Software (GUI applications only) and the idea of a developer using both CLI and GUI tools? And if so, how should it be handled?
Cheers!
--alec
On 30/12/14 12:34 PM, Alec Leamas wrote:
On 30/12/14 20:57, Luya Tshimbalanga wrote:
On 29/12/14 04:33 AM, Alec Leamas wrote:
This certainly works, but is it really a reasonable trade-off in a developer context where things like compilers and interpreters are part of the very core? What role does Gnome Software play here? How fruitful is the idea to hide packages in this context?
Compiler and interpreters i.e.Glade having GUI and implements app-data (supposedly mandatory starting on Fedora 22) will be displayed on Gnome Software.
Glade is neither a compiler nor an interpreter, it's an IDE.
My bad.
Gnome Software is to abstract the package concept to only focus on applications accessible to desktop.
Agreed. And I can see some usecases where this makes a lot of sense.
But the question then becomes if this is the proper thing to do for the Workstation target user which is a developer. As such, she will in many cases want to install things like gcc, different python stacks using collections, text processing tools and so on. None of which with a GUI. She will also sometimes be interested in multiple desktops for testing etc., causing the "MATE apps not visible" problem.
What about DevAssistant that comes with Fedora Workstation? Have you tried it? MATE apps not visible means they needed app-data included on their .desktop files hence the pleas from Richard Hughes. The case of multiple desktop installation reaches advanced use territory meaning advanced tool like yumex.
Bottom line: isn't there is a mismatch between Gnome Software (GUI applications only) and the idea of a developer using both CLI and GUI tools? And if so, how should it be handled?
No. Fedora Workstation already provided needed tools for CLI like Gnome Terminal included by default.
On 30/12/14 22:58, Luya Tshimbalanga wrote:
On 30/12/14 12:34 PM, Alec Leamas wrote:
On 30/12/14 20:57, Luya Tshimbalanga wrote:
On 29/12/14 04:33 AM, Alec Leamas wrote:
Gnome Software is to abstract the package concept to only focus on applications accessible to desktop.
Agreed. And I can see some usecases where this makes a lot of sense.
But the question then becomes if this is the proper thing to do for the Workstation target user which is a developer.
[cut]
What about DevAssistant that comes with Fedora Workstation? Have you tried it?
No, it doesn't seem to solve any problem for me (?). That said, while such solutions certainly might be useful a generic installer application represents some kind of foundation I think all developers will need, sooner or later. Different devs, different ideas, different needs - not all can be shrink-wrapped.
MATE apps not visible means they needed app-data included on their .desktop files hence the pleas from Richard Hughes. The case of multiple desktop installation reaches advanced use territory meaning advanced tool like yumex.
Still the same question: is there a mismatch between the GUI only Gnome Software (GS) and the Workstation target user presumably using both CLI and GUI tools + perhaps multiple desktops?
If you describe this as "advanced use", should we read this as if the Workstation developer usecase is too advanced for GS?
And if the target usecase is too advanced for GS, what is then the role for GS in the Workstation product?
Cheers!
--alec
On 30/12/14 22:58, Luya Tshimbalanga wrote:
On 30/12/14 12:34 PM, Alec Leamas wrote:
On 30/12/14 20:57, Luya Tshimbalanga wrote:
Bottom line: isn't there is a mismatch between Gnome Software (GUI applications only) and the idea of a developer using both CLI and GUI tools? And if so, how should it be handled?
No. Fedora Workstation already provided needed tools for CLI like Gnome Terminal included by default.
Again: this is not about Gnome (I'm an overall happy Gnome user). It's about Gnome Software, the installer, and only that.
The Workstation PRD explicitly, more than once states developers of all sorts are the primary target market. The special focus is for a platform for application development.
I wonder two things:
a.) Should more developer tools be installed by default?
'dnf group list' shows the following items with "develop" in the group name: C Development Tools and Libraries D Development Tools and Libraries Development Tools RPM Development Tools While 'dnf group list hidden' additional shows Development and Creative Workstation Development Libraries GNOME Software Development Java Development [skipping KDE and Xfce specific items] Legacy Software Development LibreOffice Development Perl Development X Software Development
b.) Would it be helpful, friendlier, and better emphasize the special focus, if these group install items mentioned above were exposed in GNOME Software with an appropriate icon? GNOME Software is already smart enough to lump OS updates as a single line item as if it were a metapackage, when actually it's a collection of the current system only related packages available for updating. So there's already a UI/UX precedent for displaying non-applications within Software.
Chris Murphy
On 30 December 2014 at 23:31, Chris Murphy lists@colorremedies.com wrote:
b.) Would it be helpful, friendlier, and better emphasize the special focus, if these group install items mentioned above were exposed in GNOME Software with an appropriate icon?
We could do this right now, although I don't think "expose the entire comps tree" makes a lot of sense. We need translations, icons, screenshots, and of course approval from the Fedora/GNOME designers. Addons would be a logical place for this, although I think it probably needs more design thought about how to handle these "non-application" metagroupings. Installing a compiler is something that *something* needs to handle, I'm just not sure if that should be gnome-software itself or something that *uses* gnome-software to do the correct thing and to handle updates.
Richard
On 31/12/14 16:25, Richard Hughes wrote:
On 30 December 2014 at 23:31, Chris Murphy lists@colorremedies.com wrote:
b.) Would it be helpful, friendlier, and better emphasize the special focus, if these group install items mentioned above were exposed in GNOME Software with an appropriate icon?
We could do this right now, although I don't think "expose the entire comps tree" makes a lot of sense.
Here is also questions whether this is the right thing to do, I guess many packages, notably -devel ones, doesn't belong to a group. How should these then be handled?
And from a user perspective, if you already *know* that you need to install e.g., gcc or foo-devel first finding the proper group to install seems a bit awkward.
Perhaps this path also might create pressure to include all sorts of things into the groups, a "misuse" of the groups feature?
[cut]
Installing a compiler is something that *something* needs to handle, I'm just not sure if that should be gnome-software itself or something that *uses* gnome-software to do the correct thing and to handle updates.
Here is a some common ground, indeed. Seems that we agree on that installing CLI stuff is something that should be handled in a developer-oriented workstation (not that you have said something else, but some others).
Now, in my mind installing/updating non-GUI software is not a corner-case for a developer - it's probably the most common installation done even when working with GUI tools. Because even so you need tools such as compilers but also libraries/-devel packages. And often lot's of them.
From this perspective, I guess that if gnome-software (g-s) upstream defines installing CLI stuff as something which should be handled by "something else", I cannot really see the point handling updates in g-s. Rather, g-s would then become a nice add-on to browse and install GUI applications.
In the end, isn't this one hand about if gnome-software's upstream is willing to undertake the work to adapt also to the developer usecase? And on the other, which tool the workstation group should use for graphical software installations? Because as of now, gnome-software just doesn't fit the workstation bill?
Cheers!
--alec
On 2 January 2015 at 10:02, Alec Leamas leamas.alec@gmail.com wrote:
Here is a some common ground, indeed. Seems that we agree on that installing CLI stuff is something that should be handled in a developer-oriented workstation
If you're using gcc, you're using a terminal. We supply two command line package managers (dnf, yum) which allow you to do this. If you're using eclipse, then we already allow applications to install addons for different use-cases (which can have deps like gcc),
Now, in my mind installing/updating non-GUI software is not a corner-case for a developer - it's probably the most common installation done even when working with GUI tools.
Citation needed.
From this perspective, I guess that if gnome-software (g-s) upstream defines installing CLI stuff as something which should be handled by "something else", I cannot really see the point handling updates in g-s.
I don't see how you've got to this logic at all.
In the end, isn't this one hand about if gnome-software's upstream is willing to undertake the work to adapt also to the developer usecase?
No! GNOME Software is designed as an application installer for GNOME. We're using gnome-software in Fedora workstation, but that doesn't mean that the upstream application has to align with the workstation PRD 100% or else it's "not suitable".
Because as of now, gnome-software just doesn't fit the workstation bill
I think you're misunderstanding what most developers do. We probably spend about 10 minutes installing development packages (on the command line) when setting up a new OS instance. I then spend a year or so of installing or removing the odd application, and a few minutes every week applying updates. I don't think GNOME Software is hugely useful for installing low-level developer packages, which is fine. It doesn't mean it's not a useful application.
Rather than talking in riddles in your emails, could you also please suggest what needs to be done? Are you in favour of ripping out gnome-software and installing yumex in the workstation image? Do you have an alternate application proposal with design mockups?
Richard
On 02/01/15 11:42, Richard Hughes wrote:
Because as of now, gnome-software just doesn't fit the workstation bill
I think you're misunderstanding what most developers do. We probably spend about 10 minutes installing development packages (on the command line) when setting up a new OS instance. I then spend a year or so of installing or removing the odd application, and a few minutes every week applying updates. I don't think GNOME Software is hugely useful for installing low-level developer packages, which is fine. It doesn't mean it's not a useful application.
I don't know if "most" developers works with more or less just one toolchain and environment as you describe. At least "some" actually works in a lot of projects, with different development packages and sometimes also tools.
That said, what about describing the developer usecase as a project, focusing on a user using both GUI and CLI tools?
- Get the sources (if they exist). - Install a toolchain, GUI-based or not. - Install dependencies: -devel packages, interpreted modules, etc. - Install project- or user-specific tools (GUI or not). - Keeping the installed sw updated.
Installing the toolchain seems like DevAssistant to me. Besides this, I understand your position as if users are supposed to use yum/dnf except for GUI development tools and their dependencies (?)
To my mind, forcing user to the prompt to this extent is less than ideal. A GUI installer certainly has advantages even for an occasional CLI user. And having to use different installers is a Bad Thing.
Rather than talking in riddles in your emails, could you also please suggest what needs to be done? Are you in favour of ripping out gnome-software and installing yumex in the workstation image? Do you have an alternate application proposal with design mockups?
At this point, I'm just trying to understand the usecase. Without that, decisions like using yumex instead of gnome-software makes no sense, nor does mock-ups. It's also a question to what extent upstream is willing to support this usecase.
That said, my gut feeling is that the balance between simplicity and functionality is quite different for a "novice user" and a developer and that this needs to be handled with different modes, views or so (if gnome-software should handle it). Adding things like random CLI applications, -devel packages etc. to the search result for a novice user is just not an option, agreed. But IMHO a developer probably needs it in some form.
Cheers!
--alec
/*Alec Leamas leamas.alec@gmail.com*/ wrote on Sat, 03 Jan 2015 14:57:10 +0100:
On 02/01/15 11:42, Richard Hughes wrote: <....> That said, my gut feeling is that the balance between simplicity and functionality is quite different for a "novice user" and a developer and that this needs to be handled with different modes, views or so (if gnome-software should handle it). Adding things like random CLI applications, -devel packages etc. to the search result for a novice user is just not an option, agreed. But IMHO a developer probably needs it in some form.
Search results can be presented in groups (same as groups already used in the main screen): Sound/Graphics/Fonts/Development Libraries/etc...
Usually, when a user search for some terms, he already know its category. In fact, I think grouping search results is useful even in the current state without any CLI tools or development libraries. It needs a good UI design though. Maybe search results can be 'tagged' with their category, and a list of categories (of the results) is presented somewhere at the top/side so that the user can select one or some tags so that only packages from those categories will be shown. Or, the UI might ask the user (ouch, frowned upon!) some questions (if results were scattered in many categories) so that it can fine tune the results.
Thanks, Hedayat
Cheers!
--alec
----- Original Message -----
On 02/01/15 11:42, Richard Hughes wrote:
Because as of now, gnome-software just doesn't fit the workstation bill
I think you're misunderstanding what most developers do. We probably spend about 10 minutes installing development packages (on the command line) when setting up a new OS instance. I then spend a year or so of installing or removing the odd application, and a few minutes every week applying updates. I don't think GNOME Software is hugely useful for installing low-level developer packages, which is fine. It doesn't mean it's not a useful application.
I don't know if "most" developers works with more or less just one toolchain and environment as you describe. At least "some" actually works in a lot of projects, with different development packages and sometimes also tools.
That said, what about describing the developer usecase as a project, focusing on a user using both GUI and CLI tools?
- Get the sources (if they exist).
- Install a toolchain, GUI-based or not.
- Install dependencies: -devel packages, interpreted modules, etc.
- Install project- or user-specific tools (GUI or not).
- Keeping the installed sw updated.
Installing the toolchain seems like DevAssistant to me. Besides this, I understand your position as if users are supposed to use yum/dnf except for GUI development tools and their dependencies (?)
Currently DevAssistant "assistants" (read: plugins) that we have in Fedora are more of "kickstart a new project and install deps along" rather than "install a toolchain and perhaps do some other environment setup". This can however be easily extended by writing different plugins that will do just that. E.g. I can imagine us having "da prep fedora-dev c" (which will BTW automatically gain a clickable counterpart in GUI) that will setup development environment for C (and similar for other languages). We can even provide some choices like --use-eclipse, --use-whatever-other-IDE, ... I'm willing to put my work into this, but I'm mostly a Python developer, so I'd need input from people working with languages.
Does that sound worth pursuing?
On 05/01/15 10:04, Bohuslav Kabrda wrote:
----- Original Message -----
That said, what about describing the developer usecase as a project, focusing on a user using both GUI and CLI tools?
- Get the sources (if they exist).
- Install a toolchain, GUI-based or not.
- Install dependencies: -devel packages, interpreted modules, etc.
- Install project- or user-specific tools (GUI or not).
- Keeping the installed sw updated.
Installing the toolchain seems like DevAssistant to me. Besides this, I understand your position as if users are supposed to use yum/dnf except for GUI development tools and their dependencies (?)
Currently DevAssistant "assistants" (read: plugins) that we have in Fedora are more of "kickstart a new project and install deps along" rather than "install a toolchain and perhaps do some other environment setup". This can however be easily extended by writing different plugins that will do just that. E.g. I can imagine us having "da prep fedora-dev c" (which will BTW automatically gain a clickable counterpart in GUI) that will setup development environment for C (and similar for other languages). We can even provide some choices like --use-eclipse, --use-whatever-other-IDE, ... I'm willing to put my work into this, but I'm mostly a Python developer, so I'd need input from people working with languages.
Does that sound worth pursuing?
To my mind this looks attractive for the simple fact that multiple projects are more likely to share toolchain than dependencies.
But here is also questions e. g., are toolchains candidates for group installs or other existing mechanisms which could be exposed in Gnome Software? Would this than be an alternative and better way?
That said, what we really need here is the overall scheme, and this starts with the usecase. So: is the description above OK?
Given the usecase: if we use DevAssistent for the toolchain, which tool is then used for project dependencies in the general case? A modified Gnome Software or a general package manager like Gnome Packages?
Also, if we don't use Gnome Software for dependencies or the toolchain, what's then the role of it? A tool to keep the system updated? Isn't this then a rather massive overkill?
Cheers!
--alec
On 05/01/15 10:04, Bohuslav Kabrda wrote:
----- Original Message -----
On 02/01/15 11:42, Richard Hughes wrote:
Because as of now, gnome-software just doesn't fit the workstation bill
I think you're misunderstanding what most developers do. We probably spend about 10 minutes installing development packages (on the command line) when setting up a new OS instance. I then spend a year or so of installing or removing the odd application, and a few minutes every week applying updates. I don't think GNOME Software is hugely useful for installing low-level developer packages, which is fine. It doesn't mean it's not a useful application.
I don't know if "most" developers works with more or less just one toolchain and environment as you describe. At least "some" actually works in a lot of projects, with different development packages and sometimes also tools.
That said, what about describing the developer usecase as a project, focusing on a user using both GUI and CLI tools?
- Get the sources (if they exist).
- Install a toolchain, GUI-based or not.
- Install dependencies: -devel packages, interpreted modules, etc.
- Install project- or user-specific tools (GUI or not).
- Keeping the installed sw updated.
Installing the toolchain seems like DevAssistant to me. Besides this, I understand your position as if users are supposed to use yum/dnf except for GUI development tools and their dependencies (?)
Currently DevAssistant "assistants" (read: plugins) that we have in Fedora are more of "kickstart a new project and install deps along" rather than "install a toolchain and perhaps do some other environment setup". This can however be easily extended by writing different plugins that will do just that. E.g. I can imagine us having "da prep fedora-dev c" (which will BTW automatically gain a clickable counterpart in GUI) that will setup development environment for C (and similar for other languages). We can even provide some choices like --use-eclipse, --use-whatever-other-IDE, ... I'm willing to put my work into this, but I'm mostly a Python developer, so I'd need input from people working with languages.
Does that sound worth pursuing?
FYI: I have filed an RFE with gnome-software regarding ordering of the search results, which should significantly help bringing DevAssistant Assistants to the top:
https://bugzilla.gnome.org/show_bug.cgi?id=742388
Tomas Radej
On Wed, Dec 31, 2014 at 8:25 AM, Richard Hughes hughsient@gmail.com wrote:
On 30 December 2014 at 23:31, Chris Murphy lists@colorremedies.com wrote:
b.) Would it be helpful, friendlier, and better emphasize the special focus, if these group install items mentioned above were exposed in GNOME Software with an appropriate icon?
We could do this right now, although I don't think "expose the entire comps tree" makes a lot of sense. We need translations, icons, screenshots, and of course approval from the Fedora/GNOME designers. Addons would be a logical place for this, although I think it probably needs more design thought about how to handle these "non-application" metagroupings.
Sounds very reasonable.
Qualifying my position: I'm fairly comfortable with yum/dnf group installs now, so this isn't a sticking point for me personally. This really is the Workstation WG's turf to define what kind of UI/UX they want to have for developers new to the platform. And I'm inclined to think keeping developers (even CLI dominant ones) away from the esoterics of platform packaging is a good thing. I don't know if Software will instinctually be their go to for such a thing, so that's also a question someone needs to answer.
Installing a compiler is something that *something* needs to handle, I'm just not sure if that should be gnome-software itself or something that *uses* gnome-software to do the correct thing and to handle updates.
Could maybe be in scope for Fedora dev assistant also. http://fedoraproject.org/wiki/Features/DevelopersAssistant "Make the development on Fedora easier for beginners." "Try to install package containing setup for your favourite language."
2014-12-30 23:58 GMT+02:00 Luya Tshimbalanga luya@fedoraproject.org:
MATE apps not visible means they needed app-data included on their .desktop files hence the pleas from Richard Hughes.
Perhaps I couldn't get my thoughts in order when I started this thread, but among the things I wrote was that although MATE apps now have AppData files, they are not visible in gnome-software, because of the GNOME_SOFTWARE_COMPATIBLE_PROJECTS environment variable.
Am 29.12.2014 um 04:28 schrieb Stephen John Smoogen:
It is your age, and there has been nothing gradual about it.. Look the world has moved a lot in the last 30 years, and we have gone past the point where current developers are humouring us old folk for making jokes about IDE-operators
no, it is not the age
i bought my first PC in 1998, started with Visual Basic and after only payling a little around with Linux the years before i switched in summer 2006 from Windows to Linux due setup a new working machine and don't use dual-boot that time
you can't imagine how many things i did with the GUI to find out shell commands are much more powerful and for the most things a 3 liner bash script can replace the most GUI's
that's why i call it harmful try to hide the shell from users
2014-12-29 14:10 GMT+02:00 Reindl Harald h.reindl@thelounge.net:
that's why i call it harmful try to hide the shell from users
Well, to be fair nobody is trying to hide the shell and GNOME terminal has received some love in the latest releases. Package suggestions in the terminal can be useful for beginners and for advanced users, who don't want to do the "yum whatprovides */foo" and "yum install bar" dance. It can't stop you from dancing, though.
When I was 3 years old, I learned to type mechanically BRUN SABOTAGE ( http://en.wikipedia.org/wiki/Sabotage_%28video_game%29), later at school we learned Logo, so I was conditioned from an early age to textual interfaces. Then came System 6 and a few years later, windows 95. Until GNOME 3, perhaps with the exception of Enlightenment, every "mainstream" DE was a retake of that paradigm. Sure, with every iteration they became much more functional and polished, but GNOME 3 was the first that pushed me out of my comfort zone. I had to get acquainted with conky (yet another silver lining) and up to the time that the first gnome extensions came out, I had a little trouble getting things done. I got used to it though and with time I came to appreciate it. Granted, it's certainly not suited for every machine and perhaps not for every user, particularly those whose brains have been hardwired with time to a certain modus operandi. It might also need some tweaking to get it to one's taste, but that has always been the case with every DE. Every new release brings huge improvements over the last one and I'd say that from 3.6 onwards, there is nothing I miss from version 2.
What amazes me, is that novice computer users find their way around GNOME's UIs quite easily (more easily than I did anyway), which means that the Human Interface Guidelines do work. People who had only used windows very few times in the past, started getting things done in under an hour. Sure, they didn't need to monitor the health of their RAID10 arrays, or the processes that generate traffic on eth3, but that is absolutely possible as well.
I still have a couple of minor complaints. The first is that there is a chasm between the configuration options that are offered in the UI and those in Gsettings, or between Tweak Tool and CSS/JavaScript, if you want to tweak the UI itself. I think there is some room for something like an "advanced view" in the Settings panel. The second is about the combination of GNOME and Fedora, in that at times it feels like the interface pulls in one direction and the underlying system pulls in the opposite. But this constant change keeps one on one's toes and that's why we use Fedora, is it not? Constantly crying wolf, only makes it harder to notice when the wolf is actually on our doorstep.
On Sun, Dec 28, 2014 at 8:28 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 28 December 2014 at 17:32, Ralf Corsepius rc040203@freenet.de wrote:
On 12/29/2014 12:58 AM, Michael Catanzaro wrote:
On Sun, Dec 28, 2014 at 2:42 PM, Alec Leamas leamas.alec@gmail.com wrote:
Hm... developers which never touches the terminal?! Seems like a really narrow group (?)
Not really. At a previous workplace, we used two different IDEs for the two programming languages we needed to work with, and wrote GUI apps to handle whatever we might otherwise need a terminal to handle.
Maybe it's my age which gradually going to show, but I would not call these people "developers" but would call these folks "IDE-operators".
It is your age, and there has been nothing gradual about it.. Look the world has moved a lot in the last 30 years, and we have gone past the point where current developers are humouring us old folk for making jokes about IDE-operators. It is not a joke as much as a "wow those people are pathetic" in the same way when we were younger and wondered why "old" people still wore double polyester flare bottom pants in the late 1980's.
From 1984 to 2001 there was a rather popular platform that didn't have
a CLI. It wasn't hidden, it simply didn't exist. Its replacement has a terminal application, but the developer CLI tools are an optional installation, it remains predominately a GUI development environment.
So I don't think it's an age thing, but rather a lack of awareness of the historical and current state of software development in the wider world. Developers have been developing software without CLIs for a long time.
2014-12-29 19:25 GMT+02:00 Chris Murphy lists@colorremedies.com:
From 1984 to 2001 there was a rather popular platform that didn't have a CLI. It wasn't hidden, it simply didn't exist.
I take it you are referring to OS/2. It did have a cmd.exe.
On Mon, Dec 29, 2014 at 11:22 AM, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
2014-12-29 19:25 GMT+02:00 Chris Murphy lists@colorremedies.com:
From 1984 to 2001 there was a rather popular platform that didn't have a CLI. It wasn't hidden, it simply didn't exist.
I take it you are referring to OS/2.
Nope. Vastly more popular than OS/2.
Am 29.12.2014 um 19:39 schrieb Chris Murphy:
On Mon, Dec 29, 2014 at 11:22 AM, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
2014-12-29 19:25 GMT+02:00 Chris Murphy lists@colorremedies.com:
From 1984 to 2001 there was a rather popular platform that didn't have a CLI. It wasn't hidden, it simply didn't exist.
I take it you are referring to OS/2.
Nope. Vastly more popular than OS/2
besides that it makes people tired speaking in riddles the only reason i am active in that thread is to notice that people should not make differences between GUI/CLI and so not lower rate CLI apps
* there are users just browse the web, chat and read e-mail * there are users doing a lot of things in a terminal * there are users doing only sometimes things in a terminal
it always depends on the goal to achive for a task
well, and that is why there are tasks you *can * do 1000 times more better in a terminal or in a 3-liner shell script with one or two params and others where you are much faster using the GUI
this world is grey
hence everybody start using Linux should *know* there are terminal apps and which ones and make his own decision if they fit the usecase and in doubt be able to use both worlds
what makes me angry is "nobody should need to use a terminal" that's not the point, a new user just needs to know the capabilities don't hide them from these people because they are born too late
*show them* all the nice capabilities and don't hide half
if they donä't want to use them - fine! but if they don't use them just they don't know about is a damage
----- Original Message -----
well, and that is why there are tasks you *can * do 1000 times more better in a terminal or in a 3-liner shell script with one or two params and others where you are much faster using the GUI
this world is grey
hence everybody start using Linux should *know* there are terminal apps and which ones and make his own decision if they fit the usecase and in doubt be able to use both worlds
The way I view it, there are two fairly separate cases:
A) Application development (with a wide definition of an “application” as “teaching the system to do something new”, i.e. all the way from simple aliases and pipelines through 10-line shell scripts all the way to 10k-line shell or Perl script monsters).
Yes, these things can’t be done in our GUIs nearly as easily, but there _really are_ large groups of people who never will, don’t want to, or are perhaps even forbidden from, doing such things (consider cashiers or bank tellers). So it is quite reasonable to hide these capabilities until the user indicates some kind of interest in developing applications (where “indicates interest” today probably means a Google search, so we can get away with requiring one or two non-obvious but easy to do steps to get developer access).
Also note that the shell prompt is one of the worst application development environments still in wide use. Very weak and inconsistent programming language, no module system, minimal auto-completion/intelligence, no inline help, horrible debugging tools even compared to 1980s Turbo Pascal. It _should_ be possible to have a programming environment that is vastly easier to use than the shell prompt we have; but I have very little hope of this improving in the medium term.
B) Application usage, interacting with applications somebody else wrote.
Here, GUIs _as a category_ (not necessarily the GUIs we are currently providing) should always be better than CLIs _as a category_ simply because the GUI can in the worst case just copy the CLI layout and behavior so it will not be worse than a CLI; and then there are all the graphics and mouse interactions and shadows and animation that a GUI can do but a CLI can’t.
So to get the best sofware system possible we should 1) actually write such better GUIs, and 2) tell people that such better GUIs are available.
what makes me angry is "nobody should need to use a terminal"
“Nobody should need to use a terminal” is a case of 2) above [and partially a case of “shell is a horrible application development environment” from A)].
Note that "nobody should need to“ and “currently nobody needs to” are very different.
And there is a major difficulty: doing 2) before 1) is done can be counter-productive, counter-productivity or in the worst case just dishonest; but doing 1) without 2) is likely impossible if the CLI capabilities keep expanding faster than we can add GUI interfaces to the same capabilities. So I can see a case for being vocal about “nobody should need to use a terminal” even now; but that case critically depends on the ability of the community to actually write the better non-terminal interfaces. Mirek
Am 02.01.2015 um 21:05 schrieb Miloslav Trmač:
Here, GUIs _as a category_ (not necessarily the GUIs we are currently providing) should always be better than CLIs _as a category_ simply because the GUI can in the worst case just copy the CLI layout and behavior so it will not be worse than a CLI; and then there are all the graphics and mouse interactions and shadows and animation that a GUI can do but a CLI can’t.
no it can't
a gui for "grep file | grep -v x | grep -y | sort | uniq | awk... > newfile" is impossible because you *never* can build a GUI that is the same way flexiable and still useable
And there is a major difficulty: doing 2) before 1) is done can be counter-productive, counter-productivity or in the worst case just dishonest; but doing 1) without 2) is likely impossible if the CLI capabilities keep expanding faster than we can add GUI interfaces to the same capabilities. So I can see a case for being vocal about “nobody should need to use a terminal” even now; but that case critically depends on the ability of the community to actually write the better non-terminal interfaces.
but you can't and won't use the GUI the same way on remote machines over slow lines as you can use a CLI and hence smart, short and repeatable tasks are done in shell-scripts because a "ssh user@host /usr/local/bin/task.sh" is done before you remote GUI even starts
On Fri, Jan 2, 2015 at 10:47 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 02.01.2015 um 21:05 schrieb Miloslav Trmač:
Here, GUIs _as a category_ (not necessarily the GUIs we are currently providing) should always be better than CLIs _as a category_ simply because the GUI can in the worst case just copy the CLI layout and behavior so it will not be worse than a CLI; and then there are all the graphics and mouse interactions and shadows and animation that a GUI can do but a CLI can’t.
no it can't
a gui for "grep file | grep -v x | grep -y | sort | uniq | awk... > newfile" is impossible because you *never* can build a GUI that is the same way flexiable and still useable
That *particular* widget has been done, with various search and regexp widgets. But they tend to be done quite badly, with each deverloper going "ooohhh, shiny!!!" and concentrating on feature addition and showing off all the cool widgets. Kind of like Gnome, actually.
There's an old, fascinating essay about this by Eric Raymond, called "The L:uxury of Ignorance", over 10 years ago. Gnome tools tend to violate most of the guidelines, and the software installation tool violates these in particular:
11. What does my software look like to a non-technical user who has never seen it before?
And from the guidelines Eric included from a letter writer's submission:
* Can you gracefully and easily duplicate your tools and configuration for a similar installation? * Are there settings you can do from the command line or hand-editing config files that cannot be done from the GUI?
In case you can't guess, those are postscript guidelines were written by me
but you can't and won't use the GUI the same way on remote machines over slow lines as you can use a CLI and hence smart, short and repeatable tasks are done in shell-scripts because a "ssh user@host /usr/local/bin/task.sh" is done before you remote GUI even starts
The GUI's can be handy, especially because yum text output becaumes difficult to script unnecessary header information and the erratic newlines for long package names.
Hello,
Am 02.01.2015 um 21:05 schrieb Miloslav Trmač:
Here, GUIs _as a category_ (not necessarily the GUIs we are currently providing) should always be better than CLIs _as a category_ simply because the GUI can in the worst case just copy the CLI layout and behavior so it will not be worse than a CLI; and then there are all the graphics and mouse interactions and shadows and animation that a GUI can do but a CLI can’t.
no it can't
a gui for "grep file | grep -v x | grep -y | sort | uniq | awk... > newfile" is impossible because you *never* can build a GUI that is the same way flexiable and still useable
1) This is “application development” in my earlier mail, the other category to which the generic claim above was not intended to apply.
2) Even then, except for the un-specified awk and invalid (grep -y), I have just reproduced the functionality in LibreOffice Calc, in about the same time it took me to look up (grep -y) and make sure that this must have been a typo. (Cue arguments that LibreOffice is not usable ☺ )
So I can see a case for being vocal about “nobody should need to use a terminal” even now; but that case critically depends on the ability of the community to actually write the better non-terminal interfaces.
but you can't and won't use the GUI the same way on remote machines over slow lines
Those slow lines are disappearing, and will be pretty rare by the time we get any UI design finished and polished. Using web interfaces, or even a remote desktop connection, from computers or even tablets is nowadays very common outside of the Linux world; “we need to use ssh and vim because Internet is slow” is, AFAICT, simply no longer true. Mirek
On 5 January 2015 at 09:09, Miloslav Trmač mitr@redhat.com wrote:
Hello,
Am 02.01.2015 um 21:05 schrieb Miloslav Trmač:
Here, GUIs _as a category_ (not necessarily the GUIs we are currently providing) should always be better than CLIs _as a category_ simply because the GUI can in the worst case just copy the CLI layout and behavior so it will not be worse than a CLI; and then there are all the graphics and mouse interactions and shadows and animation that a GUI
can
do but a CLI can’t.
no it can't
a gui for "grep file | grep -v x | grep -y | sort | uniq | awk... > newfile" is impossible because you *never* can build a GUI that is the same way flexiable and still useable
- This is “application development” in my earlier mail, the other
category to which the generic claim above was not intended to apply.
- Even then, except for the un-specified awk and invalid (grep -y), I
have just reproduced the functionality in LibreOffice Calc, in about the same time it took me to look up (grep -y) and make sure that this must have been a typo. (Cue arguments that LibreOffice is not usable ☺ )
Cool. Can you explain to someone else how in the world they would do that in OpenOffice? Because my brain has never figured out how to do it more than after a couple of days of poking around.
[This can be off-list or a different thread because I would really like to know.]
So I can see a case for being vocal about “nobody should need to use a terminal” even now; but that case critically
depends
on the ability of the community to actually write the better
non-terminal
interfaces.
but you can't and won't use the GUI the same way on remote machines over slow lines
Those slow lines are disappearing, and will be pretty rare by the time we get any UI design finished and polished. Using web interfaces, or even a remote desktop connection, from computers or even tablets is nowadays very common outside of the Linux world; “we need to use ssh and vim because Internet is slow” is, AFAICT, simply no longer true. Mirek
Here in the fourth world USA, we aren't actually seeing a decrease in slow lines but an increase as the oligarchy in control of networks is figuring out ways to advertise faster speeds but actually only deliver much slower ones. You can get 200 MB in a short burst and then 4.5 MB and your upstream is most likely 128kb->256kb. I realize that Europe has a much better infrastructure these days.. but 60% of Fedora customers are in rural US regions which aren't as well served.
In any case, for everyone in this conversation. Please please please don't make the assumption that because X does or does not work great for you because of where you live etc.. that everyone else has the same experience. Actually assume it is probably safer to assume that outside of whatever reality bubble you live in, it is not.
--
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 05/01/15 17:35, Stephen John Smoogen wrote:
Here in the fourth world USA, we aren't actually seeing a decrease in slow lines but an increase as the oligarchy in control of networks is figuring out ways to advertise faster speeds but actually only deliver much slower ones. You can get 200 MB in a short burst and then 4.5 MB and your upstream is most likely 128kb->256kb. I realize that Europe has a much better infrastructure these days.. but 60% of Fedora customers are in rural US regions which aren't as well served.
In any case, for everyone in this conversation. Please please please don't make the assumption that because X does or does not work great for you because of where you live etc.. that everyone else has the same experience. Actually assume it is probably safer to assume that outside of whatever reality bubble you live in, it is not.
I don't envy how the political climate on your continent has affected this for you. However, connecting to the top of this sub-thread, for the Fedora Workstation usecase this is not necessarily that bad - a developer works normally with local tools, although of course browsing and downloading is affected by network speed.
Cheers!
--alec
Am 05.01.2015 um 17:48 schrieb Alec Leamas:
I don't envy how the political climate on your continent has affected this for you. However, connecting to the top of this sub-thread, for the Fedora Workstation usecase this is not necessarily that bad - a developer works normally with local tools, although of course browsing and downloading is affected by network speed.
no idea which sort of developers you know
where i work developemnt environments are running often on virtualized remote machines at all because snapshots, backups and we develop network aware applications at all
hence we have small shell scripts as commands in the PATH for common tasks and i don't need to bother if i am at office in the same LAN, on my home machine with a 365/24 VPN link or even on a smartphone over VPN and can fire up basic tasks always the same way regardless of connection speed and location
On 05/01/15 19:10, Reindl Harald wrote:
Am 05.01.2015 um 17:48 schrieb Alec Leamas:
I don't envy how the political climate on your continent has affected this for you. However, connecting to the top of this sub-thread, for the Fedora Workstation usecase this is not necessarily that bad - a developer works normally with local tools, although of course browsing and downloading is affected by network speed.
no idea which sort of developers you know
where i work developemnt environments are running often on virtualized remote machines at all because snapshots, backups and we develop network aware applications at all
hence we have small shell scripts as commands in the PATH for common tasks and i don't need to bother if i am at office in the same LAN, on my home machine with a 365/24 VPN link or even on a smartphone over VPN and can fire up basic tasks always the same way regardless of connection speed and location
OK, what's "normal" clearly varies, agreed. But the conclusion in the Fedora Workstation context is actually the same: developers needs both CLI and GUI tools.
Cheers!
--alec
Am 05.01.2015 um 17:09 schrieb Miloslav Trmač:
but you can't and won't use the GUI the same way on remote machines over slow lines
Those slow lines are disappearing, and will be pretty rare by the time we get any UI design finished and polished
sorry, but that is nonsense
my home internet has 250 MBit downstream and 25 Mbit upstream and it is still true that before a graphical remote application appears i am done with a SSH connection (besides that 90% of the things i want to do remote are even faster if i type them in the alway open konsole window on my KDE desktop and hence need to learn how to do things *once* and they work everywhere, mostly even on non-linux unix like systems)
what you shiny GUI is missing now and will be missing forever is *free piping* of commands mathcing the current task and not possible to pack in a graphical interface without overload it until it unuseable at all
On 02/01/15 21:05, Miloslav Trmač wrote:
----- Original Message -----
well, and that is why there are tasks you *can * do 1000 times more better in a terminal or in a 3-liner shell script with one or two params and others where you are much faster using the GUI
this world is grey
hence everybody start using Linux should *know* there are terminal apps and which ones and make his own decision if they fit the usecase and in doubt be able to use both worlds
The way I view it, there are two fairly separate cases:
A) Application development (with a wide definition of an “application” as “teaching the system to do something new”, i.e. all the way from simple aliases and pipelines through 10-line shell scripts all the way to 10k-line shell or Perl script monsters).
Yes, these things can’t be done in our GUIs nearly as easily, but there _really are_ large groups of people who never will, don’t want to, or are perhaps even forbidden from, doing such things (consider cashiers or bank tellers). So it is quite reasonable to hide these capabilities until the user indicates some kind of interest in developing applications (where “indicates interest” today probably means a Google search, so we can get away with requiring one or two non-obvious but easy to do steps to get developer access).
Also note that the shell prompt is one of the worst application development environments still in wide use. Very weak and inconsistent programming language, no module system, minimal auto-completion/intelligence, no inline help, horrible debugging tools even compared to 1980s Turbo Pascal. It _should_ be possible to have a programming environment that is vastly easier to use than the shell prompt we have; but I have very little hope of this improving in the medium term.
B) Application usage, interacting with applications somebody else wrote.
Here, GUIs _as a category_ (not necessarily the GUIs we are currently providing) should always be better than CLIs _as a category_ simply because the GUI can in the worst case just copy the CLI layout and behavior so it will not be worse than a CLI; and then there are all the graphics and mouse interactions and shadows and animation that a GUI can do but a CLI can’t.
So to get the best sofware system possible we should 1) actually write such better GUIs, and 2) tell people that such better GUIs are available.
While I think you are right in some cases like cashier, isn't this discussion really about the Fedora Workstation?! Since for this the target user is a developer, can we just agree that in this case the user needs both CLI and GUI apps (although some developers certainly sticks to one of them).
Cheers!
--alec
PS: I'm not sure about all lines becoming fast. Doing remote sysadm over mobile connections comes to my mind. But this is *not* the workstation usecase... DS
While I think you are right in some cases like cashier, isn't this discussion really about the Fedora Workstation?! Since for this the target user is a developer, can we just agree that in this case the user needs both CLI and GUI apps (although some developers certainly sticks to one of them).
The gist is that * Nobody _should_ need to use a terminal: non-developers¹ don’t need it, and developers deserve a better environment. It’s “only” a matter of writing lots of new software. AFAICT Workstation would in some ideal future want to get to this state. (And non-Linux operating systems are getting closer and closer to this ideal over time.)
* _Currently_ most Linux developers do need to use a terminal.
So there is no right answer, only a trade-off: Make terminal usage discouraged and difficult for current users, and hopefully get better non-terminal environment in the future, or make terminal usage easy and the generally recommended way, and give up hope on the developer UI significantly improving for the future users. Mirek
¹ Again considering shell scripts and pipelines as “development”.
(on CLI)
and developers deserve a better environment.
No, developers deserve the environment they ask for, not what someone else thinks is "better".
There are aspects of the shell that are a matter of pure preference, like syntax coloring.
There are aspects where personal preference or efficiency in the common case may override someone else’s idea of good design, like perhaps the textual programming language that can’t easily enough handle file names with newlines (which aren’t forbidden).
But I feel quite confident in saying that having a debugger with breakpoints and the ability to view variables, instead of (bash -x) and sprinkling around echo statements, is a nowadays a basic expectation and an essential tool for productivity, not a frivolous personal preference. (And if the response is “use a non-shell language and a powerful editor if you that kind of functionality”, then that just proves my point.) Mirek
Am 05.01.2015 um 19:36 schrieb Miloslav Trmač:
While I think you are right in some cases like cashier, isn't this discussion really about the Fedora Workstation?! Since for this the target user is a developer, can we just agree that in this case the user needs both CLI and GUI apps (although some developers certainly sticks to one of them).
The gist is that
Nobody _should_ need to use a terminal: non-developers¹ don’t need it, and developers deserve a better environment. It’s “only” a matter of writing lots of new software. AFAICT Workstation would in some ideal future want to get to this state. (And non-Linux operating systems are getting closer and closer to this ideal over time.)
_Currently_ most Linux developers do need to use a terminal.
So there is no right answer, only a trade-off: Make terminal usage discouraged and difficult for current users, and hopefully get better non-terminal environment in the future, or make terminal usage easy and the generally recommended way, and give up hope on the developer UI significantly improving for the future users.
that's a completly wrong black/white viewpoint
* make terminal usage *never* discouraged and difficult * hopefully get better non-terminal environment in the future * keep terminal usage easy * do *not* give up hope on the developer UI significantly improving
these points can live at the same time
BUT discourage terminal and *hopefully* get better non-terminal environment *in the future* is by all respect pure bullshit because i don't throw away my car now in the hope of get a private aeroplane in the future
On Mon, Jan 5, 2015 at 10:36 AM, Miloslav Trmač mitr@redhat.com wrote:
While I think you are right in some cases like cashier, isn't this discussion really about the Fedora Workstation?! Since for this the target user is a developer, can we just agree that in this case the user needs both CLI and GUI apps (although some developers certainly sticks to one of them).
The gist is that
- Nobody _should_ need to use a terminal: non-developers¹ don’t need it, and developers deserve a better environment. It’s “only” a matter of writing lots of new software. AFAICT Workstation would in some ideal future want to get to this state. (And non-Linux operating systems are getting closer and closer to this ideal over time.)
Having watched people develop under Mac OS X, they have really shiny things to play with. Xcode is pretty, and there are whole pile of nice editors and such to use. Heck, even Firefox and Chromium are gradually turning into developer tools as opposed to just being browsers and debuggers.
Nonetheless, the productive Mac OS X developers I know all have something like an entire desktop devoted to just running terminals.
Given that no one, on any OS I've ever seen*, has come up with something better than a terminal for running scripts, watching log messages scroll by, using fancy shell commands, etc., I think that expecting Fedora to magically solve all these problems is both overly optimistic and is an entirely inappropriate assumption to base the OS design on.
* The terminal on Windows is, or at least was, awful. That just meant that productivity went down, not that the GUI tools were in any respect better.
--Andy
- _Currently_ most Linux developers do need to use a terminal.
So there is no right answer, only a trade-off: Make terminal usage discouraged and difficult for current users, and hopefully get better non-terminal environment in the future, or make terminal usage easy and the generally recommended way, and give up hope on the developer UI significantly improving for the future users. Mirek
¹ Again considering shell scripts and pipelines as “development”.
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Andrew Lutomirski (luto@mit.edu) said:
On Mon, Jan 5, 2015 at 10:36 AM, Miloslav Trmač mitr@redhat.com wrote:
While I think you are right in some cases like cashier, isn't this discussion really about the Fedora Workstation?! Since for this the target user is a developer, can we just agree that in this case the user needs both CLI and GUI apps (although some developers certainly sticks to one of them).
The gist is that
- Nobody _should_ need to use a terminal: non-developers¹ don’t need it, and developers deserve a better environment. It’s “only” a matter of writing lots of new software. AFAICT Workstation would in some ideal future want to get to this state. (And non-Linux operating systems are getting closer and closer to this ideal over time.)
Having watched people develop under Mac OS X, they have really shiny things to play with. Xcode is pretty, and there are whole pile of nice editors and such to use. Heck, even Firefox and Chromium are gradually turning into developer tools as opposed to just being browsers and debuggers.
Nonetheless, the productive Mac OS X developers I know all have something like an entire desktop devoted to just running terminals.
Given that no one, on any OS I've ever seen*, has come up with something better than a terminal for running scripts, watching log messages scroll by, using fancy shell commands, etc., I think that expecting Fedora to magically solve all these problems is both overly optimistic and is an entirely inappropriate assumption to base the OS design on.
I'm not sure that GNOME Software is the right place to solve this, though - if I'm using the terminal to build things:
- I shouldn't be searching for grep/sed/awk - those are part of the base operating system, and should be treated as such. - I shouldn't be searching for gcc, gcc-c++, make, etc. as separate promoted to GNOME Software applications; those should be treated as part of a development kit that's installed and updated as a unit, any more than I should be searching for libgweather or libdrm as part of installing a desktop app. - Even searching for -devel packages implies a "target == host" build sensibility that is relevant mostly to those developing Fedora, and not to most of those developers that I run into on a day-to-day basis (and likely not the developers we're targeting.) They're interested in using mock along with system libraries for RHEL/CentOS, using pip/npm/rubygems, etc.
Bill
On 06/01/15 17:39, Bill Nottingham wrote:
- I shouldn't be searching for gcc, gcc-c++, make, etc. as separate promoted to GNOME Software applications; those should be treated as part of a development kit that's installed and updated as a unit, any more than I should be searching for libgweather or libdrm as part of installing a desktop app.
It seems like we could use DevAssistant for this. This would probably mean creating/polishing more toolchain-oriented separately packaged plugins as proposed by Bohuslav and some way to make them more visible as bug filed by Tomas Radej (all in this thread).
- Even searching for -devel packages implies a "target == host" build sensibility that is relevant mostly to those developing Fedora, and not to most of those developers that I run into on a day-to-day basis (and likely not the developers we're targeting.) They're interested in using mock along with system libraries for RHEL/CentOS, using pip/npm/rubygems, etc.
Indeed. Still, it seems like this boils down to that developers need a way to install packages, not just applications. Also, to be fair I don't really see if we could or should package all conceivable CLI-based tools into DevAssistant plugins, so also here a developer might need to be able to install packages. And large parts of this thread is about how this relates to gnome-software.
Another question is of course how things like python-pip and rubygem fits into the puzzle. But whatever the solution is for this, it's likely not gnome-software, agreed.
Cheers!
--alec
/*Bill Nottingham notting@splat.cc*/ wrote on Tue, 6 Jan 2015 11:39:27 -0500:
<...>
- Even searching for -devel packages implies a "target == host" build sensibility that is relevant mostly to those developing Fedora, and not to most of those developers that I run into on a day-to-day basis (and likely not the developers we're targeting.) They're interested in using mock along with system libraries for RHEL/CentOS, using pip/npm/rubygems, etc.
So you mean that Fedora target developers are either using dynamic languages, or they develop native software for RHEL/CentOS?! So you believe that "target == rhel/centos"? And native software developers for *modern* distros are not targets? This is really offending. RHEL/CentOS themselves should mainly target their developers. I guess that most of the developers you run into are working for RedHat.
Notice that -devel packages are not useful only for developing Fedora. I work in a company in which everyone else is using Ubuntu, and that is their target OS for their software. However, I use Fedora and its -devel packages (unless they doesn't exist or too old), but my code compiles fine on their Ubuntu too. And it should compile on any other distro which have packages with comparable versions. So, Fedora -devel packages are useful for developing software for any modern distro, but you want to target specific distributions?!
Regards, Hedayat
On 6 January 2015 at 10:48, Hedayat Vatankhah hedayat.fwd@gmail.com wrote:
*Bill Nottingham notting@splat.cc notting@splat.cc* wrote on Tue, 6 Jan 2015 11:39:27 -0500:
<...>
- Even searching for -devel packages implies a "target == host" build sensibility that is relevant mostly to those developing Fedora, and not to most of those developers that I run into on a day-to-day basis (and likely not the developers we're targeting.) They're interested in using mock along with system libraries for RHEL/CentOS, using pip/npm/rubygems, etc.
So you mean that Fedora target developers are either using dynamic languages, or they develop native software for RHEL/CentOS?! So you believe that "target == rhel/centos"? And native software developers for *modern* distros are not targets? This is really offending. RHEL/CentOS themselves should mainly target their developers. I guess that most of the developers you run into are working for RedHat.
1) Notting doesn't work at Red Hat anymore. 2) You are assuming too much from the beginning. You take a couple of words from his sentence and make a hole diatribe of how stupid he must be for something he didn't say. Please do not do that.
-- Stephen J Smoogen.
On Tue, Jan 6, 2015 at 1:28 PM, Stephen John Smoogen smooge@gmail.com wrote:
So you mean that Fedora target developers are either using dynamic languages, or they develop native software for RHEL/CentOS?! So you believe that "target == rhel/centos"?
No, you misread his comment, he's actually saying the opposite. You both agree on that point. Happy Tuesday.
/*Michael Catanzaro mcatanzaro@gnome.org*/ wrote on Tue, 06 Jan 2015 13:51:24 -0600:
On Tue, Jan 6, 2015 at 1:28 PM, Stephen John Smoogen smooge@gmail.com wrote:
So you mean that Fedora target developers are either using dynamic languages, or they develop native software for RHEL/CentOS?! So you believe that "target == rhel/centos"?No, you misread his comment, he's actually saying the opposite. You both agree on that point. Happy Tuesday.
If that's the case as you and Stephen J Smoogen say, I'm sorry.
Regards, Hedayat
Hedayat Vatankhah (hedayat.fwd@gmail.com) said:
/*Bill Nottingham notting@splat.cc*/ wrote on Tue, 6 Jan 2015 11:39:27 -0500:
<...>
- Even searching for -devel packages implies a "target == host" build sensibility that is relevant mostly to those developing Fedora, and not to most of those developers that I run into on a day-to-day basis (and likely not the developers we're targeting.) They're interested in using mock along with system libraries for RHEL/CentOS, using pip/npm/rubygems, etc.
So you mean that Fedora target developers are either using dynamic languages, or they develop native software for RHEL/CentOS?! So you believe that "target == rhel/centos"? And native software developers for *modern* distros are not targets? This is really offending. RHEL/CentOS themselves should mainly target their developers. I guess that most of the developers you run into are working for RedHat.
... Not at Red Hat now, but what I'm saying is that the developers I interact with are targeting mainly Ubuntu LTS and CentOS/RHEL, even if their devel platform is Fedora. It goes back to uses of Fedora in production - while Fedora Server certainly wants to change this, most all of the *deployed* server systems that people are targeting for their code aren't Fedora. Once you assume that you want to support the use case of developers using Fedora to develop for things that aren't Fedora, I just feel that worrying about a package tool for installing -devel packages pales in trying to streamline the workflows the developers needs around using things like mock and jenkins as build tools, and test environments that aren't even local to the machine at all, whether they involve virtualization, containers, or remote cloud services.
Bill
/*Bill Nottingham notting@splat.cc*/ wrote on Wed, 7 Jan 2015 10:56:31 -0500:
Hedayat Vatankhah (hedayat.fwd@gmail.com) said:
/*Bill Nottingham notting@splat.cc*/ wrote on Tue, 6 Jan 2015 11:39:27 -0500:
<...>
- Even searching for -devel packages implies a "target == host" build sensibility that is relevant mostly to those developing Fedora, and not to most of those developers that I run into on a day-to-day basis (and likely not the developers we're targeting.) They're interested in using mock along with system libraries for RHEL/CentOS, using pip/npm/rubygems, etc.
So you mean that Fedora target developers are either using dynamic languages, or they develop native software for RHEL/CentOS?! So you believe that "target == rhel/centos"? And native software developers for *modern* distros are not targets? This is really offending. RHEL/CentOS themselves should mainly target their developers. I guess that most of the developers you run into are working for RedHat.
... Not at Red Hat now, but what I'm saying is that the developers I interact with are targeting mainly Ubuntu LTS and CentOS/RHEL, even if their devel platform is Fedora. It goes back to uses of Fedora in production - while Fedora Server certainly wants to change this, most all of the *deployed* server systems that people are targeting for their code aren't Fedora. Once you assume that you want to support the use case of developers using Fedora to develop for things that aren't Fedora, I just feel that worrying about a package tool for installing -devel packages pales in trying to streamline the workflows the developers needs around using things like mock and jenkins as build tools, and test environments that aren't even local to the machine at all, whether they involve virtualization, containers, or remote cloud services.
Well, I agree completely that solving the issue of installing -devel packages is not enough to make Fedora suitable for developers; but it is certainly needed. However, it would be even better if Fedora can be a great general purpose development platform supporting development for other targets such as RHEL/CentOS, Ubuntu and even Windows (using mingw toolchain + wine, and then maybe virtual environments/remote access to run/test/debug on real Windows OS); which could expand to development for embedded devices/OSes like Android. But, IMHO, support for none of these should be more important than native Fedora development; specially since targeting OSes like RHEL/CentOS/Ubuntu LTS is usually important for developers for commercial software. Someone who is developing free(open source) software usually prefers to use 'latest and greatest', for which usually Fedora and it's -devel packages are one of the best things available out there. And I think free software developers should be top priority for Fedora compared to others. There is nothing wrong with supporting others, but the "main" target developers should be free software developers, and they are less likely to need using mock or RHEL system libraries.
Regards, Hedayat
Bill
2014-12-29 20:39 GMT+02:00 Chris Murphy lists@colorremedies.com:
Nope. Vastly more popular than OS/2.
OK, yes, my Macintosh Classic didn't have a cli. But the Macs back then were much like feature phones are today. You got basic functionality in the standard package with the very beautiful UI and if you wanted to do anything other than draw in MacPaint or edit text files, you had to give $$ to Apple. So one could argue that the lack of a CLI (among other developer/power user tools) was part feature, part marketing decision.
On Mon, Dec 29, 2014 at 12:52 PM, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
2014-12-29 20:39 GMT+02:00 Chris Murphy lists@colorremedies.com:
Nope. Vastly more popular than OS/2.
OK, yes, my Macintosh Classic didn't have a cli. But the Macs back then were much like feature phones are today.
This is beside the point. However, even if feature phones had an installable developer tools do you think you'd develop applications on the feature phone? Could you develop a HyperCard or Photoshop 1.0 type of application? And you think it'd be usable? And you think it'd be a ground breaking, game changing set of applications that would create a multi-billion dollar industry? No on all counts so it's not only beside the point, the metaphor is wrong.
You got basic functionality in the standard package with the very beautiful UI and if you wanted to do anything other than draw in MacPaint or edit text files, you had to give $$ to Apple. So one could argue that the lack of a CLI (among other developer/power user tools) was part feature, part marketing decision.
None of that matters. The argument is that someone is only a developer if they are using a platform with a CLI, specifically dominating the process at a minimum, if not required to successfully develop software. And a real developer would only ever choose such a platform. And the cherry on this ridiculous hot fudge sundae, is that somehow this perceived requirement might be changing due to one's age.
The first assertion is historically and linguistically wrong. The second assertion is anachronistic, as that platform appeared 31 years ago. I'd be surprised if the median age on this list is 31, so most people on this list probably were in diapers at the time a multi-billion dollar industry was being created by developers using a CLI-less development environment.
Best as I can tell real developers are adaptable and use tools that are available, but also aren't shy about asking for and developing new development tools. Hughsie wrote the most functional, most stable, 1.0 version application I've ever used, and faster than Matilda the Witch could flick her wand. Oh but if he wasn't slovenly dependent on CLI tools at the time, he wouldn't be a developer, he'd be an operator. It's just so absurd as to defy belief, and yet he's having eggs thrown at him? WTFsauce. This reads like a really bad comedy show where the distinctly not funny comedian starts throwing tomatoes at the audience for not laughing. Oh but he's not a real comedian, because he wasn't on a stage.
There is such a thing as listening too much to a community that can act like an anchor to innovation. I think the most active developers wanting a stronger IDE need one more thing, and that's a better filter so they can ignore the egg throwers. The real developers are those who are actively getting things done, and are not defined by what interface they're using.
Am 29.12.2014 um 22:01 schrieb Chris Murphy:
The real developers are those who are actively getting things done, and are not defined by what interface they're using.
yes, and that's why the real developers need to get aware of *all* capabilities of their operating system and not got hidden useful apps because their icon is not large enough or in a format with too less colors or not enough screenshots provided upstream
2014-12-29 23:01 GMT+02:00 Chris Murphy lists@colorremedies.com:
OK, yes, my Macintosh Classic didn't have a cli. But the Macs back then
were
much like feature phones are today.
This is beside the point. However, even if feature phones had an installable developer tools do you think you'd develop applications on the feature phone? Could you develop a HyperCard or Photoshop 1.0 type of application? And you think it'd be usable? And you think it'd be a ground breaking, game changing set of applications that would create a multi-billion dollar industry? No on all counts so it's not only beside the point, the metaphor is wrong.
For a little over a decade, java-based and other apps for feature phones generated billions for those involved, in either direct revenue or license fees, until the smartphones started replacing the PDAs and becoming mainstream. Much like closed-source feature phones, Apple kept control over the hardware and the software of Macs, leaving little -if any- leeway for users and developers. The Macs were great productivity machines in that they had a good set of tools for specific tasks, a pleasant interface that allowed easy access to those tasks and they rarely crashed on the job, because Apple didn't have to worry about the software being glitch-free on every conceivable hardware combo. Just like my KRZR is still great at placing calls, sending texts and playing my tunes. My own coding skills are completely irrelevant. On principle alone, I wouldn't choose to write anything on such a platform (even if it had a cli from the very beginning).
None of that matters. The argument is that someone is only a developer if they are using a platform with a CLI, specifically dominating the process at a minimum, if not required to successfully develop software.
Not my argument. Someone who uses the terminal is in no way a better developer than someone who works with a GUI. Coding and interfacing with the machine are two very different things. However, a linux developer (as in someone who develops programs to be run on linux systems, not a developer in general who just happens to have his tools of choice running on linux) who ignores the existence of shells is like an OS X developer who has never used, well... OS X.
I'd be surprised if the median age on this list is 31, so most people on this list probably were in diapers at the time a multi-billion dollar industry was being created by developers using a CLI-less development environment.
What does the CLI-less-ness of Macs and their gazillion dollar industry have to do with the rest of this discussion though? Windows have had a cmd.exe (with its tremendous limitations) since time immemorial and several years ago a "Power Shell" was added. Some users (and developers) know they're there, most do not. Does that have anything to do with Microsoft's dominance over the PC market? As for the age thing, I may have owned a IIe and a Macintosh Classic, but over the years I've only come across five people who happened to have used anything Apple made in that era -and I've lived in seven cites in two different countries. Most computer users I knew at the time were on Sinclairs, IBM and IBM-compatibles and later on Amiga and Atari.
Exactly because Apple had set up a money barrier between users and developers, a user would never get the chance to tinker with the internals of their system, whereas on linux everyone is free to do as much or as little as they please. Feel like checking if there is anything left from that C class you took ages ago? Just install gcc and give it a shot. You think you could automate some mundane, repetitive task you have to do every now and then? Fire up vi (or emacs, nano, gedit, pluma, leafpad etc.) and write a shell script and feed it to your always-present shell. You might botch your system, but that's part of the learning process. In System 5, 6 and 7, there was an extra step in that process, which involved several hundred $ changing hands. And yes, there wasn't a shell.
Hughsie wrote the most functional, most stable, 1.0 version application I've ever used, and faster than Matilda the Witch could flick her wand. Oh but if he wasn't slovenly dependent on CLI tools at the time, he wouldn't be a developer, he'd be an operator. It's just so absurd as to defy belief, and yet he's having eggs thrown at him? WTFsauce. This reads like a really bad comedy show where the distinctly not funny comedian starts throwing tomatoes at the audience for not laughing. Oh but he's not a real comedian, because he wasn't on a stage.
I have to agree with you here. I haven't had the pleasure of Ms Matilda's acquaintance, but gnome-software is incredibly fast, especially given the tasks it performs. Also, things should never get personal and snarky comments are detrimental to the discussion. If a real issue occurs that can't be amicably resolved here or in bugzilla, there are community elected steering committees that can take over.
There is such a thing as listening too much to a community that can act like an anchor to innovation.
Only a small subset of a much larger community is active on these lists. Those who are vocal about an issue here or in the forum, are those who feel affected by it in a good or mostly in a bad way. They do not necessarily represent an equal proportion of the community. Perhaps regular or sporadic surveys might help get some input from the non-vocal users. And let's not forget that not everyone here has english as their mother tongue, so things can and do get lost in translation.
The fact that I take from this thread and which keeps getting buried in the avalanche of postings, is that there is an ongoing and good effort to provide graphical means for users to install, configure and use Fedora on their computers, without ever having to use a terminal because there is no alternative. Those who enjoy using a terminal will still be able to perform those same tasks without bothering with the UI elements. New users will always have the opportunity to discover the awesomeness of a shell, but by choice; not by need.
On Mon, Dec 29, 2014 at 5:58 PM, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
What does the CLI-less-ness of Macs and their gazillion dollar industry have to do with the rest of this discussion though?
None really. I was just pushing back against the idea platform CLIness has anything to do with who is a developer vs IDE controller.
The fact that I take from this thread and which keeps getting buried in the avalanche of postings, is that there is an ongoing and good effort to provide graphical means for users to install, configure and use Fedora on their computers, without ever having to use a terminal because there is no alternative. Those who enjoy using a terminal will still be able to perform those same tasks without bothering with the UI elements. New users will always have the opportunity to discover the awesomeness of a shell, but by choice; not by need.
I agree.
I'd still like to see a fedup + Software integration to make upgrades a routine aspect of the Fedora lifecycle rather than a major and seemingly risky event. Already, updating with Software is a completely trustworthy, single button click, single reboot experience. That's not at all the experience I had recently on Windows.
Fedora has a certain advantage with the fast development cycle, which is that the upgrades aren't as big a leap in package versions as it is between e.g. Ubuntu's LTS releases. So I don't see the cycle time frame as inherently a problem, even for novices. Hardware OEM projects, like Sputnik, gravitate toward Ubuntu because a 5 year support model is familiar to them, and probably also that Canonical offers pay for support.
More problematic, is Rawhide languishing during the intensive refinement needed after branch, followed by the sigh of exhaustion/relief, followed by the effort of a new wind up. I remain a proponent of making beta higher quality so that more people are wiling to test and find the major bugs before final is baked; and also to make the testing time period between beta and final less frantic that also risk late slips.
On 28 December 2014 at 19:32, Ralf Corsepius wrote:
On 12/29/2014 12:58 AM, Michael Catanzaro wrote:
On Sun, Dec 28, 2014 at 2:42 PM, Alec Leamas wrote:
Hm... developers which never touches the terminal?! Seems like a really narrow group (?)
Not really. At a previous workplace, we used two different IDEs for the two programming languages we needed to work with, and wrote GUI apps to handle whatever we might otherwise need a terminal to handle.
May-be it's my age which gradually going to show, but I would not call these people "developers" but would call these folks "IDE-operators".
We have a number of such folks at work too. I guess no one held their hands and showed them the power of the terminal before. Needless to say, a few demonstrations is almost always sufficient for them to realize what they have been missing and they usually change their workflow and start using the terminal by their own will.
I believe the main reason for this is that Windows does not ship with a decent terminal, and most of these folks grew up with Windows. Hopefully, this will change.
Best, Orcan
On Sun, Dec 28, 2014 at 09:42:07PM +0100, Alec Leamas wrote:
On 28/12/14 18:05, Michael Catanzaro wrote:
On Sun, Dec 28, 2014 at 9:48 AM, Alec Leamas leamas.alec@gmail.com wrote:
Possibly. But isn't there quite a difference between the "novice user" and the Fedora Workstation target user i. e., developers?
Not necessarily. I wrote:
"Yes, Workstation targets developers, but not exclusively, and also developers who use fancy IDEs and who don't work with the terminal. I just don't want this thread to degenerate into a discussion of this lousy definition [of normal/novice users], since it's not important. What's important is that we want Workstation to be excellent for users who never touch the terminal."
Hm... developers which never touches the terminal?! Seems like a really narrow group (?)
it's not as narrow as you may think, developers may use the terminal selectively for some tasks and the GUI exclusively for others. That subset isn't the same for all developers, so you end up having to provide all features working well in the GUI.
e.g. I hardly ever use nautilus to handle fils, but I also hardly ever use the terminal for any configuration, connecting to networks, firewall stuff, etc. etc. I hardly ever use it to start non-terminal apps except for eog/evince.
so even though I use the terminal heavily, I still would count myself in the above group and I definitely need a good GUI around my terminals. And, I want my desktop to be simple and get out of the way of what I actually want to do.
Cheers, Peter
Fedora currently suffers from the impression that it is a complicated OS for advanced users only, and that novices (including novice developers) should use Ubuntu instead.
I have full sympathy for this goal. Question is if it aligns with the developer target for the workstation?
Am 29.12.2014 um 01:19 schrieb Peter Hutterer:
On Sun, Dec 28, 2014 at 09:42:07PM +0100, Alec Leamas wrote:
On 28/12/14 18:05, Michael Catanzaro wrote:
On Sun, Dec 28, 2014 at 9:48 AM, Alec Leamas leamas.alec@gmail.com wrote:
Possibly. But isn't there quite a difference between the "novice user" and the Fedora Workstation target user i. e., developers?
Not necessarily. I wrote:
"Yes, Workstation targets developers, but not exclusively, and also developers who use fancy IDEs and who don't work with the terminal. I just don't want this thread to degenerate into a discussion of this lousy definition [of normal/novice users], since it's not important. What's important is that we want Workstation to be excellent for users who never touch the terminal."
Hm... developers which never touches the terminal?! Seems like a really narrow group (?)
it's not as narrow as you may think, developers may use the terminal selectively for some tasks and the GUI exclusively for others. That subset isn't the same for all developers, so you end up having to provide all features working well in the GUI.
exactly!
but not hide terminal apps and pretend nobody should have a need to use them these day
e.g. I hardly ever use nautilus to handle fils, but I also hardly ever use the terminal for any configuration, connecting to networks, firewall stuff, etc. etc. I hardly ever use it to start non-terminal apps except for eog/evince.
so even though I use the terminal heavily, I still would count myself in the above group and I definitely need a good GUI around my terminals. And, I want my desktop to be simple and get out of the way of what I actually want to do.
exactly!
but that completly different to "a user should not need to know what a terminal is or find terminal apps in the software center even if he knows them by name for good reasons"
/*Michael Catanzaro mcatanzaro@gnome.org*/ wrote on Sun, 28 Dec 2014 11:05:00 -0600:
On Sun, Dec 28, 2014 at 9:48 AM, Alec Leamas leamas.alec@gmail.com wrote:
Possibly. But isn't there quite a difference between the "novice user" and the Fedora Workstation target user i. e., developers?
Not necessarily. I wrote:
"Yes, Workstation targets developers, but not exclusively, and also developers who use fancy IDEs and who don't work with the terminal. I just don't want this thread to degenerate into a discussion of this lousy definition [of normal/novice users], since it's not important. What's important is that we want Workstation to be excellent for users who never touch the terminal."
Fedora currently suffers from the impression that it is a complicated OS for advanced users only, and that novices (including novice developers) should use Ubuntu instead.
Well, I was really surprised that developers are considered a target audience here. GNOME Software *might* be considered good enough for normal users, but its far from usable for a developer; even a developer who don't want to touch the terminal. Actually, it is *terrible* for such a developer. Why?
1. He search for "C++" and .... (I doubt that it tries to interpret it as a regular expression or something. Probably it thinks that the user is an idiot and removes "+" signs on behalf of him). 2. He has installed Eclipse + CDT and hopefully he can compile his C++ programs with GCC. Now, he learns about Clang and would like to try it. 3. He is using an x86_64 system, but he happen to need to compile his program for 32bit systems. or even cross-compile for ARM. 4. He needs a networking library, or want to use Boost, or ....
GNOME Software is not that useful for a developer. As Rechard himself said, he'll need a package manager anyway. So, If Workstation product really targets developers, specially the ones who don't want to use terminal, it MUST include a graphical package manager.
Regards, Hedayat
On 01/01/15 04:21 PM, Hedayat Vatankhah wrote:
Well, I was really surprised that developers are considered a target audience here. GNOME Software *might* be considered good enough for normal users, but its far from usable for a developer; even a developer who don't want to touch the terminal. Actually, it is *terrible* for such a developer. Why?
From what I understand, Gnome Software is intended for front-end applications only.
- He search for "C++" and .... (I doubt that it tries to interpret it
as a regular expression or something. Probably it thinks that the user is an idiot and removes "+" signs on behalf of him).
DevAssistant application available by default on Fedora Workstation is designed for that purpose.
- He has installed Eclipse + CDT and hopefully he can compile his C++
programs with GCC. Now, he learns about Clang and would like to try it.
Clang is a compiler that be installed as an add-ons for Eclipse. That is very much an request of enhancement for IDEs installation in Gnome Software.
GNOME Software is not that useful for a developer. As Rechard himself said, he'll need a package manager anyway. So, If Workstation product really targets developers, specially the ones who don't want to use terminal, it MUST include a graphical package manager.
There are developers unaware of the concept of package manager which does not help. Gnome Software is actually useful once the add-ons functionality is fully expanded on applications. Works need to be done allowing a seamless integration.
/*Luya Tshimbalanga*/ wrote on Fri, 02 Jan 2015 12:25:49 -0800:
On 01/01/15 04:21 PM, Hedayat Vatankhah wrote:
Well, I was really surprised that developers are considered a target audience here. GNOME Software *might* be considered good enough for normal users, but its far from usable for a developer; even a developer who don't want to touch the terminal. Actually, it is *terrible* for such a developer. Why?
From what I understand, Gnome Software is intended for front-end applications only.
Probably true, but it already includes fonts and input sources. So, someone has felt that 'front-end applications only' is too narrow. Now, where you can draw the line?
- He search for "C++" and .... (I doubt that it tries to interpret
it as a regular expression or something. Probably it thinks that the user is an idiot and removes "+" signs on behalf of him).
DevAssistant application available by default on Fedora Workstation is designed for that purpose.
Did you try that? The problem with searching for "C++" is that it will list almost all applications (probably it searches for "C"). So it has nothing to do with DevAssistant.
- He has installed Eclipse + CDT and hopefully he can compile his
C++ programs with GCC. Now, he learns about Clang and would like to try it.
Clang is a compiler that be installed as an add-ons for Eclipse. That is very much an request of enhancement for IDEs installation in Gnome Software.
So, every IDE should have a 'clang' addon? and also a gcc addon? At least, if 'shared' add-ons are available things will be much easier.
I wonder why people want to split developers into two categories: GUI-only and Terminal-only? Why there couldn't be a "GUI as much as possible developer"? Such a developer will prefer to install autotools and clang/gcc using a GUI application, then open a terminal and run "./configure && make && sudo make install" in shell? Why do people think that a developer which wants (actually, since currently there are no(?) GUI ways to do configure, make and make install, he is forced) to use terminal should be 'punished' to use command line for installing the tools he need?
(Well, hopefully in future there will be a tool (DevAssistant?) which can help you to configure, compile and install a package from source. Then, it can have gcc/clang/... compilers as its addons too; so it's become more practical to have GUI-only developers who don't need to install a compiler directly).
GNOME Software is not that useful for a developer. As Rechard himself said, he'll need a package manager anyway. So, If Workstation product really targets developers, specially the ones who don't want to use terminal, it MUST include a graphical package manager.
There are developers unaware of the concept of package manager which does not help. Gnome Software is actually useful once the add-ons functionality is fully expanded on applications. Works need to be done allowing a seamless integration.
Add-ons cannot cover development libraries, unless every library is an add-on for all IDEs!
Regards, Hedayat
-- Luya Tshimbalanga Graphic & Web Designer E:luya@fedoraproject.org W:http://www.coolest-storm.net
On 02/01/15 01:15 PM, Hedayat Vatankhah wrote:
Probably true, but it already includes fonts and input sources. So, someone has felt that 'front-end applications only' is too narrow. Now, where you can draw the line?
I exaggerated.
Did you try that? The problem with searching for "C++" is that it will list almost all applications (probably it searches for "C"). So it has nothing to do with DevAssistant.
I just searched "C++" resulting a freeze of Gnome Software due to handling of "++" character. That is a bug I already submitted https://bugzilla.redhat.com/show_bug.cgi?id=1178199 Normally, Gnome Software should list DevAssistant on the first list as I have no problem typing python or ruby keyword on the search field.
So, every IDE should have a 'clang' addon? and also a gcc addon? At least, if 'shared' add-ons are available things will be much easier.
In this case, why not?
I wonder why people want to split developers into two categories: GUI-only and Terminal-only? Why there couldn't be a "GUI as much as possible developer"? Such a developer will prefer to install autotools and clang/gcc using a GUI application, then open a terminal and run "./configure && make && sudo make install" in shell? Why do people think that a developer which wants (actually, since currently there are no(?) GUI ways to do configure, make and make install, he is forced) to use terminal should be 'punished' to use command line for installing the tools he need?
They were attempt of create a frontend for that purpose and most of them were poorly implemented. Take a look of how Microsoft and Apple do their development. it is a matter of finding a better way of implementing the tool.
(Well, hopefully in future there will be a tool (DevAssistant?) which can help you to configure, compile and install a package from source. Then, it can have gcc/clang/... compilers as its addons too; so it's become more practical to have GUI-only developers who don't need to install a compiler directly).
DevAssistant is a start. Next step will be adding packaging guideline and other stuff. It takes time but it can be done.
Add-ons cannot cover development libraries, unless every library is an add-on for all IDEs!
Then is IDE packaging issue. When it comes of using a development applications, the software should suggest installing the missing library. If Gnome Video is able to prompt uses to install missing component, then why shouldn't be possible for IDE application to do the same? Granted I don't know well the functionality but the logic is application should detect and suggest adding the missing function.
/*Luya Tshimbalanga*/ wrote on Fri, 02 Jan 2015 17:29:14 -0800:
On 02/01/15 01:15 PM, Hedayat Vatankhah wrote:
Probably true, but it already includes fonts and input sources. So, someone has felt that 'front-end applications only' is too narrow. Now, where you can draw the line?
I exaggerated.
Did you try that? The problem with searching for "C++" is that it will list almost all applications (probably it searches for "C"). So it has nothing to do with DevAssistant.
I just searched "C++" resulting a freeze of Gnome Software due to handling of "++" character. That is a bug I already submitted https://bugzilla.redhat.com/show_bug.cgi?id=1178199 Normally, Gnome Software should list DevAssistant on the first list as I have no problem typing python or ruby keyword on the search field.
Thanks for filling the bug. :P I was thinking when I'll report it.
So, every IDE should have a 'clang' addon? and also a gcc addon? At least, if 'shared' add-ons are available things will be much easier.
In this case, why not?
I was actually suggesting a solution which could fit in the current design. I'm not against the latter (while I still prefer having them as independent applications, in case you really don't need an IDE. However, if it is also available as a DevAssistent add-on, it'd be good; but actually I'm mis-using DevAssistant as 'Development Tools' category!)
I wonder why people want to split developers into two categories: GUI-only and Terminal-only? Why there couldn't be a "GUI as much as possible developer"? Such a developer will prefer to install autotools and clang/gcc using a GUI application, then open a terminal and run "./configure && make && sudo make install" in shell? Why do people think that a developer which wants (actually, since currently there are no(?) GUI ways to do configure, make and make install, he is forced) to use terminal should be 'punished' to use command line for installing the tools he need?
They were attempt of create a frontend for that purpose and most of them were poorly implemented. Take a look of how Microsoft and Apple do their development. it is a matter of finding a better way of implementing the tool.
If you mean finding a replacement for autotools, I disagree. While having better ways is great (and actually, there are many 'autotools replacements' and some of them are GUI friendly. A good example is CMake), but there is a fact that there are many packages using autotools. I don't know how Apple does it (but I think I remember some of my friends actually being *forced* to use command line to install an auto-tools based library), but I wonder if you know about a 'better way' Microsoft provides. As far as I know, installing and using third-party development libraries under Windows is nearly Terrible. And, the last time I tried to use Boost under Windows it certainly needed using command line to use boost build system. I used several other libraries under Windows, none of them provided any *good* means for installation and usage. Most importantly, Windows doesn't (or at least, didn't!) have any Software Center like tools at all. So, there are no means in Windows for finding and installing development libraries; and hence it can't be better or worse than ours!
(Well, hopefully in future there will be a tool (DevAssistant?) which can help you to configure, compile and install a package from source. Then, it can have gcc/clang/... compilers as its addons too; so it's become more practical to have GUI-only developers who don't need to install a compiler directly).
DevAssistant is a start. Next step will be adding packaging guideline and other stuff. It takes time but it can be done.
Add-ons cannot cover development libraries, unless every library is an add-on for all IDEs!
Then is IDE packaging issue. When it comes of using a development applications, the software should suggest installing the missing library. If Gnome Video is able to prompt uses to install missing component, then why shouldn't be possible for IDE application to do the same? Granted I don't know well the functionality but the logic is application should detect and suggest adding the missing function.
Hmm... that's weird, I can't understand what you mean. Gnome Video's job is very easy: a video has a special format, and there are specific plugins to enable playing that. However, assume that I need an XML library for C++: 1. How can I tell the IDE that I need an XML library? 2. What should IDE do if there are 5 different XML libraries for C++? How should I tell it which one I want, specially if I don't know what should I use already, and want to see what is available out there?
To me, it seems like implementing a special purpose software manager inside IDE with almost all functionality GNOME Software provides. As I said in another post, user reviews/rating for development libraries (like what GNOME Software provides for applications) can be really helpful when a developer wants to choose a library for a specific purpose.
Regards, Hedayat
-- Luya Tshimbalanga Graphic & Web Designer E:luya@fedoraproject.org W:http://www.coolest-storm.net
On 03/01/15 20:26, Hedayat Vatankhah wrote:
/*Luya Tshimbalanga*/ wrote on Fri, 02 Jan 2015 17:29:14 -0800:
Add-ons cannot cover development libraries, unless every library is an add-on for all IDEs!
Then is IDE packaging issue. When it comes of using a development applications, the software should suggest installing the missing library. If Gnome Video is able to prompt uses to install missing component, then why shouldn't be possible for IDE application to do the same? Granted I don't know well the functionality but the logic is application should detect and suggest adding the missing function.
Hmm... that's weird, I can't understand what you mean. Gnome Video's job is very easy: a video has a special format, and there are specific plugins to enable playing that. However, assume that I need an XML library for C++:
- How can I tell the IDE that I need an XML library?
- What should IDE do if there are 5 different XML libraries for C++?
How should I tell it which one I want, specially if I don't know what should I use already, and want to see what is available out there?
To me, it seems like implementing a special purpose software manager inside IDE with almost all functionality GNOME Software provides. As I said in another post, user reviews/rating for development libraries (like what GNOME Software provides for applications) can be really helpful when a developer wants to choose a library for a specific purpose.
In other words: there is a difference between the toolchain and project dependencies.
The toolchain e. g. eclipse + gcc etc. can be probably partly be fixed using IDE dependencies, DevAssistant and similar setups reflecting general tool-set dependencies, agreed.
OTOH, the dependencies for a specific project cannot really be handled this way. Such libraries are specific for the code you build, not the tools. Making them dependencies of e. g., eclipse just doesn't make any sense.
Cheers!
--alec
----- Original Message -----
From: "Alec Leamas" leamas.alec@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Saturday, January 3, 2015 10:19:30 PM Subject: Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
On 03/01/15 20:26, Hedayat Vatankhah wrote:
/*Luya Tshimbalanga*/ wrote on Fri, 02 Jan 2015 17:29:14 -0800:
Add-ons cannot cover development libraries, unless every library is an add-on for all IDEs!
Then is IDE packaging issue. When it comes of using a development applications, the software should suggest installing the missing library. If Gnome Video is able to prompt uses to install missing component, then why shouldn't be possible for IDE application to do the same? Granted I don't know well the functionality but the logic is application should detect and suggest adding the missing function.
Hmm... that's weird, I can't understand what you mean. Gnome Video's job is very easy: a video has a special format, and there are specific plugins to enable playing that. However, assume that I need an XML library for C++:
- How can I tell the IDE that I need an XML library?
- What should IDE do if there are 5 different XML libraries for C++?
How should I tell it which one I want, specially if I don't know what should I use already, and want to see what is available out there?
To me, it seems like implementing a special purpose software manager inside IDE with almost all functionality GNOME Software provides. As I said in another post, user reviews/rating for development libraries (like what GNOME Software provides for applications) can be really helpful when a developer wants to choose a library for a specific purpose.
In other words: there is a difference between the toolchain and project dependencies.
The toolchain e. g. eclipse + gcc etc. can be probably partly be fixed using IDE dependencies, DevAssistant and similar setups reflecting general tool-set dependencies, agreed.
OTOH, the dependencies for a specific project cannot really be handled this way. Such libraries are specific for the code you build, not the tools. Making them dependencies of e. g., eclipse just doesn't make any sense.
Yeah, it doesn't make sense to make dependencies of eclipse but usually when something is missing it's not that hard to find what to install programatically. Pointing again to the video for eclipse https://rgrunber.fedorapeople.org/eclipse_packagekit_2.ogv . I remember something about Anjuta being able to do something similar but can't find it now. Of course this can not cover every "creative" build environment but such approach works well for video codecs so it's not impossible.
Alexander Kurtakov Red Hat Eclipse team
Cheers!
--alec
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
----- Original Message -----
From: "Hedayat Vatankhah" hedayat.fwd@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Friday, January 2, 2015 11:15:58 PM Subject: Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
Luya Tshimbalanga wrote on Fri, 02 Jan 2015 12:25:49 -0800:
On 01/01/15 04:21 PM, Hedayat Vatankhah wrote:
Well, I was really surprised that developers are considered a target audience here. GNOME Software *might* be considered good enough for normal users, but its far from usable for a developer; even a developer who don't want to touch the terminal. Actually, it is *terrible* for such a developer. Why?
From what I understand, Gnome Software is intended for front-end applications only. Probably true, but it already includes fonts and input sources. So, someone has felt that 'front-end applications only' is too narrow. Now, where you can draw the line?
- He search for "C++" and .... (I doubt that it tries to interpret it as a
regular expression or something. Probably it thinks that the user is an idiot and removes "+" signs on behalf of him). DevAssistant application available by default on Fedora Workstation is designed for that purpose. Did you try that? The problem with searching for "C++" is that it will list almost all applications (probably it searches for "C"). So it has nothing to do with DevAssistant.
- He has installed Eclipse + CDT and hopefully he can compile his C++
programs with GCC. Now, he learns about Clang and would like to try it. Clang is a compiler that be installed as an add-ons for Eclipse. That is very much an request of enhancement for IDEs installation in Gnome Software. So, every IDE should have a 'clang' addon? and also a gcc addon? At least, if 'shared' add-ons are available things will be much easier.
I wonder why people want to split developers into two categories: GUI-only and Terminal-only? Why there couldn't be a "GUI as much as possible developer"? Such a developer will prefer to install autotools and clang/gcc using a GUI application, then open a terminal and run "./configure && make && sudo make install" in shell? Why do people think that a developer which wants (actually, since currently there are no(?) GUI ways to do configure, make and make install, he is forced) to use terminal should be 'punished' to use command line for installing the tools he need?
(Well, hopefully in future there will be a tool (DevAssistant?) which can help you to configure, compile and install a package from source. Then, it can have gcc/clang/... compilers as its addons too; so it's become more practical to have GUI-only developers who don't need to install a compiler directly).
GNOME Software is not that useful for a developer. As Rechard himself said, he'll need a package manager anyway. So, If Workstation product really targets developers, specially the ones who don't want to use terminal, it MUST include a graphical package manager.
There are developers unaware of the concept of package manager which does not help. Gnome Software is actually useful once the add-ons functionality is fully expanded on applications. Works need to be done allowing a seamless integration. Add-ons cannot cover development libraries, unless every library is an add-on for all IDEs!
It can be done dynamic aka install devel packages on request by IDEs - see https://rgrunber.fedorapeople.org/eclipse_packagekit_1.ogv
Alexander Kurtakov Red Hat Eclipse team
Regards, Hedayat
-- Luya Tshimbalanga Graphic & Web Designer E: luya@fedoraproject.org W: http://www.coolest-storm.net
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
/*Aleksandar Kurtakov akurtako@redhat.com*/ wrote on Sun, 4 Jan 2015 02:55:17 -0500 (EST):
----- Original Message -----
From: "Hedayat Vatankhah" hedayat.fwd@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Friday, January 2, 2015 11:15:58 PM Subject: Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
<...>
GNOME Software is not that useful for a developer. As Rechard himself said, he'll need a package manager anyway. So, If Workstation product really targets developers, specially the ones who don't want to use terminal, it MUST include a graphical package manager.
There are developers unaware of the concept of package manager which does not help. Gnome Software is actually useful once the add-ons functionality is fully expanded on applications. Works need to be done allowing a seamless integration. Add-ons cannot cover development libraries, unless every library is an add-on for all IDEs!
It can be done dynamic aka install devel packages on request by IDEs - see https://rgrunber.fedorapeople.org/eclipse_packagekit_1.ogv
It's great, but it is not address my concerns, because: 1) If its going to be the only method for installing -devel packages, it should always work: it should be able to install a missing library or header file (consider a makefile only project). Also, not everybody uses correct package name in their configure script, some people use corresponding Debian package name (with a lib prefix and even sometimes full debian package name: libfoo-dev); so partial/non-exact matching should be also implemented.
2) More importantly, it doesn't address my main concern at all: what if I want to create a new project, and I'm looking for a good XML library, or would like to see what Fedora has to offer in this area? Even if I've found a great library in Internet, I should create a test in my configure/cmake checks for that library and see if PK will find it. It doesn't look like a user friendly way to search for a development library! It's a workaround around a missing UI.
Looking for development libraries, see their ranking and even reading user's reviews is all completely useful for a developer, which aligns perfectly with what Software offers for applications.
Regards, Hedayat
Alexander Kurtakov Red Hat Eclipse team
On 28 December 2014 at 15:48, Alec Leamas leamas.alec@gmail.com wrote:
wouldn't it raise questions about the Gnome Software application's role in the workstation product?
I don't think it does, no. I'm a Red Hat employee, a Fedora user, but also a GNOME developer. I'm not terribly keen pushing the tenet of "GNOME Software doesn't show MATE applications when running in GNOME" to "GNOME Software isn't suitable for Fedora Workstation".
Richard
On 29/12/14 16:18, Richard Hughes wrote:
On 28 December 2014 at 15:48, Alec Leamas leamas.alec@gmail.com wrote:
wouldn't it raise questions about the Gnome Software application's role in the workstation product?
I don't think it does, no. I'm a Red Hat employee, a Fedora user, but also a GNOME developer. I'm not terribly keen pushing the tenet of "GNOME Software doesn't show MATE applications when running in GNOME" to "GNOME Software isn't suitable for Fedora Workstation".
Fair enough. But to me, adding "GNOME Software (GS) also cannot install compilers, interpreters and other CLI tools" creates a more problematic situation.
And even the MATE applications issue is actually *very* different when evaluated in a developer context. A developer is both more likely to be interested in using multiple desktops (testing) and also probably more capable of handling the complexity required.
Is GS intended to be a one size fits all solution for both "novice users" and the workstation target developer user? If so, I cannot really see how this could be handled reasonably unless there is explicit support for the different roles e. g., some kind of modes or so.
And if walking this path, the Workstation default mode would be the one corresponding to a developer, right?
Cheers!
--alec
On 12/29/2014 04:48 PM, Alec Leamas wrote:
Fair enough. But to me, adding "GNOME Software (GS) also cannot install compilers, interpreters and other CLI tools" creates a more problematic situation.
To me, "Fedora Workstation" w/ Gnome is an incarnation of GnomeOS - An OS aimed at single-user, single-seat, kiosk-style of use-cases, aiming at competing with Android/WinRT, MetroUI and iOS.
Is GS intended to be a one size fits all solution for both "novice users" and the workstation target developer user?
I don't know if it's aimed at being a "one size fits all" solution. To me, it's a matter of fact, that in general, there can never ever be such a thing as a "one-size fits all" solution anywhere.
And if walking this path, the Workstation default mode would be the one corresponding to a developer, right?
Define "Workstation". I don't know which audience the people, who implemented it, were aiming at - It definitely wasn't my use-case scenario.
Ralf
On 30/12/14 13:07, Ralf Corsepius wrote:
On 12/29/2014 04:48 PM, Alec Leamas wrote:
And if walking this path, the Workstation default mode would be the one corresponding to a developer, right?
Define "Workstation". I don't know which audience the people, who implemented it, were aiming at - It definitely wasn't my use-case scenario.
The only definition I'm aware of is [1].
Cheers!
--alec
[1]: http://fedoraproject.org/wiki/Workstation/Workstation_PRD
Am 30.12.2014 um 13:07 schrieb Ralf Corsepius:
Is GS intended to be a one size fits all solution for both "novice users" and the workstation target developer user?
I don't know if it's aimed at being a "one size fits all" solution. To me, it's a matter of fact, that in general, there can never ever be such a thing as a "one-size fits all" solution anywhere.
it can and it is known as KDE because KDE is highly configureable but you do not need to configure much to start - but you have the capabilities to adopt the UI to your personal workflow
also GNOME tries to make a interface for a desktop as well as for tablets - KDE developers, especially in context Plasma5 realized that this is only a compromise for all usecases
the idea is that the UI knows if it runs on a tablet or you connected a docking station with a 27" screen and appears differently _______________________________________
http://linux-beta.slashdot.org/story/14/07/16/1355218/kde-releases-plasma-5
Plasma 5.0 improves support for high-DPI displays and ships a converged shell, able to switch between user experiences for different target devices
On 30/12/14 04:07 AM, Ralf Corsepius wrote:
On 12/29/2014 04:48 PM, Alec Leamas wrote:
Fair enough. But to me, adding "GNOME Software (GS) also cannot install compilers, interpreters and other CLI tools" creates a more problematic situation.
To me, "Fedora Workstation" w/ Gnome is an incarnation of GnomeOS - An OS aimed at single-user, single-seat, kiosk-style of use-cases, aiming at competing with Android/WinRT, MetroUI and iOS.
Only valid with default setting from Live Media. Listed OS above are primarily designed from mobile device in mind with "GnomeOS" is simply a general purpose combining elements from mobile desktop environments and notably Apple OS X.
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Alec Leamas -
Aleksandar Kurtakov -
Alexander Ploumistos -
Andrew Lutomirski -
Ben Cotton -
Bill Nottingham -
Bohuslav Kabrda -
Chris Murphy -
DJ Delorie -
Emmanuel Seyman -
Garry Williams -
Hedayat Vatankhah -
Ian Malone -
Luya Tshimbalanga -
Michael Catanzaro -
Miloslav Trmač -
Nico Kadel-Garcia -
Orcan Ogetbil -
Peter Hutterer -
Rahul Sundaram -
Ralf Corsepius -
Reindl Harald -
Richard Hughes -
Stephen John Smoogen -
Tomas Radej