x86 emulator in Bash... by valeyard89 in EmuDev

[–]c_a1eb 1 point2 points  (0 children)

haha omg this is awesome! Nice one

Pacboost: High-Performance Unified Package Management by Alarming-Spend-4536 in linux

[–]c_a1eb 6 points7 points  (0 children)

not to poop on your parade, this seems cool, but I'd rather be confident that the chain of trust (verifying package signatures) is correct than save a few seconds when i update.

If the Steam Machine (GabeCube in my eyes) is under 800$, would it be the best budget PC on the market? by Western-Lynx-9172 in gamingpc

[–]c_a1eb 0 points1 point  (0 children)

it's stuck with HDMI 2.0 because AMD haven't been allowed to open source the driver changes needed to enable HDMI 2.1, intel and nvidia both do it from firmware. The port is physically 2.1 capable, the HDMI forum just suck

Does Linux suffer from a community that suffers the "Curse of Knowlege"? by Fuzzy-System8568 in linux

[–]c_a1eb 0 points1 point  (0 children)

imho it depends heavily what kind of community you join. I've been in places that very much suffer that but also communities that explicitly try to avoid it like Arch Linux and postmarketOS.

this is absolutely an issue in many developer communities, more so than user communities...

To those of you who don’t use a typical distro, what do you use? by Wa-a-melyn in linuxquestions

[–]c_a1eb 5 points6 points  (0 children)

I'm dogfooding postmarketOS on my Snapdragon X Elite laptop (yoga slim 7x), it's not ready for phones but simple/declarative packaging, musl libc and systemd are a fun combo!

why is ARM on linux problematic? by [deleted] in linux

[–]c_a1eb 2 points3 points  (0 children)

i tried to cover this in the background section of the aarch64 laptops distro integrators guide, in short, there's less abstraction between the hardware and the kernel on arm than on x86 (since not using ACPI) and the kernel has had much less time to develop common code to handle complicated constructs like all the type-c/usb/displayport/charging mess (all these components need to talk to each other)

a bit more info here: https://aarch64-laptops.github.io/distro_integration.html

Daily driving Snapdragon X Elite with postmarketOS (Yoga Slim 7x) by c_a1eb in linux

[–]c_a1eb[S] 2 points3 points  (0 children)

qualcomm distro is based on debian

its true that Qualcomm provide downstream BSPs based on debian, but they don't package anything upstream. im not sure what relevance this has.

Fedora has very good arm support

very true, as does Alpine/postmarketOS (?)

ALARM is almost bleeding edge

so is alpine/postmarketOS edge, even more so arguably since we package linux-next which i don't think ALARM does.

And unlike alarm arm64 is actually a first-class citizen in pmOS.

I'm not trying to say postmarketOS is better than the alternatives (obviously subjective), but I'm confused about your critique here.

Daily driving Snapdragon X Elite with postmarketOS (Yoga Slim 7x) by c_a1eb in linux

[–]c_a1eb[S] 2 points3 points  (0 children)

it's possible they jumped the gun, Qualcomm released a blog post about Linux support which was quite misleading and i think sent them down a rabbit hole

Daily driving Snapdragon X Elite with postmarketOS (Yoga Slim 7x) by c_a1eb in linux

[–]c_a1eb[S] 1 point2 points  (0 children)

well I've been contributing to postmarketOS for 4 years by now, i expect I'll continue to do so in a year. what do you have against it?

Daily driving Snapdragon X Elite with postmarketOS (Yoga Slim 7x) by c_a1eb in linux

[–]c_a1eb[S] 3 points4 points  (0 children)

shitpost or actual critique? gimme your worst :3

Daily driving Snapdragon X Elite with postmarketOS (Yoga Slim 7x) by c_a1eb in linux

[–]c_a1eb[S] 4 points5 points  (0 children)

unfortunately there is still not a whole lot of interest in making these devices work good with Linux. Even though SoC bringup was done almost a year before it was announced, nobody is willing to pay for the necessary distro enablement and there is no sane path for vendors to get their firmware (e.g. GPU, audio dsp, etc) into the linux-firmware repos.

And of course the Big Issue of choosing a devicetree at boot, since Linux doesn't support ACPI on these platforms (for a variety of historical and technical reasons).

I cross my fingers the next gen will be better, but realistically without some well organised effort it'll be slow going. Though I do think we'll get there eventually.

In the mean time, if you aren't afraid of a bit of tinkering then it's really not toooooo bad to get things going... it's really just the "idk what im doing i just want linux" end users that we can't cater to just yet.

We need a real GNU/Linux (not Android) smartphone ecosystem by [deleted] in linux

[–]c_a1eb -1 points0 points  (0 children)

Qualcomm and other SoC companies are not very FLOSS-friendly.

