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

81–90 of 129 posts

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

#81

Post by ur-whale »

maxloh wrote: post #47
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.

Snap is definitely not abandoned.

> Snap is definitely not abandoned.

You seem to be say it like it's a good thing?

Can't wait for that thing to explode and die.

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

#82

Post by nottorp »

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…

I work on a mercurial hosted project right now. What ticks me off is all those unnamed heads you need to handle every time you pull other people's changes. Yes they're more flexible. Most of the time that just means extra operations for no good reason.

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

#83

Post by pjmlp »

ddtaylor wrote: post #42
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.

Wayland was created in 2008. Mir was created in 2013. Bazaar and Git were created around the exact same time. Unity was abandoned after a failed attempt to circumvent Gnome 3. I was actually involved with the development of Compiz and they hired Sam to work on Unity, as he was one of the masterminds behind Compiz, but again they just didn't have the vision or execution to make it work.

Unity was great, after it was abandoned I tried yet again GNOME 3, me that in the past have collaborated with Gtkmm, ended up moving into XFCE, and nowadays I am fully on macOS/Windows anyway.

If I ever go back to GNU/Linux full time, GNOME certainly won't be it.

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

#84

Post by usrnm »

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 is very different from my experience with git. I know that the kernel uses branches a lot, but that's probably because of git's history with the project. At every company I worked git is used exactly the same way as CVS or SVN was used many years ago: you make some local changes, you push these local changes to the central store, you forget about it. Branches make local switching between tasks easier, but apart from that nobody cares about branches and they're definitely not treated as an important part of the repo. In fact, they're usually deleted immediately after the change is merged.

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

#85

Post by pjmlp »

LeFantome wrote: post #70
invalidator wrote: post #35

Earlier quoted context omitted.

The interest is BECAUSE it's well explored territory. The concept is proven and works fine. On the low end where RISC-V currently lives, simplicity is a virtue. On the high end, RISC isn't inherently bad; it just couldn't keep up on with the massive R&D investment on the x86 side. It can go fast if you sink some money into it like Apple, Qualcomm, etc have done with ARM.

ARM is RISC and dominates x86 in most markets. In 2026, RISC-V is not what I would call “low end”. Look up the P870-D, or Ascalon, it C950. Do you think Apple spends more money than Intel on chip design?

ARM is mostly RISC, and doesn't dominate x86 in desktop and servers.

Apple business is vertical integration, they have zero presence in the chip market.

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

#86

Post by omcnoe »

usrnm wrote: post #84
omcnoe wrote: post #78

Earlier quoted context omitted.

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 is very different from my experience with git. I know that the kernel uses branches a lot, but that's probably because of git's history with the project. At every company I worked git is used exactly the same way as CVS or SVN was used many years ago: you make some local changes, you push these local changes to the central store, you forget about it. Branches make local switching between tasks easier, but apart…

I think you have it swapped around. This is exactly the kind of workflow that git provided better support for - lightweight branches, not integral part of master history, deleted after merge.

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

#87

Post by sph »

mikestorrent wrote: post #27
aappleby wrote: post #16

Earlier quoted context omitted.

Why "mediocre"? I've written production assembly language for a half-dozen different processor architectures and RISC-V is my favorite by far.

You should write an article on that explaining why you like it to the common man

Silly opinion that has no relevance to building competitive CPUs, but I like that RISC-V is modular and you can pick and choose which extensions to adopt.

Makes writing a simulator so easy (just have to focus on RV32I to get started), and also makes RISC-V a great bytecode alternative for a homegrown register-based virtual machine: chances are RV32I covers all the operations you will need on any Turing-complete VM. No need to reinvent the wheel. In a weekend I implemented all of RV32IM, passing all the official tests, and now I have target my VM with any major compiler (GCC, Rust) with no effort.

If there is any architecture that scales linearly from the most minimal of low-energy cores to advanced desktop hardware is RISC-V.

Disclaimer: I don't know much about ARM, but 1) it isn't as open and 2) it's been around enough to have accumulated as much historical cruft as x86.

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

#88

Post by kombine »

ddtaylor wrote: post #66
popcornricecake wrote: post #64

Earlier quoted context omitted.

Ubuntu Touch... I was so excited about it that I bought one of the phones with it preloaded. I even used it as my sole daily driver for months, until I learned that I was not receiving all calls made to me. Even after that I kept hoping it would keep developing so that I could pick it up again one day. But then Canonical abandoned it instead. That's when they became as good as dead to me.

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.

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

#89

Post by jurip »

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…

Yeah, agreed. I liked the idea of Mercurial branches better than git's — in principle I prefer more rather than less metadata in history — but they genuinely had a scaling problem. I can't recall the numbers, this being more than a decade ago, but I tested with a realistic number of branches for a team of developers using short-lived branches for a while and you could easily see Mercurial slowing down.

Back when I was testing bookmarks were available, but Bitbucket was pretty much the only forge that supported Mercurial and their tooling didn't support bookmarks, so that made them a non-starter for many users.

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

#90

Post by lukaslalinsky »

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.

I was honestly wishing Ubuntu would keep upstart alive. I preferred it as init system.
Post reply on HN