Ubunto

[Martin Gregorie]

Don't they eat their own dogfood over at Gnome HQ?

You'd hope so, but it doesn't look like it: if they did, surely they'd
have realised how much slower G3 is to use than G2 and done something
about it.

 

[Martin Gregorie]

Missing the point that it's open source, so if you really, really prefer
G2 to G3 you can always fix up G2 yourself to work on these.

Not missed at all. I've got more pressing things to work on than fixing G3

But it's also very likely that the Gnome folks will address the
complaints about G3 -- and, if they don't, that people will eventually
fork G3 and make a "no pet peeves" version of that.

As I said, I'll look at G3.2 but the omens as listed in the 3.2 roadmap
don't look good.

But why don't you run up F15 and give us your impressions?

 

[Martin Gregorie]

I am a puzzled by the Unix folk having so many ways of handling the GUI.
I have heard of Gnome 1 2 3, KDE, X-Windows, Xfce, Unify

Because we get a choice over the L&F. Everything uses X11, aka X-windows:
thats the underlying display technology for all graphical displays on
UNIX/Linux but it doesn't do window management/desktops. X-term is a non-
graphical way of using X11 as a text-mode terminal -rather like a DOS
box, but capable of talking to both local and remote hosts.

To do anything useful with X11 you use a window manager: all distros pick
one to use as default and each has its own style of handling the desktop,
decorating application windows, launching applications, etc. etc. - hence
the religious wars and differences of opinion over them. The common ones
are Gnome and KDE (the two commonest ones), XFCE (very basic, but
lightweight. If you run up VNC the default desktop for it is XFCE) and
Unity (currently restricted to Ubuntu, introduced because they hate Gnome
3 but its reportedly disliked just as much).

Gnome 1,2,3 are just versions of Gnome - think Java 2,3,4,5 6,....

Which does Java use?

None, but Swing has a limited ability provide the same look and feel as
the native windows manager for the system the JVM is installed on as well
as Java's cross-platform Metal look & feel, e.g. G3 buttons and text
entry boxes have rounded corners, but Java doesn't and its default button
background gradient is different, as is the main menu bar though the
appearance is fairly close. The title bar and its drop-down menus are,
however, identical.

When you write a C program do you have to pick one? or do they share a
common core API?

No, they have different APIs. My distro uses Gnome by default but can
support KDE. Almost all the apps I use are Gnome apps, but I do use one
or two KDEapps. They run OK, but have a slightly different look & feel
and drag in a whole bunch of KDEsupport libraries - but a decent package
installer deals with that automatically. Package installers also differ:
RedHat distros such as Fedora and Redhat clones use yum, Ubuntu and the
other Debian clones use apt.

 

[Martin Gregorie]

In there anything you would want to tell programmers thinking of
developing Java on Fedora?
http://mindprod.com/jgloss/redhat.html is an entry a bit long in the
tooth.

It just works. Out of the box the RedHat distros (RHEL - RedHat
Enterprise Linux - and Fedora) use OpenJava, though you can easily switch
to Oracle/Sun Java by simply downloading and installing it and changing
the default search path ($PATH) so that compilers, etc are preferentially
loaded from there rather than from OpenJava.

 

[Stanimir Stamenkov]

Thu, 13 Oct 2011 22:27:29 +0200, /Robert Klemme/:

Not that I am aware of - unless you consider Gnome 2 mandatory for
Java development. I haven't worked with Gnome 3 yet and will
certainly install it in a VM before going life.

I've seen many replies complaining about Gnome 3, but I haven't seen
anyone mentioning Unity - how does it compare?

http://unity.ubuntu.com/

 

[Martin Gregorie]

Thu, 13 Oct 2011 22:27:29 +0200, /Robert Klemme/:

I've seen many replies complaining about Gnome 3, but I haven't seen
anyone mentioning Unity - how does it compare?

http://unity.ubuntu.com/

I've seen at least as many complaints about it as I've seen about G3.
Most of the complaints have been similar to those about G3: people don't
like its L&F and design, think its incomplete and/or rough round the
edges and was originally released before it was ready.

Hopefully somebody who has used it for more than a quick test will chip
in with their impressions vs. G2.

 

[Arved Sandstrom]

I've seen at least as many complaints about it as I've seen about G3.
Most of the complaints have been similar to those about G3: people don't
like its L&F and design, think its incomplete and/or rough round the
edges and was originally released before it was ready.

Hopefully somebody who has used it for more than a quick test will chip
in with their impressions vs. G2.

Hopefully that someone will _not_ do that, seeing as how Ubuntu 11.10
*just* came out, and purportedly addresses a number of problems that
folks had with the Unity interface in 11.04. A better assessment would
be from someone who got some serious time in with 11.04 (I know a few
such), and is now willing to use 11.10 for a few months and report back.

