1:36 p.m.
Yumex is great package manager
What do you think?
$ sudo yum install yumex
Regards!
balerocms.com
1:39 p.m.
On Thu, Nov 6, 2014 at 2:36 PM, Anibal Gomez <anibalgomez(a)balerocms.com> wrote:
Yumex is great package manager
Glad you like it.
What do you think?
The project overall is currently moving towards using dnf as the
default package manager. On top of that, Workstation is using the
software installer to accomplish graphical software installation. I
don't believe Yumex is going to replace this as the default.
josh
1:45 p.m.
On 11/06/2014 02:36 PM, Anibal Gomez wrote:
Yumex is great package manager
What do you think?
$ sudo yum install yumex
Regards!
balerocms.com
Hi Anibal!
Thanks for the suggestion!
However, The currently of the Workstation is focusing more on the
Software application for installing new software. While it is not a
graphical package manager (it only searches and installs applications
that have .desktop files) the concept is that the average user of Fedora
should be able to find and install all the applications they require for
the workstation it, and if they require lower level packages and
services, using yum (and soon the yum replacement, DNF), via the command
line is IMO the recommended default way.
cheers,
ryanlerch
3:16 p.m.
On Nov 6, 2014 2:45 PM, "Ryan Lerch" <rlerch(a)redhat.com> wrote:
Given our target audience, why not just present everything in
Software? Is
there some user testing data of our audience that has shown an alarming
amount of confusion regarding GUI driven installation of, for instance,
libraries?
Imho, as long as it's clear what is a GUI program and what isn't, I think
it far better to have one officially supported way of installing software
than the frustration of searching for some utility in Software and not
finding it.
Personally, I just never touch Software. Not b/c I have anything against
GUI software management but b/c I
don't want to be forced to wonder "is this $package going to show up in
Software?"
Best/Liam
On 11/06/2014 02:36 PM, Anibal Gomez wrote:
> Yumex is great package manager
> What do you think?
> $ sudo yum install yumex
> Regards!
> balerocms.com
Hi Anibal!
Thanks for the suggestion!
However, The currently of the Workstation is focusing more on the
Software
application for installing new software. While it is not a
graphical package manager (it only searches and installs applications that
have .desktop files) the concept is that the average user of Fedora should
be able to find and install all the applications they require for the
workstation it, and if they require lower level packages and services,
using yum (and soon the yum replacement, DNF), via the command line is IMO
the recommended default way.
3:18 p.m.
On Thu, Nov 6, 2014 at 11:16 PM, Liam <liam.bulkley(a)gmail.com> wrote:
On Nov 6, 2014 2:45 PM, "Ryan Lerch" <rlerch(a)redhat.com> wrote:
>
> On 11/06/2014 02:36 PM, Anibal Gomez wrote:
>>
>> Yumex is great package manager
>>
>> What do you think?
>>
>> $ sudo yum install yumex
>>
>> Regards!
>>
>> balerocms.com
>
> Hi Anibal!
>
> Thanks for the suggestion!
>
> However, The currently of the Workstation is focusing more on the
Software application for installing new software. While it is not a
graphical package manager (it only searches and installs applications that
have .desktop files) the concept is that the average user of Fedora should
be able to find and install all the applications they require for the
workstation it, and if they require lower level packages and services,
using yum (and soon the yum replacement, DNF), via the command line is IMO
the recommended default way.
>
Given our target audience, why not just present everything in Software? Is
there some user testing data of our audience that has shown an alarming
amount of confusion regarding GUI driven installation of, for instance,
libraries?
Imho, as long as it's clear what is a GUI program and what isn't, I think
it far better to have one officially supported way of installing software
than the frustration of searching for some utility in Software and not
finding it.
Personally, I just never touch Software. Not b/c I have anything against
GUI software management but b/c I
don't want to be forced to wonder "is this $package going to show up in
Software?"
Best/Liam
--
desktop mailing list
desktop(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
Software is not about "packages". it's about applications.
--
-Elad Alfassa.
3:35 p.m.
On 11/06/2014 04:18 PM, Elad Alfassa wrote:
On Thu, Nov 6, 2014 at 11:16 PM, Liam <liam.bulkley(a)gmail.com
<mailto:liam.bulkley@gmail.com>> wrote:
On Nov 6, 2014 2:45 PM, "Ryan Lerch" <rlerch(a)redhat.com
<mailto:rlerch@redhat.com>> wrote:
>
> On 11/06/2014 02:36 PM, Anibal Gomez wrote:
>>
>> Yumex is great package manager
>>
>> What do you think?
>>
>> $ sudo yum install yumex
>>
>> Regards!
>>
>> balerocms.com <http://balerocms.com>
>
> Hi Anibal!
>
> Thanks for the suggestion!
>
> However, The currently of the Workstation is focusing more on
the Software application for installing new software. While it is
not a graphical package manager (it only searches and installs
applications that have .desktop files) the concept is that the
average user of Fedora should be able to find and install all the
applications they require for the workstation it, and if they
require lower level packages and services, using yum (and soon the
yum replacement, DNF), via the command line is IMO the recommended
default way.
>
Given our target audience, why not just present everything in
Software? Is there some user testing data of our audience that has
shown an alarming amount of confusion regarding GUI driven
installation of, for instance, libraries?
Imho, as long as it's clear what is a GUI program and what isn't,
I think it far better to have one officially supported way of
installing software than the frustration of searching for some
utility in Software and not finding it.
Personally, I just never touch Software. Not b/c I have anything
against GUI software management but b/c I
don't want to be forced to wonder "is this $package going to show
up in Software?"
Best/Liam
--
desktop mailing list
desktop(a)lists.fedoraproject.org
<mailto:desktop@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/desktop
Software is not about "packages". it's about applications.
Liam, I understand your frustration in searching for things in software
and not being able to find them. Just out of interest, what kinds of
packages were you searching for? Command line applications like mutt or
vim? Or command line tools like git, etc? Or low level packages like
kernel and other libraries?
The line was drawn in Software to define an "Application" as something
that has a desktop file -- aka a GUI application. Although you could
argue that mutt, vim, git etc are applications also but users are going
to use them on a command line, so i think the assumption that was made
was that those users would be comfortable using the command line to
install them.
One thing that Software does add to the experience for GUI applications
is the ability to browse and search all the different kinds of
applications, see screenshots and more detailed descriptions. In my
software installation workflow, if i am looking for a graphical
application to solve my problem, i search Software (now too with the
search provider, it appears in the Overview when searching there), and
if i need a command line anything -- i go to the commandline and search
the repos using DNF.
cheers,
ryanlerh
5:47 p.m.
Hi
On Thu, Nov 6, 2014 at 4:35 PM, Ryan Lerch wrote:
The line was drawn in Software to define an "Application"
as something
that has a desktop file -- aka a GUI application. Although you could argue
that mutt, vim, git etc are applications also but users are going to use
them on a command line, so i think the assumption that was made was that
those users would be comfortable using the command line to install them.
<https://admin.fedoraproject.org/mailman/listinfo/desktop>
I have noted this before but this isn't a good assumption. I am very
comfortable using yum,dnf etc but I would prefer to use GNOME Software
since I get the benefit of ratings and while I am using GNOME Software to
install a bunch of apps, picking up git and mutt (or even graphical apps
that don't ship with appdata etc) along the way is easier than mentally
switching contexts depending on whether the app fits GNOME Software
requirements to be listed.
Rahul
7:33 a.m.
On November 7, 2014 1:47:25 AM EET, Rahul Sundaram <metherid(a)gmail.com> wrote:
Hi
On Thu, Nov 6, 2014 at 4:35 PM, Ryan Lerch wrote:
> The line was drawn in Software to define an "Application" as
something
> that has a desktop file -- aka a GUI application. Although you could
argue
> that mutt, vim, git etc are applications also but users are going to
use
> them on a command line, so i think the assumption that was made was
that
> those users would be comfortable using the command line to install
them.
> <https://admin.fedoraproject.org/mailman/listinfo/desktop>
>
I have noted this before but this isn't a good assumption. I am very
comfortable using yum,dnf etc but I would prefer to use GNOME Software
since I get the benefit of ratings and while I am using GNOME Software
to
install a bunch of apps, picking up git and mutt (or even graphical
apps
that don't ship with appdata etc) along the way is easier than mentally
switching contexts depending on whether the app fits GNOME Software
requirements to be listed.
And considering Workstation's target audience it makes sense for Software to provide
non-GUI applications too. Developers may know how to use git, but they shouldn't have
to learn how to use dnf. This would be a serious UX problem for most people if we stick to
this decision.
8:39 a.m.
On 7 November 2014 13:33, Nikos Roussos <comzeradd(a)fedoraproject.org> wrote:
This would be a serious UX problem for most people if we stick to
this decision.
So you want a UI that's more technical than gnome-software, and less
technical than dnf? I tried that with gnome-packagekit, and it wasn't
powerful enough for power users and wasn't easy to use for mere
mortals. Install gnome-packagekit (either from the software center, or
dnf :) and have a play.
Richard
8:53 a.m.
On 11/07/2014 09:39 AM, Richard Hughes wrote:
On 7 November 2014 13:33, Nikos Roussos
<comzeradd(a)fedoraproject.org> wrote:
> This would be a serious UX problem for most people if we stick to this decision.
So you want a UI that's more technical than gnome-software, and less
technical than dnf? I tried that with gnome-packagekit, and it wasn't
powerful enough for power users and wasn't easy to use for mere
mortals. Install gnome-packagekit (either from the software center, or
dnf :) and have a play.
Richard
Yeah, the problem here is where to draw the line. A developer may also
want to install libraries for the language they are developing in (e.g.
perl), but showing all the perl modules in software is really hard to do
while still making it usable. A search for "Web" alone would show
results for 7 perl modules that most users probably don't want.
cheers,
ryanlerch
8:57 a.m.
On Thu, Nov 06, 2014 at 06:47:25PM -0500, Rahul Sundaram wrote:
Hi
On Thu, Nov 6, 2014 at 4:35 PM, Ryan Lerch wrote:
> The line was drawn in Software to define an "Application" as something
> that has a desktop file -- aka a GUI application. Although you could argue
> that mutt, vim, git etc are applications also but users are going to use
> them on a command line, so i think the assumption that was made was that
> those users would be comfortable using the command line to install them.
> <https://admin.fedoraproject.org/mailman/listinfo/desktop>
>
I have noted this before but this isn't a good assumption. I am very
comfortable using yum,dnf etc but I would prefer to use GNOME Software
since I get the benefit of ratings and while I am using GNOME Software to
install a bunch of apps, picking up git and mutt (or even graphical apps
that don't ship with appdata etc) along the way is easier than mentally
switching contexts depending on whether the app fits GNOME Software
requirements to be listed.
"This assumption doesn't fit me" != "This isn't a good
assumption."
Revisiting this approach on the basis of how you and I use our systems
is not constructive because we are atypical by definition.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
9:16 a.m.
Hi
On Fri, Nov 7, 2014 at 9:57 AM, Paul W. Frields wrote:
"This assumption doesn't fit me" != "This isn't a good
assumption."
Revisiting this approach on the basis of how you and I use our systems
is not constructive because we are atypical by definition.
I don't know about that. I am providing a rationale which you can agree
or disagree with but excluding people as atypical doesn't help. FYI, I am
in a DevOps role now and would count myself as part of the target audience
for Fedora workstation since funny enough I am running Fedora in my work
laptop and doing the sort of things you would expect someone running Fedora
workstation to do. Have we talked to anyone else in the target audience or
done any usability studies that suggest that filtering out command line
apps or libraries is actually helpful? What GNOME Software does *is* make
an assumption and that needs to be validated.
Rahul
9:38 a.m.
I just happened to have a discussion about this over lunch so I'll bite.
On Fri, Nov 7, 2014 at 4:16 PM, Rahul Sundaram <metherid(a)gmail.com> wrote:
I don't know about that. I am providing a rationale which you
can agree or
disagree with but excluding people as atypical doesn't help. FYI, I am in a
DevOps role now and would count myself as part of the target audience for
Fedora workstation since funny enough I am running Fedora in my work laptop
and doing the sort of things you would expect someone running Fedora
workstation to do. Have we talked to anyone else in the target audience or
done any usability studies that suggest that filtering out command line apps
or libraries is actually helpful? What GNOME Software does *is* make an
assumption and that needs to be validated.
I wouldn't call it an assumption. It's a conscious design decision.
gnome-software is supposed to be an application installer where an
application is something that user can tangibly relate to, i.e. it has
a UI and an icon to be launched.
The current problem is that gnome-software is currently implemented on
top of the "sea of packages" repository model that is the only
currently existing software distribution model that we have available,
and this mismatch between design intent and implementation shows
through some cracks here and there despite the fantastic work that has
gone into gnome-software.
The way I see it (disclaimer: I'm not a gnome-software developer or
designer so this is just my personal opinion), at some point, when the
infrastructure to distribute bundled applications gets developed,
gnome-software will switch to show that kind of application and the
package repository will be a secondary thing that might get used just
fulfill dependencies.
Basically gnome-software is designed for a world where there's a very
clear distinction between applications and operating system.
Unfortunately we don't live in that world yet.
Rui
10:36 a.m.
Hi
On Fri, Nov 7, 2014 at 10:38 AM, Rui Tiago Cação Matos wrote:
I wouldn't call it an assumption. It's a conscious design decision.
gnome-software is supposed to be an application installer where an
application is something that user can tangibly relate to, i.e. it has
a UI and an icon to be launched.
Well, just because it has a UI and icon doesn't mean it automatically gets
included in GNOME Software. The requirements are higher than that (no Gtk1
apps or apps which don't have a high resolution icon, appdata etc) and is
getting more stringent with time. That is a fine design goal if it was
supposed to cater to purely desktop apps I suppose but the result of is
that I cannot trust GNOME Software search because it might be excluding
something I find useful and the filtering is not something I can configure.
So I end up using dnf in the command line even though I would love to use
GNOME Software more.
Rahul
9:43 a.m.
On 7 Nov 2014 15:24, "Rahul Sundaram" <metherid(a)gmail.com> wrote:
On Fri, Nov 7, 2014 at 9:57 AM, Paul W. Frields wrote:
>
>
> "This assumption doesn't fit me" != "This isn't a good
assumption."
> Revisiting this approach on the basis of how you and I use our systems
> is not constructive because we are atypical by definition.
I don't know about that. I am providing a rationale which you can agree
or
disagree with but excluding people as atypical doesn't help. FYI, I am
in a DevOps role now and would count myself as part of the target audience
for Fedora workstation since funny enough I am running Fedora in my work
laptop and doing the sort of things you would expect someone running Fedora
workstation to do. Have we talked to anyone else in the target audience or
done any usability studies that suggest that filtering out command line
apps or libraries is actually helpful? What GNOME Software does *is* make
an assumption and that needs to be validated.
I actually found Software useful for the first time today. I had
vim-enhanced installed but I really wanted gVim. Searching for it using dnf
yielded nothing, and of course searching for vim yields loads of noise. (I
also tried searching for vim-gtk, vim-gnome, etc.) Searching for vim in
Software immediately found what I was after though. If Software included
libraries etc. it would be just as unhelpful as dnf for cases like this.
R
--
"Racing turtles, the grapefruit is winning..."
12:37 p.m.
Hi,
On Fri, Nov 7, 2014 at 10:43 AM, Richard Turner <rjt(a)zygous.co.uk>
wrote:
Searching for vim in Software immediately found what I was after
though. If Software included libraries etc. it would be just as
unhelpful as dnf for cases like this.
To this point, I think maybe something like DevAssistant would be the
sort of tool for finding and installing particular libraries. 'App
shopping' is definitely different than seeking out a particular library
so it probably doesn't make sense to cater to both in the same app.
I don't know what the answer is for actual applications that are
non-GUI that the target audience for workstation uses, though. I do
think it would be cool (as I think Ryan has suggested on this list
previously) to have .desktop files for command line apps so you can
launch them from the shell and so that they'd have a more useful
description / icon / etc in the windows overview so you can distinguish
your vim vs your mutt session in a grid of rectangular black boxes
otherwise labeled 'gnome terminal' (I use guake to avoid this scenario
now bc it drove me batty) If they did have desktop files then you'd
have the currently missing follow up / visual completion of
installation and it might then make more sense to include them in
software.
If workstation wasn't aimed at developers this wouldn't be a concern.
All of the above IMHO.
~m
1:38 p.m.
On Fri, Nov 07, 2014 at 10:16:07AM -0500, Rahul Sundaram wrote:
Hi
On Fri, Nov 7, 2014 at 9:57 AM, Paul W. Frields wrote:
>
> "This assumption doesn't fit me" != "This isn't a good
assumption."
> Revisiting this approach on the basis of how you and I use our systems
> is not constructive because we are atypical by definition.
>
I don't know about that. I am providing a rationale which you can agree
or disagree with but excluding people as atypical doesn't help.
I appreciate your wanting to have last word, so you're welcome to it
after this. :-) Excluding atypical cases is a necessary part of focus.
You and I both have a lot of historical Linux experience at the CLI,
using a lot of tools like yum, etc., and don't use the platforms most
prevalent out there like Mac OS X that I see most developers and
dev-ops folks using at conferences.[*]
[*] I can't really speak for what you use here, I'm conjecturing based
on my experience with your dedication to FOSS.
FYI, I am in a DevOps role now and would count myself as part of the
target audience for Fedora workstation since funny enough I am
running Fedora in my work laptop and doing the sort of things you
would expect someone running Fedora workstation to do. Have we
talked to anyone else in the target audience or done any usability
studies that suggest that filtering out command line apps or
libraries is actually helpful? What GNOME Software does *is* make
an assumption and that needs to be validated.
Not arguing that validation helps, I'm simply saying that requiring
validation because you don't feel your case is covered isn't
necessarily the right approach.
Anyway, I'm leaving further debate to hughsie & co. to decide on how
best to approach any revisit of assumptions, design, etc.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
4:10 p.m.
Hi
On Fri, Nov 7, 2014 at 2:38 PM, Paul W. Frields wrote:
Completely agree with that but I don't think command line experience makes
me atypical since developer types are part of the explicitly stated focus
of the workstation.
Rahul
I appreciate your wanting to have last word, so you're welcome to it
after this. :-)
That isn't excellent. Can we please focus on the discussion instead? Thanks
Excluding atypical cases is a necessary part of focus.
6:30 p.m.
On Fri, Nov 7, 2014 at 5:10 PM, Rahul Sundaram <metherid(a)gmail.com>
wrote:
Completely agree with that but I don't think command line
experience
makes me atypical since developer types are part of the explicitly
stated focus of the workstation.
To be fair (and maybe a pain in the butt, sorry) - even when I was in
computer science classes using Visual Studio (those were dark days) we
had to use the command line to run our apps. I know that relatively
speaking in the world of tech that is a very long time ago. Is
programming so different than that now that you can do it
professionally / seriously without command line tools (or without
wanting to use command line tools?)
Here's some real-life developers who aren't as niche as us (or at least
not in our niche!)
http://madelin.woods.usesthis.com/ - (developer for square) "I write my
code in Sublime Text 2 (tricked out with a ton of extra installed
packages), use iTerm2 for my terminal"
http://jennifer.wong.usesthis.com/ - (developer for Zillow / HotPads)
"I run git directly in Terminal, so I can learn its intricacies better
and I have a bunch of my personal projects committed to my GitHub
account."
http://adam.wiggins.usesthis.com/ - (founder / developer Heroku) "For
web development, my go-to stack for many years has been Vim, Git, Ruby,
Bundler, Sinatra, Postgres, Sequel, GitHub, Heroku, and S3."
http://brendan.gregg.usesthis.com/ - (Netflix perf engineer) "I use a
lot of somewhat standard software. For word processing, I do a lot of
my writing in the vim text editor. I wrote my last book in vim, for the
drafts, before they become OpenOffice and Word documents, which I use
as well. "
http://george.nachman.usesthis.com/ - (Google search app developer)
"For coding, I use vim when possible and XCode when necessary. Most
desktop GUIs do more harm than good, and I'd rather hang out in a TTY
all day."
http://yuri.victor.usesthis.com/ - (UX/dev at Vox Media) "I spend most
of my time on the command line full screen 4 windows at once opened
with a hotkey, but use Mac OS X because I can type things like "open
Photoshop," which I use mainly for making funnies on Twitter."
http://diana.kimball.usesthis.com/ (SoundCloud developer) "I also spend
a lot of time in Terminal; I write code in vim and recently switched to
using fish as my shell."
I could go on, but you get the point.
Here and there you'll see a dev profiled on that site who uses Linux,
but it's almost invariably Ubuntu (I found one Debian.)
~m
2:25 a.m.
On Sat, Nov 8, 2014 at 1:30 AM, Máirín Duffy <duffy(a)fedoraproject.org> wrote:
On Fri, Nov 7, 2014 at 5:10 PM, Rahul Sundaram <metherid(a)gmail.com> wrote:
Completely agree with that but I don't think command line experience makes
me atypical since developer types are part of the explicitly stated focus of
the workstation.
To be fair (and maybe a pain in the butt, sorry) - even when I was in
computer science classes using Visual Studio (those were dark days) we had
to use the command line to run our apps. I know that relatively speaking in
the world of tech that is a very long time ago. Is programming so different
than that now that you can do it professionally / seriously without command
line tools (or without wanting to use command line tools?)
The answer is "it depends" ... it depends mostly on two things
1) What are you developing for?
and
2) Which tool(s) do you use for it?
If the answer to 2) is $EDITOR then you probably will have to use a
terminal anyway. If it is $IDE it depends on 1) i.e whether you
develop something that can simply run in an IDE an does not need a
terminal for deployment and/or debuggung or not (like simple web apps
or android apps where testing in the emulator is sufficient).
11:11 p.m.
Hi Ryan,
On Nov 6, 2014 4:35 PM, "Ryan Lerch" <rlerch(a)redhat.com> wrote:
I don't use mutt or vim, but, otherwise, yeah, any of those.
There's also inbetweener items like gedit-plugin*, or gstreamer-plugins.
In the final evaluation, however, i'm not sure it really matters what it is
I'm trying to install. It simply is... odd... to have to make a "guess" as
to whether Software can install what I need. I say guess b/c I know that
the application needs a desktop file but I don't want to have to think
about that kind of thing. I don't want to be forced to make the decision
which tool to use in order to get the job done.
That simply seems like an unnecessary cognitive burden.
I understand that, and I'm perfectly fine using the CLI, but since a big
push was made with f.n to make Fedora a place for developers I thought I'd
kick the tires on the rest of the default apps.
I've been on f21 for awhile now and I can say that because of the
split-installation method, I just no longer even bother with Software.
Again, keep in mind, I've no issue with it because it's a GUI. A GUI
software manager can be a great experience as it is both more discoverable
than a CLI (even one as fine as yum), and allows for a richer experience
such as screenshots, ratings (which, iirc, don't mean anything now, but
will, presumably, become actual indications of user satisfaction, as much
as such a system allows), browsing-based discovery, and the like.
I understand all of that, but I also don't like the fact that Software is
giving me an abridged view of the repos.
If I'm genuinely searching for a tool, I won't know ahead of time whether
it only provides a CLI, or a GUI. Given that I just want the best tool I
want to know what tools are available and Software simply doesn't work in
that case. What's more, the original assumption given for the split seems
odd given the genuine issues that Software is causing. I'm simply unsure
why it is so important that the assumption must hold. As a result of that
assumption the facts on the ground are that users have to go through mental
gymnastics if they both want to install something and continue to use
Software rather than just always use the CLI. Given such a situation it
appears that users would gradually just stop using Software. Especially our
target group who aren't afraid of the terminal.
I'm not trying to be difficult with this as I want Fedora to succeed, I'm
just not seeing the benefits of the assumption, especially (once again!),
given our target user base.
Best/Liam
On 11/06/2014 04:18 PM, Elad Alfassa wrote:
> On
Thu, Nov 6, 2014 at 11:16 PM, Liam <liam.bulkley(a)gmail.com> wrote:
> > >> On Nov 6, 2014 2:45 PM,
"Ryan Lerch" <rlerch(a)redhat.com> wrote:
>> >> > On 11/06/2014 02:36
PM, Anibal Gomez wrote:
>> > >> >> Yumex is great
package manager
>> > >> >> What do you
think?
>> > >> >> $ sudo yum install
yumex
>> > >> >> Regards!
>> > >> >> balerocms.com
>> >> > Hi Anibal!
>> >> > Thanks for the
suggestion!
>> >> > However, The currently
of the Workstation is focusing more on the
Software application for installing new
software. While it is not a
graphical package manager (it only searches and installs applications that
have .desktop files) the concept is that the average user of Fedora should
be able to find and install all the applications they require for the
workstation it, and if they require lower level packages and services,
using yum (and soon the yum replacement, DNF), via the command line is IMO
the recommended default way.
>> >> Given our target audience,
why not just present everything in Software?
Is there some user testing data of our
audience that has shown an alarming
amount of confusion regarding GUI driven installation of, for instance,
libraries?
>> Imho, as long as it's clear what is a GUI program and
what isn't, I
think it far better to have one officially supported way of
installing
software than the frustration of searching for some utility in Software and
not finding it.
>> Personally, I just never touch Software. Not b/c I have
anything
against GUI software management but b/c I
>> don't want to be forced to wonder "is this $package
going to show up in
Software?"
> >> Best/Liam
> > >> --
>> desktop mailing list
>> desktop(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/desktop
> Software is not about
"packages". it's about applications.
Liam, I understand your frustration in searching for things in software
and not
being able to find them. Just out of interest, what kinds of
packages were you searching for? Command line applications like mutt or
vim? Or command line tools like git, etc? Or low level packages like kernel
and other libraries?
The line was drawn in Software to define an "Application"
as something
that has a desktop file -- aka a GUI application. Although you could
argue
that mutt, vim, git etc are applications also but users are going to use
them on a command line, so i think the assumption that was made was that
those users would be comfortable using the command line to install them.
One thing that Software does add to the experience for GUI
applications
is the ability to browse and search all the different kinds of
applications, see screenshots and more detailed descriptions. In my
software installation workflow, if i am looking for a graphical application
to solve my problem, i search Software (now too with the search provider,
it appears in the Overview when searching there), and if i need a command
line anything -- i go to the commandline and search the repos using DNF.
12:59 p.m.
On 11/06/2014 09:11 PM, Liam wrote:
I understand all of that, but I also don't like the fact that
Software
is giving me an abridged view of the repos.
If I'm genuinely searching for a tool, I won't know ahead of time
whether it only provides a CLI, or a GUI. Given that I just want the
best tool I want to know what tools are available and Software simply
doesn't work in that case. What's more, the original assumption given
for the split seems odd given the genuine issues that Software is
causing. I'm simply unsure why it is so important that the assumption
must hold. As a result of that assumption the facts on the ground are
that users have to go through mental gymnastics if they both want to
install something and continue to use Software rather than just always
use the CLI. Given such a situation it appears that users would
gradually just stop using Software. Especially our target group who
aren't afraid of the terminal.
I'm not trying to be difficult with this as I want Fedora to succeed,
I'm just not seeing the benefits of the assumption, especially (once
again!), given our target user base.
I have also often found myself in this position where I am not sure if I
will be able to find something in Software. I tend to not use it for
anything but discovery of new GUI applications because it does not give
me a full picture of the ecosystem of packages around the application,
and for example, whether I might want to install some related packages
that enable some extended functionality but don't show up in Software.
I would like it if there were an easily accessible toggle switch to show
or hide libraries and CLI applications in searches. To me this seems to
be a reasonable compromise.
Cheers,
Zach
3:14 p.m.
On 7 November 2014 18:59, Zach Ploskey <zach(a)ploskey.com> wrote:
I might want to install some related packages that enable
some extended functionality but don't show up in Software.
We do have metainfo for that in F21:
http://blogs.gnome.org/hughsie/2014/06/11/application-addons-in-gnome-sof...
I would like it
if there were an easily accessible toggle switch to show or hide libraries
and CLI applications in searches. To me this seems to be a reasonable
compromise.
If we enabled this "mode" they'd be thousands of items, all with the
same icon. Like Mo says; it's a different app. You want a GUI
application you use gnome-software. You want a package GUI, use
gnome-packagekit. I think trying to mush the two into one coherent
application would end up in an installer application that does neither
very well at all.
Richard
5:08 p.m.
On Fri, Nov 07, 2014 at 09:14:50PM +0000, Richard Hughes wrote:
If we enabled this "mode" they'd be thousands of items,
all with the
same icon. Like Mo says; it's a different app. You want a GUI
application you use gnome-software. You want a package GUI, use
gnome-packagekit.
I don't think it's that easy. Sure, if you already know you want to
install a specific package, just using yum/dnf is the obvious solution.
When you don't know the name of the thing you want (or, even, if
something like it exists at all) it gets messy, though. Say I need some
program to convert weird document format X into PDFs or do some other
random task. As searching and browsing available programs with yum is
not a particularly pleasant activity I go for Gnome Software.
Using it is a nice experience but it doesn't get me any results for my
search. I think 'aww crap, no tool for me in the repos' although there
are two perfectly fine command-line programs in Fedora I'd be happy to
know about.
People on this list might know they have to search for "packages" when
there're no "applications" available. That's not true for everyone. My
anecdotal experience from helping out fellow students suggests it's a
common issue. They need a C compiler, bison and make to do assignments
and it just doesn't show up in Ubuntu's software center (at least it
didn't then, maybe they changed that). They don't know what to do and
ask someone with more experience. Well, sometimes at least. The other
(at least as common) option is to start googling and then paste random
commands from some website into a root shell.
I agree with you that dumping gigantic lists of packages on the screen
isn't a solution. But just dismissing the problem as "it's for
applications only" isn't that great, either. Not when most users
probably think of "applications" as being the same thing as programs in
general.
Lars
5:59 p.m.
On Sun, Nov 9, 2014 at 6:08 PM, Lars Seipel <lars.seipel(a)gmail.com>
wrote:
When you don't know the name of the thing you want (or, even, if
something like it exists at all) it gets messy, though. Say I need
some
program to convert weird document format X into PDFs or do some other
random task. As searching and browsing available programs with yum is
not a particularly pleasant activity I go for Gnome Software.
I search online to figure out the name of said app first and then
search for it on the system. Especially for the PDF conversion case
because there are *so* many utilities for that sort of thing but each
only does a few niche things well. Even if each one had a profile in
GNOME software, it's not going to have all the little nitty gritty
details I'd be better served with from an in-depth blog post or forum
post or whatever about in. (I say this having had to do many apparently
rather freaky conversions esp. with PDF and EPS and color spaces over
the years, thanks vendor friends.)
Using it is a nice experience but it doesn't get me any results
for my
search. I think 'aww crap, no tool for me in the repos' although there
are two perfectly fine command-line programs in Fedora I'd be happy to
know about.
I do think it'd be nice to have command-line programs for PDF
conversion in GNOME software - being a biased designer that
occasionally does print work who needs these tools. To be fair, PDF
conversion is a bit of a mess in the FLOSS world and I think we'd
benefit from having one (or less than 20, anyway) comprehensive tool
for working with PDFs and performing the sorts of tasks useful for
people needing to wrangle them.
I think that the above, though, is a bit different than having say
python-babel in GNOME software.
People on this list might know they have to search for
"packages" when
there're no "applications" available. That's not true for everyone. My
anecdotal experience from helping out fellow students suggests it's a
common issue. They need a C compiler, bison and make to do assignments
and it just doesn't show up in Ubuntu's software center (at least it
didn't then, maybe they changed that). They don't know what to do and
ask someone with more experience. Well, sometimes at least. The other
(at least as common) option is to start googling and then paste random
commands from some website into a root shell.
This is a good case for using DevAssistant. And the professors aren't
telling them what to install to get their assignments done? (?!) Do
they not have lab sessions where part of the first class is spent
configuring their laptops to complete assignments? Even some of my
400-level comp sci classes had environment configuration stuff in the
first lecture.
I agree with you that dumping gigantic lists of packages on the
screen
isn't a solution. But just dismissing the problem as "it's for
applications only" isn't that great, either. Not when most users
probably think of "applications" as being the same thing as programs
in
general.
I think a couple of things are being conflated:
- GUI app vs command line app
- App vs non-app (e.g. library, codec, driver, etc.)
I'm with you on the first one - I think more command line apps should
be included. However, I'm not so sure that something like GCC counts as
a 'command line app.' (I mean, kinda sorta, but not really!) Even when
doing C development on my system, I have never installed the gcc
package specifically - I use the development package group. For a lot
of libraries needs to compile an app, I also don't typically install
the packages one-by-one, I do yum-builddep. I think DevAssistant has an
option similar to yum-builddep. I also think it does a bit better than
installing the development package group, because it's a bit more
granular and you can pick particular languages and frameworks of focus
and not install everything that could be used for development.
~m
7:07 p.m.
On 11/09/2014 06:59 PM, Máirín Duffy wrote:
On Sun, Nov 9, 2014 at 6:08 PM, Lars Seipel
<lars.seipel(a)gmail.com> wrote:
> When you don't know the name of the thing you want (or, even, if
> something like it exists at all) it gets messy, though. Say I need
> some program to convert weird document format X into PDFs or do some
> other random task. As searching and browsing available programs with
> yum is not a particularly pleasant activity I go for Gnome Software.
I search online to figure out the name of said app first and then search
for it on the system. Especially for the PDF conversion case because
there are *so* many utilities for that sort of thing but each only does
a few niche things well. Even if each one had a profile in GNOME
software, it's not going to have all the little nitty gritty details I'd
be better served with from an in-depth blog post or forum post or
whatever about in. (I say this having had to do many apparently rather
freaky conversions esp. with PDF and EPS and color spaces over the
years, thanks vendor friends.)
That's great. We all do that. Wasn't there an XKCD where he explained
that everyone thought that he was good at computers, but 90% of that was
that he knew how to use Google?
But if that little app isn't there in the out-of-the-box "Applications"
installer utility, what should a user do?
> They don't know what to do and
> ask someone with more experience. Well, sometimes at least. The other
> (at least as common) option is to start googling and then paste random
> commands from some website into a root shell.
Oh, right.
This is a good case for using DevAssistant. And the professors
aren't
telling them what to install to get their assignments done? (?!) Do they
not have lab sessions where part of the first class is spent configuring
their laptops to complete assignments? Even some of my 400-level comp
sci classes had environment configuration stuff in the first lecture.
Maybe things have gotten better, but for my coursework the instructions
were "use language X. it's installed on the lab computers. If you want
to develop and test on your own computer, that's fine. Make sure it runs
on the lab computers too."
At the instigation of this thread, I just checked out DevAssistant -
it's pretty neat, and it even suggested some utilities that I had
forgotten about. It should probably concern someone that I've never
heard of DA before. But not all package-finding missions are about *that
kind* of developer tool.
What about Python's Twisted framework? Netcat? Nmap? Erlang?
> I agree with you that dumping gigantic lists of packages on the
screen
> isn't a solution. But just dismissing the problem as "it's for
> applications only" isn't that great, either. Not when most users
> probably think of "applications" as being the same thing as programs
> in general.
I think a couple of things are being conflated:
- GUI app vs command line app
- App vs non-app (e.g. library, codec, driver, etc.)
I'm with you on the first one - I think more command line apps should be
included. However, I'm not so sure that something like GCC counts as a
'command line app.' (I mean, kinda sorta, but not really!)
gcc is most definitely something that a Fedora Workstation user may
(probably will) search for. And expect to find. And if the
out-of-the-box application installer tool doesn't find it, they will be
confused. Just because there are 73 other ways to end up with gcc on
your system (none of which include using the out-of-the-box-default
installer utility) doesn't mean that it will be easy for a user to find
those.
The only counter-example I've heard for why the yum/dnf metadata won't
find what you want is someone who tried to find gvim, but that sounds
like a red herring. That's just poor packaging. Who would think to call
it vim-X11? I've never heard it called that. And it's especially weird
to not even mention "gvim" somewhere in the description. That's a
packaging bug and someone should fix that.
Why can't the default packaging selector app be a do-it-all app? The
defaults can restrict searches to whatever the definition of
"Application", but let the user use the full power of the packaging
system's metadata.
-Adam Batkin
9:20 p.m.
Hi
On Sun, Nov 9, 2014 at 6:59 PM, Máirín Duffy wrote:
This is a good case for using DevAssistant. And the professors
aren't
telling them what to install to get their assignments done? (?!) Do they
not have lab sessions where part of the first class is spent configuring
their laptops to complete assignments? Even some of my 400-level comp sci
classes had environment configuration stuff in the first lecture.
There were a lot of points in your mail and they are worth addressing but
since I was in college doing a Master's program not too long ago, I wanted
to reply to this quickly:
Typically professors are willing to help out or point you in the right
direction if you are using Windows or perhaps even a Mac depending on what
they use themselves but so far in all the classes I have attended, I am the
only person using Linux on my laptop and therefore when I get struck, I got
to figure out the equivalent tools myself. Sometimes I give up and just
use a VM but most often than not, the tools were already in the repository
but I didn't know the names of the packages and yum was returning too much
while GNOME Software was returning too little or nothing.
Our tools rock if you know exactly what you are looking for but are fairly
unhelpful if you don't. GNOME Software in Fedora 21 is good enough for me
to put it in front of someone who doesn't know Linux and expect them to
find *desktop* apps but if it is not too selfish to ask, I would want the
same for command line apps too.
Btw, the usability on devassistant when I tried it out was pretty bad. I
know you blogged about the problems you ran into and I will file bug
reports when I have time as well. It certainly has potential but it's
nothing something I would advertise heavily at this point.
Rahul
3:30 p.m.
On 11/7/2014 10:59 AM, Zach Ploskey wrote:
On 11/06/2014 09:11 PM, Liam wrote:
> I understand all of that, but I also don't like the fact that Software
> is giving me an abridged view of the repos.
>
> If I'm genuinely searching for a tool, I won't know ahead of time
> whether it only provides a CLI, or a GUI. Given that I just want the
> best tool I want to know what tools are available and Software simply
> doesn't work in that case. What's more, the original assumption given
> for the split seems odd given the genuine issues that Software is
> causing. I'm simply unsure why it is so important that the assumption
> must hold. As a result of that assumption the facts on the ground are
> that users have to go through mental gymnastics if they both want to
> install something and continue to use Software rather than just always
> use the CLI. Given such a situation it appears that users would
> gradually just stop using Software. Especially our target group who
> aren't afraid of the terminal.
>
> I'm not trying to be difficult with this as I want Fedora to succeed,
> I'm just not seeing the benefits of the assumption, especially (once
> again!), given our target user base.
I have also often found myself in this position where I am not sure if
I will be able to find something in Software. I tend to not use it
for anything but discovery of new GUI applications because it does not
give me a full picture of the ecosystem of packages around the
application, and for example, whether I might want to install some
related packages that enable some extended functionality but don't
show up in Software. I would like it if there were an easily
accessible toggle switch to show or hide libraries and CLI
applications in searches. To me this seems to be a reasonable compromise.
Cheers,
Zach
I also think that sugar-runner with@sugar-desktop should be installable
via software. It is admittedly a 6-12 yr old software (not usually
associated with developers) but It is python based and is training many
kids to learn programming via its many applications which show source so
they can learn to program.
For example:
http://wiki.sugarlabs.org/go/Google_Code_In_2014
http://activities.sugarlabs.org/en-US/sugar/
Tom Gilliard
satellit
3455
days inactive
3459
days old
desktop@lists.fedoraproject.org
28 comments
17 participants
participants (17)
-
Adam Batkin -
Anibal Gomez -
drago01 -
Elad Alfassa -
Josh Boyer -
Lars Seipel -
Liam -
Máirín Duffy -
Nikos Roussos -
Paul W. Frields -
Rahul Sundaram -
Richard Hughes -
Richard Turner -
Rui Tiago Cação Matos -
Ryan Lerch -
Thomas Gilliard -
Zach Ploskey