Fri Aug 16 17:38:07 NZST 2002
V K writes:
> > in Suse 8. It is just too bad that the ncurses terminal implementation in
> > yast2 is inane and unnecessarily difficult to use.
> Agreed. The keycodes are shocking. But it does work, and you implied it
> wasn't available, unless I misunderstood that at midnight.
I didn't write particularly precisely in the first place. The point is that
the keycodes are so shocking as to render yast useless. I personally can't
be bothered with it when I can directly edit the configurations files
quicker than it takes to work the keypresses in yast.
Also, by now, you should know that I'm not a point-and-click fan. Didn't you
notice that I wrote my whole PhD thesis on a vt220 terminal with emacs?
That was even when all those Sun workstations running X window were around -
like right on the next desk. These cluttered windows displays and a mouse
are so distracting. I still sometimes miss the old vt220. It really
focussed me on the work when I used it.
> The easiest way to use upgrades for SuSE is to mirror the updates
> directory with rsync, leave it on disk or put it on a CD. Note you must
> have the correct dir structure, but there's an sdb article about it. If
> it's on CD, run patch CD update, if it's on disk, run online update and
> select source=locadiskpath. Works a charme. Oh yes, both from yast,
I was given the rpm files only. I therefore had no choice about having
correct dir structure, etc. That was all I had to work with. Old yast with
Suse 7.2 would work with that. New yast2 with Suse 8.0 doesn't. I consider
that a step backwards.
> did upgrade to KDE 3.0.2 with that while running KDE as shipped.
Interesting. I'm surprised it worked OK.
> > Now I have a shell script that will be very
> > useful for package upgrades in the future.
> Shell script? No need to put rpm -UvhF into a shell script.
My shell script does more than that. There were problems that
straightforward use of rpm per package couldn't sort out.
> > > It would be, if you use BSD lpr. Nobody does any more.
> > Hmmm. We are doing so on our Alphas. Your claim has just been proven
> > false. Taa daa!
> As anyone recently pointed out, these days Unix=Linux (unless you go by
> financial turnover) :))
Sorry, but I don't accept that. Whoever recently pointed that out is either
blind or a fool. IIRC, Linux only has an installed base equivalent to
Sun's. Certainly significant, but it's arrogant and narrow minded to suggest
all the other Unices essentially don't exist or matter now.
Admittedly, my office computer is indeed running Linux, but that's only
because Microsloth is so incredibly bad, and when I got the office computer
there wasn't really any other suitable choice. I am often essentially only
using my office PC as an X-terminal because our Alphas (running Tru64 Unix)
are so much better.
However your comment on finance is certainly relevant. We bought our last
Alpha running Tru64 Unix a couple of years ago. Compaq (now HP) have
completely priced themselves out of the market so we won't be buying anymore
of those. We are now seriously considering going to MacOS X for our servers
to replace the alphas.
> > I note looking at the lprng documentation that they recommend the ifhp
> > filter for interfacing via the JetDirect port (9100) of HP network
> > printers. That is what I would like to have. But Suse implement a
> > connection to the lpd port (515) of the printers
> Set up a filter queue only, and another raw queue for printing, then
> change printcap for the raw queue to go via jetdirect instead of suse's
Yes, I might have a go at that. Another question, why do Suse insist on a
filter queue that feeds into a raw queue for every printer? Why not just
set up one queue to a postscript printer. Everything of any interest
generates postscript, and the only printers of any interest are postscript
printers, so why bother with a filtered/raw queue distinction?
I suspect I'll end up configuring the printer queues myself instead of using
yast. Fortunately we already have shell/perl scripts to do that on our
alphas and so it will be minimal work to modify them for Suse.
> > It took me longer than 5 minutes using yast. Mainly because yast
> > buggered it up and didn't make the correct changes to shut down the
> > cupsd and run the lpd. I had to find the problems yast introduced and
> > fix up the config myself.
> I sent that as bug report too. It seems when uninstalling cups the daemon
> doesn't get removed, thus clobbering printcap while running. Fixed
> already. The fault would be with the rpm, not yast. Or are we talking
> about something different here?
It's possible that when I installed cups that I decided I didn't like the
way yast installed the cups daemon and changed things around. I've got a
vague recollection that I may have done that. So the possibility exists the
system was in a state yast didn't know how to handle. All the more reason
to biff it. It really just doesn't cut my eccentricities! :-/
Dr Michael Cree Email: cree@p...
Dept. Physics and Elec. Eng.
University of Waikato
Private Bag 3105 Fax: +64-7-8384835
Hamilton Telephone: +64-7-8384301
More information about the wlug
NOTICE: This is an archive of a public mailing list. The University of Waikato is not responsible for its contents.