Re: tlug: diald (was: mouse fixed; now what about email)

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "jb" == Jonathan Byrne <jpmag@example.com> writes:

    jb> -----Original Message----- From: Karl-Max Wagner
    jb> <karlmax@example.com>

    >> that Linux is a helluva lot more sophisticated than anything M$
    >> churns out. Like a Jeep compared with space shuttle.
    >> Astonished that it is easier to operate a Jeep than a space
    >> shuttle ?

    jb> In some areas that is certainly true, but not all areas.
    jb> Don't get me started about the primitive, mainframe-era
    jb> printing system that gives you practically no control over
    jb> your printer.  The (!')'#! Ghostcript driver doesn't even let
    jb> you choose which print quality level you'd like, even if your
    jb> Deskjet has three different ones (mine does), nor does the

Wrong.  Look up the `-r' switch and its relatives.  (I won't say RTFM,
it's not obvious that this is available from the docs.)  I'm pretty
sure that most of the deskjet drivers pay attention to it.  It's not
the printing system, it's the applications.  This is not lpr's job.
lpr's job is multiplexing printer requests from God knows where.

    jb> Unix printing system allow for setting your paper size in the

Bzzt.  If the application is properly designed, there are Postscript
conventions for doing this.  Ghostscript drivers leave a bit to be
desired, and may not be able to handle this (especially in multiple
tray environments), but many printer manufacturers refuse to provide
correct information (why I have no idea; that's also 3 year old
gossip, it may be different today).

    jb> application, etc.  Even MS-DOS was never this bad in those
    jb> areas.  If that's sophisticated, a Trabant is a Rolls-Royce.

Windose has this feature because there's only one kind of printer on a
Windose network: a Windose printer.  Manufacturers spend a lot of
money and effort ensuring that their driver provides all the features
provided for in the Windose printer API.

    jb> I'd love to see that printing system step into the twentieth
    jb> century, but don't expect it to do so until well into the
    jb> twenty-first :-(

Why should it?  I haven't waited for a print job to finish in years.[1] 
Spool it, forget it, pick it up at my convenience.  Draft mode saves a
little ink, it's true, but screen previewing saves a lot more.

I'm not saying this works for everybody, but evidently it works for
the vast majority of people capable of writing the drivers or apps
needed to provide the features you want.  (Either that, or it's in
such demand that only M$ can afford to pay the astronomical salaries
such programmers demand ;-)

I don't think that print spoolers should provide draft mode so that
weenies can look at their mistakes on paper more cheaply; I think that
the formatters should be made better so that fewer mistakes are made
and previewers should be made better so that they're caught before
they get to paper.

    jb> The GUI is a problem area too, in terms of being fragmented
    jb> with no real standard, in terms of widgets sets that start at

We have a real standard.  It's called "MS Windows" aka Motif.  There
are political and legal problems in getting it disseminated.

    jb> second-rate and go downhill from there towards butt-ugly, and

I don't see the Lucid and Enhanced Athena sets as being butt-ugly, and 
they're about as bad as you have to accept in Linux, since Athena 3D
is drop-in compatible with Athena.

    jb> in terms of generally not providing a lot of the little
    jb> niceties and smoothness that you get from some other

The "widget sets for the rest of us" don't even provide the amount of
globbing that the ancient Bourne shell does.  Niceties and smoothness
are not a clear win for either side.  People who don't use
sophisticated scheduling algorithms to multi-task their own work don't
appreciate Bourne shell globbing (let alone the find -regex option),
and I don't see why they should; I don't appreciate being forced to
grope for the mouse to select a file with a unique first letter
conveniently, when `a<TAB>' works so well....  COMMAND.COM for Windose 
Naughty-five still doesn't have completion.  :-(

    jb> platforms, and yes, I was very happy to see an article on this
    jb> in the May issue of Linux Journal.

    >> What is difficult with PPP ?

Buttheaded providers who won't tell you what authentication mechanisms 
and line settings they're using.

I think the big problem is the fact that there's no automatic way to
deal with authentication stuff; it makes the initial handshake to the
provider difficult.  And there can be problems with modem
configuration, but as Jonathan says that should be dealt with with a
config database.

    jb> A great deal, on Linux and FreeBSD.  Lots of people have lots
    jb> of difficulty getting a connection established.  That's why
    jb> all those how-tos are out there, and in spite of them, people
    jb> still have problems.  MacOS and Windows95/NT 4 have their
    jb> problems, but they both are a lot easier to set up and manage
    jb> than Linux, especially if you want to have multiple

This part is easy; I don't even need an interactive editor.

$ su
# cd /etc
# for i in ppp.*; do cp $i gol.${i#ppp.}; done
# chown $I_FORGET gol.*
# chmod $I_FORGET_THIS_TOO gol.*
# for i in gol.*; do \
  sed -e 's/53-6870/03-9999-9999/g' -e 's/ppp/gol/' $i > $i.tmp; \
  mv $i.tmp $i; \
  done
# echo >>gol.chatscript "'ogin:' 'turnbull'"
# echo >>gol.chatscript "'assword:' 'no-this-isn't-my-password'"
  % ppp.chatscript doesn't use a login sequence; PAP is a different
  % technique
# cd /usr/bin
# ln -s poff gol-off
# cp pon gol-on
# sed -e 's/ppp\./gol\./' gol-on > gol-on.tmp
# mv gol-on.tmp gol-on
# chown root.tty gol-on
# chmod 4755 gol-on
# exit
$ gol-on

and away you go (assuming you're a member of the group that owns
/etc/gol.*).  Of course, this won't work with diald, but then, diald
can't read your mind and know which ISP you want anyway.

    jb> connections (yes, X-ISP apparently solves this problem for
    jb> Linux, but how many distributions have it?).

    >> Neither Mac OS nor Windows have been *designed* with networking
    >> in mind. Linux has.

    jb> Linux is designed with networking through an Ethernet card in
    jb> mind, not dial-up stuff.  The configuration software for
    jb> dial-up networking could be better on Windows 95, and on the
    jb> Mac front Open Transport PPP is just awful (best thing to do
    jb> with it is rip it out and use FreePPP 2.6 instead), but they
    jb> are a lot easier to set up than what usually ships with Linux.

When Windose works, it's trivial, it's true.  When it doesn't, you
wait for the manufacturer to ship you the upgraded setup program.

However, no Windose setup ever worries about the concept that it might 
have to answer _incoming_ calls (fax programs, yes, but the physical
layer is much better specified there).  This makes modem and tty setup 
somewhat harder.

    >> Hmmm....and users have no fucking idea of init strings, DNS
    >> etc.  etc.....good luck.

    jb> But you shouldn't *have* to know, that's my point.  If the

You shouldn't, but often you must.  I have NEVER seen an automatic
program (except one that initializes with ATZ and hopes for the best)
set up a link properly here at Tsukuba-dai, because they all do at
least ATX4 and the stupid ancient PBX's dial tone is an interrupted
sort of thing that convinces the modem that the phone is already busy.

    jb> interface of the software is *done right* (yes, I know how
    jb> rare that is), all you should have to do is type in the
    jb> information your ISP gives you for your DNS servers, userid,
    jb> password, etc., and hit the Connect button.  And you should be

This requires a database of hardware, or a SCSI-type interface where
the hardware tells you what it is.  PCMCIA does it (well, actually all
the PCMCIA modems look pretty much alike), but most modems don't, yet,
anyway.

    jb> And it shouldn't be something you *have* to know; the init
    jb> string should be something that can be/is looked up in your
    jb> system's modem database, or provided by the driver that comes
    jb> with the modem.

What makes you think the manufacturer knows your needs?

    jb> and monitors that now exists: as long as your monitor is on
    jb> the list and your video card is on the list, it's really easy
    jb> to set this up in TurboLinux, and that's the way it ought to

Sort of easy, yes.  But TL does not use the whole list yet.

    jb> be.  Modems are the next frontier in this area, I think.  I'd
    jb> like to see printers be the one after that, but I expect
    jb> printer support on alternative OSes to continue to stink for a
    jb> long time to come.  I'm just lucky that my home printer is
    jb> sort of supported under Linux (that is, it works, but most of
    jb> its capabilities are ignored by GS).

You bitch about this a lot, but both of your complaints above are in
fact handled by Ghostscript itself, if not by the particular driver
you use.  And I just don't see draft quality and paper size as "most
of the capability" of any printer.  In my own experience, LaTeX2e
handles paper size well enough; I don't have a multiple tray printer,
but simply by setting the paper size to letter, A4, B5, or
A5/landscape in the documentclass options and hand-feeding I get
appropriate output.  And (as mentioned above) I have never felt the
need to use draft mode.

    >> Don't forget: TCP/IP networking is not child's play.
    >> Networking in general IS complicated stuff and many problems
    >> are not even

    jb> That's true, which is why this is an area where developers
    jb> need to really excel.  MacOS and Windows95 are most of the way
    jb> there on this.  A person with some experience should never
    jb> have a problem, but they still do tend to throw curves for

And when they do, Mac and Windose make it insoluble.  MacOS and
Windose are _not_ most of the way there on this.  It looks that way
because single workstation installations have been made simple, and
multiple workstation installations have professional support staff who 
hide the complexity from the end user.

I am definitely looking forward to the day that Microsoft has to
support enterprises working in a mixed IPv4/IPv6 environment.

    jb> One point that seems lost on most of the current Linux
    jb> community is that hacking on shell scripts, recompiling
    jb> kernels, and the various other things that a lot of Linux
    jb> users take for granted as a daily activity is *not* using your
    jb> computer, unless doing those things happens to be your job and
    jb> you use your computer to develop those things.

I don't think it's lost on anyone.  We just don't care that we're
o-taku, and we're not paid to care about everybody else.

    jb> A computer is no different.  It needs to be low/no user
    jb> maintenance to the greatest extent possible, so that the user
    jb> can spend time *using it*, not fixing it.  IS staff will say
    jb> the same thing about it: they want to be able to maintain and
    jb> update it easily, with minimal fuss.  This is an area where
    jb> Linux is in good shape already, especially TurboLinux.

Yeah, just ask the sysadmins on this list who take down their NT
networks every night, reboot them all to Linux, distribute software
upgrades, install and configure them, and have NT back up and running
for the lusers in the am.

    jb> Updating packages with TurboPackage is the easiest thing in

Not yet; it still is missing some of the features of dselect, as you
pointed out this morning on the beta list.

    jb> the world.  Neither Microsoft nor Apple have anything like it

    jb> (note to Scott: a future version of TurboDesk should allow a
    jb> network administrator to force-feed updates to all the Linux
    jb> boxes on the office LAN, simultaneously.  Show MS what Zero
    jb> Administration really means :-) ).

