Hacker News Reader

Comment by mmastrac | Hacker News Reader

This seems like a much more advanced version of EOMA68, a compute card project re-using old PCMCIA connectors.

I feel like USB-C gives much more flexibility: it has a well-defined configuration enumeration protocol that's already supported everywhere. There's a lot more options for extensibility and future-proofing with USB-C.

With the onboard storage this is one step closer to my dream: the ability to plug a phone's compute module into a desktop to give me access to a more powerful GPU, extra storage, etc.

My big question: will this card format be an open standard, or will Intel be locking it down?

View on HN

I like the idea of extensible and replaceable computers: I would be much less concerned about my fridge being an IOT device if the IOT component was an easily upgraded and replaced Intel atom or Qualcomm Snapdragon compute card.

In terms of process migration I still think Google has missed a trick by not marrying Android and light-weight containers. If I could flick my wrist to send a phone process to my Chromebook, Android tablet, Andromeda device or smart TV life would be pretty interesting. Maybe one gesture for screen mirroring and another to move rather than mirror or copy the process.

This would also open up new channels for malware sure but also cool things like trusted processes / data for authentication. You have an invitation to my party, you say? Dock it with my Google Home device which signed your invitation to prove it, then...

>device which signed your invitation to prove it, then...

Then you realize why nobody shows up to your parties. :P

>>device which signed your invitation to prove it, then...

>Then you realize why nobody shows up to your parties. :P

Sure they do, but they're all hackers or cypherpunks. Listen all three of us had a great time. :-) :-)

But seriously, wouldn't it be fun to host a party where everyone had to hack an invitation?

IIRC defcon does this with their badges.

We designed an architecture for replaceability during the summer for our UAV project. Our current architecture has been based on the Zynq-7000 which is a two ARM-core + FPGA SoC. Here we had custom logic for doing things such as controlling signals to the servos in the FPGA and then software drivers communicating with the FPGA through memory maps. This resulted in a tight coupling between the drivers on the compute platform and the IO hardware.

Our next hardware generation will have a dedicated FPGA handling the communication with the GPS, IMU, servos. The compute platform will communicate with the FPGA over Ethernet. This means that all hardware drivers can be written against a network based interface, resulting in a loose coupling between the compute and IO. This means that both the IO hardware and compute hardware can be replaced individually without breaking the setup, and without having to rewrite any drivers. It also results in high transparency for debugging IO, with the possibility of easily recording and playing back a scenario. You can also test the full flight software on a developer's desktop machine during development without the embedded compute platform.

As embedded compute platforms get better all the time, while the IO stays more stable, this will make it easy to replace the compute every 2-3 years.

This is essentially what React Native has done for UI <~> Logic communication, allowing the latter (think iOS/Androind/Apple tv os/macOS etc.) to be replaced by any compute platform - even Compute Card in theory I think.

You're applying the same mental model to hardware which can be seen in the similarity of tools that can be enabled on top of such abstraction. Way to go!

The flexibility that emerges from decoupling our software and hardware solutions is a [recent] trend that will only gain on traction as more people become aware of it's implications to how we create solutions to technological problems.

How can we evangelize this better? From my experience it's complicated to communicate this idea well.

not sure if true, may be recency bias or the fact that I'm still young and inexperienced in many ways and lack historical background knowledge in tech

(put an asterisk before "[recent]" not knowing that it will format the comment. HN greenhorn)

Out of curiosity, why are you going to communicate to the FPGA over Ethernet vs PCIe or SPI or USB? It seems like you'd have to do a lot of high level processing on the FPGA to get it behave nicely on an Ethernet network.

With UDP and custom FPGA IP for handling the packets the processing works fine. Network behavior is made easier as the IO board will mostly be used in a dedicated point-to-point Ethernet connection.

Our opinion is that Ethernet is easier to analyze using tools such as Wireshark, in addition to being easier to run in a cable between different PCAs. It also allows the IO board to be easily networked for communicating with development tools to reprogram the FPGA memory, debug issues, do testing from a developer machine etc without concern for driver issues on various host operating systems.

Sounds like an interesting architecture. What UAV project is this?

It's the "LocalHawk" yearly summer project run by the Norwegian KONGSBERG group.

https://www.youtube.com/watch?v=kUfp87cDaE0 (2016)

https://www.youtube.com/watch?v=Prz7yc1i4ac (2014)

Another of their summer projects this year was the "CoastalShark" autonomous jetski where they constructed a sophisticated autonomous surface vessel. For their demonstration they used it to pull a guy on water skis:

https://www.youtube.com/watch?v=7T6jCyVF5j0

If only Android apps ran in some kind of virtual machine...

I had the same idea about the phone years ago. I don't know why we can't just take our iPhone or (more likely) Android, plug it into a docking station and use that at work as a desktop, pick it up and use it as a smartphone, or dock it to something at home.

Someone correct me if I'm wrong, but isn't that the idea behind continuum in Windows 10?

That is indeed what continuum is. Right now it's limited by the fact that you can only run Universal Windows Apps (UWP) that support ARM.