I have tended to use Ubuntu for my Linux work for a few years, and with
Ubuntu I wait about a half cycle (3 months) after each release to see if
I'll even bother to get it. In this case I saw the Unity reviews so
stuck with 10.10. Now I'll wait until early New Year and see if enough
folks like 11.10, and then switch up.

AHS

 

[Tom Anderson]

According to Gnome.org, there is no 3.3 except as a bugfix/development/
unstable version. The next major release will be 3.4 which seems to have
a roadmap full of builtins that IMO should be applications.

Right, well in that case, i certainly won't wait for 3.3!

tom

--

 

[Tom Anderson]

If G3 is as bad as people say, one of these might persist after
dominating over the other, unlike the case where the official
distribution is on a par qualtiy-wise with the forks.

It is possible, yes. However, at this point, i think a forked GNOME 2 is
effectively in a competition with XFCE. GNOME 2 is currently ahead in
terms of sophistication, but given the current sizes of the development
communities, it won't stay that way. It's possible that XFCE will not
develop to the same level of complexity as GNOME 2, and instead stay lean
and simple; however, that would be the first time in recorded software
history that this has happened.

I disagree.

Your disagreement, of course, is also irrelevant. I and thousands of other
users have voted with our package managers.

tom

 

[Tom Anderson]

Just a bit!

It just works.

That is just about true, but i think it's glossing over some facts worth
knowing.

I would identify the following points:

0. You should read:

http://fedoraproject.org/wiki/Java

Out of the box the RedHat distros (RHEL - RedHat Enterprise Linux - and
Fedora) use OpenJava,

1. The default Java is OpenJava. I *think* a standard install does not
include it, but it's easy enough to install. There is one package for the
JRE (ie the 'java' program and supporting cast), called
java-1.6.0-openjdk, and one for the rest of the JDK (ie the 'javac'
program and supporting cast), called java-1.6.0-openjdk-devel. The javadoc
is in a third package, java-1.6.0-openjdk-javadoc.

2. None of the above includes Derby, which is included in the Sun
releases. That's a package simply called derby.

though you can easily switch to Oracle/Sun Java by simply downloading
and installing it

5. This can be obtained in the usual place, and is an RPM file (there is
also a 'compressed binary' - ignore that).

There is an important aside here for those not familiar with package
management in Red Hat (or Linux generally). There are two distinct layers
to package management. The lower layer is RPM - RPM files and the 'rpm'
command, which is all about taking RPM files (which are bundles of files,
like a fancy ZIP file) and unpacking them into the filesystem. If you give
RPM a file for a package, it will do the unpacking, then remember that it
did it, so it can delete the package, replace it with a new version, etc.
The upper layer is YUM - repositories and the 'yum' command, which is all
about dependencies and downloads. If you give YUM a package name, it will
find and download the RPM for it, and also work out all the packages it
depends on, and find download RPMs for those too, if necessary. It will
then transactionally install all of them (or rather, ask RPM to do so). It
will also know to check for updates to these packages.

The upshot of this is that if you install something from an RPM, then all
you get is the installation. It is up to you to obtain the installer,
install dependencies, install updates when they are released, and so on.
Whereas if you install from YUM, the machine does all that for you. The
critical bit there is updates: if a new bugfix release of a package is
pushed out, an install from RPM does nothing at all, whereas an install
from YUM will upgrade to it as a matter of routine. (I feel so sorry for
users of operating systems where this is not the norm, such as Windows and
most of OS X; Unix users get this wonderful up-to-dateness as standard)

And so:

6. OpenJDK is a YUM install and the Sun JDK is an RPM install. So,
choosing Sun over OpenJDK means giving up painless automatic updates.

and changing the default search path ($PATH) so that compilers, etc are
preferentially loaded from there rather than from OpenJava.

Whilst you can do this:

7. The right way to manage multiple installations of Java is through the
standard 'alternatives' mechanism. See:

http://fedoraproject.org/wiki/Packaging:Alternatives
http://fedoraproject.org/wiki/Java#Java_Runtime_Environments_.28JRE.29
http://wiki.yyovkov.net/solutions:java:sunjavaonfedora

8. Being the 'default' Java means, amongst other things, that OpenJDK is a
dependency of any package which uses Java. Hence, even if you install the
Sun JDK, using YUM to install such a package will drag in OpenJDK - even
though it won't actually be used! It's possible this won't happen if you
have correctly used the alternatives mechanism, as above, but i can't
guarantee it.

Oh, and:

9. I don't think any standard installation process sets the JAVA_HOME
environment variable, so add an export for that to your .bashrc (and make
sure your .bash_profile sources your .bashrc - or do something different
if you prefer). This is not required, but i often come across bits of
software (like JBoss) which either assume or are greatly comforted by its
presence.