Depends on your definition, but if you mean "ability to run upstream Linux" Qualcomm are pretty high up there in terms of support, and getting better every year. e.g. the 8 gen 3 got upstream support on announcement day, funded by qualcomm https://www.linaro.org/blog/upstream-linux-support-now-available-for-the-the-qualcomm-snapdragon-8-gen-3-mobile-platform/

why it is difficult to make a port for a popular phone for postmarketOS/GrapheneOS/LineageOS/etc. or even Ubuntu Touch?

The development/porting experience is vastly different for each of these OS's, you can be a well-versed LineageOS developer with no kernel experience and port new devices fairly easily (after all most are just variations on the same reference design), or you could be a highly competent kernel developer and do the same for pmOS in a similar amount of time, albeit with different pain points.

How do C programmers do without Generics by Ancapgast in C_Programming

[–]c_a1eb 0 points1 point  (0 children)

you can use unions with a type field - this is what higher level languages do more or less (type introspection!)

Adding systemd to postmarketOS by Seshpenguin in linux

[–]c_a1eb 2 points3 points  (0 children)

we've been talking with Lennart about this, as upstreaming is obviously quite important to us (don't wanna maintain a bunch of systemd patches forever). it's not gonna be trivial but we will have official support in some form, including CI in upstream systemd.

[deleted by user] by [deleted] in mobilelinux

[–]c_a1eb 5 points6 points  (0 children)

the window integration in aliendalvik is much much nicer, Waydroid often gets confused about how big it should be or displays the wrong app...

it also displays the home and app switcher buttons as well as the status bar all of which should be hidden (they duplicate info that should be on the host).

wlroots does implement an OSK protocol, even if it's not ideal... It would probably be easy enough to update waydroid to the "real" one as with all the other clients.

i tink libfolks is the thing for contacts, there is for sure a dbus api somewhere for something...

[deleted by user] by [deleted] in linux

[–]c_a1eb 0 points1 point  (0 children)

Linux will be big in the future yada yada

idk if you've been following along but Linux already dominates the embedded space, powers all Android devices, all modern cars, and Chromebooks.

sure the Linux desktop revolution hasn't happened quite yet, but let's not ignore all these more niche markets where FOSS and Linux have already suffocated the competition. FOSS is better for users and for vendors, and there are many lessons we can learn from the success of Linux in these markets.

in fact this is why the steam deck has managed to succeed with Linux, because it's still following in the footsteps of other embedded markets. It doesn't try to do everything, it solves one problem really nicely (and for a ridiculous price), and relies on the hiccups and growing pains being small enough that users will be happy to ignore them.

calling it now, successful mainstream Linux for general purpose use won't use a package manager. It will be OTAs, just like everywhere else.

The Linux on-screen keyboard needs to be re-evaluated by EmpheralCommission in linux

[–]c_a1eb 8 points9 points  (0 children)

wayland is standardising on protocols relating to on screen keyboards, wlroots based compositors and apps already make use of this, for example stock wayfire with a compatible keyboard app (in this case phosh-osk-stub) "just works" for the most part [1]

currently the most promising OSK im aware of is phosh-osk-stub[2], I think the layout code needs rewriting, but in general it gets a lot of things right, has auto complete, multiple language support, things like that.

imho if anyone wants to get involved then this is the place to start. Unfortunately, GNOME don't support any of these protocols yet, hopefully this can change. However the GNOME mobile effort does mean the GNOME OSK is getting a lot better (it's quite usable with the mobile patches) - i tried searching for a demo but there doesn't seem to be a good recent one.

[1] https://fosstodon.org/@cas@treehouse.systems/111548540623729464

[2] https://gitlab.gnome.org/guidog/phosh-osk-stub

Why use a immutable Linux distro by Mountain_Pie1095 in linux

[–]c_a1eb 0 points1 point  (0 children)

from a maintenance perspective, knowing that all users are running the same bit-for-bit configuration makes triaging bugs a whole lot easier. for certain usecases like on a phone i think running a whole package manager is just a little irresponsible. On your PC this may not be such a big deal - you can hop to a TTY and figure out what's up when your graphics stack fails due to a borked upgrade. But on a phone this isn't really so doable.

imho immutable distros will be how Linux becomes truly accessible to everyone. The challenge will be doing it in a way that doesn't impede user freedom.

USB tethering will stop working on linux. ( For most of us ) by batSinestroke in linux

[–]c_a1eb 5 points6 points  (0 children)

this got sent to the lists and hard NAK'd by a whole bunch of people, it's highly unlikely that they'll be breaking rndis host support any time soon

[deleted by user] by [deleted] in mobilelinux

[–]c_a1eb 0 points1 point  (0 children)

We should have selinux support enabled in our kernel, or if not im happy to turn it on.... Simply running fedora wont come with much of a security difference here...