Ubunto

[Arne Vajhøj]

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)

Updating is not the issue.

Testing that updates will not break anything is the issue.

Arne

 

[Tom Anderson]

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.

I'd almost say it was the other way round. PostgreSQL is pretty easy to
install - as root (paraphrasing what i actually just did):

yum install postgresql-server # will prompt to confirm
sudo -u postgres initdb
# possibly edit pg_hba.conf
service postgresql start
sudo -u postgres createuser -P -S developer # will prompt for a password
sudo -u postgres createdb -O developer development

pg_hba.conf is the file which defines access methods, and access control.
With every package i have ever installed, it is created in a state which
allows the normal console user to get access to the database. However, the
details vary: IIRC, on OS X (with MacPorts), it is set up to use peer
authentication for unix domain sockets (which is secure), and MD5 password
authentication for TCP/IP sockets (which is fairly secure). However, a
default install on Fedora 15 has no authentication on either kind of
socket; that said, TCP/IP sockets are only opened on the loopback
interface, so this is not that bad. An old installation on Fedora came
with only unix domain sockets by default, and no TCP/IP. So, that file may
need some tweaking.

So, not nearly as easy as installing Derby (which with a Sun JDK involves
precisely zero steps), but not at all difficult. Suitable for a
development machine.

Whereas i think the great strength of Derby is in production - if and only
if you are distributing code to run on desktop machines. There, the less
you need to install, the better, and the fact that Derby comes in the JDK
makes it a bit of a slam-dunk. It's not a particularly great database, but
you can't argue with the ease of installation.

tom

 

[Tom Anderson]

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?

I haven't. We used to run CentOS 5 systems with only Sun JDK and no
OpenJDK, but i think that was because there was no OpenJDK at the time.

tom

 

[Martin Gregorie]

We will see.

I am a bit skeptical about that happen.

The lack of network transparency in Wayland would be a major showstopper
for me: my preferred way of working and of organising data and tasks
across a network more or less depends on this feature of X11.

That said, I'm uncertain how unusual this way of working appears to
others.

 

[Martin Gregorie]

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.

Of course, but with PostgreSQL installed and running, the effort needed
to add a new project/database/call it what you will is probably the same
as it would be with Derby - and I don't need to learn another database's
SQL syntax quirks to do it.


I've nothing against Derby: its on my list of things to get up to speed
with, but hasn't yet got to the head of the list.

 

[Martin Gregorie]

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.

That's only true if you leave automatic updating enabled: I don't.

By turning it off I can easily do a fast backup with rsync immediately
before running yum, thus creating the possibility of a fairly easy backout
should it be needed. So far, after 8+ years of using Fedora that hasn't
been necessary.

 

[blmblm]

The lack of network transparency in Wayland would be a major showstopper
for me: my preferred way of working and of organising data and tasks
across a network more or less depends on this feature of X11.

That said, I'm uncertain how unusual this way of working appears to
others.

Seems perfectly normal to me to have graphical applications running
on machine A and displaying output on machine B, and I also(?) am
not eager to replace X11 with something that didn't have this
"works across a network" functionality. But I've noticed that
my ideas about a lot of computing-related things seem well out
of the current mainstream, so -- a data point, but perhaps not
a very representative one.

 

[Lew]

Seems perfectly normal to me to have graphical applications running
on machine A and displaying output on machine B, and I also(?) am
not eager to replace X11 with something that didn't have this
"works across a network" functionality. But I've noticed that
my ideas about a lot of computing-related things seem well out
of the current mainstream, so -- a data point, but perhaps not
a very representative one.

Such use of X11 across a network, in particular across SSH, is common and widespread.

 

[Robert Klemme]

Such use of X11 across a network, in particular across SSH, is common and widespread.

I have always found X11 across a network to be extremely slow and hence
don't use it. IMHO RDP is significantly more efficient especially for
remote connections, VNC's protocol could be as well.

For my daily work I use putty combined with screen sessions on the
remote machines (mostly Solaris). That is quite fast and also
comfortable. And if your ssh connection breaks down for any reason
(network issue, logout, reboot) your shells and other processes are
still there.

