ARM goes Client/Desktop

ARM seems now to officially aim at Client/Desktop/Laptop =>

Link

I just think it’s not on them, or they need serious partners and cheap offers to succeed there…

There’s been a long-standing rumour that Apple are going to move from x86 to ARM for their desktops/laptops.

It also wouldn’t surprise me if Google were keen on pushing ARM laptops more. ARM is by far the most popular Android CPU architecture, so an ARM device running a Google-derived OS (Android, Chrome OS, Fuchsia, etc.) is going to be able to natively run the largest proportion of appstore apps.

Then there’s games consoles – since each generation is typically a clean break from the last, it’s very easy for the big console giants to pivot between architectures. ARM chips have been popular in handhelds for many years, more powerful chips could start to appear in home consoles (and already have, if you include the Nintendo Switch).

Or it could just be another flop like ARM server chips or netbooks. Only time will tell!

Or it could just be another flop like ARM server chips or netbooks.

Servers suffer the “it doesn’t run Windows” in most organisations that could ever need a server. It could be more powerful than any existing x86 family server and still fail to make headway because “we need the support that comes with windows”.¹
Netbooks had the same sort of issue where the target audience wanted the familiarity of Windows. Apple devices have the whole “we’re better than MS and others” thing going and even there it took a long while for Apple to escape the niche market of the Mac doing publishing stuff and little else as far as users were concerned.

¹ A large Oracle database running on a Solaris platform was due for replacement about 3 years ago and preparations started about 4 years ago. Despite performance stats showing Unix platforms being better for the task (and Oracle’s own unsurprisingly being to of the stats) the system is in the process of being migrated to a Windows platform. The reasoning was that it needed to be Windows because it needed to be – i.e. no valid reasoning.

Servers suffer the “it doesn’t run Windows” in most organisations that could ever need a server.

And in the cloud, you have the problem that you want all your boxes to be using the same CPU architecture, so that you (or your provider) can easily shunt your workloads around. Unless ARM servers can offer something customers care about (lower prices?), it’s not going to take off.

Lower power consumption? Not a trivial issue for a server farm.

This is just ARM finally recognising the elephant in the room, which is that their customers are shipping “PC class” hardware with ARM inside. It means that they’re no longer pretending to be in a different market to the desktop CPU vendors.

I’m not sure that netbooks were really a flop. Though the concept of a low power ARM laptop hasn’t really survived, there are supposedly quite a few Chromebooks out there, so perhaps it could be said that the product category evolved.

I’m not sure that netbooks were really a flop. Though the concept of a low power ARM laptop hasn’t really survived,

For a long time I used an EeePC. I quite like it, and it was a nice form factor. Small enough to be compact, large enough not to be a toy.

The problem is that there’s no decent ARM specific operating system. Sure, we have a billion flavours of Linux, but in economic terms I reckon you could get more grunt per pound (currency) with a cheap x86 box.
Somebody (Toshiba?) made an ARM netbook around 2011/2012 that had a version of Android. ON A MACHINE WITHOUT A TOUCHSCREEN. You can guess why I wrote that in capitals…

I think ARM’s strength is in phones and tablets. As for other sectors, it’ll be an uphill battle.

You can guess why I wrote that in capitals…

I can guess, but I’m far from sure I’d be right. For what it’s worth, I have no love whatsoever for touchscreens.

I don’t think I’m alone in this, but I’ve no idea whether you’re a member of the same minority.

Touchscreens are okay, in a handheld device with an OS designed to be used by touch.

Touchscreens are not okay in a large form mounted vertically – arm fatigue is why the light pen never took off even though it was simple to build and the Beeb had support for it baked in.

Touchscreens are not okay when used with a traditional OS that gets retrofitted with support. It’s worth noting that you’re basically talking of control by the equivalent of a one button mouse, with added anomalies (like pinching or other two/three finger movements), plus a distinct lack of accuracy due to small surface and large pieces of meat. You’ll notice Android generally lacks menus, buttons are huge, text selection is bloody ridiculous (read: always broken), and the system only runs one task full screen at a time (later versions can do split screen, but you only actually interact with one of the tasks at any given moment), plus the on screen keyboard takes up a big amount of screen space even in small mode.
Yeah. The metaphors between touchscreen handheld and desktop are just entirely and completely different.

That said, touchscreens are probably not okay for typing. I always use swipey-typey(-mctypeface…sorry, it had to be done) because prodding a finger at a solid piece of glass with no give…I kind of wish I could live long enough to see if millennials suffer much greater instances of arthritis due to the years spent pounding out their inner thoughts by jabbing their fingers at unforgiving bits of glass…

As for my specific feelings on touch screens – do you have a better idea? On the right devices for the right reasons it is useful. On a Windows netbook “because we can” is probably not so useful…

For that reason (and the wonky fingers reason), I often use a Bluetooth keyboard with my device. It’s faster, it’s better feeling, but alas it is almost twice the size of the iPad Mini and maybe four times the width of my phone.

Somebody (Toshiba?) made an ARM netbook around 2011/2012 that had a version of Android.

I have one of those at home (I think since 2010, but I could misremember) :-)

It was the Toshiba AC100, based on the NVIDIA Tegra 250 (1 GHz QuadCore, which was quite a feat back then basically around the time of OMAP3). It had flash memory instead of a harddrive (only 8 GiB unfortunately). A crispy 10" HD display. Very good build quality with a great touchpad and keyboard.

But, as you said…unfortunately based on Android 2.2 (initially 2.1) and without access to Google Play (or whatever it was called back then – Google Market?), but instead an alternative app store which had nearly no apps inside, and most of those few in Japanese. There was an effort to port Ubuntu to it, but I never got that to run reliably. And I can confirm that Android does not work well without a touch screen.

It would have made up for a great RISC OS laptop on the other hand…but the Tegra 250 was never a good porting target because of NVIDIA’s secrecy.

Touchscreens are okay, in a handheld device with an OS designed to be used by touch.

Ah, okay, we’re on the same page. I don’t use any device like that, but I can imagine. Well, I occasionally have to suffer my wife’s iPad to sort something out, but it’s the unfamiliar way the apps work that’s a pain, not the touchscreen per se.

it’s the unfamiliar way the apps work that’s a pain

I expect the command-line experts said the same when the first Wimp GUIs arrived. That said, I agree with you completely: I find the opacity of iOS apps and general workings deeply frustrating.

I have to say I like having a proper keyboard and being able to touch type, while looking forward at my screen, not downward. That’s just simple ergonomics.

Followed the link in the first post and beyond. Now I am curious. Is it a major road block for a RISC OS port to Cortex A76 that ARM32 mode is only executable in EL0 (aka user mode)?

Is it a major road block for a RISC OS port to Cortex A76 that ARM32 mode is only executable in EL0 (aka user mode)?

More like the end of the road.

It would be relatively straightforward to write a tool which performs static translation of (sane) AArch32 assembler source to AArch64. It could help us get a leg-up into the AArch64 world, although it would ultimately just be a sticky plaster prior to rewriting all the assembler components in a higher-level language.

(Source)