Alas it's not FUD, just ignorance and gross stupidity. I'm afraid there will always be assholes, and the judiciary is no exception.
If I were a professor working on colormap pattern scanning to help the police categorize and identify kiddie porn so they could get a conviction, I certainly wouldn't be picking somewhere like Virginia to do the work.
Their loss.
///Peter
Re:Wow. Science fiction writers would be happy.
on
Pushing The Envelope
·
· Score: 1
As their Java/TomCat server seems to have lost its little brain, I can't see anything from their site. Not a good advertisement for their technology.
///Peter
--
"The sure-fire cure for seasickness is to sit under a tree." --Spike Milligan
Re:great program, but it isn't keeping up
on
Gimp 1.2.0 Released
·
· Score: 1
I don't mind the technology level -- my needs are modest -- but the crapulous interface restrictions still place the Gimp well behind Win* equivalents like Paintshop Pro, alas. Take a simple screenshot and try to save it as a GIF -- you can't, GIF is grayed out of the filetype selection dropdown. I'm sure there is some arcane reason connected with layers or channels, but the principle that software should not stand in the user's way seems to have been forgotten here.
The user interface paradigm is the one remaining problem with what is otherwise an excellent program, but it's a big problem, and remains unaddressed by the authors for reasons I have never seen explained. To be told, when trying to do something simple like save the file as.eps, that it can't do it because the output format doesn't support some feature of internal representation is merely ludicrous: if I want it saved as PostScript, I want it saved as PostScript, please, and I want the software to immediately undertake whatever flattening or conversion is necessary to perform this simple task. Every other graphics editor does this without being told...why not the Gimp?
I agree completely that XML is the right standard to use -- in fact it is the ONLY one which is not bound to any vendor or particular piece of software -- but I find it mildly puzzling that the
original poster does not appear to be aware of it.
DocBook is excellent for writing system documentation, but without doing a document analysis it is not possible to say if it is the right tool for this task.
HTML is NOT an option except as an output format generated from (eg) DocBook to allow the docs to be viewed on the Web. Ditto LaTeX, for use in generating PDF or PS. Neither makes a good document repository format and should never be considered for such.
Actually I'm not convinced. There were systems in
the UK in the late 60s (I think part of the EPSS)
which could send messages between users of different machines. I saw one demonstrated in
1969 and while my memory may be fuzzy (I was in
high school then) it was clear that the message
traveled between two machines.
So I realised a few mins after posting.
Would it be too much bother to them to make
the crash manager reattach itself to the
calling tty. Jeez kids, we were doing this
kind of stuff in the 70s. But maybe Linux
won't let you (I left this OS stuff behind
many moons ago).
OK, so run it in the foreground. Mother still dumps core. Moz is a waste of time at this stage,
wipe it.
The point about an SGML document is that a user MUST have the DTD in order to use the document, so it is impossible to keep it secret.
Under certain circumstances you can use a DTD to create an XML document, and then send someone the document without the DTD, because XML may still work without it.
XML doc control is different from open-source
programming in that a DTD is not a program, it's more like a config file, and there is no point in keeping it secret.
If your DTD is a useful tool, it makes sense to allow others to use it; if it's really useful it may even become a de facto standard.
But there are so many useful DTDs out there already that creating your own should only be done after a document analysis has demonstrated that none of the existing ones will fit the bill.
SGML has some 30-40 extra options that we left out when designing XML, to make it easier to program for. Writing XMl software is not hard; writing SGML software is much harder because you have to cope with all the options. There are lots of big differences in the tagging of SGML once you start using all the options for abbreviation (minimization).
Linuxdoc uses SGML because they started before XML was invented. They did their stuff a bit off on a tangent without getting any help from people who already knew SGML, so a lot of it was very flaky for a long time. Now it's stable, but there's a huge legacy of SGML. But DocBook-X is ready to use.
Toolchain is easy: XML--XSLT--LaTeX--PDF using JadeTeX, or XML--Omnimark--LaTeX--PDF.
Emacs has an excellent xml mode built into the standard psgml-mode for SGML (does both). There's also a DTD mode for writing DTDs and an XSL IDE mode for doing XSL.
Buzzword compliance is important when you have top deal with management. But XML requires less resources than SGML because it's simpler to program for. But structured doc and info needs careful planning no matter what s/w you use.///Peter
--
And yet, if your employers want you to start
writing XML apps eventually, you'll refer to
the W3C spec.
If your employer hasn't started to think about
the future of hir online business yet, start
looking for a new job (oh, and boning up on
the latest specs:-)
But the US is still the laughing-stock of the
rest of the world wrt software patents, with
the Patent Office still granting patents on
patently unpatentable concepts. How much longer
before someone patents the concept of a word?
I shall clearly have to buy the book. The Gimp
has probably the crassest and most ridiculous
set of interface restrictions I have seen since
VMSmail.
It goes out of its way to make it hard
to use, barring you from doing the simplest and most obvious things like saving a file in another format (on spurious grounds like the use of layers: so flatten the file, dodo!).
It runs counter to everything we stand for in the UNIX
world, which is to enable things, not disable them.
It is a locus classicus of Knuth's criticism of dwelling on borderline cases and special parameters, providing some excellently-written and robust routines for doing stuff you want once in a lifetime and failing miserably to provide the simplest and most obvious requirements like easy cut and paste of image portions.
Sadly, even the leading light in the other camp, PaintShop Pro, is going this way: the latest version is even less
intuitive than the previous one.
In their scramble to provide the latest and flashiest filters and the most sophisticated image-munging around (and let's not forget the Gimp is very sophisticated, as well as being extremely reliable), too many graphics programs are neglecting the basics we all need for everyday trimming and tidying up.
Doubtless I shall change my mind once the book has explained everything to me. It's just a pity it needs a book, rather than using the interface, Luke.
I don't know if the labour shortage is everywhere
but I'm being headhunted from Europe to the US
because companies can't find people my age (47)
and experience (20 years online) in the USA. I'm
not aware of being an indentured servant...yet.
>And the Courier font's "1" has been different from the "l" for
decades!
Not in the UK, where the digit 1 was originally pilfered
to make space for the pounds sterling sign,
because, of course, it wouldn't matter using
a lowercase ell for a digit, now, would it...
Slashdot Mirror
http://listserv.heanet.ie/cgi-bin/wa?A2=ind9410&L= html-wg&P=R5759
///Peter
If I were a professor working on colormap pattern scanning to help the police categorize and identify kiddie porn so they could get a conviction, I certainly wouldn't be picking somewhere like Virginia to do the work.
Their loss.
///Peter
///Peter
-- "The sure-fire cure for seasickness is to sit under a tree." --Spike Milligan
The user interface paradigm is the one remaining problem with what is otherwise an excellent program, but it's a big problem, and remains unaddressed by the authors for reasons I have never seen explained. To be told, when trying to do something simple like save the file as .eps, that it can't do it because the output format doesn't support some feature of internal representation is merely ludicrous: if I want it saved as PostScript, I want it saved as PostScript, please, and I want the software to immediately undertake whatever flattening or conversion is necessary to perform this simple task. Every other graphics editor does this without being told...why not the Gimp?
I agree completely that XML is the right standard to use -- in fact it is the ONLY one which is not bound to any vendor or particular piece of software -- but I find it mildly puzzling that the original poster does not appear to be aware of it.
DocBook is excellent for writing system documentation, but without doing a document analysis it is not possible to say if it is the right tool for this task.
HTML is NOT an option except as an output format generated from (eg) DocBook to allow the docs to be viewed on the Web. Ditto LaTeX, for use in generating PDF or PS. Neither makes a good document repository format and should never be considered for such.
Peter Flynn
Editor, XML FAQ
Actually I'm not convinced. There were systems in the UK in the late 60s (I think part of the EPSS) which could send messages between users of different machines. I saw one demonstrated in 1969 and while my memory may be fuzzy (I was in high school then) it was clear that the message traveled between two machines.
OK, so run it in the foreground. Mother still dumps core. Moz is a waste of time at this stage, wipe it.
This is balls, I'm afraid. Moz dumps core the moment you run it (virgin RH 6.2 with no funnies). What's more, it won't even debug...
$ /usr/local/mozilla/mozilla & /usr/local/mozilla/run-mozilla.sh /usr/local/mozilla/mozilla-bin
a /components
/usr/local/mozilla/mozilla-bin just dumped a core file.
/usr/local/mozilla/mozilla
[3] 2308
$
MOZILLA_FIVE_HOME=/usr/local/mozilla
LD_LIBRARY_PATH=/usr/local/mozilla
LIBRARY_PATH=/usr/local/mozilla:/usr/local/mozill
SHLIB_PATH=/usr/local/mozilla
LIBPATH=/usr/local/mozilla
ADDON_PATH=/usr/local/mozilla
MOZ_PROGRAM=/usr/local/mozilla/mozilla-bin
MOZ_TOOLKIT=
moz_debug=0
moz_debugger=
Oh no!
Do you want to debug this ? You need a lot of memory for this, so watch out ? [y/n] y
bash: y: command not found
[3]+ Stopped (tty input)
$
NS6 may be fulla bugs but at least it executes.
///Peter
Under certain circumstances you can use a DTD to create an XML document, and then send someone the document without the DTD, because XML may still work without it.
XML doc control is different from open-source programming in that a DTD is not a program, it's more like a config file, and there is no point in keeping it secret.
If your DTD is a useful tool, it makes sense to allow others to use it; if it's really useful it may even become a de facto standard.
But there are so many useful DTDs out there already that creating your own should only be done after a document analysis has demonstrated that none of the existing ones will fit the bill.
///Peter
--
SGML has some 30-40 extra options that we left out when designing XML, to make it easier to program for. Writing XMl software is not hard; writing SGML software is much harder because you have to cope with all the options. There are lots of big differences in the tagging of SGML once you start using all the options for abbreviation (minimization). Linuxdoc uses SGML because they started before XML was invented. They did their stuff a bit off on a tangent without getting any help from people who already knew SGML, so a lot of it was very flaky for a long time. Now it's stable, but there's a huge legacy of SGML. But DocBook-X is ready to use. Toolchain is easy: XML--XSLT--LaTeX--PDF using JadeTeX, or XML--Omnimark--LaTeX--PDF. Emacs has an excellent xml mode built into the standard psgml-mode for SGML (does both). There's also a DTD mode for writing DTDs and an XSL IDE mode for doing XSL. Buzzword compliance is important when you have top deal with management. But XML requires less resources than SGML because it's simpler to program for. But structured doc and info needs careful planning no matter what s/w you use. ///Peter
--
And yet, if your employers want you to start writing XML apps eventually, you'll refer to the W3C spec. If your employer hasn't started to think about the future of hir online business yet, start looking for a new job (oh, and boning up on the latest specs :-)
I think there's a company in Richmond WA that claims to make one...
But the US is still the laughing-stock of the rest of the world wrt software patents, with the Patent Office still granting patents on patently unpatentable concepts. How much longer before someone patents the concept of a word?
I shall clearly have to buy the book. The Gimp has probably the crassest and most ridiculous set of interface restrictions I have seen since VMSmail.
Sadly, even the leading light in the other camp, PaintShop Pro, is going this way: the latest version is even less intuitive than the previous one.
In their scramble to provide the latest and flashiest filters and the most sophisticated image-munging around (and let's not forget the Gimp is very sophisticated, as well as being extremely reliable), too many graphics programs are neglecting the basics we all need for everyday trimming and tidying up.
Doubtless I shall change my mind once the book has explained everything to me. It's just a pity it needs a book, rather than using the interface, Luke.
I don't know if the labour shortage is everywhere but I'm being headhunted from Europe to the US because companies can't find people my age (47) and experience (20 years online) in the USA. I'm not aware of being an indentured servant...yet.
Not in the UK, where the digit 1 was originally pilfered to make space for the pounds sterling sign, because, of course, it wouldn't matter using a lowercase ell for a digit, now, would it...