Funnily enough in our company the de facto standard is to use NX with X
sessions - even though there seem to be issues when disconnecting and
reconnecting. And people do not use graphical applications anyway -
mostly just shells.

Kind regards

robert

 

[blmblm]

I have always found X11 across a network to be extremely slow and hence
don't use it. IMHO RDP is significantly more efficient especially for
remote connections, VNC's protocol could be as well.

There is that (the performance issue). My experience has been that
over a fast local network, it's good enough for most applications,
though I seem to remember that there are exceptions (though not what
they are). Over a not-so-fast network, yeah, it can be too slow to
be usable.

For my daily work I use putty combined with screen sessions on the
remote machines (mostly Solaris). That is quite fast and also
comfortable. And if your ssh connection breaks down for any reason
(network issue, logout, reboot) your shells and other processes are
still there.

Funnily enough in our company the de facto standard is to use NX with X
sessions - even though there seem to be issues when disconnecting and
reconnecting. And people do not use graphical applications anyway -
mostly just shells.

Strongly agreed about the value of "screen" -- I've even been known
to use it locally, for its cut-and-paste features.

Nice to know that there are at least a few other shell fans out there?

 

[Robert Klemme]

There is that (the performance issue). My experience has been that
over a fast local network, it's good enough for most applications,
though I seem to remember that there are exceptions (though not what
they are). Over a not-so-fast network, yeah, it can be too slow to
be usable.

I think the last I tried remotely via X was Firefox. It was awful even
though it was a LAN IIRC.

Strongly agreed about the value of "screen" -- I've even been known
to use it locally, for its cut-and-paste features.

Nice to know that there are at least a few other shell fans out there?

Count me in.

Cheers

robert

 

[Martin Gregorie]

There is that (the performance issue). My experience has been that over
a fast local network, it's good enough for most applications, though I
seem to remember that there are exceptions (though not what they are).
Over a not-so-fast network, yeah, it can be too slow to be usable.

Same here - which is what I was speaking about.

Strongly agreed about the value of "screen" -- I've even been known to
use it locally, for its cut-and-paste features.

I've never gotten around to using screen, though I do normally use the
microEmaxs editor everywhere - its multi-screen abilities combined with
shelling out over the top of it do almost everything I need.

Everything else is easily met with a few more ssh sessions in Gnome
terminal windows, since its not a lot harder to cut 'n paste between
those than it is within a multi-windowed terminal application.

Nice to know that there are at least a few other shell fans out there?

Most of my programming activity is command-line oriented regardless of
whether I'm driving a local or remote system, which I do with ssh and X11
forwarding: use of the latter boils down to developing Swing programs
with much lower use of it to run remote copies of GIMP, LibreOffice progs,
and firing up Opera remotely if I want to proof read Javadocs.

 

[blmblm]

I think the last I tried remotely via X was Firefox. It was awful even
though it was a LAN IIRC.

Hm! It almost surely depends on the speed of the network; for me
Firefox over a local network works reasonably well. Well, except
that X doesn't seem to have a way to forward sound. Often that's
not a problem, but sometimes it is. I wonder if there's some way
around that .... well, probably not a question for this group.

[ snip ]

 

[blmblm]

Same here - which is what I was speaking about.

I've never gotten around to using screen, though I do normally use the
microEmaxs editor everywhere - its multi-screen abilities combined with
shelling out over the top of it do almost everything I need.

For me the other benefit of "screen" is the one previously mentioned
by the person who first mentioned this tool -- it sets up something
that persists even if the network connection is broken, deliberately
or not. For me examples of both kinds of breakage do arise -- it's
useful to be able to set something up under "screen" at work, detach
the screen session, and reattach it later from home, or vice version,
and it's also useful to be able to set up something that will persist
even if the ssh session under which it was started times out.

Everything else is easily met with a few more ssh sessions in Gnome
terminal windows, since its not a lot harder to cut 'n paste between
those than it is within a multi-windowed terminal application.

Most of my programming activity is command-line oriented regardless of
whether I'm driving a local or remote system, which I do with ssh and X11
forwarding: use of the latter boils down to developing Swing programs
with much lower use of it to run remote copies of GIMP, LibreOffice progs,
and firing up Opera remotely if I want to proof read Javadocs.

