Quoting: ShadowXeldronI am interested in an ARM laptop for battery life, but seeing how you can't upgrade the RAM on any of them I'm kind of iffy. 32GB of RAM will at least make it somewhat future proof. At the very least I'm interested to see a Linux-specific vendor have a shot at an ARM laptop.

It's likely going to be able to run all my Firefox tabs, Audacious and emulators just fine, but how well would it be able to handle x86_64 emulation? I'd probably try and build stuff manually to run on native ARM anyway, but I'd like to have the option to run x86_64 software for proprietary software and programs that just won't run on ARM.

The mnt reform community did all these things with less, but they can finally upgrade their RAM for some time, so now some got a little more breathing space. [External Link]

Quoting: ShadowXeldronI'd probably try and build stuff manually to run on native ARM anyway

In my experience this isn't needed, but I've seen people talk about it.
The one issue I experienced with having to compile from source is torbrowser, but I haven't tried emulation for that one yet, because I hadn't thought of that.

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: PublicNuisanceStuff like this rarely effetcs me. I actually prefer to not use cloud saves. I want manual offline options and to back it up myself. People can complain it's more work, and it is, but then again when crap like this happens I just laugh and go about my day.

It'd be nice if there were a folder where game saves were put by standard.

OOH, that's a Wine specific problem actually.
Standard that stuff is on windows set in user\Appdata and in linux in user/.local, but wine maintains for each prefix its own Appdata.
I understand the issue.

View this comment - View article - View full comments

Quoting: BoldosHmm.... I wonder what GPU and/or NPU capabilities this thing has?:unsure:

The X1E80100 has a 45 NPU TOPS.
42MB cache
LPDDRX5 RAM support(on die DDR5 RAM)
source [External Link]

View this comment - View article - View full comments

Quoting: elmapulthis may be one one those races where the only way to win is not to compete.

i mean, arm conversion will break backward compatibility , so the ones who dont try to migrate to arm might actually make money while everyone else loses.

or maybe this can work...

You're misunderstanding the situation.
Linux has been doing ARM for as long as it exists.
I already own a Linux ARM desktop from before Apple.
Yes, it breaks compatibility, with non-open source software, but only in ways the customer expects, because Apple and Windows are doing it too and it hides our own breakage of Windows and Mac api reliant software.
Microsoft had to give up Anti-cheat and tons of more modern Windows api-stuff for Arm.
Apple had to pay crossover tons of money, design custom hardware and strong ARM their entire dev community to switch to ARM.
The entire GNU/LINUX stack has full functionality and decennia of testing in native ARM, essentially all .deb packages have ARM versions.
In ARM Linux will stand out as a shining example of compatibility, because everything has been tested in servers, IOT devices, Phones, Apple devices, game consoles and home labs.

Linux isn't bad at compatibility.
It's the ruling king, since its founding.
The only reason we see so much weakness is, because our view is skewed, because the competition can run native, while GNU/Linux got to build translation layers and even than the problem only remains true for newer stuff, the old stuff runs better on Linux.

They came to challenge each other on our turf.
Lets loot their chambers.

Edit:
Qualcomm and Mediatec support Linux first, Windows second.

View this comment - View article - View full comments

Quoting: ShabbyX

Quoting: LoudTechie

Quoting: tfkDon't want to spoil the fun here. But this situation is rather similar to the xz vulnerability. Original dev overworked, other one jumps in. Makes all kinds of changes. Who is es20490446e? Does the software need root access? Ring zero? Nuclear launch keys? 🤔

...I may be overthinking this.

My gut says you're overreacting, but it's a good and secure way of thinking, so I'll answer your questions to the best of my ability.
This software needs root.

Differences:
the changes they made fixed actual issues users were having and other devs(for example nwilder) were dealing with instead of an issue that exist only in the issues without anyone we trust reporting existing issues.
Also this maintainer asks actively for issues to fix.
This project isn't very useful and as such popular for servers, which are the main targets on the linux ecosystem.
I checked the changes and found no Binary changes.
The old maintainer had archived the project already for some time before the current took over, meaning that the project had already had some time to decline in popularity, because of lack of support.

Things that are the same:
New maintainer and overworked old maintainer.

Edit:
also this is python based, so more people can actually understand their changes.
With my basic scrolling I found nothing directly alarming.

But what if they learned from the xz experience, and now they are going to work on building trust for a year by doing real work before sneaking in an attack?

(Alright, alright, *this* project is not widespread enough, but the atacks are getting suffisticated enough that your argument is not enough)

Maintainer replacement is a rare event.
Big projects are often maintained by the same person for more than 10 years.

The xz attack was "just" ~3 years of work, because they correctly predicted(not as impressive as it sounds) a maintainer that had already been maintaining a valuable project for a long time, who would snap within a manageable amount of time.
For this reason they basically immediately enabled the malware function after this rare event of, which they benefited.

If this maintainer replacement is contrary to the xz attack a cog in some larger more elaborate scheme instead part of the finishing blow, we're dealing here with an attacker with far more resources than the xz attacker(~6 years of dev team time instead of ~3 years, or 1+ election cycle instead of 1- election cycle).
My check ascertained me they're not running the same script as 90% of the current known maintainer replacement attackers.

Also maybe It eases you to know that es20490446e has been active for 7 years(, which is 4 years longer than Jian Tang) and has an inactive period of 3 years before that, which implies that they've had a healthy junior dev inferiority complex.
They also have a widespread widespread social media presence [External Link], which is less common among adversaries, because it makes it easier to trace you.

View this comment - View article - View full comments

Quoting: tfkDon't want to spoil the fun here. But this situation is rather similar to the xz vulnerability. Original dev overworked, other one jumps in. Makes all kinds of changes. Who is es20490446e? Does the software need root access? Ring zero? Nuclear launch keys? 🤔

...I may be overthinking this.

My gut says you're overreacting, but it's a good and secure way of thinking, so I'll answer your questions to the best of my ability.
This software needs root.

Differences:
the changes they made fixed actual issues users were having and other devs(for example nwilder) were dealing with instead of an issue that exist only in the issues without anyone we trust reporting existing issues.
Also this maintainer asks actively for issues to fix.
This project isn't very useful and as such popular for servers, which are the main targets on the linux ecosystem.
I checked the changes and found no Binary changes.
The old maintainer had archived the project already for some time before the current took over, meaning that the project had already had some time to decline in popularity, because of lack of support.

Things that are the same:
New maintainer and overworked old maintainer.

Edit:
also this is python based, so more people can actually understand their changes.
With my basic scrolling I found nothing directly alarming.

View this comment - View article - View full comments

Quoting: preludelinuxWell with Recall im sure that will increase quickly. Its interesting that devs still make mac ports before linux native ports though and says they make more money on mac when there are more gamers on linux.

To Mac users it makes sense to spend 10$ on an emulator and 200$ on a set of headphones and they let apple manage their system settings.

View this comment - View article - View full comments

Bwahaha, another. Lets watch them suffer.

View this comment - View article - View full comments

Quoting: denyasisI used ClamAV, but it can be finicky with time outs on large files, etc.

Considering how wide open user space can be, I've always been kinda surprised how lacking Linux security has always been with protecting the user. I always chalked it up to the mentality of "The user is on their own" and "We're too smart to download junk or visit a bad website".

Linux is developed by and for enterprise users and you see that really strong in the security space.
Everything exists, but it requires a degree in computer science to be useful.
SE-Linux(permission system used by phones(IOs and android)), ClamAV, special security fork of the kernel, security flags when compiling your own kernel, IPtables, etc.
Some security features actually do leak to us idiots though.
Strict division of user and root.
Password by default.
Executable flagging.
Clear file identification(both the UI and the system use the same bits for file type indication).

View this comment - View article - View full comments

Quoting: MalIt's all nice and good but far from the tipping point.

Does anyone have some kind of research/analisys that tries to identify the % at which point the "network effect" will trigger?

https://web.archive.org/web/20230204153910if_/https://www.degruyter.com/document/doi/10.2202/1446-9022.1256/html [External Link]
This paper answers your question for a simplified model, but it's complex enough that I can't do the math.

View this comment - View article - View full comments