Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What is RISC-V and why it matters to Canonical

ubuntu.com

Post reply on HN
Print view View original

101–110 of 129 posts

Re: What is RISC-V and why it matters to Canonical

#101

Post by ddtaylor »

loloquwowndueo wrote: post #52
unethical_ban wrote: post #28

Earlier quoted context omitted.

Not sure on the timelines, but snap, upstart and Mir were all attempts at evolving Linux ecosystem that lost to RedHat-backed systems. Unity was legit abandoned, and bazaar... Not sure what they were trying to solve there with git and forges already existing.

> Not sure what they were trying to solve there with git and forges already existing. What? Bzr predates git (by a few days but still). Launchpad predated GitHub by a lot. canonical just played those cards horribly and lost.

I still maintain some Launchpad packages and recipes. It's an insanely archaic system and borderline non-functional. I wouldn't wish it upon most.

Re: What is RISC-V and why it matters to Canonical

#102

Post by ddtaylor »

kombine wrote: post #88
ddtaylor wrote: post #66

Earlier quoted context omitted.

Sadly, KDE and Gnome each spent a lot of time on the same things. Plasma Mobile has ate more time that could have went into making Plasma a better desktop.

That's a strange argument. Open source software including Plasma Mobile is developed by volunteers who choose to spend their time on a given project. I am quite happy with the pace of Plasma Desktop and the progress made in the past 3 years on its 6th iteration.

As a KDE developer I can say that there are times that we have done things differently or taken the long road because we wanted to support Plasma Mobile.

It would have just been better to continue doing the desktop specific things and let the Plasma Mobile enthusiasts make those changes.

Re: What is RISC-V and why it matters to Canonical

#103

Post by Chyzwar »

topspin wrote: post #14
Chyzwar wrote: post #12

Earlier quoted context omitted.

[flagged]

"It is Chinese companies looking for ARM alternative" The V in RISC-V represents iteration of the ISA, over the last 46 years, most of which occurred in the US, mainly at Berkeley.

Exactly without billions in investments this would yet another experimental ISA.

Re: What is RISC-V and why it matters to Canonical

#104

Post by stubish »

loloquwowndueo wrote: post #51
ddtaylor wrote: post #23

I stopped listening to what Canonical says. They often get involved in things and disturb the ecosystem then abandon stuff or dig a "not invented here" hole. Unity, Bazaar, Mir, Upstart, Snap, etc. All of them had existing well established projects they attempted to uproot for no purpose other than Canonical wanted more control but they can't actually operate or maintain that control.

The project bzr was trying to uproot may not be the one you’re thinking of. First release of Bzr predates git by about a month.

Similarly upstart, from 2006, widely deployed before Redhat brought in systemd. And got dropped when Debian decided to go with systemd. Surprising how this gets misremembered given the hate systemd initially received.

Re: What is RISC-V and why it matters to Canonical

#105

Post by stubish »

ddtaylor wrote: post #100
lukaslalinsky wrote: post #90

Earlier quoted context omitted.

I was honestly wishing Ubuntu would keep upstart alive. I preferred it as init system.

That is half the problem. They often introduce neat ideas, but then fail or refuse to integrate them with he rest of the FOSS ecosystem. Then anyone who subscribes to their experiment is left cleaning up the mess and trying to migrate the features or ideas they like to the remaining projects that should have been extended in the first place.

Not sure how you can say that about upstart. It was pretty much the accepted successor to shell scripts for an init system, for a few years until Redhat started pushing systemd. You would probably be using it now if Debian hadn't gone with the Redhat systemd over OpenRC and upstart.

Re: What is RISC-V and why it matters to Canonical

#106

Post by camel-cdr »

ljhsiung wrote: post #18