This is exactly why x86-emulation-on-ARM (http://arstechnica.com/information-technology/2016/11/x86-em...) is a very exciting project from Microsoft.

As mobile chips continue to improve, emulating x86 becomes a viable way of tapping into the huge Windows ecosystem of applications when not running on battery power.

I think this is Microsoft's last shot of becoming relevant in the mobile space.

Unfortunately, that ecosystem wasn't designed with small touchscreens in mind, nor battery efficiency...

Bring your own screen, keyboard, and power supply. Continuum is a weird beast, I'm not exactly sure who would get something out of it even if app support was good.

VDI which is what most large organizations are moving to. That computer on the desk is just a dumb terminal.

If the phone hardware was more powerful, and the win32 app support was there, it could replace your PC. You'd have a USB-C dock, with keyboard, screen and mouse, into which you plug your phone. Your phone is your PC, and when you leave you take it with you along with all your files and all your software.

You could combine it with something like a nexdock to also turn it into a laptop. Would be cheaper than getting a phone, and a desktop pc and a laptop, and it would avoid all those nasty issues with keeping devices in sync.

The qualcomm 820 already performed at core m levels, and the 835 is 25% faster, so it should be fine if paired with enough ram and storage.

Sorry, I wrote GP with an extra thread in mind without referencing it, about how phones-as-desktops hasn't happened https://news.ycombinator.com/item?id=13333797

The problem isn't power. Phones have been powerful enough for about 5 years (since around iPhone 4s, as a means of dating it).

Sounds like MaruOS to me http://maruos.com/ (not sure it's actively developed / more than a PoC since the Nexus 5 is already a bit outdated)

Yes, like laptops. I thought so too.

Speaking to retailers recently, demand is for office apps usable on touch. i.e. if it can possibly done without a keyboard, people will do that. From listening to users, they will moan and complain about touch "productivity" apps... but will choose it.

Personally, I switched entirely to a phone a year ago... though with a bluetooth keyboard.

Exactly what Ubuntu are/were working on:

https://wiki.ubuntu.com/Touch/CoreApps/Convergence

I have a lumia 950 with continuum, and it does this even without the dock. You wirelessly project to any w10 device, and it's like plugging in a different compute engine. You get a desktop, the start menu is your phone's home screen, all apps adapt to the bigger screen, and you can multitask. You use the keyboard and mouse of the PC.

It has two major downsides right now. There's no win32 support, so there's not much to run on the desktop, which MS is going to address by bringing x86 emulation to arm. Secondly, the hardware isn't quite powerful enough, which limits the max. resolution and the ability to multitask, which the new qualcomm 835 based phones with 4+ gb of ram should address.

It is impressive, but I haven't found a use for it. After all, when you have a laptop, why use it to run apps from your phone?

The "Motorola lapdock" was an attempt at doing this, but it seems not to have taken off.

Motorola Atrix was doing this at CES 2011.

I recall Nokia demoing something like that with their later Symbian phones. Video out to a TV, bluetooth keyboard and mouse, and you got the phone UI up on the TV and could operate it much like you operated a desktop. And you could still see and interact with the UI on the phone screen.

Android was out at that point, but could barely do video out by blanking the phone screen. Forget about operating it via other means. And i don't think iPhone was doing much better.

One reason why i feel the focus on those platforms reset mobile device progress by a decade.

Unless I missed it, I don't see any info on how it boots. Does it have UEFI? Is it a standard PC?

Where Intel can win is if a standard x86 Linux distribution could boot off of this with little modification. Right now in the ARM world, unless your device supports device tree configuration, kernels are highly customized per device.

> re-using old PCI-express connectors.

actually it's PCMCIA connectors (which have nothing to do with PCI express)

Oops, typo - will fix.

I'm starting to wonder if next-generation blade systems might not just have a bunch of USB-C connectors to act as a backplane. They provide power, data connectivity, external storage links and anything more. Small, self-contained modules like this could contain the CPU and whatever other components are best to have locally, like a small local SSD and memory.

For blades I would expect mostly PCIe lanes to the outside. USB-C IMHO adds a lot of extras that are not needed for that use case.

USB-C/TB can carry PCIe lanes, so it's mostly a matter of latency due to protocol overhead more than bandwidth.

Sure, but why would you add that overhead (both in latency and electronics needed) to transport e.g. 16 PCIe lanes over 4 USB connections just to then direct it to PCIe devices anyways, especially if those devices partially need more than 4 lanes?

USB-C is a really cool solution, but a solution for the needs of laptops/other personal devices, not servers.

Why would you add the overhead?

* Dead simple design. * Easily hot-swappable without expensive proprietary connectors. * Low cost solution that provides adequate bandwidth.

This isn't something that will perform better than a proper server with actual PCIe lanes, but it will perform better than a blade from two generations ago that didn't have that kind of backplane bandwidth and it will cost less to manufacture.

And less waste / nonsense. If you have an appliance, you'd typically like to upgrade it's computing module much more frequently than the envelope.

A nice side-effect might be that interfaces become more open, and you can run e.g. whatever OS you like inside your smart cheese grater.

EOMA68 gets me thinking about those Compaq Ipaqs that could be fitted with a sleeve (i think Compaq referred to them as jackets) with a PCMCIA slot. One use of all this was to turn the Ipaq PDA into a mobile phone.

Reply on news.ycombinator.com