Once upon a time you could proofread javadocs with a frames-capable
text-mode browser (such as elinks). Not so much with Java 7,
alas .... Maybe a rant for another thread, but at least a return
from topic drift?

 

[Martin Gregorie]

For me the other benefit of "screen" is the one previously mentioned by
the person who first mentioned this tool -- it sets up something that
persists even if the network connection is broken, deliberately or not.
For me examples of both kinds of breakage do arise -- it's useful to be
able to set something up under "screen" at work, detach the screen
session, and reattach it later from home, or vice version,
and it's also useful to be able to set up something that will persist
even if the ssh session under which it was started times out.


Once upon a time you could proofread javadocs with a frames-capable
text-mode browser (such as elinks). Not so much with Java 7,
alas .... Maybe a rant for another thread, but at least a return from
topic drift?

Have you any idea why?

I prefer just tried lynx, which I prefer to elinks, on a Java 6 javadocs
set. It did a reasonable job despite insisting on the non-frames set of
pages. Apart from that, the worst you can say about it is that its
formatting of method parameters with long fully qualified types is
somewhat untidy.

 

[blmblm]

For the record --

s/vice version/vice versa/

(pointed out via e-mail by an alert fellow poster)

*No* idea how that one happened!

[ snip ]

 

[blmblm]

[ snip ]

Have you any idea why?

Why what? Why "not so much"? because that may be a bit of an
exaggeration -- but the HTML produced by the Java 7 "javadoc" tool
has a fairly different look from what was produced by previous
versions, and it explicitly complains if you use a browser that
doesn't support Javascript, and .... :

I prefer just tried lynx, which I prefer to elinks, on a Java 6 javadocs
set. It did a reasonable job despite insisting on the non-frames set of
pages. Apart from that, the worst you can say about it is that its
formatting of method parameters with long fully qualified types is
somewhat untidy.

Generally I also prefer lynx, but it doesn't support frames, and
elinks does, and to me that makes a difference for this use case.

Anyway, try either one on on a Java 7 javadocs set -- both still
display the content, but IMO the formatting is noticeably less
satisfactory than for Java 6,

 

[David Lamb]

For the record --

s/vice version/vice versa/

(pointed out via e-mail by an alert fellow poster)

*No* idea how that one happened!

An auto-correct you didn't notice?

 

[David Lamb]

[ snip ]

Have you any idea why?

Why what? Why "not so much"? because that may be a bit of an
exaggeration -- but the HTML produced by the Java 7 "javadoc" tool
has a fairly different look from what was produced by previous
versions, and it explicitly complains if you use a browser that
doesn't support Javascript, and .... :

Eeek. I use NoScript and try to keep my set of "allowed" sites minimal;
I suppose should be able to trust the Oracle website (or mine, if I
make a local copy for some reason) but it still seems to me like a bad
design decision.

 

[Tom Anderson]

The lack of network transparency in Wayland would be a major showstopper
for me: my preferred way of working and of organising data and tasks
across a network more or less depends on this feature of X11.

Stealing links from wikipedia, there is a chance it may become remotable:

http://lists.freedesktop.org/archives/wayland-devel/2010-November/000097.html
http://lists.fedoraproject.org/pipermail/devel/2010-November/145306.html

I avoid the term "network transparent", because that term is palpable
nonsense. I have a couple of years of day-in, day-out experience of X (in
fact, NX) being significantly less than transparent over a network.

That said, I'm uncertain how unusual this way of working appears to
others.

The specific X way of working (program on one machine, window system
entirely elsewhere) is probably fairly niche these days. But the
VNC/RDP/NX way of working, where the remote program thinks it is talking
to a local window system, which is actually a stub which is sending its
updates across the network, is very common.

There is a thing called SPICE:

http://spice-space.org/

Which is basically a remote windowing protocol that plugs into a virtual
machine (as long as it's QEMU), rather than into a window server; that is,
it's sort of a virtual VGA cable, of which nothing above the level of the
VM itself (so not even the guest OS - although maybe it needs special
drivers?) is aware. You could presumably run a Wayland server on that, and
have apps talk to Wayland talk to the VM talk to a SPICE client over the
network. I have no idea if that would be a good thing or not.

tom