Should swinstall & Ignite-UX tools be implemented w/Java?

[Patrick Wallek]

Peter,

Very interesting and well thought out response.

Now I would like to respond to your points.

1) You hit the nail on the head when you mention that differnet software has requirements for different versions of Java. If I install a new version I don't want it to break other stuff.

2) I do have a problem with every developer and their dog including their own JRE version with the software. This adds a LOT to the disk requirements when loading software. *I DON'T WANT 6 DIFFERENT VERSIONS OF JAVA JRE FOR 6 DIFFERENT PACKAGES!!!!!!!!* Too many developers are assuming that there is unlimited disk space for installing
software. If have a machine with only a 4GB disk drive for the boot drive, I STILL WANT TO BE ABLE TO MANAGE THE SYSTEM EFFECTIVELY.

3) I do have Perl installed on all my machines. The *ONLY* reason it is installed on some machines is because of the security_patch_check tool. Again, I don't like having to install something for a SINGLE application.

4) You are right, anyone can write bad code in any language. It's just that I have seen much worse examples of it with Java stuff.

5) Command line had BETTER be offered as well as a basic effect TUI.

6) The big question I have is WHY are tools moving away from X11 and towards Web / Java / whatever? I don't see the problem with X11 tools. At this point X11 is stable and the X11 libraries are standard HP-UX and most PC based X servers are pretty good.

I am not a big fan of using a browser to manage things. The biggest problem is that most developers (and this includes HP) do not think to check with multiple browsers. Most things are developed for IE (which I also despise) and no thought is given to cross-browser compatibility. Even using Java does not guarantee this. I do not see the

7) Performance / memory issues - Again developers everywhere develop towards the high-end systems with lots of CPU and lots of memory. Why the heck do you do that??? I personally think all developers ought to have minimum configuration machines, whether it be PCs or Unix boxes, and be forced to write code that will work on those boxes. YOU CAN NOT ASSUME THAT EVERYONE HAS MULTI-GB OF RAM OR 72GB DISK DRIVES FOR THE OS!!!!!!!! I've got some old E35 and E55 boxes with 256MB or 384MB or RAM running HP-UX 11.11. I use the swinstall TUI / GUI occasionally on those and it works pretty well. I would hate to think what a Java interface would do on those.

Applications and operating systems are becoming WAY TOO BLOATED because of issues like this. I want something that will run decently on ALL machines, from my D boxes on up to my rp5470s. Mind you I don't expect the exact same response on the D as on the rp5470. BUT I do expect well written, tight, efficient, SECURE code.

Now all that being said, what is the motivation behind this survey? Is HP getting requests from customers to convert to Java for these tools? Is it a mandate within HP to do this? What is the rationale here?

I personally do not see what doing this would accomplish, other than pissing off quite a few Sys Admins. As I said, I see nothing wrong with the X11/TUI/CLI that is currently available for these utilities.

I am curious now -- Has this been asked of systems administrators anywhere besides this forum? If so, what was the response? I would be curious if it was the same as here (about 95% negative so far).

As someone else above said -- Thank you for taking the time to ask us. Now please listen to us. Even better, how about some feedback once a decision is made.

[PeterWolfe]

Thanks Patrick,

>1) You hit the nail on the head
>when you mention that differnet
>software has requirements for
>different versions of Java. If I
>install a new version I don't want
>it to break other stuff.

Agreed.

>2) I do have a problem with every developer
>and their dog including their own JRE
>version with the software. This adds a LOT
>to the disk requirements when loading
>software. *I DON'T WANT 6 DIFFERENT
>VERSIONS OF JAVA JRE FOR 6 DIFFERENT
>PACKAGES!!!!!!!!* Too many developers are
>assuming that there is unlimited disk space
>for installing software. If have a machine
>with only a 4GB disk drive for the boot
>drive, I STILL WANT TO BE ABLE TO MANAGE
>THE SYSTEM EFFECTIVELY.

Note that I was careful to point out that
the different products groups have to
cooperate here. All the internal HP
products need to share a common copy of the
JRE to avoid this problem. Of course, a
third party application would have no
choice but the reach the same conclusion
we've reached and have their own JRE. You will
definitely get JRE proliferation at some
level (there's no avoiding it). Of course,
the third party JRE's would probably not be
required to be on the system disk.

It really is conceptually the same as
linking an executable non-shared. Yes, you
remove the dependency on shared libraries
changing but you've made the executable
larger (and introduced other issues that
are a rathole for this discussion)...


>5) Command line had BETTER be offered as
> well as a basic effect TUI.