This will require ripping out the CD-ROM drives and shutting off FTP
and HTTP so that the users can't reconfigure their own boxes.

The right way to do this is to put the common software on a single
server.

    jb> The fact that NT and Windows 95 provide a lot more of this
    jb> end-user ease of use stuff and still have a much shorter
    jb> learning curve is a big reason (other than the clout that MS
    jb> carries, of course) why NT is doing very well in business
    jb> these days as an alternative to the low end of the workstation

I assume in "clout" you include the fact that technical staff often
are incapable of convincing the decision-makers of the technical
merits of Linux (or GCC), so they are forced to buy MS products, as
well as MS's monopoly on the ability to make incompatible changes in
the most popular office software file formats.

NT is doing well because it's the only upgrade path from Windose
Naughty-Five provided by Microsoft.  If it had to compete on its own
merits, well, it's not a bad product.  It's just not a great one,
which Windows 95 (as a _commercial product_, much as _I_ hate using
it) is.

    jb> market, despite the fact that a Linux workstation can actually
    jb> be put together for less money, because a Linux CD is a lot
    jb> cheaper than NT, you only have to buy one to set up all your
    jb> workstations, and its greater efficiency and optimization mean
    jb> you need to spend less on hardware to make it run well.  But

2/3 the processor speed and 1/4 the RAM, is what I'm hearing.  Of
course, that's overhead; if you've got 2GB of RAM, you aren't going to 
notice whether the kernel consumes 16MB or 64.  :-)

    jb> Linux really can have the stability, the superiority, *and*
    jb> the ease of use.

