Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is good news for risc-v! The fact that it can be implemented so easily by hobbyists furthers the cause of trusted hardware. Sure, it won't be implementable by hobbyists at the speeds necessary for modern desktop computing, but a trusted security core (something like a yubikey) could be implemented on completely from-scratch hardware, but then still use existing trusted/vetted software (openssl), just a cross-compile away.


"Modern" desktop computing is perhaps less resource hungry than you think when you cut away so much graft of telemetry.

None or barely few games, of course. But word processing, email, and pure HTML browsing without javascript? Maybe not HTML5's fancy features, but general rich text?

I think it's very achievable.


My software "stack" hasn't changed in maybe 15 years now. It's emacs + firefox + terminal and a couple utilities here and there. It ran fine on my first computer with a single core ~1GHz CPU and 128MB of RAM (although multi-core architectures and more RAM did make it a lot easier to multi-task later). The only reason I upgrade my computer these days is to run modern games, for everything else except compilation I could probably use a computer from 10 years ago and not feel the difference.

I'd gladly switch to a completely open source hardware architecture even if it meant losing a significant amount of raw performance provided that the hardware and OS are stable and it's not prohibitively expensive.


I don't know what "prohibitvely expensive" is in your case, but there's a possibility today:

Grab one HiFive Unleashed for $999 [1]:

- 4 cores up to 1.5Ghz

- 8Gb DDR4 ECC Ram

- 1Gbps ethernet

Then grab one HiFive Unleashed Expansion Board for $1,999 [2]:

- SSD M.2 Connector

- SATA3 Connector

- x16 PCIE Connector (4 lanes of pcie2)

- A bunch of other cool stuff you wouldn't probably use (SPI, FPGA, etc.)

Finally grab some M.2 Drive and a graphics card ($500 maybe?).

This would set you back a grand total of $3500, which is definitely way more expensive than the current mainstream but may fit within "non-prohibitively expensive" for some. The whole platform should be open source [3].

[1] https://www.crowdsupply.com/sifive/hifive-unleashed [2] https://www.crowdsupply.com/microsemi/hifive-unleashed-expan... [3] https://www.sifive.com/products/hifive-unleashed/


While the hifive is an awesome proof of concept 3,5 k$ for essentially something performing roughly as well as a raspberry pi seems prohibitively expensive for now.


Seems worth it.

My issue would be paying all that, and then strapping closed source hardware to it.


That sounds nice actually.

I'm currently dealing with our legacy system which means I have multiple virtualised systems running in a replica of our production system.

Currently using ~25 gig of RAM just to run the environments and an IDE.


It isn't the telemetry that's slowing us down, but layers upon layers of (mostly needless) abstraction and buffer bloat.

Windows 95 had most of the things we use in a GUI environment today and it ran on a 486 with 8MB of ram. When packaged in Electron with a javascript x86 emulator it is still smaller than many modern text editors. Plenty of GUIs ran on significantly less.

Since the modern web is basically one of the worlds most overengineered and crufty VM platforms, I don't expect it would run very well, and that would probably be enough to doom the system in the eyes of many, sadly.


Never mind that Win95 didn't need a GPU that could push millions of polygons just to draw its UI...


What layers of abstraction are we stacking? Sure, there's electron/v8, but that's just one layer. You said yourself that notepad in an electron-based x86 VM is still pretty small, so clearly electron itself isnt the problem.

Maybe people just demand more from their software these days, and all these little conveniences just add up more than you'd realize? That would also explain why the system is not "doomed in the eyes of many" as you claim it ought to be.


What conveniences? Most web apps (e.g. Google Docs) have less functionality than their Win95 counterparts, notwithstanding the stupendous amounts of added bloat.


A lot of the conveniences of the modern computing landscape are anything but.

Laggy response times in aforementioned text editors, frivolous UI animations on certain OSs, terrible web apps like JIRA...

The complexity doesn't necessarily mean better software. It's quite often worse along many dimensions: performance, usability, maintainability, portability.


The web is incredibly bloated unfortunately. I had to upgrade my RAM recently because I couldn't open too many browser tabs without making the system hang, even with javascript disabled. Apart from that, you can do almost everything from the command line so even an old Raspberry Pi could be usable as a desktop computer.


You could still have a lot of RAM with RISC-V. The web does require lots of RAM nowadays, yes. But it is not a problem in this regard.


Take a look at Tab Wrangler extension. It closes tabs you haven’t used in a while.


I am curious if you how how this compares to The Great Suspender? I also don't understand why Chrome and Firefox don't buil tab managers directly into the browser.


Firefox used to have Tab Groups, it got removed but the webextension API got some new features specifically to support similar functionality in an extension.

i.e. https://addons.mozilla.org/en-US/firefox/addon/basic-panoram...

In reality I think it's just not a priority for browser devs because the overwhelming majority of users do not use huge numbers of tabs.


Thanks. Yeah I suspect tab junkies are probably a minority. Do you know is the latest Firefox on par with Chrome in terms of tab usage and memory footprint?


Memory usage in FF with lots of tabs seems a bit better than Chrome, CPU usage seems a bit worse. I think the UI does a significantly better job of handling them though, since Chrome just shrinks everything until there's no text left.

About a year ago FF was really awful with lots of tabs, CPU usage was very high and the UI would occasionally freeze up for 10+ seconds at a time. They're really been making some big performance improvements lately.


> But word processing, email, and pure HTML browsing without javascript? Maybe not HTML5's fancy features, but general rich text?

All things I've seen achieved on a 486... In fact, come to think of it, I've seen people doing all of the above on m68k-based systems too.


> pure HTML browsing without javascript

I highly doubt this is achievable now. Turn on NoScript and vast majority of web sites just refuse to work not even properly, but to just load the content.


I wonder what the "vast majority" is that you mention. For me, with JS off by default, the majority of sites I come across when searching for things are perfectly readable without JS.

The sites that need it are a small whitelist of ones I trust (e.g. the banks a sibling comment mentioned), which I enable.

...That said, a 75MHz RISC-V will be approximately comparable in performance to a 100MHz 486DX4, or a 40MHz Pentium.


Then don't use shit websites that require javascript.


... like my banks?

I actually like/need to use websites that use javascript, imagine that


Those things only require a couple hundred Mhz of general purpose computing to make sense.

Maybe less, should specific purpose assists be available.

And RAM address space sufficient to contain the tasks.


I think the best feature of the RISC-V instruction set is that is very clear and very simple. The RV32I instruction set is composed by ~40 different instructions and, depending of the environment and the implementation, you don't even need implement all them, as long the compiler will never generate some instructions. A simpler core means faster clock rates, less logic and more cores per chip, which much more performance. By this way, although the performance in the FPGA is not so good as in a ASIC, the results are not so bad:

https://www.hotchips.org/wp-content/uploads/hc_archives/hc29...

With 1680 RISC-V cores running in parallel at 250MHz, the result is impressive, even working in a FPGA!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: