Since AMD launched their Ryzen 4000 series laptop processors anything with an Intel processor looks underpowered which is a shame because the rest of the specs here are reasonable for the price. :(

I'm in the market for a new laptop too, was all set to pull the trigger when the first Ryzen laptops landed and now I'm in a holding pattern waiting for more AMD based options to come to market.

View this comment - View article - View full comments

Quoting: Purple Library GuyThe thing is, you're looking at things from a packager's perspective, but I'm looking at things from an end-user perspective, and as an end-user I have no real way to judge between packagers' ideas of what's a good package and Distro maintainers' ideas of what makes a good package, but I have some notion who the distro people are and basically no idea about the packagers. I don't choose between packagers, I choose between distros.

Err, Packaging is done by the distros. In fact that's pretty much all that distros are, a group of individuals taking the source code of various applications and packaging them. Often in the process making their own changes to that source code in ways aren't evident to the end user. I'm not anti-distro, but I do believe it should be made clearer to end-users what they are actually getting.

I'm looking at this from two perspectives - that of the end user who wants and thinks they are getting 'Application A' and from the perspective of the developers of 'Application A' who are frustrated because they know that the end user on many distros isn't getting 'Application A' but a broken and buggy hybrid version made by a packager who doesn't have a clue what they are doing.

Snap actually isn't unique to Ubuntu. Anyone can create a Snap package and they often do. Not that I'm advocating for Snap, I'm really not because of technical issues with containerisation, but I'm not siding with Mint packagers either. The Mint packagers arguments are a case of the pot calling the kettle black. The solution I'm proposing is a unified package format, used across all distros and yes all platforms (which Snap offers) but with the 'vanilla' packaging performed by the developers of each application. With a single unified, portable format this is something developers could actually handle. Distros would continue to be free to create their own versions of packages, but they'd be required to indicate such by altering the name e.g. "firefox-mint" and end-users would be free to chose between the 'genuine original' and the 'distro modified' version.

View this comment - View article - View full comments

Quoting: Purple Library Guy

Quoting: GBeeWhat the Mint packagers seem most concerned about is their own demise. If the world moves to Snap then there will be less opportunity for them to screw with code before it reaches the end user. This is a future I can get behind

That's ridiculous. If I choose to use a particular distribution, I want the people in charge of that distribution to have control over the packages. If I wanted the packagers of a different distribution to have control, I would have chosen that different distribution. Duh.

You seem to be misunderstanding the difference between distro level customisation and packagers silently modifying and f***ing up applications in all sorts of ways for no good reason and usually without end-users even being aware. Packages being created by _developers_ of the original application (you decided to ignore that part of my comment) would avoid a lot of instability, bugs, security flaws and provide consistency in application behaviour but would not prevent distros customising configurations, themes and generally deciding the mix of default packages to give their own spin.

View this comment - View article - View full comments

Quoting: CatKiller

Quoting: GuestMy main grip with snap was when it installed chromium on my Kubuntu 19.10 it was slower to start. Even with a SSD.

Yep. First run startup of a graphical application is slow. It needs to set up an entire environment of all the things that the application expects to be there to keep it isolated from the actual environment.

This is the wider issue with containers and containerisation. It's something of a battle I'm fighting at work right now as some people in the company have been bitten by the container bug as a solution for realtime scaling. They haven't considering the startup penalty and we've already demonstrated it to be significant in some cases. I mean it's preferable to scaling with VMs for so many reasons, but it's not the solution to every problem.

I would agree on the whole that containerisation is not, and should not be the universal solution for every distro and certainly not the choice for a power user or developers distro. There are good arguments for it to be used by the likes of Ubuntu though, a beginner-friendly distro or in at least one server-centric distribution.

View this comment - View article - View full comments

Yeah, reading more around the issue, this seems likely a completely flawed argument, and even back-firing argument by the Mint packagers. They argue that because Canonical builds the Snap packages they are proprietary, yet if the Mint team built the packages they are not. From the end-user perspective there is no difference - both are building packages that have to be decompiled in order to see what is actually in them.

What the Mint packagers seem most concerned about is their own demise. If the world moves to Snap then there will be less opportunity for them to screw with code before it reaches the end user. This is a future I can get behind, but ONLY IF the building of the Snap is done by the original application developers.

As a developer, we've long battled the packagers to get them to properly and faithfully provide their end users with the application we've poured thousands of hours of time into. Instead, many distributions quietly make changes of their own to the code before shipping a usually broken version under the name of the original. Because end users are usually unaware that they are getting something that's been modified by the packager they blame resulting bugs on the Devs and the product reputation suffers. The more public battles that resulted in the likes of IceFox (Firefox modified by Debian packagers) are just the tip of the iceberg.

Of course the source code remains open, and Mint packagers (amongst others) will remain free to create their own versions, but it will be much clearer that these aren't the original unmodified package as they would be required to change the package name to avoid collisions.

All in all, if they are arguing for greater transparency for end users, they are arguing against their own existence.

Now as a Dev I do have my own issues with Snap - namely that a full Snap distribution makes building and testing out changes much harder. I for one wouldn't want to use a Snap based distro for that reason, it would make my life significantly more difficult.

View this comment - View article - View full comments

Maybe I need more coffee, but I've no clue what "Snaps are more locked-down as they compared it to using proprietary software, it pushes Ubuntu directly and Snaps are done in the background." means?

Perhaps I should read the original for elucidation. The above explanation has severely confused me :(

View this comment - View article - View full comments

Great. Just as Fedora finally provides packages for 440.64, NVidia roll out 440.82. :huh:

View this comment - View article - View full comments

IMHO a cheap brush off for Epic. They can say they are supportive of linux, but without actually providing that support in-house. $25,000 really is just a small fraction of what a single software engineer would make in a year and therefore significantly less than Epic would spend hiring a team with linux experience to provide a native store (and games).

"Here's some pocket change, now leave us alone ..."

I guess we should be supportive of any engagement with the community, but I'm just very cynical about Epic.

View this comment - View article - View full comments

It looked crap even then, at least that was the verdict among my friends at the time. It was one reason those SW prequels were so badly received. Their CGI special effects actually looked worse in comparison to contemporary film releases and the original films.

View this comment - View article - View full comments

I don't think we're missing much with the ray-tracing, everything I've heard is that the difference is almost imperceptible while the performance impact is significant.

Now if only it would download just a bit faster.

View this comment - View article - View full comments