Yes!! There was never any question about
command lines. Some of the replies seemed
to think there was. Let's say it again:
There will always be a command line! In
mean this in the general terms that Java
GUIs don't make commands lines go away.

It's good to hear that you also want the
TUI/curses UI.

>6) The big question I have is WHY are tools
> moving away from X11 and towards Web /
> Java / whatever? I don't see the problem
> with X11 tools. At this point X11 is
> stable and the X11 libraries are
> standard HP-UX and most PC based X
> servers are pretty good.

The main issue most admins have with X11 is
that it only works when you are local to
the machine. IOW, on a LAN. X11 was
designed with 10Mb Ethernet as a design
center. You can't use it from home over a
dial-up line (not reasonably anyway -
things like Low-bandwidth X don't really
work well). You typically can't use it in a
WAN. So the trend has to been to move away
from X11 to things like Java and browser
based management (for GUIs that is). I
agree that in recent years another trend
has been that more and more folks have
access to DSL and cable modems from home
and X can work just fine in those
environments. However, it's just like your
4GB disk/300MB memory example - you
wouldn't want management tools to assume
that's what you had available remotely.

Another reason is "manage from a
PC". Whether folks like it or not, most of
universe has a Windows desktop. Yes you can
run a PC X server and it's "fine". You have
the standard hurdles of keyboard mappings
and X fonts but those are reasonably
surmounted. Aside: Note that requiring that
the admin have a PC X server is akin is
requiring that he have Java locally on his
PC :-) Browser based management is even
simpler since he's guaranteed to have a
browser.

So Java and Browsers represent platform
neutrality. You can run the management
tools from anywhere via those
implementations. Folks are universally
comfortable with browsers as well so it
makes things "simpler".

>I am not a big fan of using a browser to
>manage things. The biggest problem is that
>most developers (and this includes HP) do
>not think to check with multiple
>browsers. Most things are developed for IE
>(which I also despise) and no thought is
>given to cross-browser compatibility. Even
>using Java does not guarantee this. I do
>not see the

Your reply got cut off here but the point
is well taken. It's pointless to claim
browser support when all you support is a
single browser.... I don't think that it's
that we "don't think to check". It's the
incredibly scary qualification matrix need
to claim support for multiple browsers. For
Tru64 we supported Netscape and IE on PCs
for the base OS admin tools. For UX we'd
like to support Mozilla and IE.

>7) Performance / memory issues - Again
>developers everywhere develop towards the
>high-end systems with lots of CPU and lots
>of memory. Why the heck do you do that??? I
>personally think all developers ought to
>have minimum configuration machines,
>whether it be PCs or Unix boxes, and be
>forced to write code that will work on
>those boxes. YOU CAN NOT ASSUME THAT
>EVERYONE HAS MULTI-GB OF RAM OR 72GB DISK
>DRIVES FOR THE OS!!!!!!!! I've got some old
>E35 and E55 boxes with 256MB or 384MB or
>RAM running HP-UX 11.11. I use the
>swinstall TUI / GUI occasionally on those
>and it works pretty well. I would hate to
>think what a Java interface would do on
>those.

I'll pass on the "min config machines for
developers" for now :-) I had suggested
that memory footprint is an issue on memory
constrained systems. You have confirmed
that you are one of the lucky fellows who
has such systems :-) OK, so for you we have
the CLI and the TUI. Both should perform
well in that environment. I agree that a
Java UI would most likely would not work
well on these systems. However, these are
so old, will they even be supported by the
newer releases of HP-UX release? If not,
then those systems stay where they
are. These new tools are aimed at newer
systems in general (newer UX releases)
where java performance tends to be less of
an issue.


>Now all that being said, what is the
>motivation behind this survey? Is HP
>getting requests from customers to convert
>to Java for these tools? Is it a mandate
>within HP to do this? What is the rationale
>here?

I'll let the SMD Team answer this one since
it's their survey. I just happened to spot
this while following the forums and the
answers impact the products in my space as
well.

>I am curious now -- Has this been asked of
>systems administrators anywhere besides
>this forum? If so, what was the response? I
>would be curious if it was the same as here
>(about 95% negative so far).

Yes actually. There have been HP World
surveys asking similar questions
(e.g. preferences around CLI vs. TUI vs GUI
tools). I don't have the data but I'll ask
the product planners if they could post it.

>As someone else above said -- Thank you for
>taking the time to ask us.