10. There are loads of Java libraries in the package repositories, all
just a few effortless keystrokes away. However! I'm not sure i really
recommend getting libraries this way. Although YUM makes getting libraries
easy, it doesn't help you distribute code written against the libraries -
unless your consumers are also running Fedora, you are going to have to
take care of packaging the dependencies yourself. If you instead use
something like Ivy to get your jars, you can somewhat reasonably just
distribute your ivy.xml file, or if not, use Ivy to build a zip-of-jars to
distribute.

11. There are quite a few Java applications in the package repositories,
and these don't have the distribution problem of the libraries. I
installed Ant, Ivy, and Groovy this way. I once installed IntelliJ IDEA
(community edition) this way (modulo some manual bodging of broken
dependencies). I once installed Eclipse this way, but that turned out to
be a terrible idea, because it couldn't update itself (or install plugins,
i think) without being run as root. Essentially, its own package
management fought with YUM. Bad.

(getting increasingly random ...)

12. If you use Eclipse and eGit, and do access control by client key, and
your key has a passphrase, and you generate or passphrase-protect this key
on your shiny new Fedora box, then you will hit a bug where eGit's
internal version of SSH cannot understand the key (it only understands
3DES-encrypted keys; the current OpenSSH uses AES). You need to set the
GIT_SSH environment variable to point to your ssh binary, ie to
/usr/bin/ssh, to override the internal version. This is not really a
Fedora-specific problem.

I'll stop now.

tom

 

[Tom Anderson]

I am a puzzled by the Unix folk having so many ways of handling the
GUI. I have heard of Gnome 1 2 3, KDE, X-Windows, Xfce, Unify

Unix folk have so many ways of handling everything! Count the numbers of
mail daemons, text editors, web servers, pagers, mail clients, package
managers ...

When you write a C program do you have to pick one? or do they share a
common core API?

Not on your nelly.

tom

 

[Martin Gregorie]

Right, well in that case, i certainly won't wait for 3.3!

Just so's you know.

 

[Tom Anderson]

Because we get a choice over the L&F. Everything uses X11, aka X-windows:
thats the underlying display technology for all graphical displays on
UNIX/Linux

OS X is a certified UNIX, and does not use X for its main window system. I
don't know much about Android, but i suspect it does not use X.

Less pedantically, mainstream Linux seems to be heading away from X too:

http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)

To do anything useful with X11 you use a window manager: all distros
pick one to use as default and each has its own style of handling the
desktop, decorating application windows, launching applications, etc.
etc. - hence the religious wars and differences of opinion over them.
The common ones are Gnome and KDE (the two commonest ones), XFCE (very
basic, but lightweight. If you run up VNC the default desktop for it is
XFCE) and Unity (currently restricted to Ubuntu, introduced because they
hate Gnome 3 but its reportedly disliked just as much).

