Quoting: t3gThat’s an interesting take as Firefox in Flatpak or Snap is supposed to add another layer of sandboxing security.

This is true for most software, but Firefox already sandboxes web content. While Firefox's sandbox is weaker than Chromium-based browsers, it is still more robust than Flatpak's sandbox. As you can understand, they've had a lot of practice over the past 28 years...

As Seirdy's note explains, you can't have sandboxes inside of sandboxes:

QuoteWeb browsers are an alternative to Flatpak; they have their own sandboxing and updating mechanisms.

Most distributions build Firefox without auto-update support, of course, but TOR Browser Bundle does have this.

So, in most cases, Flatpak is better than no sandbox, but not in this case.

My information only comes from Seirdy, though, so don't assume I know anything more.

View this comment - View article - View full comments

Quoting: DesumI thought Wayland's security made running Wine without xWayland a technical nightmare because of all the unsafe things Windows allows programs to do?

Isn't this true of X, too? I guess sandboxing X.org in Wayland helps some of this, but WINE is meant to be able to run viruses just as well as normal programs.

I doubt sandboxing it will help much if you're running malicious software. Especially since most Wayland compositors don't implement any extra security features aside from the basic stuff the protocol asks for. GNOME seems to be the compositor most ahead in this, because it actually asks you before a program tries to look at your screen (much to the chagrin of some users in its implementation. Though KDE/Wlroots compositors might have implemented this now.

Quoting: ShmerlAnd as I also added above, one of the factors is the GPU. Nvidia blob is the drag on Wayland usage due to it causing poor experience on it. But the trend for Nvidia is negative as you can see on the same page, so that will speed things up for Wayland adoption.

Yes, NVIDIA with Wayland compositors is pretty bad. Sway doesn't support NVIDIA at all, so you end up with black flashes every few seconds. On KDE, display scaling is broken and everything looks wrong. Among a bunch of other issues I can't name because I ran away quickly. GNOME is the best compositor, but wake from suspend is hilariously broken, too, and it has difficulty fullscreening some programs. GNOME is at least smoother than X.org for me and I don't get black flashes. When I run GNOME on X.org, the top half of my screen flashes black occasionally. Yes, X.org. Shrug.

I've decided to just run KDE on X.org now because it doesn't flash black at all. If I have problems with this, I guess I can try i3...

I'm buying an AMD card next time...

View this comment - View article - View full comments

I've been thinking about switching to Fedora Silverblue/Sericea soon, but the only problem with these distributions is their plan to remove Firefox from the base image and install it as a Flatpak. It's not a good idea to install browsers with Flatpaks, because it weakens the sandbox and makes you more vulnerable to attacks. I really don't want to play with my browser like that.

On the other hand, the project is kind of forced to pick the Flatpak because they can't legally distribute H.264/AAC and other codecs with a native Firefox package (I don't know why Flatpaks that come with the ISO are any different, buy anyway), so that results in significant usability compromises.

But I do love how you can have different versions of the same program installed with Toolbox. Really, that's game-changing. And I don't even need to install Gentoo to mess with slots...

View this comment - View article - View full comments

Quoting: ElectricPrismIt's a great time to be a professional using Linux in many aspects.

Now we just need an image manipulation program that supports non-destructive editing, and Natron to port to Qt5/Python 3, but at least Nuke supports GNU/Linux anyway (not really a consumer/prosumer tool, though). Finding a viable replacement to After Effects on GNU/Linux is hard...I guess there's DaVinci Resolve Fusion, too.

On the other hand, GIMP's GTK3 port is done, they're working on properly supporting Wayland, and then they can work on the interesting fundamental stuff like vector shapes and other non-destructive editing features like smart objects and non-destructive effects. And previews for effects! A few more years and I can see GIMP being workable for professional use.

On the NLE side, Kdenlive is getting some big changes soon which will make quick adjustments much easier. There's still Lightworks for users who want a professional NLE.

I really want color accuracy for working with Darktable, which is a fantastic RAW processing program.

Audacity is being ported to a more modern toolkit, overall UX makeover, and is getting great new features, after Muse Group acquired the Audacity trademark and employed the Audacity team.

Running Affinity Creative Suite through WINE is finally starting to seem like a viable option, at least until GIMP gets those non-destructive editing features.