And definitely thanks for the great
feedback!

pete

[Michael Tully]

1(a) NOOOOO Why ruin something that works fine
1(b) As others have stated Java is a pain and if you have to upgrade a particular software product at any time or recover your system ... well enough ...
1(c) The current choice of GUI/TUI and LUI (sorry CLI) is fine.

2(a) Fix the man pages. Have one man page per command or write a white paper that has more examples. The current ones' stink.
2(b) No

[H.Merijn Brand (procura]

Peter, maybe because I have no native English tongue, I'm not as verbose and clear in writing as you are, but some things have to get off my chest.

I realy like all the arguments, and the way they are put. Still there is a HUGE difference between java and perl.

I'm as curious as you are about what the reactions might have been if the team would have suggested perl or python. I'm very biased, I know, but I hope you admit that perl is much more usable in a HP-UX environment than java. Perl can be used for both graphic (GUI) and non-graphic (TUI/CLI) environment, and the same backend can be used for both graphic (Tk) and non-graphic user end.

I'm using perl every day, and not only for the security patch check. Again, being a perl5 porter, I'm biased, and with 7 perl's on each machine I'm not the regular user, but almost all scripts written in perl5.005 still work without problems in bleading edge perl. One reason for that is that perl has a test suite that is run daily accross the world on several architectures with several OS releases ranging from linux to HP-UX and from AIX to OS/2. These regression tests are also bundled in the smoke suite, which enables users that don't know anything about building and testing perl still help maintaining the qualitee and stabilitee.

I'm not aware that this is available for java.

Perl is also used for Database connections and interaction, and if Oracle would have chosen to use perl for their installation, instead of java, that would have made a whole lot of people happy. Oracle 8 needs java for installation. Installation from the command prompt has been abandoned. This sucks. I never used the oracle installer after that. It's just for installing the product, and leaves a footprint on my disk that I don't need or want.

Patrick sais he does not use perl, except for the sec check. I bet he does not realize that HP-UX uses perl already in the installation process, so perl is on the system anyway.

Changes to more recent versions of perl make life easier, but only if you depend on Unicode (which I do right now) or have other edge cases. I have no problem converting back to perl5.005, though I love the new features in higher versions.

Your aim is to support Mozilla and IE. I use neither. I'm using Opera (small and fast), Firebird (small and fast), and Konqueror (default on my linux). None is on your list. Why? You missed my post in this thread? Why not just go for following the (xhtml) standards, so _all_ browsers are supported. I cannot imagine the need of shockwave support in swinstall functionality, so even Amaya should be fit to use (not that I'm pushing for Amaya here, but that for sure is the browser that shows errors first).

As for working from home. I'm working from home about 20% of the time (including right now). X11 over a single ISDN line is very well doable, but I switched to using remote desktop. Why? Because if the line drops, or I have too much distortion, the process can continue on the desktop at work, which has LAN access, and a speedy connection to my HP-UX machines. I would not even _think_ of running any system administration tasks over ISDN/ADSL with java/IE/... from my home desktop, be that linux or M$.

ssh or ssh -X are my choises from Linux.

Hope you are able to untangle these spaghetti thoughts into something usable for HP.

Enjoy, Have FUN! H.Merijn

[Volker Borowski]

Hello Peter,

I have to admit that reading your post might have set some things right, that I had thought of as facts, because I learned that things are done that way in real life.
May be these things could be done better, but the world has not got the message yet.

I do work with several JAVA products from SW Vendors like Oracle and SAP.

None of them ships a seperate fitting JRE or JDK to be installed as a seperate product. In case you download SW from their servers (like SAP's Downloadmanager or JAVA GUI) they direct you to go to sun and get it (That's where my 1b) experience is from.

Oracle does this partly. They ship their own JRE (I think even in two versions, 1.1.8 and 1.3.1) in their own directories (I am fine with this). But you need a JDK in addition for the very first install (I do not even know why).
At least it asks you for a JDK HOME. So if they set up their own JRE, why don't they for the JDK ? May be licensereasons forbid this (no idea if).

I agree, that my security concern is not JAVA related. It is Client-Server related. Now the tools I worked with (i.e. SAPINST or SAPs Upgrade Assistent) all have the intention to implement a Server-Application on the UNIX-box and a GUI on a client (typical a PC). So if you do no see this as one reason to do java, because you could stay net-less with java, you are bound to X in this case (how else would you do graphics ?).
So why not do X directly ?

