Hacker News Reader

Comment by blitmap | Hacker News Reader

I look forward to a RISC-V proc powering my laptop with some ridiculous Nvidia GPU. We must escape x86 :(

There is some gentle irony in wanting an open source ISA CPU paired with a GPU so proprietary the ISA is not even public knowledge.

"The journey of a thousand miles..."

I'm looking forward to the day we can operate dedicated, proprietary GPUs like black boxes we can turn on and off at will as optional accelerators. :-)

Twice the battery life and all the computing power :) sounds like heaven

Atm, arm is likely a better fit for that.

Right now the arm SBCs actually make functional desktops. There's very little you can't do on a raspberry pi other than run closed software.

You can actually run Windows on a Raspberry Pi. Having said that, they make for horrible machines to do actual work on even with desktop Linux.

Vim and gcc run fine, I can compiler kernels and busybox and work on my personal software projects and homework on mine. They don't run gnome or html5 browsers as well as your laptop might but nothing runs those well anyway.

t-try installing Chrome on it...

lynx for life yo!

Not Chrome proper but Chromium works (surprisingly) well on Raspberry Pi 3.

well... can you load like JS heavy site

The "Windows" you can run on a Raspberry Pi (ignoring anything involving X86 emulation) isn't a general-purpose OS. It's more like a deployment target for UWP/IoT apps that you write on a Windows 10 PC.

It's written in C. Why not a general purpose OS?

There are important people at Microsoft who basically get very confused about what "x86" or "arm" means. There was a contingent that decided allowing third parties to port win32 apps with a recompile was off the table (despite it being very doable - just look at explorer or notepad running on surface rt), and to this day whenever many MS folks make public statements about windows on arm they sound hopelessly confused.

Important people don't know what underlying hardware their software runs on? I mean it's not that hard to figure that out... I hope they're not just parroting what others tell them.

I could never figure out if it was stupidity or willful ignorance. Probably elements of both.

So I quit that company.

Pretty sure that this depends on the definition of 'functional'. My 386DX40 was functional, but I'm glad I have 8 i7 cores now.

Odroid is probably a better choice for a little extra oomph you would want on a desktop without costing that much more: http://www.hardkernel.com/main/main.php

I wish ARM made all their manufactures use UEFI. Microsoft did for their phones, but the bootloaders are locked. All the other ARM devices are SoCs with random shit connected to random pins and non-upstreamable kernels. It's not a platform.

For a new design to work, it really need to be a sold platform, with a spec and kernels that don't need per-device images to boot and run. Device trees help, but they're just not enough.

ARM has the beginnings of that platform coming together, just in the server space. It's pretty much implementable:

https://en.wikipedia.org/wiki/Server_Base_System_Architectur...

I'd rather they use Coreboot. UEFI is definitely coming "locked" to virtually all ARM-based devices, and my guess is Microsoft is at fault there, perhaps just by simply making it being locked the "default", and then the OEMs not bothering to change that.

> SoCs with random shit connected to random pins and non-upstreamable kernels

The non-upstreamable part is due to variety factors, including but not limited to dubious code quality, tendency to reinvent things in house and unwillingness to share code with competitors and develop common frameworks. UEFI won't help with these particular issues.

As for random shit connected to random GPIOs (or mapped to random memory), you probably really want ACPI. Fwiw, ACPI is said to be coming to ARM and last time I heard Linux developers weren't exactly excited - ACPI means running opaque vendor-provided bytecode which pokes I/O registers behind the OS's back and, if x86 is anything to go by, contains countless bugs which can't be fixed without the vendor releasing firmware update and users applying it, so you end up with a collection of machine-specific workarounds anyway.

devicetree is how this is all typically managed for Linux on ARM.

Reply on news.ycombinator.com