Quoting: GuestWell snaps are being forcibly pushed on people, so it's worth discussing the matter.

Yeah, they should be discussed, definitely, and improved. But it's rarely covered in a consistent way. Canonical get a lot of flack for stuff that nearly every other member of the Linux community gets a free pass on.

Canonical are definitely "forcing" snaps, because they're a success story on other Ubuntu platforms like IOT and the independent vendors that Ken mentions. Hopefully they address the various shortcomings in the desktop clients quickly, because rightly or wrongly, they're already pushing people away from desktop Ubuntu.

View this comment - View article - View full comments

Quoting: SoltrummanAs a Ubuntu user since 06.06 snaps are probably the biggest misstep up there with MIR and we all know how well that NiH-project turned out.

I've covered before how ridiculous calling things "NIH" is. It's literally how Linux evolves and becomes better. Weird that Canonical gets hate for that, but no-one bats an eyelid when Redhat decide to replace the entire sound system, or indeed, the entire fucking init system.

Flatpaks have lots of problems too - go google how well Steam runs as a flatpak. But it's gotten better. Flatpaks, generally, will get better.

So will snaps. People need to stop shitting from a great height on something that doesn't even need to affect them.

• Slow start up on Firefox - install the deb until it's fixed. It will get fixed.


• Don't like the snap folder in your home? Neither did I - easily fixed with a .hidden file.


• Snaps too big? Well, last I check was a while back, but Firefox was around 200Mb. If you're on a low-resource system that you care about Mb instead of Gb then sure, maybe snaps aren't for you. But then, neither are Flatpaks or AppImages.

Can't speak to the Loopback issue because in 20+ years of Linux, I've never, ever had to check my /dev/loop devices. Ever. Maybe I'm lucky that way.

But bottom line, why all this weird hate? It feels like the usual anti-Canonical sentiment. Other, far worse technologies aren't grilled like this. I just don't get it.

View this comment - View article - View full comments

Quoting: dr_jekyll2. I call it a structural flaw, because as one user pointed out, rsync works much faster and smoother without freezing the desktop etc. (I tested it multiple times myself).

The bug also notes that comparing the rsync or cp is a waste of time, because the KIO helpers that perform the action in KDE are multi-purpose and have to work consistently across local filesystems, SMB, NFS, FTP, SSH, WebDav and everything else. So yes, I'd like it to be faster. But no, it's not a structural flaw. It's actually a very cool design that just performs poorly in certain edge cases.

As for the rest of your comments, we'll just agree to differ. The KDE priorities will never please everyone, of course, but I much prefer their decisions, approach and transparency compared to, say, Gnome.

View this comment - View article - View full comments

Quoting: dr_jekyllSome of these flaws are quite heavy and point to structural problems, for example this bug:
https://bugs.kde.org/show_bug.cgi?id=342056 [External Link]

I'd like certain stuff to be a bit faster, but I wouldn't call that a structural flaw - even the original reporter of that bug noted that his use case (that of millions of small files in tens of thousands of directories) is an edge case. Nice to see Nate Graham commenting on it though.

I'd honestly rather Nate & Co keep doing what they're doing by focussing on the small things that put people off in KDE. Canonical did a similar thing with Ubuntu - it was called the 100 papercuts project. Now they're replicating that effort in KDE (15 Minute Bugs) which is great to see.

Theming could use a tidy-up too, although it's admittedly so powerful, that would be a fairly big challenge.

View this comment - View article - View full comments

Quoting: itscalledreality

Quoting: scaineProprietary-esque? What the hell does that mean?

Canonical adds Canonical made software/features by default to Canonical’s OS. Snap packages come to mind.

Anyone can use snaps. Nothing proprietary about them. The back-end is closed-source, but available to use by anyone. I've covered this before.

I wish I knew where all the Canonical hate comes from. Redhat doesn't get this shit for Fedora. SUSE gets a free pass. I've always wondered why folk are so quick to jump on this particular bandwagon.

View this comment - View article - View full comments

Quoting: itscalledreality