So, not too bad at all. Finding a good After Effects replacement has been tough for me, though. I recently stumbled across Enve, though I'm not sure this software will work either. It doesn't seem to be under active development anymore.

Work on high-level stuff in the compositor and kernel is important...but having great creative software for users to use seems like the bigger challenge currently.

View this comment - View article - View full comments

Quoting: ahoneybun

Quoting: pleasereadthemanualI would hope Kubuntu does some of the work setting this up, as it's sold from a Linux company.

Speaking for System76 we do a lot of work to get switching to work correctly so I know it can be done for this system as well.

I hope it's not a terrible experience for users. In my experience, it will try to run the compositor with NVIDIA by default, which is a terrible idea on both X.org because it will stutter and kill your battery life, while on Wayland it probably won't stutter, but it'll break resume from suspend on GNOME for example. So the first step is to switch to using Intel primarily, and then switch to NVIDIA for specific situations like hardware decoding.

This is my experience from 1-2 years ago, mind you—things may have improved. At that time, you had to restart your entire desktop session if you wanted to switch to your discrete GPU completely—from the sounds of it, some distributions now have a graphical utility allowing you to switch GPUs on the fly. But it still doesn't switch automatically, right?

Quoting: ahoneybun

Quoting: ArdjeA laptop with NVidia is a waste of money for someone who works with Linux.

Depending on the case this is incorrect, it can be helpful for AI/ML work, video work and gaming.

I don't know about video editing work particularly. A video editor's only real professional options on Linux are DaVinci Resolve Studio, which doesn't have AAC decoding/encoding (the audio codec used with the most popular video codec in the world) and Lightworks. Sure, with DaVinci Resolve Studio, you get to decode H.264 if you have a NVIDIA card; that's true. That's still only half the way there, because you need to transcode your AAC audio in your .mp4 container to something else before you can ingest it. And then after you render it, you need to transcode it again back to AAC. At that point, the time you're saving with NVENC on the render is probably negligible. If you're not working with H.264, I can understand this. However, even if you don't have codec problems, I've seen that DR seems to be quite...buggy on Linux. It also doesn't support display scaling.

Lightworks does take advantage of NVENC, but the workflow is so alien to me, I never got far into it. Cinelerra-GG takes advantage of NVENC too, but there are other bottlenecks slowing it down with the CPU, from my understanding. And, well, Kdenlive still has that stability problem to work out.

Now, if you're talking about VFX, that might be true, as this is a field I know Linux is used widely in.

View this comment - View article - View full comments

I do like laptops with a lot of ports, but I have to wonder why they chose to go with NVIDIA. As someone with a NVIDIA card, the only reason I keep it on Linux is with the hope that DaVinci Resolve will one day support H.264/AAC decoding/encoding with their Studio version. It's a pretty awful experience otherwise compared to even my integrated Intel graphics. And NVIDIA Optimus laptops are the absolute worst. I owned one of those, and it's a considerable amount of work for newbies to get graphics-switching setup. The only reasonable way to do it, in my opinion, is with prime-run. I would hope Kubuntu does some of the work setting this up, as it's sold from a Linux company.

NVIDIA works a little better on Wayland than X.org for me, in some cases, but worse in others. I'd really like to see NVIDIA properly support Wayland compositors sometime in the near future, but I'm not holding out hope. I think I'll get an AMD GPU in a few years, because NVENC and CUDA are not worth the trouble.

I would probably buy this laptop with 32GB of RAM if I were purchasing.

Interesting naming, by the way.

I took a look at the sales page:

 
Furthermore, it is even stronger in OptiX and ML performance.

So, yes, they chose NVIDIA for machine learning. It's possible on AMD, but not easy, I've heard. It also suggests users might use the laptop for Blender.

In my opinion, I would not purchase a laptop with a discrete GPU anymore. It kills battery life, especially on Linux:

Big battery: The 80 Wh battery provides up to 4 hours of on-the-go computing in power-save mode.

View this comment - View article - View full comments

Oh, this is much nicer. It's also mostly accessible without Javascript, aside from search, which is an improvement over the original. The descriptions for some programs are very sparse, though, to the point of being completely uninformative, like BetterBird. I wonder if there should be some minimum standard descriptions need to meet.

View this comment - View article - View full comments

Has anyone been able to get this working on desktop?