None of those are window managers. They are desktop environments; they
*include* a window manager as a core component (GNOME 2's is Metacity),
but this can often be replaced (the popular upgrade on GNOME 2 is to
Compiz). They include other important things too, like the session
manager, panels, dock, etc.

I'll also add LXDE, which an even more lightweight desktop environment for
people who think XFCE is bloated.

None, but Swing has a limited ability provide the same look and feel as
the native windows manager for the system the JVM is installed on

Again, it's not the window manager it's imitating, it's the widget
toolkit. A widget toolkit knows how to draw buttons and scrollbars and so
on, and is one of the building blocks of a desktop environment (although i
think not a window manager proper?). KDE uses the Qt toolkit; all other
significant desktop environments use GTK.

A surprising thing for newcomers to Linux is that applications written
using one widget toolkit will happily work on a desktop using another one
(eg a Qt app on GNOME, which uses GTK). This is because the widget
toolkits talk directly to the X server. The only thing is that the app's
widgets will look inconsistent with the rest of the desktop.

as well as Java's cross-platform Metal look & feel, e.g. G3 buttons and
text entry boxes have rounded corners, but Java doesn't and its default
button background gradient is different, as is the main menu bar though
the appearance is fairly close. The title bar and its drop-down menus
are, however, identical.

GNOME 3 uses GTK as a widget toolkit, and styles it with a special theme.
Java imitates GTK with a standard theme (i assume), hence the difference.

AWT must use a widget toolkit directly. In the Fedora release, this
appears to be GTK.

If you're into SWT, that uses GTK directly.

How does Eclipse (as a representative SWT app) look under GNOME 3?

tom

 

[Martin Gregorie]

Just a bit!


That is just about true, but i think it's glossing over some facts worth
knowing.

Sure. Short Answer!

1. The default Java is OpenJava. I *think* a standard install does not
include it,

That's most likely true, but I haven't manged to do an install that
didn't include it because there at least package I've needed has it as a
dependency - and remember at package selection time (I don't delay this
until post-install) there's as yet no way to pull in Sun/Oracle Java.

2. None of the above includes Derby, which is included in the Sun
releases. That's a package simply called derby.

True. Due to a PostgreSQL fixation I keep meaning to use it but haven't
yet.
However, by that time OpenJava is already installed. So far I haven't
been brave enough to uninstall it after I've installed the Sun/Oracle JDK.
Have you tried this?

The upshot of this is that if you install something from an RPM, then
all you get is the installation. It is up to you to obtain the
installer, install dependencies, install updates when they are released,
and so on. Whereas if you install from YUM, the machine does all that
for you.

Not entirely true because you can add repositories to the Yum
configuration: I normally add rpmfusion and atrpms and current releases
of GoogleMaps add their repository as well.

whereas
an install from YUM will upgrade to it as a matter of routine. (I feel
so sorry for users of operating systems where this is not the norm, such
as Windows and most of OS X; Unix users get this wonderful
up-to-dateness as standard)

Agreed. That is why I add atrpms and rpmfusion, but beware: there can be
odd dependency clashes between repositories: there are currently stopping
me from installing vlc and avidemux: eventually I'll crack and compile
these from source.

6. OpenJDK is a YUM install and the Sun JDK is an RPM install. So,
choosing Sun over OpenJDK means giving up painless automatic updates.

If you pull in an RPM install/update directly (as I regularly do for both
Java and Opera, the next yum update will complain that something changed
the RPM database without telling it. This can be safely ignored if you
know you did this.

7. The right way to manage multiple installations of Java is through the
standard 'alternatives' mechanism. See:

I use this for swapping from sendmail to Postfix, both both are Fedora
packages: not doing so causes arse-ache. However, merely changing $PATH
by dropping java.sh (my custom script: contains pathmunge commands) into
/etc/profile.d/ is easy and works equally well.

FWIW the predefined alternatives in F15 are only OpenJava and gcj
(compile to native using the gcc Java-->C preprocessor)

8. Being the 'default' Java means, amongst other things, that OpenJDK is

a dependency of any package which uses Java. Hence, even if you install
the Sun JDK, using YUM to install such a package will drag in OpenJDK -
even though it won't actually be used! It's possible this won't happen
if you have correctly used the alternatives mechanism, as above, but i
can't guarantee it.
Quite.

9. I don't think any standard installation process sets the JAVA_HOME
environment variable, so add an export for that to your .bashrc (and
make sure your .bash_profile sources your .bashrc - or do something
different if you prefer). This is not required, but i often come across
bits of software (like JBoss) which either assume or are greatly
comforted by its presence.
True.

10. There are loads of Java libraries in the package repositories, all
just a few effortless keystrokes away. However! I'm not sure i really
recommend getting libraries this way. Although YUM makes getting
libraries easy, it doesn't help you distribute code written against the
libraries - unless your consumers are also running Fedora, you are going
to have to take care of packaging the dependencies yourself. If you
instead use something like Ivy to get your jars, you can somewhat
reasonably just distribute your ivy.xml file, or if not, use Ivy to
build a zip-of-jars to distribute.

Quite. I use a few of them, configured in manually.

I agree with your other points, but haven't added anything: I manually
installed ant and don't use any IDEs.

 

[B1ll Gat3s]

Your disagreement, of course, is also irrelevant.

Classic unsubstantiated and erroneous claim.

 

[Lew]

Classic unsubstantiated and erroneous claim.

Plonk.

 

[B1ll Gat3s]

The upshot of this is that if you install something from an RPM, then
all you get is the installation. It is up to you to obtain the
installer, install dependencies, install updates when they are released,
and so on. Whereas if you install from YUM, the machine does all that
for you. The critical bit there is updates: if a new bugfix release of a
package is pushed out, an install from RPM does nothing at all, whereas
an install from YUM will upgrade to it as a matter of routine. (I feel
so sorry for users of operating systems where this is not the norm, such
as Windows and most of OS X; Unix users get this wonderful
up-to-dateness as standard)

The flip side of this, of course, is that Unix users can also wake up
one morning to fresh new bugs that have just spontaneously materialized
in software that had been working perfectly for them yesterday.

 

[B1ll Gat3s]

Plonk.

Famous Last Word.

 

[Arne Vajhøj]

True. Due to a PostgreSQL fixation I keep meaning to use it but haven't
yet.

I don't think Derby and PostgreSQL are alternatives.

You could use Derby for your development incl. unit test
because it is practically no install/config and PostgreSQL
for your QA and production for the reliability and
performance.

Arne

 

[Arne Vajhøj]

OS X is a certified UNIX, and does not use X for its main window system.
I don't know much about Android, but i suspect it does not use X.

Less pedantically, mainstream Linux seems to be heading away from X too:

http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)

We will see.

I am a bit skeptical about that happen.

Arne