#2286 Bridge $1595???
38 messages in this thread
I completely agree with you, Gabe, so you aren't spitting. Workbench may
have a mouse and icons, but it's no Mac. Workbench and CLI are amazingly
inconsiderate, and there are many commonly executed tasks for which there
are no Workbench equivalents, whereupon the Guru recommends the use of the
CLI, which only leads to more confusion and inconsistencies. I don't think
we should blame Commodore for this one. I think we should blame Amiga
developers. Look where they continue to devote their attention, into
little CLI hacks, and obscure applications that require a computer science
degree to exploit. Sure, some say "programmers are users too", but all
users are not programmers. Why make anything more complicated than it need
be? Programmers are supposedly more computer literate, yet they shrink
away from "simpler" solutions like a more usable Workbench. More and more,
I don't think it will be said that Commodore that killed the Amiga,
instead, the developers and hackers will be rightly blamed.
Assuming that one of your goals is a much more powerful workbench
environment, what are you looking for in it? Actually, I suggest we start
a new thread as to what wb should be about.
And your programs address the shortcomings of the Amiga? Face it John, the
WB has faults that are difficult to overcome with any reasonablr amount of
effort. Can you in all sincerity blame the developer or hacker for not
spending an inordinate amount of time making an application work with every
possible combination of CLI/WB? WorkBench issues are being addressed for
1.4, with a complete rewrite seeming the most likely.
It appears that my message was misinterpreted. I meant to say that most
Amiga developers and hackers are apparently not concerned with the failings
of Workbench, and would rather devote their energy to a gaggle of CLI
hacks. I wasn't necessarily faulting applications that don't integrate
with the Workbench. Workbench issues should have been addressed in 1.2 and
1.3, instead of hoping for them to happen in 1.4. The faults have been
there all along. Instead of talking about the flaws, too many people have
been hung up in relatively meaningless CLI-comp-sci "improvements". Those
things are complicated, too, and look at the effort thrown at them.
As meant to say, ten years from now, when people (probably us) are sitting
around over a beer talking about the Amiga's failings, we aren't going to
say it died because the LIST command didn't recurse, or have a certain
option, we're going to remember that Joe User was forced to the CLI to
install a printer driver or do a certain kind of file copy, or forced to
the CLI to install a program on a hard disk.
Though many of the 'improvements' were, as you say, to add options or
what have you to existing commands, many more were to fundamental design
flaws or to bug fixes that affected both environments. Who knows… 10
years from now we may be saying that the Mac failed because they didn't pay
attention to the need for choices.
I don't know what method you use to judge success, but by every measure I
know the Mac is already one, and will not be looked back upon 10 years from
now as a "failure." The Amiga is another story. The Mac had its "down"
period (where it seemed everybody was complaining about what it couldn't
do) that lasted two years. Then Jobs was thrown out, the Mac Plus came out
(with some great improvements) and the Mac has been on the upward climb
ever since.
The Amiga is now going on its _third_ year of "complaints." And there is
no real hope in sight of it ever taking off like the Mac did. Oh, there is
always the "wait til 1.2 (or 1.3, or 1.4, …) and that will be fixed." But
always CBM drops the ball and never quite comes through.
There are always those enthusiasts who will like the machine no matter what
happens to it in the next five years. Even the Mac had its "following"
during the dark times–and they were just a devout group as the Amiga's.
The point is (and this is where I differ from your comment) that barring
some major turnaround at CBM, the Amiga will hardly be remembered 10 or 15
years from now, while the Mac will be. I wish it weren't so (I prefer the
Amiga to the Mac in its multitasking abilities and hardware), but it I just
don't see it happenning.
You never know until the time comes. Tell me, how many Macs had been sold
in the first three years? The Mac II is a different beast altogether, and
widespread accptance seems to be more likely for it, primarily, in my
opinion, to the needs of the users (expandability, speed, etc.).
The Amiga may well be forgotten in 10 years, but then that isn't much
different than most of today's computers. It has every bit as much chance
of still going strong as has, say, the Mac II.
It is MUCH easier to design a computer now than in earlier years
(comparing the growth of the Mac to the Amiga). Computers are getting
outdated faster and faster. Even within the development of a single
machine this is evident: the Amiga 2000. The A2000 schematics are
hand-drawn while the B2000 schematics are plotted. Undoubtedly part of the
reason is that the cost of machines to do that has come down so much. Same
with other areas of computer design and manufacture. Technology is growing
at an exponential rate. Therefore you can't really make an equal-time
analogy between the growth of the Amiga and the Mac.
I can and do make the comparison in the rate of sales of the Mac and
Amiga. I think it has some validity. Look at other machines. The C64, in
the first two years, probably outsold the Amiga by a considerable margin.
Was it all due to price? I don't think so. remember, the 64 started off as
a pretty high priced machine, though lower in cost than a Mac (isn't
everything?).
The A2000 schematics were hand drawn alright, by the engineers in
Germany. Judging by the design of the Sidecar and the $C00000 memory board
they did, it does not surprise me that they used outdated methods on the
schematics.
You've got to be kidding…it might be much easier to design
something equivalent to an Apple II, or C=64 or IBM-PC than it was in the
earlier years since there are now chips that combine the functionality of
what used to be quite a few separate parts; but, if you're trying to design
a new computer that has a 'technological edge' over it's
competitors…that's much harder than it used to be.
Back in the old days, all you had to do was add color to be in the lead.
Now you have to have the latest processor, the fastest clock speed, the
highest graphic resolution, the fastest graphic routines, the fastest HD,
etc. to get into the lead. In fact, you almost have to have those things
just to compete.
Interesting…I just read a brief article from a Mac developer
talking about how Apple has never fixed the unexplained crashes, how they
keep bringing out incompatible OS systems (64K vs 128K ROMs), etc. I
almost thought I was reading the history of the Amiga rather than the Mac.
The more I've thought about it, the more I *like* versions of operating
systems that break *everything*, and force people to rewrite code. IBM and
Microsoft have effectively done that with OS/2 and Windows, even though
they hoped to retain some level of backwards compatibility. Apple has
tried to keep things backwards compatible, but it never quite works out,
and people rewrite anyways. So I say, break it all, and let 'em rewrite to
keep up. Not that I want CBM to break everything every six months. But it
does wonders for adding new changes. I think a complete break is what is
necessary for "fixing" the Amiga. Fortunately, we already have the
important operating system concepts that the IBM and Mac lack, making our
transitions much easier than theirs.
No need for ad hominem attacks. I'm sure you understand why InterChange
exists. 3D developers had lots of reasons not to cooperate and create
standard file formats. It opened markets for people like me, and let me
build a base to build 3D enhancement products like InterFont. As more
paint programs come along, I'm sure IFF will get more and more
incompatible, too. There are already plenty of problems there.
Hmm… that was no ad hominem attack. That was not an attack at all. I
was trying to make a point, and apparently I failed. You accuse developers
and hackers of ignoring the WB, and I just thought I'd point out that your
product is no different than many of the others in that regard.
Oh, is that what you meant? Like I said, I didn't mention or blame any
product, I was talking about the outward action and interest of developers.
I see little concern with the *real* problems of the Amiga, from Joe User's
point of view.
Have you ever *seen* InterChange? It's one of the few products that works
only on the Workbench screen. How many others can you think of? Modules
will run from the CLI, but it doesn't accept command line arguments. You
have to do everything from the Workbench. Why, we even use icons. With
InterFont, project icons launch the application.
I wasn't saying that developers should be developing products to cover up
the flaws in Workbench. Products aside, in what direction do developers
push Commodore? Towards the CLI and Unix-like hacks. User interface
concerns are very rarely mentioned, and I've never seen any Stanford grad
stand up and say the Amiga really needs a Workbench method of installing
printer drivers, or a way to switch Workbenches on a one-drive system…
Gee, there were some MIT grads talking about an iconic INSTALL procedure
last night at the BCS meeting. Or maybe they were Harvard types, I dunno,
but the topic came up. I'd like to see a generalized "Install" program
that will simplify installation of any new software, be it a printer driver
or an application or fonts or whatever.
So, John, why haven't you written a replacement for WBench?
You've misinterpreted my message. I didn't imply that developers should
have been writing Workbench replacements. I did mean to say that
developers should be concerned with Workbench's flaws. Commodore
development does listen to developers, to the limits of their ability given
limited resources. I think developers should be talking to them about the
Workbench flaws, not the CLI flaws. To me, that would show true concern
for the Amiga and its users, because the majority uses the Workbench
exclusively.
The problem is that you seem to be much more in touch with the real world
than CBM is. Yes, most users are Workbench only, but at CBM they work in
CLI only. Software developement at CBM takes the track of "what would I
(the developer) like to see on the Amiga" rather than "What would the
typical user like to see."
And this won't change until either (1) CBM gets some top management that
sees the advantages of making a machine that is easy for the typical user
to operate (lot likely), or (2) there is a mass exodus from the CBM
software development group and an entirely new group comes in who is
interested in making the Amiga a true challenger to the Mac in ease of use
(even less likely).
Right now the Amiga is the result of having the developers do whatever they
want (and call it an official new release of the OS) and having no real
head on top making long term strategic decisions re. software (the
management is only interested in selling as many machines as they can this
quarter, and investing in R&D for a long term software development effort
really hits hard on the current quarter's P&L).
Oh, Jim, you're just sweet-talking me. What I'd like to do is formulate an
argument to persuade developers and hackers to *care* about the user
interface of the Amiga. I'd be willing to lead the charge, as it were.
(Why, it could be a movement! We could call it PRA, for the "Project to
Revamp the Amiga." Nah, never mind 😉 I want to learn why developer-types
have ignored the CLI, why they ignore Workbench problems, and how to
persuade them that those things should be fixed before we add another layer
of inter-process communication.
Well, I gave a stab at trying to change Amiga developer's point of view
regarding user interface issues. I circulated a document "A Common User
Interface for the Amiga" about a month ago. So far very little in the way
of positive feedback has made its way back to me. However, I still try,
and will (hopefully) get a version of this document printed in Amazing
Computing.
This article discussed the reasons and advantages of a common user
interface between programs, and pointed out how such a user interface would
_not_ stifle creativity (this seems to be the major argument against
ease-of-use, amazing as this fact may seem). It then goes on to give
suggestions of the essential elements of such an interface, and talks about
how this could be implemented in an easy fashion.
Unfortunately, as I said, no one seems to be interested in this. In fact,
when the concept of "User Interface" is brought up the conversation
invariably turns to "file requesters." To me a file requester is but one
small part of the overall picture, but apparently I am in the minority.
Interestingly enough, the greatest reluctance to adopting a common user
interface has come from WordPerfect Corp. Not so strange, since they are
obviously trying to do their own interface on every machine they write
their word processor on (this is one of the reasons that their Mac version
hasn't sold that well).
Welcome to the club. There is a lot of resistance among third party
developers to ideas proposed to Commodore by other third party developers.
If developers would stop bickering amongst themselves and focus on actually
getting something accomplished and accepted by Commodore, perhaps Commodore
would be more likely to listen.
On the guidelines you've proposed, I skimmed through them, but I think you
need something more concrete. Providing tools and functions that makes it
easiest for developers to create applications that follow a set of
guidelines is the simplest way to get developers to do something. Most
developers will chose something that is easy to accomplish if it is
available, rather than spinning their wheels working on their own
customized non-standard stuff. …cheath
Where was this document distributed? I'd be interested in seeing it.
Copies of it were handed out to anyone who wanted it at the World of
Commodore show in Philadelphia. Most of them were handed out at the Amiga
Working Group meeting at that show.
Yah! But if 1 person joined, they might think he was crazy and just
ignore him. But if 2 people joined, they might think they both were crazy
and ignore them just the same. But if 3 people joined (3 people ;-), the
might think it was a movement. And if 4 people joined, they might think it
was a revolution!
With respects to "Alice's Restaurant",
David Masterson
If a developer doesn't use WB, how can he be expected to voice opinions
on it, to CBM or anyone else? I think that if you are that concerned about
it, and as a developer, you should make those suggestions yourself, and I
say this not knowing whether you do talk to CBM about it or not. James has
answered your message with yet another plea for work on the WB, and I would
hope that he too talks to CBM about it.
At any rate, CBM has stated that WB is coming out of ROM in 1.4, and that
it will get a lot of rework. Now is definitely a good time to make your
contribution to the effort.
That's a very lazy argument. I'm sorry, I give developers more credit than
that. I believe they are smart enough to understand that the Workbench is
used by most people, and that it should matter to them if there are
problems there. It truly affects the success of this machine, more than 80
percent of the gunk on the Fish disks.
No more so than supporting the WB to the exclusion of the CLI. Eliminate
the ability to run a program from the CLI with command line arguments, and
you immediately eliminate the ability to do things from script files,
whether those script are called form CLI or WB.
Does working on CLI things mean mutual exclusion with enhancing the
WorkBench operating environment? There are a number of areas where
enhancements in one aspect pay off for both; for instance, the fast
filesystem is a "DOS == CLI" enhancement, but also pays off in the WBench
environment. A toolbox library with things like file requester, font
requester, and some lower level user-interface support things is useful for
both WBench and CLI users and developers. The current state of WBench is
definitely abysmal, and needs a lot of attention from someone. When there
is a WBench-like interface which is as capable as the CLI interface, I'm
sure a lot more developers will pay more attention to it, whether it be
from Commodore or from a 3'rd party developer such as Ken Salmon's
"DeskTop".
It's not really a question of mutual exclusion. Let's look at the facts:
So far, within the R&D constraints of CBM, and the interests of developers,
*only* CLI improvements have been going on. Why? What Workbench
improvements were made in 1.3? I'd say they pale, and were done
half-heartedly, as compared to the effort that went into the file system,
for example. Most users can't even begin to understand all that has to be
done to make the transition to FFS and 1.3. I even know developers and
smart users who had a hard time getting it going – how can we say it
improves things for Joe User? It was just another thing that forced them
to the CLI and 'ed'.
You made a chicken-and-egg argument in the last part, there. What did you
mean to say? You said, when WB gets good, people will start paying
attention to it… meanwhile, they aren't.
I truly feel that if CBM had a different set of priorities, and had in
fact devoted all of their 1.3 development efforts to improving the
WorkBench environment, then we'd be currently involved in a thread flaming
them for the abysmally-slow file system, and the awkwardness and
inconsistencies of the CLI environment. ALL of these areas have needed
attention. I think it's better for all of us that CBM decided to focus in
a limited area and get something done, rather than thrashing about and
never finishing anything. As to their choice of priorities, it is
debatable, but I think that whatever direction they had chosen, it would
have been wrong for a lot of us.
I agree. But when CBM made the choice "CLI or WB?", they made the wrong
decision, I think. The WB should have been done first. I don't want that
question to be answered the same way again. And where did you get the idea
that CBM wasn't "thrashing about and never finishing anything"?
That is not a chicken and egg arguement. The WorkBench is a poor
environment, and thus developers have spoken by working in the CLI
environment. Commodore hasn't read the writing on the wall.. I'm suprised
that nobody has chosen to actually take on the task of rewriting WorkBench
until Ken Salmon did; but I don't think it is accurate to blame any
developer for ignoring WorkBench as being the cause why WorkBench is
abysmal.
I don't classify the FFS with CLI improvements, but rather as a fix for a
fundamental flaw in the system itself (namely an incredibly poorly written
DOS). Other than this, and the new printing system (which is also merely a
fix for a poor initial design), the only changes in WB 1.3 _are_ CLI
changes. New CLI commands, pipes, AUX device, RAD device, and so on are
nice, but are useful only to CLI users (with the possible exception of the
RAD device, but even with it you need knowledge of startup sequences and
MountLists to even make it available to Workbench).
Other than the fix for system flaws (FFS and printer system), just about
everything else in WB 1.3 seems to be nothing more than cute hacks that
Andy (or whoever) thought would be _neat_ to include. Not what I would
call a sound strategy for product enhancements, nor something I would call
an _official_ new revision of the OS.
I'm not a defender of the V1.3 release, I agree completely that there
should have been a new WorkBench released. This is going to become even
more clear when WorkBench comes out of ROM in V1.4, and suddenly there are
a lot of applications which can no longer boot on the system because
"LOADWB" won't do anything, since there will be no code in ROM to run.
I guess I have a different view on "What is a CLI thing". To me, the DOS
is one of the system flaws; the filesystem is one part of DOS which has now
begun to be addressed with FFS. The CLI is the major impediment to fixing
the rest of the DOS, because the CLI programs use all of the underlying,
undocumented functionality in the BCPL GlobVec. Until the CLI and related
programs are replaced, the underlying DOS cannot be fixed. Commodore
didn't address this in V1.3, but perhaps will in V1.4.
You yourself must have felt some need to 'fix' the CLI environment
since you choose to take on ARP.
Sure, there's a need to fix the WB environment, but let's put this
in some form of perspective. Something had to come first. The biggest
complaints I've heard are the slow filesystem, lack of autoboot, lack of
command history and aliasing.
Now, maybe those who have complaints about the WB just haven't made
themselves known, because the major complaint I've heard there is lack of
ability to see all the files on the disk. I've heard a few other things,
but nothing like the complaints I've seen about the CLI environment.
There may be lots of reasons for that. I don't think it's
important to speculate on the possible reasons…only the fact that the CLI
type things needed to be done first.
I don't care to jump too far into this thread at this time, but thought
I would make one comment… your last msg refer to a few of the
improvements in 1.3 as 'fixes to poor initial designs' (or words to that
effect). Which may in fact be true. But at the same most 'any' revision
to 'any' software would/could be classified the same way.
The basis behind releasing a version 'x' of software is that it fixes
bugs and/or enhances the product over version 'x-1' (read: adds
flexability/ power/whatever not incorporated into version 'x-1' due to
"poor initial design").
I think this holds true for "WizBangWordProcessor" as well as an OS. I
don't disagree with what you said, but it 'sounded' to me like you were
implying that since they were _just_ fixes/improvements, they shouldn't
have labeled it an "Official new OS".
I too would like to have seen improvement in other areas, but if they
have a better 'fix' for the filesystem and want to call it an official new
OS, then that's ok by me… as long as I can get it (read: not have to wait
for them to re-invent the WorkBench). – Keith "just passing through"
Young
Well, you are correct, since that is a valid way of labelling a "official
new release." But all in the WB 1.3 that really matters is the "fixes" to
the system's flaws (namely FFS and the new printer system), while all the
rest is window dressing. If CBM had concentrated their efforts on these
two things that mattered, and didn't diddle around with their little CLI
toys, then 1.3 would (or should) have been out much sooner.