Chrome OS; any implications for RISC OS users?
Jess
http://www.theregister.co.uk/2009/11/13/google_chrome_os_rumor/
It supposedly supports the ARM platform as well as x86.
Would this have any implications for RISC OS? (Apart from the obvious
attack on Microsoft's dominance.)
Would there be the possibility of more Arm hardware that could be used
for a RISC OS port?
Would there be software (browser plugins presumably) that could be
more easily/usefully ported? (If it is intended to be run on similar
hardware, rather than hardware ten times as powerful, that must help.)
Could an RPC/Iyonix/A9 port be viable? (Especially if it could be run
like a live CD)
--
Jess Iyonix
Rob Kendrick
Jess <phant...@hotmail.com> wrote:
> The Register reports that Chrome OS may be available soon.
>
> Would there be the possibility of more Arm hardware that could be
> used for a RISC OS port?
You want /more/ ARM hardware? There's an eye-wateringly large amount
of stuff out there. The reasons RISC OS doesn't run on so much of it
is a combination of being a pain to port, limited resources to do the
porting, and the utter mess of RISC OS licencing.
> Would there be software (browser plugins presumably) that could be
> more easily/usefully ported? (If it is intended to be run on similar
> hardware, rather than hardware ten times as powerful, that must help.)
Chrome OS is just Linux with a specific GUI. Exactly the same answers
apply.
B.
Robert Seago
> http://www.theregister.co.uk/2009/11/13/google_chrome_os_rumor/
I recently took a practical class where we used google/documents to produce
some word processor and spreadsheets. It is not unlike using MS Office
stuff. We had no problems with it in the limited ways we used it. Of
course by default the documents are stored out there in the cloud by
default, but you can import them to your system.
We will presumably need to use a linux kernel on existing hardware. I
reckon it would not be trivial to port some Chrome OS to an ARM device near
us.
C J Craig
Jess <phant...@hotmail.com> wrote:
> http://www.theregister.co.uk/2009/11/13/google_chrome_os_rumor/
Nokia N900 out today!
Processing power
At the heart of this mobile computer is its powerful 600 MHz processor
and up to 1GB of application memory. The superscalar ARM processor
delivers exceptional power and enables you to run all your
applications quickly, smoothly, and simultaneously.
ARM Cortex - A8 superscalar microprocessor core running at 600 MHz
Up to 1 GB of application memory (256 MB RAM, 768 MB virtual memory)
Linux-based operating system (Maemo)
3D graphics accelerator with OpenGL ES 2.0 support.
Chris
--
C J Craig
Ch...@skipton.demon.co.uk
Iyonix ARM XScale computer Risc OS 5.14
Rob Kendrick
C J Craig <Ch...@skipton.demon.co.uk> wrote:
> Up to 1 GB of application memory (256 MB RAM, 768 MB virtual memory)
What an ugly hack :) Still, I suppose it makes things easier. Also:
stab stab stab for it being referred to as virtual memory rather than
swap. (All the memory under Linux is virtual.)
B.
Jess
Rob Kendrick <nn...@rjek.com> wrote:
> On Sat, 14 Nov 2009 17:33:10 GMT
> Jess <phant...@hotmail.com> wrote:
>
>> The Register reports that Chrome OS may be available soon.
>>
>> Would there be the possibility of more Arm hardware that could be
>> used for a RISC OS port?
>
> You want /more/ ARM hardware? There's an eye-wateringly large amount
> of stuff out there. The reasons RISC OS doesn't run on so much of it
> is a combination of being a pain to port, limited resources to do the
> porting, and the utter mess of RISC OS licencing.
What about the fact that all the serious targets are relatively
obscure? Surely that reduces the odds of a port?
If there were devices that were as popular as say the EeePC (which
obviously is Google's aim) that would help a port.
>> Would there be software (browser plugins presumably) that could be
>> more easily/usefully ported? (If it is intended to be run on similar
>> hardware, rather than hardware ten times as powerful, that must help.)
> Chrome OS is just Linux with a specific GUI. Exactly the same answers
> apply.
Apart from the fact that Arm Linux is a pretty tiny platform, if
Google succeeds then it would be a pretty major platform.
--
Jess Iyonix
Rob Kendrick
Jess <phant...@hotmail.com> wrote:
> > You want /more/ ARM hardware? There's an eye-wateringly large
> > amount of stuff out there. The reasons RISC OS doesn't run on so
> > much of it is a combination of being a pain to port, limited
> > resources to do the porting, and the utter mess of RISC OS
> > licencing.
>
> What about the fact that all the serious targets are relatively
> obscure? Surely that reduces the odds of a port?
That's because the industry moves quickly; things aren't around long.
And nobody offers a "PC" style architecture for ARM anymore that's
consistent; the RiscPC was the last thing to do that.
> If there were devices that were as popular as say the EeePC (which
> obviously is Google's aim) that would help a port.
>
> >> Would there be software (browser plugins presumably) that could be
> >> more easily/usefully ported? (If it is intended to be run on
> >> similar hardware, rather than hardware ten times as powerful, that
> >> must help.)
>
> > Chrome OS is just Linux with a specific GUI. Exactly the same
> > answers apply.
>
> Apart from the fact that Arm Linux is a pretty tiny platform, if
> Google succeeds then it would be a pretty major platform.
I don't doubt more machines run ARM Linux than run x86 Linux. x86
Linux is limited to servers the niche market of desktops for
enthusiasts. My hi fi stack has three things that run ARM Linux. My
mobile phone runs ARM Linux. My car's satnav runs ARM Linux. My
off-the-shelf router runs ARM Linux. My webcam runs ARM Linux. The
office's access control system runs ARM Linux in each keypad and
swipecard reader. Etc etc etc. I wouldn't be surprised if somebody's
washing machine ran ARM Linux.
ARM Linux is not a tiny platform.
B.
Eric Rucker
> That's because the industry moves quickly; things aren't around long.
> And nobody offers a "PC" style architecture for ARM anymore that's
> consistent; the RiscPC was the last thing to do that.
Genesi claims they're working on a firmware interface that will
include all platform drivers and a common interface, so OS HALs can
target that interface, and run on all of their ARM-based hardware,
with full driver support.
Of course, anybody can claim anything.
I also wonder how practical OpenFirmware would be, and how much it
could do for us. I think it's rather limited, though, and only really
useful to bring up the OS.
I have noticed that a lot of server platforms are going to a
virtualization layer, that helps abstract the details of the hardware
into the hypervisor, so the OS doesn't need to understand them.
> I don't doubt more machines run ARM Linux than run x86 Linux. x86
> Linux is limited to servers the niche market of desktops for
> enthusiasts. My hi fi stack has three things that run ARM Linux. My
> mobile phone runs ARM Linux. My car's satnav runs ARM Linux. My
> off-the-shelf router runs ARM Linux. My webcam runs ARM Linux. The
> office's access control system runs ARM Linux in each keypad and
> swipecard reader. Etc etc etc. I wouldn't be surprised if somebody's
> washing machine ran ARM Linux.
>
> ARM Linux is not a tiny platform.
However, ARM Linux on the desktop IS a tiny platform. Probably not
much bigger than RISC OS (and made almost entirely of BeagleBoards.)
For that matter, ARM Linux in an environment where it's meant to run
general Linux binaries is a tiny platform. Other than Nokia Maemo
devices, and the aforementioned BeagleBoards... not much out there.
WebOS and Android both run application formats that are unique to them.
Michael Gerbracht
Rob Kendrick <nn...@rjek.com> wrote:
> On Sat, 14 Nov 2009 17:33:10 GMT
> Jess <phant...@hotmail.com> wrote:
> > The Register reports that Chrome OS may be available soon.
> >
> > Would there be the possibility of more Arm hardware that could be
> > used for a RISC OS port?
> You want /more/ ARM hardware? There's an eye-wateringly large amount
> of stuff out there.
Yes, but not a single ARM Netbook that is widely available. Of course there
are a lot of anouncements but not much more.
Porting RISC OS to it is of course a diffenrent question...
Michael
--
Please replace "nospam" by "m.gerbracht" when replying by mail
Rob Kendrick
Eric Rucker <bhto...@gmail.com> wrote:
> > ARM Linux is not a tiny platform.
>
> However, ARM Linux on the desktop IS a tiny platform. Probably not
> much bigger than RISC OS (and made almost entirely of BeagleBoards.)
And a few tens of thousands of dumb terminals and netbooks.
> For that matter, ARM Linux in an environment where it's meant to run
> general Linux binaries is a tiny platform. Other than Nokia Maemo
> devices, and the aforementioned BeagleBoards... not much out there.
> WebOS and Android both run application formats that are unique to
> them.
Although running Android applications under normal Linux on a desktop
machine is easy.
B.
jess
> On Sat, 14 Nov 2009 19:08:25 GMT
> That's because the industry moves quickly; things aren't around long.
> And nobody offers a "PC" style architecture for ARM anymore that's
> consistent; the RiscPC was the last thing to do that.
Yes, and if Chrome OS were to go mainstream, then this would improve
the odds of a consistent architecture.
e.g. if Chrome OS were a success and was ported to the Genesi Efika
and that sold in big volumes as a result.
> ARM Linux is not a tiny platform.
But Arm Linux in a context relevant to us is.
Rob Kendrick
jess <jessha...@googlemail.com> wrote:
> On Nov 14, 9:19 pm, Rob Kendrick <n...@rjek.com> wrote:
> > On Sat, 14 Nov 2009 19:08:25 GMT
>
> > That's because the industry moves quickly; things aren't around
> > long. And nobody offers a "PC" style architecture for ARM anymore
> > that's consistent; the RiscPC was the last thing to do that.
>
> Yes, and if Chrome OS were to go mainstream, then this would improve
> the odds of a consistent architecture.
And you base that assertion on what, precisely? There's no benefit
what so ever to hardware manufacturers to do this. Porting Linux to a
new platform is significantly easier than remaining within the
constraints of a common hardware architecture that may no longer do
what you want. Plus, all the silicon vendors want to sell their own
stuff.
> > ARM Linux is not a tiny platform.
>
> But Arm Linux in a context relevant to us is.
What context is that? Hundreds of thousands of desktop ARM systems are
already sold using Linux, not to mention many more mobile phones and
PDA-type devices.
Which is precisely why RISC OS will never see a market in these areas:
there's already something infinitely cheaper and much more capable
available, with the added bonus that it most likely already works on
the hardware you want to use.
B.
jess
> On Sun, 15 Nov 2009 07:49:13 -0800 (PST)
> jess <jesshampsh...@googlemail.com> wrote:
> > Yes, and if Chrome OS were to go mainstream, then this would improve
> > the odds of a consistent architecture.
> And you base that assertion on what, precisely? There's no benefit
> what so ever to hardware manufacturers to do this. Porting Linux to a
> new platform is significantly easier than remaining within the
> constraints of a common hardware architecture that may no longer do
> what you want. Plus, all the silicon vendors want to sell their own
> stuff.
So you think that every manufacturer will want an individual
architecture and linux for each of their ranges of computers?
Artificially limiting your product?
That would mean a separate version to keep up to date. It would also
mean any alternative system would have to be specifically built for
that system.
Standards evolve, either by co-ordinated effort or convergegence.
A system that can run an off the shelf OS is more valuble than one
that can't. How will arm break the dominance of x86 without this
potential?
> > > ARM Linux is not a tiny platform.
> > But Arm Linux in a context relevant to us is.
> What context is that? Hundreds of thousands of desktop ARM systems are
> already sold using Linux,
It would be hard to describe RISC OS at its peak as anything but a
small platform, and it was bigger than that. Also how many different
systems are there? The problem with Linux is that there are a
multitude of systems.
> not to mention many more mobile phones and PDA-type devices.
Since mobile phones and PDAs aren't really very relevant to us are
they?
> Which is precisely why RISC OS will never see a market in these areas:
> there's already something infinitely cheaper and much more capable
> available, with the added bonus that it most likely already works on
> the hardware you want to use.
In the current situation, Chrome OS might change that.
Chrome OS is presumably just a browser on top of the OS (much like the
Bush internet TV was, but with the difference that IE only websites
are fast becoming a thing of the past and likelyhood of decent plugin
support.)
If this goes mainstream, and a fair proportion of the devices are
hardware compatible (either a dominant model or a converged platform)
and dual booting is not a major issue, then there will be a place for
alternate systems.
RISC OS will not suffer the normal disadvantages (being crap on the
web and not being able to edit certain documents) being a show
stopper, because the units would already do that with chrome.
For RISC OS to be a commercial success, in the way ROL would have
hoped when it was formed, there would have to be huge amounts of the
machines, but to be a viable free alternative there wouldn't have to
be anything like as many.
Rob Kendrick
jess <jessha...@googlemail.com> wrote:
> > > Yes, and if Chrome OS were to go mainstream, then this would
> > > improve the odds of a consistent architecture.
>
> > And you base that assertion on what, precisely? There's no benefit
> > what so ever to hardware manufacturers to do this. Porting Linux
> > to a new platform is significantly easier than remaining within the
> > constraints of a common hardware architecture that may no longer do
> > what you want. Plus, all the silicon vendors want to sell their own
> > stuff.
>
> So you think that every manufacturer will want an individual
> architecture and linux for each of their ranges of computers?
The whole point of an operating system is to abstract the software from
the hardware. The kernel is just one component.
> Artificially limiting your product?
Sure; you wouldn't want a new machine based on the RiscPC architecture,
would you? What with its slow memory and IO, inability to do 16 bit
memory accesses, and other horrors?
> That would mean a separate version to keep up to date. It would also
> mean any alternative system would have to be specifically built for
> that system.
A separate version of Linux, perhaps. But then Linux already runs on
thousands of different pieces of hardware, and it all works. It really
isn't a problem.
> A system that can run an off the shelf OS is more valuble than one
> that can't.
Why? Most people don't care, they just want to get something done.
And ARM-based kit can be so cheap, if you want to upgrade your OS, you
get to upgrade your hardware, too.
> > > > ARM Linux is not a tiny platform.
>
> > > But Arm Linux in a context relevant to us is.
>
> > What context is that? Hundreds of thousands of desktop ARM systems
> > are already sold using Linux,
>
> It would be hard to describe RISC OS at its peak as anything but a
> small platform, and it was bigger than that. Also how many different
> systems are there? The problem with Linux is that there are a
> multitude of systems.
If you don't mean Linux, don't use the word Linux. I don't doubt there
are more things out there with "computer-like" user interfaces running
Linux as their kernel than have ever run RISC OS.
> > not to mention many more mobile phones and PDA-type devices.
>
> Since mobile phones and PDAs aren't really very relevant to us are
> they?
Except when people, such as yourself, go "oh, wouldn't RISC OS be great
on a PDA!"
> > Which is precisely why RISC OS will never see a market in these
> > areas: there's already something infinitely cheaper and much more
> > capable available, with the added bonus that it most likely already
> > works on the hardware you want to use.
>
> In the current situation, Chrome OS might change that.
What, Chrome OS might make people want to pay for RISC OS? Buh?
> Chrome OS is presumably just a browser on top of the OS (much like the
> Bush internet TV was, but with the difference that IE only websites
> are fast becoming a thing of the past and likelyhood of decent plugin
> support.)
One assumes it's a bit more than that, because that sort of thing
already exists.
> If this goes mainstream, and a fair proportion of the devices are
> hardware compatible (either a dominant model or a converged platform)
> and dual booting is not a major issue, then there will be a place for
> alternate systems.
I doubt there will be a converged platform at all. And I have no idea
what "dominant model" might mean. It's just not how ARM systems work.
Even contiguously-numbered models of ARM SoC from the same manufacturer
often can't run the same kernel.
> RISC OS will not suffer the normal disadvantages (being crap on the
> web and not being able to edit certain documents) being a show
> stopper, because the units would already do that with chrome.
So, err, why would you want to run RISC OS on them? I'm yet to work
this out: why would anybody who doesn't already use and like RISC OS
want to get involved in it? It doesn't really have any unique selling
point beyond its GUI, which has languished over the past 15 years for
not moving on. And almost all this hardware we're talking about, at
least in portable form, will hatefully not come with a middle mouse
button. :)
B.
jess
> On Mon, 16 Nov 2009 01:44:52 -0800 (PST)
> jess <jesshampsh...@googlemail.com> wrote:
> > So you think that every manufacturer will want an individual
> > architecture and linux for each of their ranges of computers?
> The whole point of an operating system is to abstract the software from
> the hardware. The kernel is just one component.
And that means that each combination of hardware has to be
specifically supported by each OS to use it.
> > Artificially limiting your product?
> Sure; you wouldn't want a new machine based on the RiscPC architecture,
> would you? What with its slow memory and IO, inability to do 16 bit
> memory accesses, and other horrors?
So in the PC world, things are still the same as 20 years ago? If RISC
OS had been successful, things would have been different. And RISC OS
was hardly the paragon of hardware independance anyway.
> > That would mean a separate version to keep up to date. It would also
> > mean any alternative system would have to be specifically built for
> > that system.
> A separate version of Linux, perhaps. But then Linux already runs on
> thousands of different pieces of hardware, and it all works. It really
> isn't a problem.
Thousands of pieces of kit that already exist. If you are effectively
starting a new platform why would you do it the same, it's not as if
netbooks can run any external hardware apart from USB.
And if your hardware isn't supported by the OS, it's only not a
problem if you can compile your own version. I suspect people who can
compile an OS are outnumbered hundreds to one by those who can install
one.
> > A system that can run an off the shelf OS is more valuble than one
> > that can't.
> Why? Most people don't care, they just want to get something done.
> And ARM-based kit can be so cheap, if you want to upgrade your OS, you
> get to upgrade your hardware, too.
Not very green, and if I have a netbook that has a good case, keyboard
and screen, would I want to buy it all again?
> > > What context is that? Hundreds of thousands of desktop ARM systems
> > > are already sold using Linux,
> > It would be hard to describe RISC OS at its peak as anything but a
> > small platform, and it was bigger than that. Also how many different
> > systems are there? The problem with Linux is that there are a
> > multitude of systems.
> If you don't mean Linux, don't use the word Linux. I don't doubt there
> are more things out there with "computer-like" user interfaces running
> Linux as their kernel than have ever run RISC OS.
But I would doubt that if you were to limit that to desktop systems
that would be viable RISC OS targets.
> > > not to mention many more mobile phones and PDA-type devices.
> > Since mobile phones and PDAs aren't really very relevant to us are
> > they?
> Except when people, such as yourself, go "oh, wouldn't RISC OS be great
> on a PDA!"
But that was when there was no distinction between a PDA and a
netbook.
RISC OS on a netbook style device would be fine. On a small tablet
device, it might be a bit of fun, but it would hardly be productive
and the only worth thinking about if no more suitable devices exist,
which they do now.
> > In the current situation, Chrome OS might change that.
> What, Chrome OS might make people want to pay for RISC OS? Buh?
Not directly, but if there are a load of machines able to run a free
version of RISC OS, some might want to buy an enhanced version. People
paid for Vista.
> > Chrome OS is presumably just a browser on top of the OS (much like the
> > Bush internet TV was, but with the difference that IE only websites
> > are fast becoming a thing of the past and likelyhood of decent plugin
> > support.)
> One assumes it's a bit more than that, because that sort of thing
> already exists.
But not backed by Google. And things that are more than that based on
a *nix (style) core already exist too.
> > If this goes mainstream, and a fair proportion of the devices are
> > hardware compatible (either a dominant model or a converged platform)
> > and dual booting is not a major issue, then there will be a place for
> > alternate systems.
> I doubt there will be a converged platform at all. And I have no idea
> what "dominant model" might mean. It's just not how ARM systems work.
The one with biggest market share.
> Even contiguously-numbered models of ARM SoC from the same manufacturer
> often can't run the same kernel.
Well if it proved to be the case that Chrome OS resulted millions of
devices with hundreds of specific versions then that would be a
negative effect on all other OSes. (Although if Chrome OS were ported
to Risc PCs and Iyonixes, it would reduce the need to keep a PC as a
second system.)
> > RISC OS will not suffer the normal disadvantages (being crap on the
> > web and not being able to edit certain documents) being a show
> > stopper, because the units would already do that with chrome.
>
> So, err, why would you want to run RISC OS on them? I'm yet to work
> this out: why would anybody who doesn't already use and like RISC OS
> want to get involved in it? It doesn't really have any unique selling
> point beyond its GUI, which has languished over the past 15 years for
There are a couple of others, the built in vector format, the use of
lots of little programs to do a job rather than one monolithic one,
possibly even the inclusion of a simple programming language.
Anyway the GUI is the major thing, it could be made a bit slicker, but
in general it is the best thought out system I've seen.
If Chrome OS is just a browser platform, then you would want something
to turn it into a dsektop computer system. That could be Ubuntu or
Linux mint, but it could also be RISC OS.
> not moving on. And almost all this hardware we're talking about, at
> least in portable form, will hatefully not come with a middle mouse
> button. :)
Perhaps you'd have to press both buttons at once to get menu (or as
I'd prefer to get adjust).
Rob Kendrick
jess <jessha...@googlemail.com> wrote:
> > The whole point of an operating system is to abstract the software
> > from the hardware. The kernel is just one component.
>
> And that means that each combination of hardware has to be
> specifically supported by each OS to use it.
Yes. Name an OS and hardware combination where this isn't true. I can
think of one (OpenFirmware), but the performance of using that system
is so dreadful nobody uses it for anything beyond booting.
> > Sure; you wouldn't want a new machine based on the RiscPC
> > architecture, would you? What with its slow memory and IO,
> > inability to do 16 bit memory accesses, and other horrors?
>
> So in the PC world, things are still the same as 20 years ago? If RISC
> OS had been successful, things would have been different. And RISC OS
> was hardly the paragon of hardware independance anyway.
The number of hacks in PC hardware for supporting old stuff is
astonishing. Google the A20 gate if you want your eyes to bleed.
Additionally, all this hideousness is emulated and enclosed in custom
chips and the CPU to do all this; which is fine due to their enormous
bulk of manufacture. You don't want to have to do all that stuff in
something designed to be cheap and needs to adjust to changing fashions.
> > A separate version of Linux, perhaps. But then Linux already runs
> > on thousands of different pieces of hardware, and it all works. It
> > really isn't a problem.
>
> Thousands of pieces of kit that already exist. If you are effectively
> starting a new platform why would you do it the same, it's not as if
> netbooks can run any external hardware apart from USB.
Because the hardware inside changes constantly. A CPU company might
only offer a specific model of SoC for 6 months. After that,
everything changes again. For example, the difference between the
S3C2440 and the S3C2450 (A9 Home and that Ubisurfer respectively) is
enough to require thousands of lines of additional code to support both.
The same is true of many of TI's offerings: most OMAPs are custom-built
for a specific customer, and then sold on the general market later,
without the documentation for some of the special bits. It's the way
the industry works.
> And if your hardware isn't supported by the OS, it's only not a
> problem if you can compile your own version. I suspect people who can
> compile an OS are outnumbered hundreds to one by those who can install
> one.
Sorry, I don't see the relevance. Most devices come with the OS
already installed and with an upgrade system built-in.
> > > A system that can run an off the shelf OS is more valuble than one
> > > that can't.
>
> > Why? Most people don't care, they just want to get something done.
> > And ARM-based kit can be so cheap, if you want to upgrade your OS,
> > you get to upgrade your hardware, too.
>
> Not very green, and if I have a netbook that has a good case, keyboard
> and screen, would I want to buy it all again?
To get something better? Cheaper to run? More suited to your
ever-changing needs? It has to be said, my mobile phone has had
perhaps a dozen upgrades to its Linux-based OS since I bought it, and
upgrading is a matter of clicking a button and leaving it to think
about it for 10 minutes.
> > If you don't mean Linux, don't use the word Linux. I don't doubt
> > there are more things out there with "computer-like" user
> > interfaces running Linux as their kernel than have ever run RISC OS.
>
> But I would doubt that if you were to limit that to desktop systems
> that would be viable RISC OS targets.
That's because there are no viable RISC OS targets, because RISC OS
isn't viable, for reasons discussed earlier.
> > > In the current situation, Chrome OS might change that.
>
> > What, Chrome OS might make people want to pay for RISC OS? Buh?
>
> Not directly, but if there are a load of machines able to run a free
> version of RISC OS, some might want to buy an enhanced version. People
> paid for Vista.
And Vista did what some people wanted. If you think the majority of
people out there would be at all satisfied with RISC OS, you're
completely mad. Other than the lack of complete browser with Flash,
instant messaging and Skype-style applications, in order to do anything
else you might want to use a computer for (word processing, graphic
design, etc) you have to pay still more money.
And say you had a port of Open Office and Inkscape; why would you want
to run them under RISC OS when they'd be so much faster and more
capable under Linux, even on the same hardware?
> > > Chrome OS is presumably just a browser on top of the OS (much
> > > like the Bush internet TV was, but with the difference that IE
> > > only websites are fast becoming a thing of the past and
> > > likelyhood of decent plugin support.)
>
> > One assumes it's a bit more than that, because that sort of thing
> > already exists.
>
> But not backed by Google. And things that are more than that based on
> a *nix (style) core already exist too.
Again, an ARM-based system having a Flash plugin does nothing for RISC
OS having one.
> > > If this goes mainstream, and a fair proportion of the devices are
> > > hardware compatible (either a dominant model or a converged
> > > platform) and dual booting is not a major issue, then there will
> > > be a place for alternate systems.
>
> > I doubt there will be a converged platform at all. And I have no
> > idea what "dominant model" might mean. It's just not how ARM
> > systems work.
>
> The one with biggest market share.
At the moment, I suspect that'd be the Qualcomm CPU used in most HTC
handsets. Other than that, they're all pretty thinly spread, as ARM
systems go. There are hundreds of ARM core licencees, each with
dozens, if not hundreds of products, all of which are incompatible.
> > Even contiguously-numbered models of ARM SoC from the same
> > manufacturer often can't run the same kernel.
>
> Well if it proved to be the case that Chrome OS resulted millions of
> devices with hundreds of specific versions then that would be a
> negative effect on all other OSes.
Firstly, that *is* the case. Secondly, the only thing that need be
different is the kernel, not the rest of the OS. Android, for example,
already supports half a dozen platforms with broadly identical user
land. Debian supports hundreds of ARM systems with exactly the same OS
components beyond the kernel.
> (Although if Chrome OS were ported
> to Risc PCs and Iyonixes, it would reduce the need to keep a PC as a
> second system.)
Why? Incidentally, a RiscPC is far too slow for this.
> > > RISC OS will not suffer the normal disadvantages (being crap on
> > > the web and not being able to edit certain documents) being a show
> > > stopper, because the units would already do that with chrome.
> >
> > So, err, why would you want to run RISC OS on them? I'm yet to work
> > this out: why would anybody who doesn't already use and like RISC OS
> > want to get involved in it? It doesn't really have any unique
> > selling point beyond its GUI, which has languished over the past 15
> > years for
>
> There are a couple of others, the built in vector format, the use of
> lots of little programs to do a job rather than one monolithic one,
> possibly even the inclusion of a simple programming language.
Under Linux, you have SVG. The entire UNIX philosophy for writing
software is do one thing and do it well, so you have lots of little
programs to do a specific job *as well as* monolithic ones. And a
standard Linux distribution perhaps comes with a dozen languages
already built-in. Christ, my mobile phone has Lua, Python and Ruby on
it. And if you're really sick, you can install a BBC Basic interpreter.
> Anyway the GUI is the major thing, it could be made a bit slicker, but
> in general it is the best thought out system I've seen.
A bit slicker? Try a lot slicker. So many utilities exist to bodge
functionality on top of it that people missed from other systems, or it
was lacking.
> If Chrome OS is just a browser platform, then you would want something
> to turn it into a dsektop computer system. That could be Ubuntu or
> Linux mint, but it could also be RISC OS.
The whole point of Chrome OS is that it is not a traditional desktop
system. Trying to turn it into one is missing the point. And even if
you did want to do this, you'd want something that was compatible,
could mount its file systems, could open documents from it, and such.
That is not RISC OS.
And why people use Linux Mint is beyond me; it appears to be Ubuntu,
except with the package manager replaced with something broken.
> > not moving on. And almost all this hardware we're talking about, at
> > least in portable form, will hatefully not come with a middle mouse
> > button. :)
>
> Perhaps you'd have to press both buttons at once to get menu (or as
> I'd prefer to get adjust).
That's what you'd have to do, and it's horrible. One of the many
reasons I bought a Thinkpad: Real middle mouse button!
B.
Torben Ægidius Mogensen
> The Register reports that Chrome OS may be available soon.
>
> http://www.theregister.co.uk/2009/11/13/google_chrome_os_rumor/
>
> It supposedly supports the ARM platform as well as x86.
>
> Would this have any implications for RISC OS? (Apart from the obvious
> attack on Microsoft's dominance.)
>
> Would there be the possibility of more Arm hardware that could be used
> for a RISC OS port?
Not anymore than the multitude of ARM platforms already out there.
The only way in which it could help RISC OS ports is if you can build
RISC OS on top of the kernel and drivers used in Google OS. Since
Google OS is just a Linux variant, I can't see this as any different
from doing the same with, say, Android or ARM-Ubuntu.
I can really only see a long-term future for RISC OS if it is made to
run on top of another (more popular) OS, so you can share drivers with
the other OS or, at the very least, rewritten so it can share drivers
even when using its own kernel. In a sense, that is what made Virtual
RISC PC and similar products possible: You use the drivers in the
underlying OS so you don't have to write specific drivers for all the
myriad different hardware combinations around.
Torben
trevj
[snipped]
> Would this have any implications for RISC OS? (Apart from the obvious
> attack on Microsoft's dominance.)
[snipped]
Accelerating departure from traditional desktop environment - could
affect all consumer-targeted OSes, including RISC OS.
Ray Dawson
>
> Thousands of pieces of kit that already exist. If you are effectively
> starting a new platform why would you do it the same, it's not as if
> netbooks can run any external hardware apart from USB.
But most external hardware is accessed by USB anyway. My desktop PC has
about 6 USB leads sprouting from it and going to printers, external hard
drives, scanner, camera etc. My Acer netbook has 3 hi speed USB sockets,
which allows it to connect to anything the desktop can. It can also connect
to my TV via the VGA output so that I can play videos from iPlayer from it.
My Risc PC, with a slow USB and limited devices which it would connect to,
is a very different story.
Cheers,
Ray D
Rob Kendrick
tor...@pc-003.diku.dk (Torben Ægidius Mogensen) wrote:
> I can really only see a long-term future for RISC OS if it is made to
> run on top of another (more popular) OS, so you can share drivers with
> the other OS or, at the very least, rewritten so it can share drivers
> even when using its own kernel.
This is called RPCemu :)
B.
Dave Symes
> B.
Networking please! ;-)
Dave
--
Dave Triffid
Rob Kendrick
> Networking please! ;-)
Last time I checked, it worked fine.
B.
Dave Symes
Rob Kendrick <nn...@rjek.com> wrote:
> On Mon, 16 Nov 2009 18:50:54 +0000 (GMT)
> Dave Symes <da...@triffid.co.uk> wrote:
> > In article <20091116140...@trite.i.flarn.net.i.flarn.net>,
> > Rob Kendrick <nn...@rjek.com> wrote:
[Snip]
> >
> > > This is called RPCemu :)
> >
> > Networking please! ;-)
> Last time I checked, it worked fine.
> B.
Really!
There is no networking with the Win PC version of RPCEmu.
Dave
--
Dave Triffid
Rob Kendrick
Dave Symes <da...@triffid.co.uk> wrote:
> In article <20091116191...@trite.i.flarn.net.i.flarn.net>,
> Rob Kendrick <nn...@rjek.com> wrote:
> > On Mon, 16 Nov 2009 18:50:54 +0000 (GMT)
> > Dave Symes <da...@triffid.co.uk> wrote:
>
> > > In article
> > > <20091116140...@trite.i.flarn.net.i.flarn.net>, Rob
> > > Kendrick <nn...@rjek.com> wrote:
>
> [Snip]
>
> > >
> > > > This is called RPCemu :)
> > >
> > > Networking please! ;-)
>
> > Last time I checked, it worked fine.
>
> Really!
> There is no networking with the Win PC version of RPCEmu.
Oh, it works fine in Linux, which was the subject of the discussion.
Sorry.
B.
Torben Ægidius Mogensen
I did mention Virtual RPC, which is similar. The advantage of using
ARM-based hardware is that instruction emulation is much simpler.
Torben
Rob Kendrick
tor...@pc-003.diku.dk (Torben Ægidius Mogensen) wrote:
> I did mention Virtual RPC, which is similar. The advantage of using
> ARM-based hardware is that instruction emulation is much simpler.
Right up until you get userland code doing things like calling
OS_EnterOS.
Additionally, using an emulator opens the door for JITing old FPA10
instructions into modern VFP or NEON instructions.
B.
Dave Symes
> In article <20091116191...@trite.i.flarn.net.i.flarn.net>,
> Rob Kendrick <nn...@rjek.com> wrote:
[Snip]
> Last time I checked, it worked fine.
> B.
Unfortunately, after I'd installed RPCEmu on Ubuntu, I looked at the
Networking stuff, non of it made much sense, so I abandoned any thoughts
of that for the time being.
Work, work, no bleeding peace when you work out of an office at home...
Maybe in a few years when I'm really old with nothing better to do than
dribble down my shirt, I might find the time to work it out. ;-)
Dave
--
Dave Triffid
Rob Kendrick
Dave Symes <da...@triffid.co.uk> wrote:
> On 16 Nov, da...@triffid.co.uk wrote:
> > In article <20091116191...@trite.i.flarn.net.i.flarn.net>,
> > Rob Kendrick <nn...@rjek.com> wrote:
>
> [Snip]
>
> > Last time I checked, it worked fine.
> Unfortunately, after I'd installed RPCEmu on Ubuntu, I looked at the
> Networking stuff, non of it made much sense, so I abandoned any
> thoughts of that for the time being.
Try putting the following into a file called "runrpcemu" in the same
directory as the rpcemu binary:
---8<---
#!/bin/bash
echo "1" >/proc/sys/net/ipv4/ip_forward
echo "1" >/proc/sys/net/ipv4/ip_dynaddr
iptables -t nat -F POSTROUTING
iptables -t nat -A POSTROUTING --source 172.31.0.0/16 -o eth0 -j
MASQUERADE
exec ./rpcemu
--->8---
Then, "chmod +x runrpcemu". You may need to change the "eth0" bit,
depending on how your networking is set up.
Then, run from the terminal with "sudo ./runrpcemu".
B.
Dave Symes
> ---8<---
> #!/bin/bash
> exec ./rpcemu
> --->8---
> B.
Thanks, I'll give that a try.
**A bit later**
Copied and pasted the lines, so they are exactly as you've written.
It reports...
iptables v1.4.4: option '-j' requires an argument
try 'iptables -h' or 'iptables --help for more information.
./runrpcemu: line 7 MASQUERADE command not found.
With regard to "eth0" that's what it is on the Ubuntu install, I've left
it at the default whatever, when 9.10 was installed...
I really have no idea...
Dave
--
Dave Triffid
Rob Kendrick
Dave Symes <da...@triffid.co.uk> wrote:
> iptables v1.4.4: option '-j' requires an argument
> try 'iptables -h' or 'iptables --help for more information.
>
> ./runrpcemu: line 7 MASQUERADE command not found.
Whoops; wordwrap snaufu. MASQUERADE should appear after -j on the same
line, and not on a line of its own. Sorry about that.
B.
Ollie Clark
> In article <20091119003...@trite.i.flarn.net.i.flarn.net>,
> Rob Kendrick <nn...@rjek.com> wrote:
>> ---8<---
>
>> #!/bin/bash
>
>> echo "1" >/proc/sys/net/ipv4/ip_forward
>> echo "1" >/proc/sys/net/ipv4/ip_dynaddr
>> iptables -t nat -F POSTROUTING
>> iptables -t nat -A POSTROUTING --source 172.31.0.0/16 -o eth0 -j
>> MASQUERADE
>
>> exec ./rpcemu
>
>> --->8---
>
>
> It reports...
>
> iptables v1.4.4: option '-j' requires an argument
> try 'iptables -h' or 'iptables --help for more information.
>
> ./runrpcemu: line 7 MASQUERADE command not found.
Hi Dave,
Rob's explained what the issue was but it would perhaps be instructive
to explain what the error messages mean.
The first one:
iptables v1.4.4: option '-j' requires an argument
So it must be refering to one of the iptables lines. The only one of
those with a -j is:
iptables -t nat -A POSTROUTING --source 172.31.0.0/16 -o eth0 -j
And you can see that -j has nothing after it (ie. it has no argument)
So that explains the first error message but doesn't help with what
you /should/ put after the -j. However, the second error message:
./runrpcemu: line 7 MASQUERADE command not found.
gives you a bit of a clue. It's right after the line that caused the
first error. It's telling you that MASQUERADE isn't a recognised as a
command.
So you've got a missing argument at the end of one line and an
unrecognised command at the start of the next line. A bit of a leap of
logic tells you that the line probably got wrapped and needs to be put
back together. :-)
Hope that's useful.
Cheers,
Ollie
Dave Symes
Ollie Clark <use...@ollieclark.com> wrote:
[Snip]
> So you've got a missing argument at the end of one line and an
> unrecognised command at the start of the next line. A bit of a leap of
> logic tells you that the line probably got wrapped and needs to be put
> back together. :-)
> Hope that's useful.
> Cheers,
> Ollie
Thanks for the detail Olly, once explained I understand...
Cheers
Dave
--
Dave Triffid
Dave Symes
> B.
Excellent, I'll give that a go later when work paperwork out of the way...
I should be doing that now, but needed a break from it.
Thanks
Dave
--
Dave Triffid
Brian Carroll
<da...@triffid.co.uk> wrote:
[Snip]
> Maybe in a few years when I'm really old with nothing better
> to do than dribble down my shirt, I might find the time to
> work it out. ;-)
You won't be able to then. I dribble all the time and look how
long it took me to sort out my problem with !BootSetup :-(
Brian.
--
______________________________________________________________
Brian Carroll, Ripon, N Yorks, UK briancarroll at f2s dot com
______________________________________________________________
Dave Symes
> > B.
> Thanks
> Dave
Yes that sorted that bit, but what follows after..
"chmod +x runrpcemu" That seems to work, though I doubt I'd know if it
didn't.
...is not doing the biz.
sudo ./runrpcemu
A RPCEmu window flashes on screen for half a second then vanishes (Always).
Dave
--
Dave Triffid
druck
> it's not as if netbooks can run any external hardware apart from USB.
You mean apart from the million and one USB devices?
You practically don't need anything else for a consumer machines, stuff
which required PCI cards few years back such as video digitisers, and
external hard drives can be done with easy by USB2. Plus 10x faster USB3
is on the way.
Just because we don't have USB drivers for more than a 2 or 3 of non HCI
devices, doesn't mean they don't exist.
---druck
Rob Kendrick
Dave Symes <da...@triffid.co.uk> wrote:
> sudo ./runrpcemu
>
> A RPCEmu window flashes on screen for half a second then vanishes
> (Always).
Sorry, I don't know. It works for me. Your next port of call is the
RPCemu mailing list.
B.
Jess
druck <ne...@druck.org.uk> wrote:
But it's very rare for USB devices to be part of the core machine.
With Desktop PCs for example you could one of a multitude of graphics
cards.
--
Jess Iyonix
Rob Kendrick
Jess <phant...@hotmail.com> wrote:
> But it's very rare for USB devices to be part of the core machine.
No? Think again. It's very common for trackpads, fingerprint readers,
and bluetooth to be attached via USB in laptops. My netbook's wireless
is even attached by USB. (USB implementations of these are cheap,
small, readily available, and can be wired up using a narrow serial bus
rather than a traditional wide parallel bus, making things cheaper to
make.)
I personally use a USB sound card with my laptop and netbook, because
the on-board sound is so dire. As well as a USB->Serial converter when
working.
B.
Chris Hughes
Jess <phant...@hotmail.com> wrote:
> In message <he4g16$8ca$1...@news.eternal-september.org>
> druck <ne...@druck.org.uk> wrote:
>> jess wrote:
>>> it's not as if netbooks can run any external hardware apart from USB.
>>
>> You mean apart from the million and one USB devices?
>>
>> You practically don't need anything else for a consumer machines, stuff
>> which required PCI cards few years back such as video digitisers, and
>> external hard drives can be done with easy by USB2. Plus 10x faster USB3
>> is on the way.
>>
>> Just because we don't have USB drivers for more than a 2 or 3 of non HCI
>> devices, doesn't mean they don't exist.
> But it's very rare for USB devices to be part of the core machine.
If I understand your comment correctly, then you would be wrong.
> With Desktop PCs for example you could one of a multitude of graphics
> cards.
And many don't need extra graphics cards since they have built in
graphics cards.
--
Chris Hughes
Jess
Chris Hughes <ne...@noonehere.co.uk> wrote:
> If I understand your comment correctly, then you would be wrong.
Obviously I've been looking at the wrong machines then, but the
argument has somewhat diverged from the question of whether it would
be good for a new platform to require a different version of the OS
for each different device. Especially, when it's a low end platform.
External USB is irrelevant (in this case), beyond a few generic
devices.
The point I was attempting to make is that things soldered to the main
board will not be subject to as much change as things that are plugged
in.
Therefore keeping to one or a few standard designs makes sense. (As
happened with the early IBM PC clones.)
--
Jess Iyonix
Rob Kendrick
Jess <phant...@hotmail.com> wrote:
> In message <7b46b7bd...@o2.co.uk>
> Chris Hughes <ne...@noonehere.co.uk> wrote:
>
> > If I understand your comment correctly, then you would be wrong.
>
> Obviously I've been looking at the wrong machines then, but the
> argument has somewhat diverged from the question of whether it would
> be good for a new platform to require a different version of the OS
> for each different device. Especially, when it's a low end platform.
It will require a different /kernel/ for each device. Not the entire
OS and environment, which can be shared.
> External USB is irrelevant (in this case), beyond a few generic
> devices.
Devices that are limited to a few generic devices are annoying. For
example, I have a WD TV, a cute little box that runs Linux that plays
media of a USB-attached mass storage device. Why can't it support
fetching the media over USB ethernet or wifi? Or even 3G? Linux
supports all of these. (I've since installed a third-party firmware
that does this, and it's great.)
> The point I was attempting to make is that things soldered to the
> main board will not be subject to as much change as things that are
> plugged in.
That's true, but not a useful observation. The hardware in products
can differ greatly between manufacturing runs, even if from the outside
it looks identical. This happens a lot in cheap consumer electronics
manufacturing, because the prices of components fluctuates so much,
> Therefore keeping to one or a few standard designs makes sense. (As
> happened with the early IBM PC clones.)
No, it absolutely does not, for precisely the reasons I've mentioned
before and have ignored. You can't make things cheaply and in bulk if
you do this, as well as being stuck with past decisions. If it were
the case, don't you think all the world's phones and PDAa would share a
platform, so they didn't need to report Windows CE/PocketPC/Windows
Mobile/Symbian/Linux for every product? The situation is, as usual,
massively more complex than you realise.
B.
Jess
Rob Kendrick <nn...@rjek.com> wrote:
> On Mon, 23 Nov 2009 10:40:15 GMT
> Jess <phant...@hotmail.com> wrote:
>> whether it would
>> be good for a new platform to require a different version of the OS
>> for each different device. Especially, when it's a low end platform.
> It will require a different /kernel/ for each device. Not the entire
> OS and environment, which can be shared.
In that situation, if a device doesn't get a new kernel created, when
the others do then it becomes obsolete. If the hardware specifics are
in a separate layer, the device only becomes obsolete when things move
on so far that a new specification for the layer is needed.
>> External USB is irrelevant (in this case), beyond a few generic
>> devices.
>
> Devices that are limited to a few generic devices are annoying. For
> example, I have a WD TV, a cute little box that runs Linux that plays
> media of a USB-attached mass storage device. Why can't it support
> fetching the media over USB ethernet or wifi? Or even 3G? Linux
> supports all of these. (I've since installed a third-party firmware
> that does this, and it's great.)
Third party firmware for limited devices is what the thread is about.
There is no way that Chrome OS (from recent reports) would be suitable
as a sole system for anyone who posts to these groups. However, what
it does do, is pretty much what RISC OS can't and a system that dual
booted would potentially be a viable main or sole machine for many
RISC OS users.
>> The point I was attempting to make is that things soldered to the
>> main board will not be subject to as much change as things that are
>> plugged in.
>
> That's true, but not a useful observation. The hardware in products
> can differ greatly between manufacturing runs, even if from the outside
> it looks identical. This happens a lot in cheap consumer electronics
> manufacturing, because the prices of components fluctuates so much,
But the market isn't a mass market yet. If it becomes a mass market,
then the odds are there will be a product suitable to be a RISC OS
machine.
>> Therefore keeping to one or a few standard designs makes sense. (As
>> happened with the early IBM PC clones.)
>
> No, it absolutely does not, for precisely the reasons I've mentioned
> before and have ignored. You can't make things cheaply and in bulk if
> you do this, as well as being stuck with past decisions. If it were
The PC market being a prime example of cheap mass market products that
live with previous bad decisions. However, you wouldn't choose to live
with previous bad decisions, new standards would elevolve.
> the case, don't you think all the world's phones and PDAa would share a
> platform, so they didn't need to report Windows CE/PocketPC/Windows
> Mobile/Symbian/Linux for every product? The situation is, as usual,
> massively more complex than you realise.
And when the PDA or smartphone were new platforms, there were hundreds
of different designs?
New systems don't start out deliberately complex.
--
Jess Iyonix
Rob Kendrick
Jess <phant...@hotmail.com> wrote:
> > It will require a different /kernel/ for each device. Not the
> > entire OS and environment, which can be shared.
>
> In that situation, if a device doesn't get a new kernel created, when
> the others do then it becomes obsolete.
Correct. What makes you think this is not in the manufacturer's
interest? They're trying to sell something cheap; not providing
indefinite support for customers no longer giving you money does not
make good business sense.
> If the hardware specifics are
> in a separate layer, the device only becomes obsolete when things
> move on so far that a new specification for the layer is needed.
This layer is called a "kernel".
> There is no way that Chrome OS (from recent reports) would be
> suitable as a sole system for anyone who posts to these groups.
> However, what it does do, is pretty much what RISC OS can't and a
> system that dual booted would potentially be a viable main or sole
> machine for many RISC OS users.
Why would the average person want to dual-boot RISC OS with it, rather
than, say, Ubuntu? Ubuntu has the advantage that it's free, and all
the typical software (mail clients, word processors, graphics alls) are
free, too.
Sure, RISC OS users might like it, but there's only 15 of them, so not
enough to fund any such port unless it was taken on by somebody
gratis. And the problem with that is the lifespan of the hardware, and
how long it is available for.
> >> The point I was attempting to make is that things soldered to the
> >> main board will not be subject to as much change as things that are
> >> plugged in.
> >
> > That's true, but not a useful observation. The hardware in products
> > can differ greatly between manufacturing runs, even if from the
> > outside it looks identical. This happens a lot in cheap consumer
> > electronics manufacturing, because the prices of components
> > fluctuates so much,
>
> But the market isn't a mass market yet. If it becomes a mass market,
> then the odds are there will be a product suitable to be a RISC OS
> machine.
And this machine will be available for perhaps 6 months. And it'll
take at least three of those to port RISC OS to it. (Assuming the SoC
is already supported, which means you're currently limited to... two
currently-available CPUs.)
> >> Therefore keeping to one or a few standard designs makes sense. (As
> >> happened with the early IBM PC clones.)
> >
> > No, it absolutely does not, for precisely the reasons I've mentioned
> > before and have ignored. You can't make things cheaply and in bulk
> > if you do this, as well as being stuck with past decisions. If it
> > were
>
> The PC market being a prime example of cheap mass market products
> that live with previous bad decisions. However, you wouldn't choose
> to live with previous bad decisions, new standards would elevolve.
The PC market is significantly different; it's *MASSIVE*, and customers
expect compatibility between vendors. Additionally, Windows. Windows
expects all that old guff. Mac OS X and Linux don't. (Intel Macs,
for example, lack the A20 hack, don't have a "traditional" BIOS, don't
boot in 16 bit mode, etc etc etc). If you can't see how the situation is
different, I feel for you.
> > the case, don't you think all the world's phones and PDAa would
> > share a platform, so they didn't need to report Windows
> > CE/PocketPC/Windows Mobile/Symbian/Linux for every product? The
> > situation is, as usual, massively more complex than you realise.
>
> And when the PDA or smartphone were new platforms, there were
> hundreds of different designs?
Absolutely.
> New systems don't start out deliberately complex.
Indeed; which is precisely why everybody starts from scratch with
designs every time in every consumer electronics market except desktop
PCs. Adapting existing designs is as expensive as designing from
scratch; it's much cheaper to mop this stuff up in software.
Not to mention that the CPUs simply do not exist to do what
you're wanting.
Nothing's stopping you going out and defining a "platform" for ARM
netbooks and getting it adopted by competing manufacturers with
different aims and silicon vendor arrangements, of course. Good luck
with that.
B.