

Use ps -ef to find the source of the file.


Use ps -ef to find the source of the file.


find will catch more if you wildcard the name with "*windows*", but that’s a moot point: we don’t have enough info to jump to “malware” conclusions here.
Looking for malware by hunting for the name in a procid list won’t usually get far, you’d be better to netstat to see what various processes are listening or phoning home to confirm suspicions of malware.
Security is nice to have but it’s not the reason I’m using Linux, so handing over my photo ID to a third party I trust is an acceptable if disappointing risk.
And for us who don’t find it an acceptable risk? Will I need an ID to read a book next?


I usually don’t watch his stuff.
And it seems you didn’t watch this video fully either, or you weren’t paying attention. Muta’s an idiot and a tool who routinely masks inability to do anything with drama… Because he’s not very good at any of it.
He doesn’t dig into the reasons for any of his issues and readily admits that he just wants it done for him “I just want things to work”
The real problem with this post is you! Coming here casting this as some fundamental problem with Linux and posting it. Why bother?
It is fragmented.
The PostMarketOS community is active, but more importantly, there is a ton of wiki info not only on installing, but figuring out drivers, info on partition slots, etc. Armbian is another place to read.
The other thing to learn about is the DEs, specifically phosh, gnome mobile, plasma mobile, xmso, lomiri, etc. They all behave differently, so you’ll want to check out each one to see if you lean more one way or the other.
Good luck. May your journey be better than mine.
Man, I’m trying to soften on AI, but this post is just awful.
I’m not gonna say “don’t do it”, but I’ve dug into this deeply and I’ve turned away from RISC V.
RISC V is slowly being pidgeon-holed into embedded systems. This is not a bad thing, the embedded market (cars, tvs, industrial controls) is huge and diverse.
RISC V has had a very rough start to introduction into bridge-and-bus systems the way we know from Intel/amd because there have simply been too many iterations of CPU registers and capability flags for integrators to take the platform seriously enough to commit to piling a bunch of effort to design, produce, and lead sales on any RISC V platform. Even arm (especially v9) has settled some of these platform issues and is ahead of RISC V in adoption in the integrated platform space (as opposed to embedded).
Long story long, it is extremely difficult to write device drivers for RISC V because one would have to write half a dozen architecture versions, just for a niche platform that barely sells. Conversely, an embedded controller for, say, a vehicle gets a preliminary build and few revisions, ongoing support isn’t part of planning the same way.
Debian and alpine. Coming up on 27 years of linux for me.


Wow, grape army.


It is not good. I have the one plus 6t and tried pmos with a few of the ui choices. There are many, many broken workflows.


What is “cross process rendering”?
The problem with using an LLM for information is that you can ask chatgpt:
“please provide me with 3 different interpretations of the main function of the Linux command ‘ls’”
and you’ll get what you ask for. An llm is an inappropriate tool to lookup accurate information.
Meh… There have been a whole lot of braindead “pls do it for me” posts going around since the influx of windows refugees.
I’m not one to be a prick about answering questions to help out, and we all start somewhere, but “help me get steam and my LLM working on Kali linux” where ppl get in way over their heads is becoming a real problem. Worse, they will call the linux community toxic for suggesting they need more fundamentals first.
I interpret the post title as a general “try your best, and come to us when you’re stuck”.


The wonderful thing about Linux is that you can do what you want. The concept of what is a “server” and what is a “desktop” has, to some degree, been peddled to us by MS and Apple. In reality, what you have here is perfectly acceptable if it works for you.


Honestly, incus.
I know it’s not strictly a utility, but holy cow, Stephane Graber and his team have put the work into that product, such that anything you can do in the ui can be done in the CLI, and more.
Tab completion entries for all the resource types (storage, instances, image repos, etc), help entries for everything, it brings a tear to the eye.
I once thought it was cool to have standardised man entries, but even better is context-sensitive --help entries that work well. Almost all the discovery I’ve made using incus, I’ve made using the commands themselves.
It’s a real testament to how putting in the documentation work might be tedious, but it is a boon to both users and devs.


Oh, come on. Pretending that foss devs have no connection to users or the community is not a take based in reality. The Linux world is full of changes made or reversed by community sentiment, even for bigger players like Canonical.
The very core of Foss is allowing popular and useful projects to gain momentum by appealing to users. Sure, you can fork a project or start your own, but that independence of the devs is rooted in community support to go do what you want.
And I’ll repeat myself: this is different, foss devs and users both will not have the option to just “go do their own thing” if these laws all become reality.


I was with you, particularly with your anti-violence stance, until this comment.
The answer to disagreements in the Linux world has been to fork a project or make your own. This is different, neither devs nor users will have a say if these various laws are instituted.
The majority of users do not care, and even if they did it’s still not the user’s place to demand the FOSS developers listen to them.
Linux is not a megacorporation. It is an array of different interests that still manage to get lots of interesting stuff done, even with those differences.
This was not a cool thing to say.


Ah, that is odd. The systemd-analyze -blame command would break down all the systemd services by time, but if the delay is before or after the systemd startup process, dmesg or system logs should give you some hints about what is taking so long.


systemd-analyze
Can tell you about how long thing took to start, and the -blame flag can help pinpoint hangs and so on.
Are you waiting for a kernel patch, or is this support simply not available yet?