> Enabling new business models This is true, but only for the bigger players. The nature of hardware still fundamentally favors scale and centralization. Every hyper-scalar eventually gets to a size that developing in-house CPU talent is just straight up better (Qcom and Ventana + Nuvia, Meta and Rivos, Google's been building their own team, Nvidia and Vera-Rubin, God help Microsoft though). This does not bode well f…

> good luck parsing through 100 different "performance optimization manuals" from 100 different companies

This would be a problem for any ISA with multiple/many vendors.

Re: What is RISC-V and why it matters to Canonical

#107

Post by pezezin »

ur-whale wrote: post #80

I've played with a bunch of RISC-V platforms, mostly SBCs in the raspi class Beyond the potential platform fragmentation due to the variability of the ISA (a very unfortunate design choice IMO), mentioned elsewhere in this thread, what I find most frustrating is the boot process / equivalent of BIOS in that world. My impression: complete lack of standardization, a ton of ad-hoc tools native to each vendor, a complete…

> 2. a unified BOOT environment which supports a broad standard of devices to boot from (SSD, network, SD-Card, hard-drives, etc...)

I got the same experience tinkering with ARM devices. It soured me so much that I have decided that until ARM offers a unified boot mechanism like x86 PCs do, I will ignore it, no matter the supposed benefits.

Re: What is RISC-V and why it matters to Canonical

#108

Post by LeFantome »

storus wrote: post #31

Will RISC-V end up with the same (or even worse) platform fragmentation as ARM? Because of absence of any common platform standard we have phones that are only good for landfill once their support lifetime is up, drivers never getting upstreamed to Linux kernel (or upstreaming not even possible due to completely quixotic platforms and boot protocols each manufacturer creates). RISC-V allows even higher fragmentation…

> platform fragmentation

RISC-V is addressing this issue quite directly. For things like desktops, laptops, SBCs and servers we have the RVA23 profile which defines quite specifically what features a chip must support to ensure code portability.

On top of this, there are platform specifications. For example, the server spec is about to finalize next month. It extends RVA23 which things like UEFI, SBI, and ACPI to ensure that your can take something like a Linux distro and easily install it on any RISC-V server, like you can in the world of x86-64.

> we have phones that are only good for landfill once their support lifetime is up

RISC-V will probably not solve that problem in general.

First, the ISA cannot really demand that your phone avoid a Broadcom wireless chip that requires proprietary firmware for example.

Also, the phone vendor can still lock down the devices to prevent running arbitrary code.

Thankfully, the RISC-V world is developing a culture of openness. If a company wants to create a fully “open” phone, they are quite likely to adopt RISC-V. And, because of RISC-V, even the SoC itself could be fully Open Source.

But your typical Android phone is not going to get more Open just because they contain a RISC-V CPU.

Re: What is RISC-V and why it matters to Canonical

#109

Post by foresto »

omcnoe wrote: post #78
foresto wrote: post #54

Earlier quoted context omitted.

> bazaar... Not sure what they were trying to solve there with git and forges already existing. You are mistaken here. Bazaar, Mercurial, and Git appeared at about the same time, and I think Bazaar was released first. IIRC, Bazaar tried to distinguish itself by handling renames better than other version control systems. In practice, this turned out not to be very important to most people. (Tangent: It wasn't clear at…

Lightweight branch model of git mapped so much better to the way that actual development processes of medium to large projects really work(ed). Named branches vs bookmarks in hg just means bike shedding about branching strategy. Bookmarks ultimately work more like lightweight git style branches, but they came later, and originally couldn't even be shared (literally just local bookmarks). Named branches on the other h…

That's a fair criticism for some workflows, and I like the lightweight model, but we should keep in mind the context of the time:

When these DVCS appeared, Git's branch design departed from what "branch" meant practically everywhere else. That added to its already significant learning curve, creating more friction for people trying (or being asked) to adopt it.

Meanwhile, Mercurial's "branch" was closer to well-established norms. This was one of several factors that made it the easier of the two to learn, which was was important when already asking people to uproot from their familiar centralized systems and learn the ins and outs of distributed version control. I suspect it also made repository migrations more straightforward, avoiding the impedance mismatch presented by Git's branches.

Re: What is RISC-V and why it matters to Canonical

#110

Post by loloquwowndueo »

ddtaylor wrote: post #101
loloquwowndueo wrote: post #52

Earlier quoted context omitted.

> Not sure what they were trying to solve there with git and forges already existing. What? Bzr predates git (by a few days but still). Launchpad predated GitHub by a lot. canonical just played those cards horribly and lost.

I still maintain some Launchpad packages and recipes. It's an insanely archaic system and borderline non-functional. I wouldn't wish it upon most.

It was deprioritized for years, the team gutted to staff other shinier projects you likely haven’t even heard of.
Post reply on HN