Ubunto

[Tom Anderson]

An auto-correct you didn't notice?

Nah, that's just the typical sort of error you get when using screen.

tom

 

[Eight of Seventeen]

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

Wow, you people just love to create problems with the clipboard, don't
you?

Whereas with a remote app and a local window system you can copy from
the remote app and paste into a local one, or a remote one that isn't
on the same remote machine as the first remote one, with a "virtual
VGA cable" obviously the copy and paste will take place on the machine
with the first remote app -- you won't be able to copy from it and
paste into a local app, or a differently-remote one.

 

[Dancing Fingers]

I've run Eclipse, the JAVA development platform, in Debian for several
years when I finally moved to Kubuntu. Eclipse runs ok but it can
freeze up your X system and you have to kill it from an terminal
session. Eclipse also tends to crash when you're doing a lot in the
editor in Kubuntu - very annoying. Finally, the double-click option
has never worked in Linux as it does in Windows. I still use it every
day but I'm using Eclipse more and more on my Windows box. I do tend
to use the latest Eclipse with the standard JAVA install so that might
be part of it.

That's my 2 cents.

Chris

 

[blmblm]

An auto-correct you didn't notice?

Heavens, no! I'm not sure vim (which of course is what I use to
compose posts ) even *has* a notion of auto-correction, and if
it did I doubt I'd enable it. Automatic detection of (supposed)
spelling errors is one thing, and useful in its way, but automatic
"correction" .... No thanks. I suppose this is a YMMV thing, because
I do know at least one smart and capable person who apparently thinks
auto-correction is just swell, but to me it just seems too likely to
produce nonsense results.

 

[blmblm]

Nah, that's just the typical sort of error you get when using screen.

A joke that whooshed over my head?

 

[Tom Anderson]

A joke that whooshed over my head?

Oh, there was something elsethread about "crud like foo^]]E^]]D^Hquux"
which i thought might have explained the error.

tom

 

[blmblm]

A joke that whooshed over my head?

Oh, there was something elsethread about "crud like foo^]]E^]]D^Hquux"
which i thought might have explained the error.

(I think this time I'll let someone else attempt to convince the
person who posted that comment about "screen" of the error of
his/her/its ways.)

 

[Eight of Seventeen]

(I think this time I'll let someone else attempt to convince the
person who posted that comment about "screen" of the [insult deleted]
of his/her/[implied insult deleted] ways.)

No. None of the nasty things that you have said or implied about me
are at all true.

 

[Arne Vajhøj]

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 .... :


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,

I am not anti-JS in any way.

But I must admit that I think the old Java doc format was better
than the new one.

The old one was simply more readable.

Arne

 

[Arne Vajhøj]

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.

But that is because you have have PostgreSQL installed and running.

Arne

 

[Arne Vajhøj]

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

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.

Something > nothing.

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.

An embedded database like Derby is great for desktop apps.

But I would not use it for a major Java EE app.

And I must admit that I am thinking mostly Java EE when
talking about production.

Arne

 

[Martin Gregorie]

But that is because you have have PostgreSQL installed and running.

True, but IIRC the initial install of PostgreSQL was pretty much a no-
brainer too.

The only non-straightforwardness I remember was due to me modifying the
installation to move the physical database from the /var tree to /home
for system management reasons. I've arranged my system so that /home is
in a separate partition and that /usr/local and /usr/java as well as all
PostgreSQL and Apache related user data are there as well. This means
that, for a clean Linux install I can reformat everything on disk except
the /home partition and know that nothing I care about will need to be
restored.

 

[Lew]

True, but IIRC the initial install of PostgreSQL was pretty much a no-
brainer too.

The only non-straightforwardness I remember was due to me modifying the
installation to move the physical database from the /var tree to /home
for system management reasons. I've arranged my system so that /home is
in a separate partition and that /usr/local and /usr/java as well as all
PostgreSQL and Apache related user data are there as well. This means
that, for a clean Linux install I can reformat everything on disk except
the /home partition and know that nothing I care about will need to be
restored.

For development purposes, the default installation of Postgres works prettywell. For production purposes, as with any DBMS, the situation can be more complicated.