Quoting: scaineI can't speak to the veracity of that claim. I doubt we'll ever know for sure why Valve went with an Arch-based over Ubuntu, but I certainly doubt it's anything to do with Debian's "gatekeeping". That gatekeeping as you call it, is often referred to as "quality control". Gatekeeping, in this context, is a good thing. And there are still lots and lots of ways around it (PPAs, forks, patchsets), so I doubt it's why Valve went with Arch instead.

Not my area of expertise though. Perhaps you're right. But it sounds like an oversimplification of a very complex landscape.

Valve already publicly stated that lack of recent packages in Debian is why they switched to an Arch base so no mystery there. Debian while it’s difficult package process can guarantee quality, that same gatekeeping can also push package maintainers away which doesn’t produce anything. Sure there’s a multitude of reasons but results are the same, packages take a while to get through to Debian.

Interesting - I hadn't them state that. They publicly said that? Sounds like the sort of thing that a lot of people would have defended, cos honestly it sounds pretty baseless.

EDIT: All I can find, personally, is from this very site, where Valve's Lawrence Yang note that they moved to Arch-based simply to enjoy the benefits of a rolling-release, which would help speed development.

Quoting: itscalledrealityUbuntu on the other hand has has so many additions from Canonical that it makes sense why Valve would target something a little less proprietary-esque like Arch.

Proprietary-esque? What the hell does that mean?

View this comment - View article - View full comments

This guy (Nate Graham) [External Link] does a great blog (syndicated to Planet KDE [External Link] outlining the week-by-week changes and improvements to KDE overall.

View this comment - View article - View full comments

Quoting: itscalledreality

Quoting: scaineWhat are you referring to?

SteamOS v1 and v2 were Debian based (and outsourced even). This meant that Valve assisted with a base distros development. Ubuntu would have benefit from these improvements if v3 (Valve internal Steam OS) were still Debian based. Debian package ecosystem is notoriously gatekept and difficult for various reasons. So Valve chose an Arch base instead.

I can't speak to the veracity of that claim. I doubt we'll ever know for sure why Valve went with an Arch-based over Ubuntu, but I certainly doubt it's anything to do with Debian's "gatekeeping". That gatekeeping as you call it, is often referred to as "quality control". Gatekeeping, in this context, is a good thing. And there are still lots and lots of ways around it (PPAs, forks, patchsets), so I doubt it's why Valve went with Arch instead.

Not my area of expertise though. Perhaps you're right. But it sounds like an oversimplification of a very complex landscape.

View this comment - View article - View full comments

Quoting: Solitary

Quoting: scaineHow quickly do Fedora update this stuff?

Usually rather quickly. You can see that Mesa 22.1 already has packages made and currently considered as update-candidate.

https://koji.fedoraproject.org/koji/packageinfo?packageID=184 [External Link]

So how does it work on Fedora? Are those just official packages, updated that quickly? Or is there an equivalent to a PPA that you have to opt into to get updates that fast? I remember back in the early Ubuntu days, you had to opt into backports to get the good stuff, which was just a tick box in your package manager. Is it like that? Or is this just the standard update cycle for Fedora?

View this comment - View article - View full comments

Quoting: GBGames

Quoting: GBGamesSo no, there is no suggestion of a absence of salary so much as the need to expend more effort to find out if the normal effort of applying for a job is worth it.

That said, for a global company, I appreciate it can be difficult to post such a thing.

Maybe in some countries the salary can be reasonably $X, and in others it can be $X*2 or $X/2, and in some countries certain benefits are just not needed (healthcare in a country that provides it universally vs a country that does not, for example).

You could probably just have edited your first post, rather than quote-posting yourself! :grin:

But yeah, your point about Canonical being a global company is entirely valid. When you posted in $, you're implying an American position, and that's not what Canonical is about, really. So in what currency do you suggest salary when you're willing to recruit from literally anywhere in the world?

Separately, I work in Finance, and you'll never, ever, get salaries even mentioned until the second round of interviews, unless the position is (extremely) senior. It doesn't even come up in first-round interviews. Perhaps that's unique to the vertical (I've only ever worked in Finance, as a cyber security specialist), but I can tell you that if a first-round candidate asked about salary expectations in the interview, we wouldn't even know how to answer, generally. The first round interviews are about team fit, challenge and appropriateness for the role. Salary doesn't even enter into it.

But I can see how it probably should.

View this comment - View article - View full comments