Third I like to enhance, that there are well coded JAVA Applications out there. SAPs Upgrade-Assistent gave us a lot of nice functions you did not have in earlier tools and is a very fine example for an excellent and usable application. But I do not have to like the way I need to install it by installing 4th party software beforehand.

So in case you can develop and ship java-based SW that uses it's own JDK, that comes as a seperate HP-SW-Set in it's own location, and gets seperate patch support from HP, which ensures that esp. this JDK fits to your tools -> Go ahead and scratch my 1b).

I am very curious how this one will turn out in the future.
Volker

[Judy Traynor]

Yes - I would like to see the java tools started.

We still need the command line swlist command set, or a way to script the commands to get the same data out, for CM software deliveriies and component identification of our development machines.

The performance issue is a problem, but (taking oracle as an example) they have gotten much better as the rev's have been rolled out.

Certainly, as the development effort begins, you should maintain, or develop in parallel the command line interfaces.

Also, include some of the advanced tuning tools, the latest java bundle, etc with the software.

Change always meets resistance, and looking back at oracles implementation of the java install gui, the first couple of releases really were bad, but now, it is workable, and pretty clean.

Good luck

[IMteam]

Patrick writes:

> Now all that being said, what is the motivation behind
> this survey? Is HP getting requests from customers to
> convert to Java for these tools? Is it a mandate within
> HP to do this? What is the rationale here?
>
> I personally do not see what doing this would accomplish,
> other than pissing off quite a few Sys Admins. As I said,
> I see nothing wrong with the X11/TUI/CLI that is currently
> available for these utilities.
>
> I am curious now -- Has this been asked of systems
> administrators anywhere besides this forum? If so, what
> was the response? I would be curious if it was the same as
> here (about 95% negative so far).

First, I want to express my sincere thanks to all of you
that have spent to time to give us your thoughts on this.
We realize that some of these topics have been discussed in
the past regarding the SAM changes to the kennel
configuration area (kcweb) and pdweb. See also the tread:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=48372

In addition to that information, we wanted to get some
opinions on the use of Java, and to confirm that much of the
feedback the SAM team received also apply to software
management tools.

So what is behind this you ask? Well, several things.

1) The current UI technology that SAM/SD/IUX, etc, have
been based on is being phased out, and the teams are
looking for alternates as they investigate updates to
these tools. SAM has blazed some paths with kcweb,
etc. The SMDteam wants to make sure those are the
right paths for software management before heading
down them.

2) The software management tools are working on some new
designs that will eventually bring many new
capabilities, and begin merging the SD/Ignite-UX
tools into a more powerful and seamless software
management suite. Given this, we need to implement
the GUI/TUI on top of this design - as such, we are
looking at UI alternatives.

3) We were initially attracted to Java for the features
of the language and the modern look and feel of the
GUI it produces. As we learned from customers that a
TUI was still essential, we researched technologies
such as "Charva", that would allow us to leverage the
Java GUI development work and come up with a TUI.
(Charva is a Java package that implements classes
that are signature compatible with swing, but render
a ASCII TUI. If interested see:
http://www.pitman.co.za/projects/charva)

4) After listening to customers like you, we are now
reconsidering our attraction to Java. It is also
clear to us (and SAM) that a TUI is a requirement.
Both teams now have TUI's in their long term plans.
(The SAM team plans to post something explaining
their direction in a future thread, so stay tuned).

Again, thanks for your time and thoughts, we really are
listening.

-- SMDTeam (David Arko)

[Patrick Wallek]

You wrote:
>>The current UI technology that SAM/SD/IUX, >>etc, have been based on is being phased >>out.......

Which UI technology is being phased out? X11? I don't see how that is possible.

Now I'm more confused that I usually am. ;)

[Victor_5]

Personally, I will say no to Java, unless you have necessary reason to support you that you have to do so.

1. The current swinstall and ignite are good enough, I don't see any reason to add java on.

2. In our environment, we have a lot of applications running on Java right now, it always give me trouble when work for those applications.

Plus, so many changes on java side, we may keep the patch team very busy.

[IMteam]

I wrote:
>> The current UI technology that SAM/SD/IUX, etc, have
>> been based on is being phased out...

Patrick asked:
> Which UI technology is being phased out? X11? I don't see
> how that is possible.

I definitely didn't mean X11. I can see how my statement was
confusing. I was referring to an internal library we refer
to as ObAM. ObAM, plus a 3rd party library underneath, is
what allowed us to render both a TUI and GUI from mostly the
same source code.