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

Ubuntu Flavors Agree to Stop Using Flatpak

omgubuntu.co.uk

Post reply on HN
Print view View original

91–96 of 96 posts

Re: Ubuntu Flavors Agree to Stop Using Flatpak

#91

Post by noirbot »

fareesh wrote: post #90
noirbot wrote: post #41

Earlier quoted context omitted.

I always hear this and really want to jump in, and then I wasted a full week trying to get Arch to dual-boot on my Framework laptop and just couldn't get it to work. The Arch wiki installation instructions regularly were out of date with the current installer and told you to use flags that didn't exist when setting up your disks. I assume I'd love it once I got it installed, but for everything I hear about how good t…

Was the problem specific to dual booting? I booted off the USB and installed GRUB. I've had issues with dual booting too occasionally, but most seem to be caused by Windows

The issue was more around me already having a bootloader and boot partition set up (rEFInd) that worked fine, but trying to get Arch to be bootable from that pre-existing one while still setting up swap and the other partitions it wanted.

I also spent a really long time dealing with the fact that my motherboard clock was out of sync, so when I was setting up pacman, it couldn't validate certs because of the clock issue, but not being able to install packages made it really hard to fix the clock sync issue.

Re: Ubuntu Flavors Agree to Stop Using Flatpak

#92

Post by noxvilleza »

jeroenhd wrote: post #88
noxvilleza wrote: post #46

Earlier quoted context omitted.

Yeah updating flatpaks on the Steam Deck takes ages, and because of the way the SteamOS is set up - you really are incentivized to use flatpaks over actual packages (which could break with updates).

Updating Flatpaks takes a few seconds. The standard Discover application that comes with the KDE desktop environment is awfully slow, though. Running flatpak update or whatever the exact command line is in the terminal will be much faster than trying to go through the GUI. I've seen this happen before on a Kubuntu install and on an Arch VM, I think it may just be a Discover bug.

Thanks for the tip!

Re: Ubuntu Flavors Agree to Stop Using Flatpak

#93

Post by rlpb »

tpoacher wrote: post #89
rlpb wrote: post #61

Earlier quoted context omitted.

On the other hand, I repeatedly recommend that ordinary users do not install software from third party apt repositories unless they really really have to. Fundamentally they're a hack, don't work right, and often result in latent packaging problems that cause future release upgrades to explode. People then unfortunately attribute those failures to the distribution rather than the broken hacks they themselves installe…

> But it's disingenuous to declare that there's no need for them I didn't say there is no need for them. They are just horrible solutions. > I repeatedly recommend that ordinary users do not install software from third party apt repositories unless they really really have to Fair enough, I wasn't making the case for third-party repositories specifically; I was indeed making the case for distribution-curated repositor…

> what I'm saying is that I will generally go to the project's website "a la windows style", and either download whatever binary they provide, or preferably if possible compile from source.

That is dangerous from a security perspective though. That third party binary, or your built binary, has permission to everything your user can, including exfiltration of your online banking sessions and so on. That's not appropriate in the modern computing environment. Apps that haven't otherwise been curated really need to be sandboxed, and if you have to go out of your way to arrange a sandboxed environment, well, that's what snaps do out-of-the-box, and we can't expect users to be able to stand that up manually any more than we can expect them to compile from source.

Re: Ubuntu Flavors Agree to Stop Using Flatpak

#94

Post by angry_octet »

flakeoil wrote: post #25
doubled112 wrote: post #16

Earlier quoted context omitted.

But that's just Ubuntu with another repo added on top, with some different default package choices.

Well, there is nothing wrong with Ubuntu, just Snap.

They are clearly trying to build a walled garden. The Pro stuff, making security package updates subscriber-first, clearly makes everyone else a target.

I can see why they are doing it, commercially, but it seems misguided. There are so many other ways they could bring value for corporate customers without trying to copy Apple/Microsoft/Red Hat.

Re: Ubuntu Flavors Agree to Stop Using Flatpak

#95

Post by fareesh »

noirbot wrote: post #91
fareesh wrote: post #90

Earlier quoted context omitted.

Was the problem specific to dual booting? I booted off the USB and installed GRUB. I've had issues with dual booting too occasionally, but most seem to be caused by Windows

The issue was more around me already having a bootloader and boot partition set up (rEFInd) that worked fine, but trying to get Arch to be bootable from that pre-existing one while still setting up swap and the other partitions it wanted. I also spent a really long time dealing with the fact that my motherboard clock was out of sync, so when I was setting up pacman, it couldn't validate certs because of the clock iss…

Windows messes with the clock every time you boot into it - there's an entry in the wiki with a bunch of different solutions

Re: Ubuntu Flavors Agree to Stop Using Flatpak

#96

Post by VeninVidiaVicii »

nequo wrote: post #60
VeninVidiaVicii wrote: post #58

Earlier quoted context omitted.

That’s a very interesting thought, and one I haven’t come across. How did you come up with this so fast?

I read about it before.[1] There is also a BLAS library made by Nvidia that makes use of CUDA. This post is about how to hook it up to GNU Octave but it also works with R: https://developer.nvidia.com/blog/drop-in-acceleration-gnu-o... What sibling says about compiling R on your work computer so that it can make full use of your CPU can help too. I am curious if that closes the performance gap for you. [1] https://cs…

These tips speed up my Arch Linux R even more, but my Ubuntu setup is still just as slow, even with these optimizations. Somewhere along the journey I did see that Xeons have problems with R, but I can't seem to find where I saw that. Darn.
Post reply on HN