I've tried with EAC enabled and disabled. I get different errors. When I check enabled, it tells me that EAC is disabled. When I check disabled, it tells me: "Contacting Server. Connecting to transport service. Please wait." And it will load forever.

Others have been getting this on desktop as well: https://www.protondb.com/app/976730

I'm trying with Proton 8.

View this comment - View article - View full comments

Quoting: Purple Library GuyThing is, stuff like this suggests to me that what things like Flatpak are supposed to solve is quite different from what Flatpaks apparently do solve. If things that were packaged by distros end up getting packaged as Flatpaks, because packagers find they prefer packaging things as Flatpaks, because it's easier to do, that says the problem with existing package management systems is not the results but how easy they are to use from the packaging end.
The obvious solution would seem to be to make existing package management systems easier to package things with, and more automatable. Maybe there's some technical/theoretical reason why that's impossible, I dunno.

In Anki's case, it was due to the developers changing the build system so many times that distribution packagers just got sick of doing it. The previous way (before they changed to the current build system, which is much simpler) was using Bazel, which few packagers were familiar with. Anki is complex software, but nothing compared to the pain that building Audacity used to be. That's why Audacity was years out of date on most distributions before Muse Group took over and started improving things.

As to why the Flatpak version exists...anyone can be a Flatpak packager; you don't have to go through the arbiters of any community. You also only need to do the work once.

Now, I'm not much of a developer, so don't take my word on any of that. This is just my even-keeled conclusion based on all I've read on both of these situations.

QuoteI'm just saying, if the reason users are ending up using Flatpaks isn't because they're more maintainable or because users are clamouring for sandboxing but just because there are newer packages, which in turn is because packaging debs or whatever is just harder/slower to do, then the solution isn't so much Flatpaks it's making packaging debs or whatever easier and faster.

Packaging takes the most time of any aspect of distribution maintainership from what I know. It doesn't move the distribution forward, but it takes so much time and effort from so many people just to keep all the software up-to-date. Hence a universal packaging format. If you want developers to be doing the packaging—and I do—you need a single format which works in as many places as possible. You also can't stand at the gates, turning away any software that isn't popular enough, or any developers that aren't worthy enough.

Some would argue that developers shouldn't be the one packaging their software; packagers should be doing that. They know the system the software is supposed to run on, so they should decide how it's packaged, which parts are compiled, and whether to apply any patches. I'm almost inclined to support this argument until I think about the absurd amount of work a group of packagers for a distribution has to do on a regular basis. I can understand that argument for critical parts of the system like Wayland, GNOME, Linux, glibc, bash, systemd, and networkmanager, but I don't think packagers should be responsible for userland software at a certain threshold.

Oh well; I'm not a packager, so I can't say one way or the other. Packaging .deb archives might be harder, but making packages for Arch is super easy. I don't think it's the difficulty in using packaging tools that's the problem; it's the build systems. And also getting people interested in keeping up with that. Arch has a community repository from which Anki was dropped last year because the Trusted User lost interest or didn't have enough time, or whatever. There were still people willing to keep up with the new build system, but they weren't Trusted Users, so the package was hosted on the AUR.

So you might say the real problem is that there is too much vetting going on to make sure the packagers are trustworthy.

View this comment - View article - View full comments

Quoting: Purple Library GuyOr I guess if there were open source applications that I needed, that were not available from my distro but were available from Flathub, I'd grumble and use it. But for most stuff I would prefer to use traditional package management integrated with my distro, and I will be unhappy if there is a general trend away from existing package management and I end up having to install everything as Flatpaks.

When I tried Fedora recently, I found the version of Anki offered in the official repositories was from 2-3 years ago. On Arch, I use the version of Anki built from the AUR, which also includes a much newer version of the database.

The only other ways to install Anki are through pip, the official binary installer on the website (not a great experience), or through Flatpak. The Flatpak way is quite easy. I assume most other distributions have an outdated version of Anki too, because they got sick of packaging it. I think FreeBSD is the only exception (and from memory, I believe most packagers were relying on the FreeBSD packager's work).

I know the one arena Flatpaks won't replace distribution-built packages is system-level packages like Linux, bash, and glibc. Installing browsers using Flatpak is also a dumb idea.

But...if it ever does get to that point, know that Gentoo, Nix and GNU Guix will welcome you with open arms :P

View this comment - View article - View full comments