Re: hmm..interesting
Peter Naulls
[huge snip]
[FU: to advocacy - it's been a while ;-) ]
Can you, and everyone else who presently isn't, please learn
not to (a) quote signatures (b) quote _some_ relevant context,
but not the entire message, so you're actually replying to something
that was said, not something you imagined.
> I think that some people might have missed the point somewhat with
> what I was suggesting.
Given you didn't give any references for your claims, you're not
addressing any of the points made in reply and it was essentially a
monologue filled with buzzwords, this isn't very surprising.
> If you look at High-end engineering and
> scientific computer users, they don't care a hoot what OS they use as
> long as it runs the programs they require.
Which RISC OS doesn't, and probably never will, so they'll care a
great deal if that's what you're trying to suggest.
[snip]
As I said before, I
> think that the ARM9 multicore is a good basis for a multi-CPU HPC
> machine and that, given the long-term ties between RiscOS and ARM,
> that it would form a good basis for the OS
The name of the system is "RISC OS", and I fail to see the reasoning
here.
- compatible with old Apps,
> familiar to coders/users of the old OS, but running Linux
> transparently as a WINE-type service so that you have access to all
> those Linux apps straight out of the box.
Or, you could just run Linux. Where does RISC OS come in here?
Never mind the ambiguity in what you think "WINE-type service"
means.
> From a software point of view, you could simply run an instance of
> the OS on each CPU with a single core acting as a switch to put out
> segments of work to each node,
Really. We're talking about an OS architecture that is completely
different to anything mainstream, if you mean what I think you mean.
CPUs in general, must be coordinated by the OS.
> whilst the OS effectively runs a
> Beowulf-type cluster in one box,
Uh huh. "Beowulf" is a general encompassing term, and doesn't
specify any particular technology.
http://en.wikipedia.org/wiki/Beowulf_%28computing%29
but if this was set up as a decent
> commercial venture (i.e not on a shoestring), then I am sure that
> enough could be done to RiscOS to open it to multiple cores, etc.
If you mean "RISC OS", and if you have a large amount of money
you are not telling us about, then yes, RISC OS should be
rewritten for multiple cores, PMT, etc. But you can already
do this, after a fashion, by running it under an emulator on
a Linux systems.
> With all due respect to companies such as Castle, ...
I can't make any sense of this, so:
[snip]
> I think that offering web-based sales would allow more configuration
> and lower cost-to-market,
Sorry, what? context?
[More snip]
> All in all, whilst it wouldn't necessarily be the next Microsoft, the
> setup could certainly fill the void left by SGI and other HPC/
> Workstation companies and it would certainly sustain itself.
Which "it"? And why do you think that void hasn't long since been
filled? After all, if that niche still existed, then SGI et al
shouldn't have vanished.
> I think I'll do a bit of research into this...as I am sure this could
> be made feasible.
Yes, it's a shame you didn't do any to start with. Still, it made
an amusing post.
I know it's highly unfashionable, and this is not just directed at
you, but can we provide even a single link or example of things we
are trying to claim on usenet?
Chance Hooper
> I know it's highly unfashionable, and this is not just directed at
> you, but can we provide even a single link or example of things we
> are trying to claim on usenet?
Ok, let me see if I can explain where I am coming from.
Risc OS is fundamentally tied to ARM architecture and, as such,
provides a better basis for an OS kernel than a port of Linux which
is, at best, a somewhat flaky version of a dedicated hardware-specific
version of Unix due to the fact it is written on a massively branched
stream of development, whilst trying to cover off any possible
variants on x86 architecture, PowerPC, etc. Linux has its uses
(primarily because you can run freely available apps and a lot of
things that were exclusive to Unix machines have been ported due to
the similarity in the kernels, etc), which is why I say that having
the ability to run Linux in a WINE-type environment would be useful if
it worked in the same way that Apple implemented Classic support in OS
X.
Given that machines that run Software-based Risc OS currently are
basically Windows PCs that boot up to fire up WINE on startup and then
run Risc OS under software emulation (VirtualRPC, etc), it can be
safely assumed that Risc OS is lightweight enough in its footprint
that you aren't crippling the system's performance in much the same
way that Classic Mac OS applications ran at native speeds (or near
enough) on OS X systems. So, why do I think that a true update of Risc
OS is a good bet for a multi-CPU workstation running ARM cpus? Easy -
because it has none of the clutter that Windows or Linux has picked up
in it's sstem architecture over the years - by offering a fixed
hardware setup (i.e set Graphics and sound, etc), only the required
drivers would be needed as standard, unlike Windows and Linux which
have to carry a vast weight of excess baggage by necessity. I think we
can all agree that Windows (the de rigeur choice of Operating System)
carries far to much crud and spends too much of its resources in just
running the system (just take a look at Task Manager the next time you
are sat at a Windows PC).
So, even if we added twice the size to the OS in adding
Multiprocessor support and other requirements, we'd still be able to
spend less CPU resource on keeping the system running before we even
start looking at the applications (http://select.riscos.com/RISCOS6/
downloads.html - not one single OS ROM set is currently over 10MB,
compared to Windows Vista which runs into the Gigabytes, as discussed
here: http://www.vistax64.com/vista-installation-setup/26282-installed-size-vista-ultimate.html).
The need to be Windows-compatible is less important in HPC circles as
you are more likely to be running custom-made applications which, as
long as languages like C, Fortran and C++ are supported, can be
recompiled where required. Of course, if you wanted to use this
concept as your main computer, you do have the choice of using web-
based apps like Google Docs or there could be a port of Open Office
created as a bundled application (or you could run it in the
abstraction layer Linux environment).
Why I said it would be feasible (and desirable) to run Linux on a per-
process basis is that you could take advantage of the application base
(not to mention terminal-based network tools) without the need to load
a full KDE or GNOME environment - you'd run it in the same way non-
COCOA applications were run on OS X under Classic mode (http://
en.wikipedia.org/wiki/Classic_Environment). Given that there is an ARM-
based kernel of Linux, this again, is feasible, although it would
require a full-time development team for not a little time, but if
this was to go ahead it'd need to be a well-funded operation, not a
hobbyist venture.
So, to recap, you could create a machine that has many ARM cpus with
a modular expansion to add more compute power, with quad Crossfire ATI
4870 to allow OpenCL-style GPU computing, running an efficient
lightweight operating system that has the ability to run your Linux
applications if needed, which can out perform an equivalent x86 system
due to more efficient CPU architecture (see this article to show how
current ARM8 CPUs match Intel Atom performance with at least 200MHz
less in terms of clock cycles) and less OS clutter (A customised Risc
OS plus all the required add-ons and the Linux abstraction layer is
still going to weigh in far less than the >7GB for an install of
Vista). Given that you wouldn't be trying to force 21st century
performance out of 20th century equipment (unlike those of us who like
to use old hardware in our day to day lives and can't have a decent
web browser, etc), we'd lose a lot of the downsides of running current
Risc OS machines (too slow to support large video files, etc), whilst
gaining none of the fat that OSes have bloated out with in the race to
become idiot-friendly. To give an equivalent example, my SGI
workstations run a fully-featured easy-to-use Unix variant in 64-Bits,
yet none of them has a hard-drive bigger than 2GB and none of them
have filled it up, as I dump out the video and 3d exports to a network
drive. Compare that to Windows which, since Windows 98, has tended to
require at least 1GB of drive space (usually more), with ever more
space required for service packs and security patches, etc. With this
in mind, I think that taking pot-shots at me for actually trying to
think how the ARM platform and Risc OS could be made relevant in a way
that means it doesn't become the preserve of an ever-dwindling number
of enthusiasts running ever-less-relevant hardware is a little counter-
productive.
ARM is actually covering more installed system types than Intel at
the moment and I think that it would be a great thing if user groups
such as this one could start to pool concepts and ideas for possible
systems so that we might benefit from some new hardware - after all,
if I could offer you, right now, a machine that would run your old
Risc OS apps, allows you to develop in your Risc OS environment, yet
can run Linux apps as close to natively as makes no difference and
which not only keeps up with, but outstrips the latest and greatest
PC, are you honestly saying you wouldn't be interested?
Peter Naulls
> /snip
>> I know it's highly unfashionable, and this is not just directed at
>> you, but can we provide even a single link or example of things we
>> are trying to claim on usenet?
Yes, and now you snipped all the points I made, so the monologue you've
now written doesn't address any of _those_ points.
>
> Ok, let me see if I can explain where I am coming from.
>
> Risc OS is fundamentally tied to ARM architecture and, as such,
> provides a better basis for an OS kernel
You're still getting the name of the OS wrong. It's "RISC OS".
Repeating it wrong over and over won't make it true. Anyway, your
logic completely fails to follow - Linux on ARM has had very
extensive development, and has far more developers than RISC OS
has. Even if not true, your reasoning has obvious holes in it.
> than a port of Linux which
> is, at best, a somewhat flaky version of a dedicated hardware-specific
> version of Unix due to the fact it is written on a massively branched
> stream of development, whilst trying to cover off any possible
> variants on x86 architecture, PowerPC, etc.
Why is Linux flakey? And how are you comparing it objectively to
RISC OS? Linux runs on more hardware than any other system on
earth, so I don't know why you claim "dedicated hardware-specific".
Again, some actual research here would do your argument some good -
or avoid you even making it.
> Linux has its uses
> (primarily because you can run freely available apps and a lot of
> things that were exclusive to Unix machines have been ported due to
> the similarity in the kernels, etc),
Linux has an extraordinary number of uses. I'm not saying that because
I'm advocate (I'm not in the normal sense), but because it's a powerful
tool. But your statement is completely isolated without a comparison
with RISC OS.
> which is why I say that having
> the ability to run Linux in a WINE-type environment would be useful
You've completely failed to define what this means.
if
> it worked in the same way that Apple implemented Classic support in OS
> X.
That was for backwards compatibility. You've not stated any aims
here.
> Given that machines that run Software-based Risc OS currently are
"RISC OS"
> basically Windows PCs that boot up to fire up WINE on startup and then
> run Risc OS under software emulation (VirtualRPC, etc),
Where did Windows come into the discussion? Why would I want to run
Window at all. Oh, btw, it's "RISC OS".
> it can be
> safely assumed that Risc OS is lightweight enough in its footprint
> that you aren't crippling the system's performance in much the same
> way that Classic Mac OS applications ran at native speeds
And safely assumed that it won't run most of the software that most
people want to.
(or near
> enough) on OS X systems. So, why do I think that a true update of Risc
> OS is a good bet for a multi-CPU workstation running ARM cpus? Easy -
> because it has none of the clutter that Windows or Linux has picked up
> in it's system architecture over the years
"its". Anyway, this is wrong. It's exactly this "clutter" it would
need to pick up to be multi core and run any meaningful applications.
>- by offering a fixed
> hardware setup (i.e set Graphics and sound, etc),
Unless you have emulation, there's no such thing as a "fixed hardware
setup". And if you have a machine to emulate RISC OS, why don't you
just use the native system?
only the required
> drivers would be needed as standard, unlike Windows and Linux which
> have to carry a vast weight of excess baggage by necessity.
Please name some excess baggage in Linux that you think I can't remove.
> I think we
> can all agree that Windows (the de rigeur choice of Operating System)
> carries far to much crud and spends too much of its resources in just
> running the system (just take a look at Task Manager the next time you
> are sat at a Windows PC).
I might or might not, but I never mentioned Windows, you did.
> So, even if we added twice the size to the OS in adding
> Multiprocessor support and other requirements, we'd still be able to
> spend less CPU resource on keeping the system running before we even
> start looking at the applications (http://select.riscos.com/RISCOS6/
> downloads.html
Why are we looking at this list? What's the relevance? And what does
this have to do with multi processing support in the "real world"?
> The need to be Windows-compatible is less important in HPC circles as
> you are more likely to be running custom-made applications which, as
> long as languages like C, Fortran and C++ are supported, can be
> recompiled where required.
Yes, on Linux. Not RISC OS.
> Of course, if you wanted to use this
> concept as your main computer, you do have the choice of using web-
> based apps like Google Docs or there could be a port of Open Office
> created as a bundled application (or you could run it in the
> abstraction layer Linux environment).
Sorry, what. You've lost the plot now.
> Why I said it would be feasible (and desirable) to run Linux on a per-
> process basis
You didn't say that. This is why quoting is important. You were
bantering something about an OS per CPU.
[snip stuff that doesn't make sense]
> So, to recap, you could create a machine that has many ARM cpus with
> a modular expansion to add more compute power, with quad Crossfire ATI
> 4870 to allow OpenCL-style GPU computing, running an efficient
> lightweight operating system that has the ability to run your Linux
> applications if needed,
You mean, Linux? Or a BSD with a Linux-compatibility layer?
[snip heavy paragraph which doesn't seem to say anything]
> ARM is actually covering more installed system types than Intel at
> the moment
I don't know what this is supposed to mean. ARM is extensively
used yes, but that has nothing to do with RISC OS, except historically,
nor anything to do with multi-core, clustering, etc, etc.
> such as this one could start to pool concepts and ideas for possible
> systems so that we might benefit from some new hardware - after all,
> if I could offer you, right now, a machine that would run your old
> Risc OS apps, allows you to develop in your Risc OS environment, yet
> can run Linux apps as close to natively as makes no difference and
> which not only keeps up with, but outstrips the latest and greatest
> PC, are you honestly saying you wouldn't be interested?
I think this is called begging this question. Arguing on the basis
of doing something right now with something that doesn't exist is purely
philosophical, and of no relevance here. In any case, I can already
run RISC OS on Linux - using RPCEmu.
So, what was your point, again?
Please, when replying:
- Learn proper quoting.
- Don't bandy about terms you haven't research on
- Give examples
- Learn to spell "RISC OS"
hth.
David
<pe...@chocky.org> wrote:
[Snip]
> - Learn to spell "RISC OS"
He spelt it proper like. Every time.
I've told you before, PETER, English doesn't differentiate between
upper an lower case (and, for that matter, spelling itself - the actual
letters used and the order in which they're used - is no more than
convention and not law) so that upper case is used merely for emphasis
and convenience. Certainly, "PETER" is no mispelling of "Peter", is it?
I doubt there's a single reader of this exchange that is confused into
thinking "Risc OS" is other than the same as ACORN'S little operating
system.
I'm also pretty sure there's more than a few would prefer you didn't
get your pink lacy knickers in such a twist about it.
--
Om Namah Shivaya | Om Shula-panine Namaha
David - toro-danyo atcost uku fullstop co fullstop uk
http://www.toro-danyo.uku.co.uk/
druck
> Risc OS is fundamentally tied to ARM architecture and, as such,
> provides a better basis for an OS kernel than a port of Linux which
> is, at best, a somewhat flaky version of a dedicated hardware-specific
> version of Unix
Rubbish, RISC OS doesn't have anything that can be described as an OS
kernel. It is a 1980s single threaded I/O layer with a nice GUI on top,
which featured a number of features which at the time where ahead of
their time, but now universally available elsewhere to a greater or
lesser degree.
Linux is a highly developed kernel which runs far better on ARM hardware
than RISC OS ever has, able to take full advantage of chip features,
including better multi-tasking, multi-threading, memory use, blocking
I/O, interrupt latency, etc, etc. Most relevant to this discussion, it
is fully SMP capable, and able to fully utilise as many cores as ARM
will ever put on a chip.
> Given that machines that run Software-based Risc OS currently are
> basically Windows PCs that boot up to fire up WINE on startup and then
> run Risc OS under software emulation (VirtualRPC, etc), it can be
> safely assumed that Risc OS is lightweight enough in its footprint
> that you aren't crippling the system's performance in much the same
> way that Classic Mac OS applications ran at native speeds (or near
> enough) on OS X systems.
A completely invalid assumption. RISC OS is emulated and runs nowhere
near native speeds, and the emulation results in a considerable load on
the native machine. Due to RISC OS's single threaded nature it means
that emulation can't benefit substantially from multiple host cores,
constraining it's performance, and failing to take full advantage of the
native resources.
> So, why do I think that a true update of Risc
> OS is a good bet for a multi-CPU workstation running ARM cpus? Easy -
> because it has none of the clutter that Windows or Linux has picked up
> in it's sstem architecture over the years
Perceived 'clutter' is completely irrelevant to the huge engineering
task to get RISC OS and it's applications able to make any sensible use
of multiples cores.
> So, even if we added twice the size to the OS in adding
> Multiprocessor support and other requirements, we'd still be able to
> spend less CPU resource on keeping the system running before we even
> start looking at the applications (http://select.riscos.com/RISCOS6/
> downloads.html - not one single OS ROM set is currently over 10MB,
> compared to Windows Vista which runs into the Gigabytes, as discussed
> here: http://www.vistax64.com/vista-installation-setup/26282-installed-size-vista-ultimate.html).
No body cares about 10MB OS's you can't even buy any suitable SOC which
doesn't have more than 128MB of on board flash for the OS. Also size of
the OS has no direct relationship to how fast it runs.
> ARM is actually covering more installed system types than Intel at
> the moment and I think that it would be a great thing if user groups
> such as this one could start to pool concepts and ideas for possible
> systems so that we might benefit from some new hardware - after all,
> if I could offer you, right now, a machine that would run your old
> Risc OS apps, allows you to develop in your Risc OS environment, yet
> can run Linux apps as close to natively as makes no difference and
> which not only keeps up with, but outstrips the latest and greatest
> PC, are you honestly saying you wouldn't be interested?
Linux applications will still look and work like Linux applications not
RISC OS ones.
RISC OS is a dying OS, we can't even get one developer to do some work
on the most vital application in todays world - the web browser. What we
are left with a few legacy applications people cling on to through
familiarity, and the necessity to turn to another OS for all the other
requirements. There is nothing you describe above which can't be done my
running Linux on the hardware and RISC OS apps in an ARM on ARM
emulator. That wouldn't require huge development efforts on the OS which
we don't have, and even if we did would be better served targeting the
few applications we do still find useful on RISC OS.
---druck
Thomas Milius
druck <ne...@druck.freeuk.com> wrote:
> Chance Hooper wrote:
> > Risc OS is fundamentally tied to ARM architecture and, as such,
> > provides a better basis for an OS kernel than a port of Linux which
> > is, at best, a somewhat flaky version of a dedicated hardware-specific
> > version of Unix
> [more of the same snipped]
>
> Rubbish, RISC OS doesn't have anything that can be described as an OS
> kernel. It is a 1980s single threaded I/O layer with a nice GUI on top,
> which featured a number of features which at the time where ahead of
> their time, but now universally available elsewhere to a greater or
> lesser degree.
>
> Linux is a highly developed kernel which runs far better on ARM hardware
> than RISC OS ever has, able to take full advantage of chip features,
> including better multi-tasking, multi-threading, memory use, blocking
> I/O, interrupt latency, etc, etc. Most relevant to this discussion, it
> is fully SMP capable, and able to fully utilise as many cores as ARM
> will ever put on a chip.
>
Sorry Dave. I have a disagree in some parts. For myself the limits or
possibilities of an API are important not the things behind which can be
modified improved etc..
UNIX was always designed as a multiuser server OS. Therefore eg. blocking I/O
was handled much better from beginning on. However RISC OS is designed as a
single user desktop system and this changes some things. I didn't make
personally good experiences with X-Window on UNIX/LINUX machines. I had to
program with it during my study. My ten times slower ATARI ST with GEM runs a
graphical output ten times faster than a high end UNIX workstation under
X-Window (only an X-Window problem). Years ago I run LINUX on my RISC PC with
X-Windows. It was terribly slow compared to RISC OS on the same machine. The
first versions of the LINUX USB stack where simply a disaster and I made some
silly experiences with the general UNIX/Linux I/O concept in case of
asynchron bidirectional activities too. The file locking under LINUX (by
default there is no one, the complex and in my opinion not really nice to
handle extension allows you to lock single Bytes of a file if you like) is
still leading to problems in the company where I am employed at as the
distinction between upper and lower cases in file names is doing. In my
opinion UNIX/LINUX has its disadvantages too. Some concepts of it I am liking
some concepts I am disliking. With RISC OS it is similar.
Multi I/O is good if running lots of applications parallel (server). However
if concentrating on one preferred task which shall run faster (client) it may
be a problem. May be LINUX has improved but a simple queue to collect the I/O
requests may lead to inefficent disc head moves from view of one applications
whilst it is good from view over all applications. And it depends on the
storage type. The multi I/O is good for conventional harddiscs to minimize
the head moves but meaningless at real RAM-disc or more actual CF/SD-cards
etc. for you don't have a waiting gap here (Ok that the actual USB interfaces
of RISC OS could be much better in this point is an another thing). A clever
buffer handling minimizes the differences between the concepts anyway.
Some things have to be solved in another way under RISC OS compared to
Windows or UNIX/LINUX. But in lots of cases you have to solve them in a
different way between Windows or LINUX too. Eg. a high end RISC OS database
server (any need for it? I am in doubt.) has to be implemented in a total
different way as ag. ORACLE or DB2. If an OS doesn't provide parallel process
disc access optimization but is good for one application doing disc access
than I can implement the application in such a way that all required accesses
are contracted to one process which optimizes the access internally and is
doing disc access exclusively (and not more). It is not so nice but a
possible way. Eg. ORACLE made attempts (without much success until now AFAIR)
to bypass LINUX for the disc access for they exspected speed acceleration and
special SANs provide optimized disc access too bypassing the OS concepts.
UNIX/LINUX HTTP-Servers were so efficent because the HTTP protocol was
designed to cope with the UNIX/LINUX process concept "by pure random". In
case that a Microsoft protocol would have won in this area (fortunately not,
but in case this had happened) Microsoft based servers would have been the
much better choice "by pure random".
And you should not forgot that you are free to modify applications also and
introduce or to expand concepts. I agree with you that RISC OS has actually
deficits but I disagree that this couldn't be changed. I personally didn't
had the time I would had to spent for RISC OS this years. However one year
ago lots of people said "ARM chips are so slow it isn't worth to spent any
efforts any longer into a desktop OS for it". And now? Lots of machines are
alerting (even without RISC OS until now).
In general a better taskWindow handling on different chores would be a great
step forward for RISC OS and I don't thing that this is impossible to
realize.
Regards
Thomas Milius
Peter Naulls
No quoting, again.
Back to comp.sys.acorn.advocacy, where this really belongs.
> Wow, I never thought posting a link to that article and a few thoughts
> about how I would like to actually make a commercial project happen
> would turn into a fifty-post flame war. Whoops!
This is usenet; it was nothing to do with your post.
> Getting back to my original point, I understand that Risc OS as is
> stands has no multi-core functionality (why would it, as it ws writen
> before such things existed) and that there is some confusion as to why
> a) you'd want to run Linux as an abstraction layer for certain apps
> and, b) why you'd ever choose Risc OS as your Operating System for an
> HPC system. There was also some confusion (and mockery) as to why I
> thought this was a good idea at all.
The confusion is largely yours it seems. You've failed to respond
to _any_ of the criticisms made of your numerous "points" - there wasn't
a coherent stream of information such that we could call it a single
idea - please learn to properly quote. Your ideas, unfortunately
don't exist in a void, and trying to ignore problems will get you
nowhere (or just ignored).
[Huge snip of monologue which doesn't seem to say much]
AFAICT, all you are asserting as that RISC OS should be
run on some kind of abstraction layer (but you won't give us
any details of how this would work), even though this can
already be done ala-RPCEmu.
Eric Rucker
> AFAICT, all you are asserting as that RISC OS should be
> run on some kind of abstraction layer (but you won't give us
> any details of how this would work), even though this can
> already be done ala-RPCEmu.
I think it's worse than that - I think he's suggesting a Cygwin-like
abstraction layer to run Linux software on RISC OS.
Which, for the workloads in question, is a terrible idea.
Tim Hill
Kendrick <nn...@rjek.com> wrote:
> On Sun, 20 Sep 2009 16:39:03 +0100 Tim Hill <t...@invalid.org.uk> wrote:
> > I don't. I have tried hand-building web pages on a windoze pee sea
> > and its an effing nightmare. However, (perhaps my familiarity with)
> > StrongED, NetSurf, HTML�, WebChange, SiteMatch etc., makes it simple
> > on Myonix and the bottleneck - uploading to the web server - is the
> > same whether pee sea, RISC OS or Mac. Thanks to WebJames I can also
> > test stuff, including PHP scripts, with whichever browsers on
> > whatever machines are hooked up.
> Yes, quite right. This is entirely because of your familiarity, and no
> other reason.
You may think so. You love windows, you troll you. Other reasons below.
> (All the "Risk OS" tools you highlight have similar,
> often better, tools on other platforms.)
I have looked and tried many but haven't found the good ones and as I
already have what I need here I don't have to waste time hunting them
down, do I?
Do the windows on those other platforms jump to the top of the stack when
you click in them? Do they? What a f****** nuisance.
Do those windows jump to full screen size when I click enlarge, even
though the window's content doesn't warrant that much real estate? Do
they? What a f****** nuisance.
Do the apps on other platforms try to be all things to all men and have
menu strips, icons, writeables, blank space and other crap taking up the
top 'third' of a full size (screen size) window, masquerading as an
oversized tool pane? Do they? What a f****** nuisance.
Do those other platforms properly implement a three button mouse with
fully-featured context-sensitive menus? No. Does someone at Apple have
only three fingers on each hand?
When Acorn was boasting about the imminent release of only a slightly
faster PC with bits named after a second-rate US TV show, it made me
worry they were turning Fisher-Price. When they boasted that they had
attracted developers from the ms-windows platform to write software for
it, I awaited its release with some trepidation. It never came. In some
ways that was a blessing. I didn't have to admit to buying a yellow
machine possibly infected with windoze ideas which needed a proper
moniker. Phew.
As the late-lamented PV used to confirm, I don't have to show Myonix to a
non RISC OS user for very long before they are amazed at how much more
productive it is than what they are used to; being able as it is to work
in several windows 'simultaneously' even if they overlap: dragging stuff
from one to another in ways no other seems to be able to manage.
Many users couldn't give a toss whether it's PMT or CMT, Intel, Motorola,
Arm or leg, 8, 16, 32 or 64 bits. We want something that seems quick and
which does the job at hand. That's all. RISC OS has a certain /je ne sais
quoi/ which makes it soo much nicer to use than just about anything else.
If you can't see that but need to get bogged down in MIPS, FLOPS, or some
other technobabble, the only thing you are missing is the point.
Just because 'everyone' drinks PG Tips, it doesn't make it the best tea.
--
__ __ __ ___ __ __ ____________________________________
|\ ||_ / __|__| | / \|__) /...Revolt now. ARMs for everyone....
| \||__\__/| | | \__/| \/ Powered by rhiskk/oH.eSs
_________________________/ <tjrh.eu>
... "The elements be kind to thee, and make thy spirits all of comfort: fare thee well !" Ant & Cleo, Act iii, Sc.2
Tim Hill
> > On Thu, 24 Sep 2009 11:51:59 +0100 Chris Bass
> > <cr....@btinternet.com> wrote:
> >
> > > Correct me if I'm wrong but I get the impression that you loath
> > > RISC OS (and perhaps don't use it).
> >
> > Did you miss the bit where I thought RISC OS was fun? It's fun to
> > use, fun to mess about with developing interesting utilities, and fun
> > to play with. I'm just under no illusions about its technical merits.
> > B.
> >
> Thanks for your correction & I agree with your comment above.
RISC OS is fun _and_ sometimes more productive.
Like many others, I boot a ("quicker") pee sea and and an Iyonix at the
same time. By the time windoze has finished booting I have often dealt
with load of emails in Pluto, alarms from Organizer and other work
related stuff in Prophet. By the time windoze is capable to be used, the
first thing I do is run EndItAll and kill about 25 bits of windoze
rubbish which won't go away no matter what I use to configure what runs
at start-up (because eventually it all comes back). There are some things
I have to do on windoze: Skype (being the latest), browsing commercial
web sites, video editing and so on. The has to be done in cooperation
with essential background tasks such as backing up to NAS, running
anti-virus scans and other anti advert rubbish, not to mention the
optional stuff such as Boinc and Fix-it. Even when all these things are
paused the 'wonderful' PMT still manages to bugger-up converting CDs to
MP3s with WMP.
Neither system is perfect but when I am in user mode windoze seems less
perfect that RISC OS, often grinding to an apparent halt when a
background task isn't.
Rob Kendrick
Tim Hill <t...@invalid.org.uk> wrote:
> In article <20090920175...@trite.i.flarn.net.i.flarn.net>,
> Rob Kendrick <nn...@rjek.com> wrote:
> > On Sun, 20 Sep 2009 16:39:03 +0100 Tim Hill <t...@invalid.org.uk>
> > wrote:
>
> > > I don't. I have tried hand-building web pages on a windoze pee sea
> > > and its an effing nightmare. However, (perhaps my familiarity
> > > with) StrongED, NetSurf, HTML³, WebChange, SiteMatch etc., makes
> > > it simple on Myonix and the bottleneck - uploading to the web
> > > server - is the same whether pee sea, RISC OS or Mac. Thanks to
> > > WebJames I can also test stuff, including PHP scripts, with
> > > whichever browsers on whatever machines are hooked up.
>
> > Yes, quite right. This is entirely because of your familiarity,
> > and no other reason.
>
> You may think so. You love windows, you troll you. Other reasons
> below.
Buh? Where have I said this?
B.