Hmm ... no, I think not.  It will be an excellent thing, and it will
be a close cousin.  But it won't be GNU/Linux any more; they'll go
their separate ways.  Hopefully, there will be family reunions every
couple of years.

But the superiority, where it exists, will continue to be on the
bleeding edge.  Interfaces that the ease-of-use tools depend on will
disappear or change.  The ease-of-use commercial distributions will be 
better off staying with the second wave.  Consider the glibc fiasco at 
RedHat.  I think it's interesting that Debian is looking like it's
about ready to release "hamm" to the world, just as PHT is about to
release TL 2, both glibc products.

RedHat tries too hard to be on the bleeding edge of Linux technology,
and not hard enough to provide deeper than cosmetic improvements on
the interface.  It's been discussed on this list recently the Bruce
Perens is (probably) leaving Debian and that the new distribution will 
(probably) distribute packages in a modified RPM format.  But that
format _will_ be modified; there are some control parameters that
Debian provides that RPM does not, and Bruce wants those, it seems.

I think that's an appropriate division of labor, too.  The tinkerers
and hackers produce good ideas, and somebody who wants to make money
slicks them up and elects them President Willie ... oops, different
diatribe.  Time to quit ;-)

Footnotes: 
[1]  That is, a successful one.  Heaven knows I've waited often enough 
for the bloody buffer to empty so a printer that I misconfigured into
text mode stops spewing Postscript code instead of graphics, long
after the netwrok stops spewing garbage into it ;-).

--------------------------------------------------------------
Next TLUG Meeting: 13 June Sat, Tokyo Station Yaesu gate 12:30
Featuring Stone and Turnbull on .rpm and .deb packages
Next Nomikai: 17 July, 19:30 Tengu TokyoEkiMae 03-3275-3691
After June 13, the next meeting is 8 August at Tokyo Station
--------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp