2:32 p.m.
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!
3:45 p.m.
On Fri, Dec 26, 2014 at 3:32 PM, Alexander Ploumistos
<alex.ploumistos(a)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.
--
Ben Cotton
7:57 a.m.
2014-12-26 23:45 GMT+02:00 Ben Cotton <bcotton(a)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.
3:53 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6:36 p.m.
On 27 December 2014 at 21:53, Adam Williamson
<adamwill(a)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).
--
imalone
http://ibmalone.blogspot.co.uk
7:26 p.m.
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
8:31 p.m.
On Mon, Dec 29, 2014 at 8:26 PM, Rahul Sundaram <metherid(a)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.
7:09 a.m.
On 30 December 2014 at 01:26, Rahul Sundaram <metherid(a)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?
--
imalone
http://ibmalone.blogspot.co.uk
7:13 a.m.
* Ian Malone [30/12/2014 13:09] :
On 30 December 2014 at 01:26, Rahul Sundaram <metherid(a)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
12:53 p.m.
On 30 December 2014 at 13:13, Emmanuel Seyman <emmanuel(a)seyman.fr> wrote:
* Ian Malone [30/12/2014 13:09] :
>
> On 30 December 2014 at 01:26, Rahul Sundaram <metherid(a)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.
--
imalone
http://ibmalone.blogspot.co.uk
4:26 p.m.
On 26 December 2014 at 20:32, Alexander Ploumistos
<alex.ploumistos(a)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
5:17 p.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
Am 27.12.2014 um 23:26 schrieb Richard Hughes:
On 26 December 2014 at 20:32, Alexander Ploumistos
<alex.ploumistos(a)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
6:57 a.m.
On 27 December 2014 at 23:17, Reindl Harald <h.reindl(a)thelounge.net> wrote:
having choices and options is the reason why people switch to Linux,
http://www.islinuxaboutchoice.com/
Richard
7:06 a.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
Am 28.12.2014 um 13:57 schrieb Richard Hughes:
On 27 December 2014 at 23:17, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> having choices and options is the reason why people switch to Linux,
http://www.islinuxaboutchoice.com/
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
3:13 p.m.
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,
http://www.islinuxaboutchoice.com/
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
4:11 p.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
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,
>
> http://www.islinuxaboutchoice.com/
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
6:23 p.m.
2014-12-28 0:26 GMT+02:00 Richard Hughes <hughsient(a)gmail.com>:
On 26 December 2014 at 20:32, Alexander Ploumistos
<alex.ploumistos(a)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
8:15 p.m.
On Sat, Dec 27, 2014 at 6:23 PM, Alexander Ploumistos
<alex.ploumistos(a)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
11:08 a.m.
2014-12-28 15:02 GMT+02:00 Richard Hughes <hughsient(a)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(a)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".
11:39 a.m.
On Sun, Dec 28, 2014 at 11:08 AM, Alexander Ploumistos
<alex.ploumistos(a)gmail.com> wrote:
2014-12-28 15:02 GMT+02:00 Richard Hughes <hughsient(a)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.
11:46 a.m.
>> * 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.
3:45 p.m.
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. :)
--
Garry T. Williams
4:06 p.m.
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
12:04 p.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
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
1:10 p.m.
2014-12-28 19:39 GMT+02:00 Michael Catanzaro <mcatanzaro(a)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(a)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.
1:34 p.m.
2014-12-28 21:10 GMT+02:00 Alexander Ploumistos <alex.ploumistos(a)gmail.com>:
2014-12-28 19:39 GMT+02:00 Michael Catanzaro
<mcatanzaro(a)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.
1:38 p.m.
On Sun, Dec 28, 2014 at 1:10 PM, Alexander Ploumistos
<alex.ploumistos(a)gmail.com> wrote:
2014-12-28 19:39 GMT+02:00 Michael Catanzaro
<mcatanzaro(a)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.
[1] http://rpmfusion.org/Configuration
2:18 p.m.
2014-12-28 21:38 GMT+02:00 Michael Catanzaro <mcatanzaro(a)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...
2:44 p.m.
On Sat, Dec 27, 2014 at 7:15 PM, Michael Catanzaro <mcatanzaro(a)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.
--
Chris Murphy
7:02 a.m.
On 28 December 2014 at 00:23, Alexander Ploumistos
<alex.ploumistos(a)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
9:48 a.m.
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
11:05 a.m.
On Sun, Dec 28, 2014 at 9:48 AM, Alec Leamas <leamas.alec(a)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.
2:42 p.m.
On 28/12/14 18:05, Michael Catanzaro wrote:
On Sun, Dec 28, 2014 at 9:48 AM, Alec Leamas
<leamas.alec(a)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?
5:58 p.m.
On Sun, Dec 28, 2014 at 2:42 PM, Alec Leamas <leamas.alec(a)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.
6:32 p.m.
On 12/29/2014 12:58 AM, Michael Catanzaro wrote:
On Sun, Dec 28, 2014 at 2:42 PM, Alec Leamas
<leamas.alec(a)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
9:28 p.m.
On 28 December 2014 at 17:32, Ralf Corsepius <rc040203(a)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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Stephen J Smoogen.
3 a.m.
On 12/29/2014 04:28 AM, Stephen John Smoogen wrote:
On 28 December 2014 at 17:32, Ralf Corsepius <rc040203(a)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(a)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
9:29 a.m.
On Mon, Dec 29, 2014 at 3:00 AM, Ralf Corsepius <rc040203(a)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.
3:50 a.m.
On 29 December 2014 at 03:28, Stephen John Smoogen <smooge(a)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
6:27 a.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
Am 29.12.2014 um 10:50 schrieb Richard Hughes:
On 29 December 2014 at 03:28, Stephen John Smoogen
<smooge(a)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
6:33 a.m.
On 29/12/14 10:50, Richard Hughes wrote:
On 29 December 2014 at 03:28, Stephen John Smoogen
<smooge(a)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(a)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(a)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
1:57 p.m.
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.
--
*Luya Tshimbalanga*
Fedora Design Team
Design Suite spin maintainer
2:34 p.m.
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
3:58 p.m.
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.
--
*Luya Tshimbalanga*
Fedora Design Team
Design Suite spin maintainer
4:30 p.m.
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
4:39 p.m.
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.
5:31 p.m.
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
9:25 a.m.
On 30 December 2014 at 23:31, Chris Murphy <lists(a)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
4:02 a.m.
On 31/12/14 16:25, Richard Hughes wrote:
On 30 December 2014 at 23:31, Chris Murphy
<lists(a)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
4:42 a.m.
On 2 January 2015 at 10:02, Alec Leamas <leamas.alec(a)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
7:57 a.m.
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
12:45 p.m.
/*Alec Leamas <leamas.alec(a)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
3:04 a.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
----- 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?
--
Regards,
Slavek Kabrda
5:16 a.m.
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
9:41 a.m.
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
11:50 p.m.
On Wed, Dec 31, 2014 at 8:25 AM, Richard Hughes <hughsient(a)gmail.com> wrote:
On 30 December 2014 at 23:31, Chris Murphy
<lists(a)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."
--
Chris Murphy
4:45 p.m.
2014-12-30 23:58 GMT+02:00 Luya Tshimbalanga <luya(a)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.
6:10 a.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
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
7:52 a.m.
2014-12-29 14:10 GMT+02:00 Reindl Harald <h.reindl(a)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.
11:25 a.m.
On Sun, Dec 28, 2014 at 8:28 PM, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On 28 December 2014 at 17:32, Ralf Corsepius <rc040203(a)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(a)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.
--
Chris Murphy
12:39 p.m.
On Mon, Dec 29, 2014 at 11:22 AM, Alexander Ploumistos
<alex.ploumistos(a)gmail.com> wrote:
2014-12-29 19:25 GMT+02:00 Chris Murphy
<lists(a)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.
--
Chris Murphy
12:47 p.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
Am 29.12.2014 um 19:39 schrieb Chris Murphy:
On Mon, Dec 29, 2014 at 11:22 AM, Alexander Ploumistos
<alex.ploumistos(a)gmail.com> wrote:
> 2014-12-29 19:25 GMT+02:00 Chris Murphy <lists(a)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
2:05 p.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
----- 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
9:47 p.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
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
1:37 a.m.
On Fri, Jan 2, 2015 at 10:47 PM, Reindl Harald <h.reindl(a)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.
10:09 a.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
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
10:35 a.m.
On 5 January 2015 at 09:09, Miloslav Trmač <mitr(a)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
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 ☺ )
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Stephen J Smoogen.
10:48 a.m.
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
12:10 p.m.
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
12:17 p.m.
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
12:06 p.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
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
10:37 a.m.
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
12:36 p.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
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”.
12:59 p.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
(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
12:59 p.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
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
1:02 p.m.
On Mon, Jan 5, 2015 at 10:36 AM, Miloslav Trmač <mitr(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
10:39 a.m.
Andrew Lutomirski (luto(a)mit.edu) said:
On Mon, Jan 5, 2015 at 10:36 AM, Miloslav Trmač
<mitr(a)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
11:13 a.m.
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
11:48 a.m.
/*Bill Nottingham <notting(a)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
1:28 p.m.
On 6 January 2015 at 10:48, Hedayat Vatankhah <hedayat.fwd(a)gmail.com> wrote:
*Bill Nottingham <notting(a)splat.cc> <notting(a)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.
1:51 p.m.
On Tue, Jan 6, 2015 at 1:28 PM, Stephen John Smoogen <smooge(a)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.
2:26 p.m.
/*Michael Catanzaro <mcatanzaro(a)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(a)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
9:56 a.m.
Hedayat Vatankhah (hedayat.fwd(a)gmail.com) said:
/*Bill Nottingham <notting(a)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
3:02 p.m.
/*Bill Nottingham <notting(a)splat.cc>*/ wrote on Wed, 7 Jan 2015 10:56:31
-0500:
Hedayat Vatankhah (hedayat.fwd(a)gmail.com) said:
> /*Bill Nottingham <notting(a)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
1:52 p.m.
2014-12-29 20:39 GMT+02:00 Chris Murphy <lists(a)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.
3:01 p.m.
On Mon, Dec 29, 2014 at 12:52 PM, Alexander Ploumistos
<alex.ploumistos(a)gmail.com> wrote:
2014-12-29 20:39 GMT+02:00 Chris Murphy
<lists(a)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.
--
Chris Murphy
3:10 p.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
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
6:58 p.m.
2014-12-29 23:01 GMT+02:00 Chris Murphy <lists(a)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.
12:17 a.m.
On Mon, Dec 29, 2014 at 5:58 PM, Alexander Ploumistos
<alex.ploumistos(a)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.
--
Chris Murphy
12:34 a.m.
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
6:19 p.m.
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(a)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?
6:32 p.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
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(a)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"
6:21 p.m.
/*Michael Catanzaro <mcatanzaro(a)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(a)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
2:25 p.m.
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.
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).
DevAssistant
application available by default on Fedora Workstation is
designed for that purpose.
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.
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
Graphic & Web Designer
E: luya(a)fedoraproject.org
W: http://www.coolest-storm.net
3:15 p.m.
/*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?
> 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).
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.
> 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.
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
7:29 p.m.
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
Graphic & Web Designer
E: luya(a)fedoraproject.org
W: http://www.coolest-storm.net
1:26 p.m.
/*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
2:19 p.m.
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++:
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.
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
2:01 a.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
----- Original Message -----
From: "Alec Leamas" <leamas.alec(a)gmail.com>
To: "Development discussions related to Fedora"
<devel(a)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++:
> 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.
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
1:55 a.m.
New subject: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
----- Original Message -----
From: "Hedayat Vatankhah" <hedayat.fwd(a)gmail.com>
To: "Development discussions related to Fedora"
<devel(a)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?
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).
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.
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.
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(a)fedoraproject.org W: http://www.coolest-storm.net
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
9:26 p.m.
/*Aleksandar Kurtakov <akurtako(a)redhat.com>*/ wrote on Sun, 4 Jan 2015
02:55:17 -0500 (EST):
----- Original Message -----
> From: "Hedayat Vatankhah" <hedayat.fwd(a)gmail.com>
> To: "Development discussions related to Fedora"
<devel(a)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
9:18 a.m.
On 28 December 2014 at 15:48, Alec Leamas <leamas.alec(a)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
9:48 a.m.
On 29/12/14 16:18, Richard Hughes wrote:
On 28 December 2014 at 15:48, Alec Leamas
<leamas.alec(a)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
6:07 a.m.
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
6:20 a.m.
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
6:26 a.m.
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
1:37 p.m.
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.
--
*Luya Tshimbalanga*
Fedora Design Team
Design Suite spin maintainer
3396
days inactive
3408
days old
108 comments
26 participants
participants (26)
-
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