There are many goals you want a DBMS to achieve. Most people seem to talk about speed or ease of use as if reliability were taken for granted. First and foremost, the prime directive of any data store is to be reliable. Ancillary to that the management protocols for the system should not impede keeping a system reliable. (The violation of this was my main complaint withMySQL. I don't know if they fixed it.) We do want the system to be of low footprint appropriate to the application domain. Fast enough for the project usage. Scalable likewise.

Postgres and Derby both tend to win in another important area - standardness of the SQL dialect.

Postgres reaches down pretty far into the low end of scale, but obviously not quite as far as Derby. Conversely, Derby does quite well into higher scale, but obviously not quite as far as Postgres.

If you're doing a lot of enterprise or web work you should consider Postgres strong contender. Even during development, it mixes well with the enterprise way of looking at things (layered and componentized). Porting a system from Postgres to, say, Oracle or DB2 turns out to be not so bad. Of course no two RDBMSes speak the same dialect of SQL, but the transformations between the big guns seem to be mostly mechanical - Oracle uses VARCHAR2 forVARCHAR, for example. It's harder when a system decides to reinvent the semantics of a keyword to something rather different, as MySQL did with TIMESTAMP.

That's just one scenario where one might find advantage to Postgres. Of course, the same arguments apply to the free versions of Oracle and DB2, to apoint.

For desktop distribution Derby may well be the ideal solution. For a desktop app needing more than desktop-scale data, perhaps a distributed DBMS architecture - keep the local DB as a sort of edge cache for wide-area data.

I put forward this pie in the sky to point out that different systems fill different niches. I observe that between them, Derby and PostgreSQL cover the gamut of RDBMS needs and could even complement each other. Solid products, open source, span the use case range: no need for me to hunt further. (This does not preclude reaching for non-RDBMS solutions.)

 

[Martin Gregorie]

For development purposes, the default installation of Postgres works
pretty well. For production purposes, as with any DBMS, the situation
can be more complicated.

PostgreSQL itself can be shifted about fairly easily: the inflexibility
was in the SYSVinit daemon management script it uses which, at least on
RedHat Fedora systems up to the F12 release, could only be reconfigured
by editing the script because it ignored the convention of stashing
configurable values in /etc/sysconfig. They fixed this for F13 - just in
time to change things again when F15 introduced the systemd service
management system.

Postgres and Derby both tend to win in another important area -
standardness of the SQL dialect.

Agreed. Does anything apart from MySQL insist on using auto-incrementing
variables where the rest of the DB world mostly uses sequences? I don't
really see the point given that you almost always want to know the value
that was assigned (particularly if the field is in a prime key) and this
forces you to read a row immediately after it was inserted.

If you're doing a lot of enterprise or web work you should consider
Postgres strong contender. Even during development, it mixes well with
the enterprise way of looking at things (layered and componentized).

I'm still very impressed with it, not least for the way it keeps its
filing system tidy and the DB stats updated with next to no management
effort apart from making backups and the periodic need to restore from
the backup after a major version upgrade.

Porting a system from Postgres to, say, Oracle or DB2 turns out to be
not so bad. Of course no two RDBMSes speak the same dialect of SQL, but
the transformations between the big guns seem to be mostly mechanical -
Oracle uses VARCHAR2 for VARCHAR, for example. It's harder when a
system decides to reinvent the semantics of a keyword to something
rather different, as MySQL did with TIMESTAMP.

The only major Postgres anomaly, that I've noticed anyway, is its use of
a BYTEA where other DBMS would use a CLOB.

For desktop distribution Derby may well be the ideal solution. For a
desktop app needing more than desktop-scale data, perhaps a distributed
DBMS architecture - keep the local DB as a sort of edge cache for
wide-area data.

Derby is very much on my radar: I just haven't yet found a round tuit or
a good reason to use Derby in place of PostgreSQL.

Have you tried using it as a small central DBMS, i.e. not run as an
integral part of an application? If so, are there any obvious gotchas or
performance issues with running it that way?

 

[markspace]

Derby is very much on my radar: I just haven't yet found a round tuit or
a good reason to use Derby in place of PostgreSQL.

I've considered using it for unit testing. I need to get cracking on
that particular personal project, actually, but I'm just tossing the
idea out there that DB doesn't have to mean production system.