kcxt @ home

just got CC'd in an insane email along with a bunch of other kernel devs, seems like someone went off the deep end with chatGPT. Documented it in a Gist, anyone have any theories? XD

https://gist.github.com/kcxt/2489f17398cd1ea10da8be516323582d

I would recommend jumping to line 490 for the weirdest bits https://gist.github.com/kcxt/2489f17398cd1ea10da8be516323582d#file-prepare_our_fighters_100k_1_million_30_million-c-L490

this looks so goofy lmao, like a bad ai generated image of a raspberry pi

bit of a shower thought but wouldn't it be kinda dope to make a drop-in replacement mainboard for the ipod classic? i have a 6g running rockbox which i love dearly, but my headphones are bluetooth.... i've been working up the energy to build a proper bluetooth mod, i've seen various attempts which are either external (sucks balls), and/or have other weird issues and limitations

to me the obvious way to do it was to wire up an esp32 to the i2s pins on the DAC, run the antenna to the inside of the usb connector or headphone jack (maybe??) to avoid having to modify the metal chassis and wire it up to the accessory port UART and talk to it from rockbox to add a bluetooth menu. it would totally be possible to add wifi too and have it sync to last.fm or something when you're at home

someone did a very similar thing to the ipod nano 3g but just hacked a bluetooth menu into the rockbox bootloader which is extremely neat fwiw

but like, the esp is not that far off the ipods main CPU right? i mean the tangara does a lot of awesome stuff with it

so the appeal mostly comes down to the joy of rockbox in particular (for me it just has a certain whimsy that only exists in FOSS projects that have been around for 20+ years (see also: U-Boot))

so then it's like what if i just got a batch of the same DAC that's already used in the ipod (and hey it can support multiple DACs why not) and designed a drop-in replacement... people already make replacement parts for everything else so you can build an ipod from scratch, only the mainboards are a limited resource i thiiiink (could be wrong tho lol)

aaaanyway, with the success of the tangara (extremely dope project!), idk if the nostalgia pull of the ipod is enough to fund a project like this

but gosh it would be cool to have a drop-in replacement that could run rockbox or even the tangara OS and give you the same feel as an OG iPod with custom firmware

or uh, if you were feeling suitably (in)sane about it write an emulator to let you run the original ipod firmware, that would be honestly fucking dope

#ipod #rockbox #tangara

i always thought "room temperature IQ" was a crazy diss but i just realised it's american and they mean Fahrenheit 😭

terrifying reality check, all the comments are people being like "yeah my brain is so fried at the end of the day from the cognitive overload"

https://www.reddit.com/r/ProgrammerHumor/s/rfadphtuOu

watching FLCL for the second time. still no idea what the fuck is going on, still somehow a banger show

sooo i tried using the new b4 review TUI for my last U-Boot PR and it was a bit of a disaster. I understand the process being a bit clunky to begin with but the whole process of actually setting up a branch was really involved. It failed to update a bunch of series on pathwork, and the b4 ty emails it generated had completely wrong commit SHAs

I get that the intention is primarily patch review but even for that it feels less like a tool i can utilise to automate the process and more like an imposed workflow that offers little flexibility

the thing that really pissed me off in the end though was realising that b4 review was VIBE CODED, kinda explains everything... This tool had so much potential but i struggle to see now how it will deliver when AI is involved in building it

#kernel #maintainer #b4 #mainline #patchwork #foss

@danirabbit@mastodon.online we have had a pretty good experience with it in pmos, although i haven't been directly involved in expenses and stuff it's fairly straightforward as i understand it. ofc it depends on what fiscal host you use since they are responsible for actually managing the funds and approving invoices and stuff

@ptrc@social.treehouse.systems eh, if you're the kinda person to think twice when you see stuff like that it takes 30 seconds to go to postmarketos.org/team and spot the woke pronouns

@ptrc@social.treehouse.systems pretty sure that's just the wording of this event booking system, there's nothing to read into and nobody is going to be checking IDs????

@dalias@hachyderm.io @womble@infosec.exchange @eigen@mattstodon.panar.ooo @mhoye@cosocial.ca never expected this level of conspiracy posting from you

@teohhanhui@mastodon.social truly gross :/

@teohhanhui@mastodon.social i think so? they make it harder and more obfuscated with every dang update

wondered why vscode was running like total shit after a recent update, then it popped up telling me the extension host crashed and offered to do an extension bisect so im like sure why not

i go through picking can/can't reproduce just based on vibes of how shit it was running

i have 116 extensions installed and THIS was the end result of that, joker moment of a fucking generation. fuck microsoft

(if you reply to this telling me to not use vscode i will probably block you, yes that includes suggesting codium or whatever. i wish this wasn't the workflow i ended up with but it is and now isn't the time for me to switch)

guess i gotta learn german just to watch anime, crazy how german netflix doesn't have english subs for a bunch of shows

I just published a tool I've been working on for ~3 years! In short, it provides a nice interface to interacting with Qualcomm register maps by allowing you to decode register address/value pairs or emit C code that can decode registers at runtime.

Unfortunately this means it's only really useful if you have access to Qualcomm register maps (i.e. because you work for a licensed vendor). But I figured it's worth sharing on the off chance someone finds it useful!

It supports parsing register in the auto-generated ".per" file format intended to be used by TRACE32 as well as ".FLAT" files (although those are known to have issues).

It would be very possible to build our own datasets of publicly documented registers from kernel sources and such.

https://github.com/linux-msm/decodepurr

Fantastic Mr Fox is such a wonderful work of art, brilliant movie

Spending April 1st watching Red Dwarf, can recommend if you want an wasy laugh.

British comedy has some absolute classics it has to be said

Hearing Craig Charles on the radio a whole lot growing up definitely biased me though heh

@drakulix@social.dreampi.es @justsoup@mstdn.social ahh that would totally be doable with a systemd-timer!

@justsoup@mstdn.social i neeeed a pmOS poster with this

Looking for a cozy Sunday project? The fairly new #postmarketOS documentation website docs.postmarketos.org has some low hanging fruit that might be interesting to some folks

The guide for upgrading to new postmarketOS releases needs to be ported over from the wiki: https://gitlab.postmarketos.org/postmarketOS/docs.postmarketos.org/-/work_items/25

And the artwork repo which contains our style guide should be added to the docs website so its more easily available: https://gitlab.postmarketos.org/postmarketOS/docs.postmarketos.org/-/work_items/32

#foss #linuxmobile #opensource #documentation

@sbysb yeah idk, i generally subscribe to the kernel/uboot workflow where you prepare patches carefully and actually have to write good commit messages. I make heavy use of git absorb and manual commit --fixup to make improvements to a patch series so it encompasses sensible changes from the context of the codebase rather than representing a timeline of changes from the context of the developer (which generally has a lot of unnecessary context and is missing more important context) overall making code harder to understand thats the mindset from where im speaking anyway, if you don't care about the quality of individual commits in the same way then whether they're human or AI written becomes quite a different question

@sbysb having a "---" line break at the end of the commit message followed by some AI generated description would be less harmful, it also has the bonus that it gets removed if you export it with git format-patch and apply it with "git am", so could be removed easily from being committed permanently to the repo while still being easily found in MRs or mailing lists

the effort people went through to capture the entire sound track of the switch 2 mariokart is crazy impressive

from glitches to noise cancelling, all because there was no setting to disable sound effects xD

https://youtu.be/aet8rWKs-A0?is=

@matthewcroughan it's genuinely depressing and i unironically think once we return to sanity there will be a grieving process for those of us who will no doubt spend the next few years advocating for people to actually be themselves and not engage with the world through the filter of an LLM. The collective trauma of social media aint got nothing on this shit

if you're using AI regularly to generate text/presentations that you intend to use persuasively i don't think i can trust a single thing you say. Where does the AI end and the human begin?

I think this is why im so against AI generated commit messages especially if the code was written by a human, you wrote the code so you should be able to demonstrate that you understand what the change does and why.

If you're deferring that to an AI and you made a subtle logic error that it decides to justify for you suddenly we have obfuscated our own fucking zero days. Good luck finding the bug if the commit message describes the error as if it was intentional.

For general text, if you start with the conclusion and let the AI write the justification then there is no justification!!! Details matter, having a paper trail for decision making matters.

I wonder how many executives will escape the consequences of their white collar crimes by blaming AI.

AI zombification is coming and it's going to create a distinct difference in communication styles between those who do and don't use it, honestly that point is already here.

And we're gonna find out yet again that marx was right when it becomes clear that AI usage correlates with class lines.

@jens@social.finkhaeuser.de *we* have a strict anti-AI policy for our contributors. Why don't you go and shame Ubuntu or Fedora who are actively pursuing shipping AI features in their distro rather than focusing on us purely for using the same init system as every other mainstream distro? im on board with your anti-AI stance, it would have been nice if systemd had stayed away altogether, but what practical outcome do you want from us? https://docs.postmarketos.org/policies-and-processes/development/ai-policy.html

@kestral@masto.hackers.town @jens@social.finkhaeuser.de i am too, i hope to god the bubble pops. i have a lot of patience for people who have concerns or questions, im more than happy to talk through my thought process because this is something i care about deeply. but at the end of the day ive learnt that it's often a waste of time to try and reason with people who are making sweeping dismissive statements of a project i have poured my soul into just because of its dependency on a project they dislike. This goes especially for systemd, we had and continue to have a lot of discussions with them about the state of the ecosystem and how we want to use their software, if we didn't align with them on a technical level we wouldn't have made the switch. our goal is to build a mobile OS that actually respects the user without compromising on being accessible to non-technical folks or on security. If your priority is to not use systemd then i just have nothing else to say because you clearly aren't taking the utilitarian approach and we have a fundamental misalignment. we are right now trying to seize the moment that the current geopolitical landscape has provided us, we aren't going to succeed in making it to production in a reasonable timeframe if a large part of our focus is reinventing the wheel (and having to get all our security code audited). There are just more important issues for us like figuring out how to enable secureboot on Android devices with pmOS, making the UX and telephony functionality actually reliable, collaborating with vendors, etc... I have no doubt that once we actually get Linux Mobile in production with at least acceptable levels of security that the devices we support will be able to run whatever systemd-free OS you want, I welcome that era with open arms. But we have to pick our battles and there is no world where it makes sense for that to be our priority. I think out original announcement blog post explained things pretty well, i should probably just link to that when people post comments like this https://postmarketos.org/blog/2024/03/05/adding-systemd/

@jens@social.finkhaeuser.de crazy take considering it's been less than 2 months since systemd started using AI for code review. Critique all you like but at least don't disrespect us by doing it in blatant bad faith we switched to systemd over 18 months ago! if we wanted to avoid it we would be setting our progress back half a decade at least. at the end of the day there's no ethical consumption under capitalism, it's a constant battle between harm reduction and moral principles, the pros did (and imo still very much do) outweigh the cons. but by all means give us an alternative that meets your standards

just realised cowboy bebop predicted the fucking columbia disaster ~4 years before it happened

the columbia shuttle is featured in episode 17 and one character comments about how all the heat shielding tiles fell off (thankfully they all survive though)

glad too see fedi is increasingly becoming the hellsite twitter used to be lol

maybe i should try to be a bit less volatile with my hot takes?

@InkomTech@infosec.exchange ok i'll try to clarify, since i don't think your quite understand my position.... THESIS: I am fundamentally ideologically opposed to legislating age verification into operating systems, for all the obvious fucked up dystopian outcomes that inevitably leads to. Maybe I should have put that in all caps or something because people really seem to want to misrepresent my position. ANTITHESIS: Should age verification legislation get passed, we should not throw our distro maintainers and middleware implementers under the bus by getting mad at them for following the law (i mean unless they come out and say they actually think the legislation is good, in that case fuck em). SYNTHESIS: we can oppose age verification laws without going after implementers for trying to avoid exposing themselves to fines. it's a rock and a hard place for distro devs and im kinda shocked that people seem to unwilling to acknowledge that reality. Thanks for the condescending comments (and extremely weird call out of Jane??), i hope your irc buddies got a kick out of it(???) i predict you either don't respond or hit me with an ad hominem, prove me wrong!

@hipsterelectron@circumstances.run i think i'm missing several layers of context to understand your point here tbh?? /gen

@eliasr@social.librem.one @pid_eins@mastodon.social i think that's fair. I certainly don't think all legislation is inherently morally good, but neither is it morally bad. still though im not a huge fan of prescribing motivations on maintainers

@navi@social.vlhl.dev @jane@smolhaj.social @freya@social.highenergymagic.net I think I could be persuaded either way on this topic tbh, it depends a whole lot on the family, the interests of the kid, their relationships, etc...

@eliasr@social.librem.one @pid_eins@mastodon.social superficially sure that makes sense, if FOSS existed in a vacuum I'd be totally on board. But despite the efforts of many to create and share software while taking zero responsibility for the consequences of their actions, software still exists in the real world.

To be clear (though I think i said so in my post) im not in favour of governments imposing restrictions or requirements on software, these laws are arbitrary and almost as hard to define concretely as they are to enforce.

With that being said, if I may attempt to challenge your underlying assumptions here: how are the requirements of law different to the requirements of (for example) a security minded individual, or an enterprise customer?

I want to daily drive a Linux phone but I care a whole lot about security and implementation details basically mean to only way to implement a truly secure OS stack is to use proprietary "trusted apps" from Qualcomm to protect my OS encryption keys (think software backed TPM), I have no doubt in my mind that people may object to the idea of Linux loading proprietary trusted apps into the "secure world" to implement this functionality, but would you object to the kernel adding support for this because it might not be "what the users want"?

I guess im making two points here so i'll try to separate them:

1. At what point is a topic so technical that the opinion of an average user with minimal context shouldn't be trusted?
2. How do you in practice enforce that "libre" software is always serving "the users" without alienation and othering?

Like I personally am always pretty confused and occasionally frustrated by the systemd unit constraints system, did i want Requires= or BindsTo= or WantedBy= or Requisite= etc.... Similarly the fact that every openrc service file is a shell script is infuriating, does these mean these aren't libre projects?

And again, yes I think the laws are fucking dumb, i just think criticising systemd and XDG in particular is just virtue signaling here, not advocating for real change. I hope i don't just come across as contrarian, you're making a philosophical argument so I hope it's ok to respond in kind.

@jane@smolhaj.social @freya@social.highenergymagic.net agreed, this was basically the point i was trying to get to. parental controls in Linux are absolutely a good feature to have, and the GNOME community have earnt a lot of respect from me for implementing this functionality. The ability to impose restrictions on non-sudo users (particularly children) is NOT a restriction of freedoms, I'd argue it's the opposite. Knowing you can give your kids a device running a FOSS OS while being able to ensure they aren't accessing software they shouldn't is a good thing, give them the freedom to enjoy tech without looking over their shoulder

@dvshkn@social.treehouse.systems i have no idea, but as far as i can tell the work so far is basically just laying the groundwork, nothing specific to the legislation that being said, IANAL obviously but surely there has been prior art in this sense, at the end of the day are distros (that don't explicitly sell/ship their software in california in this case) even responsible for people who live there installing their software even if it doesn't follow local laws?

@gourd@indiepocalypse.social eh don't get it twisted, claude didn't event reply to the review request on the birthDate MR (for real though yeah constructive criticism is good, but don't be reductive about it)

people on reddit are doing a whole lot of yapping about age verification in Linux

I would generally agree that the whole approach of these laws is total dogshit and clearly a wedge issue to enable stricter surveillance laws in the future

at the same time though, the actual implementation and potentially having a portal which exposes the users age bracket seems totally reasonable as a way to implement parental controls... I'm also not totally against holding service providers to higher standards for data processing when it comes to minors, and hey if they're doing that why shouldn't adults get the same treatment?

what im totally miffed about though is why the fuck would you get mad at systemd for adding a birthDate field to userdb, what would you have them do? Would you rather every desktop environment had its own way to store this data??

An XDG portal for this also means you can *trivially* write a stub that always identifies you as an adult or even lets you pick per-app (heck maybe per website! that might be the new cursed way of avoiding trackers under late stage capitalism)

and yeah it sure would be shit if we get real-id laws in a few years, but systemd or XDG standing on "principle" and refusing to implement this API is absolutely not going to lead to better outcomes for anyone. The last thing we want is for users in certain regions to wind up relying on implementations maintained by distros or random individuals, if we need to have this crap the least we could ask is that it's maintained by established and trusted people in the open source community!

@YaLTeR@mastodon.online @alexia that's why we're also building automated testing which will include automated testing of audio and phone calls. eventually we hope to have a comprehensive test suite that every update must pass on every device before it gets shipped

RE: @fesshole@mastodon.social

what are the requirements for a poo to be an Elvis killer 😭😭😭

gonna beat @spyraks@social.treehouse.systems at rock/paper/scissors, i play rock

whoa be careful of drop bears out there if you're visiting australia, my girlfriend lives there and said she almost had her eyes clawed out by one. crazy country

me after rambling a bunch over dinner: "but i digest"

@matthewcroughan@social.defenestrate.it i respect it for what it is, but various things just don't vibe with me super well... the linker stuff is very neat, im a bit jealous of that also the ability to bisect your whole OS is very cool, im hopeful that we'll eventually have something similar albeit considerably more cursed with pmOS, but that involves maintaining an archive of packages and version constrained apk world files to list every package in the image.... It would however let us fairly easily narrow down a regression to a specific package or easily reproduce an image for debugging proper reproducible builds are still quite a ways off though

@matthewcroughan@social.defenestrate.it @maris@chaos.social hehe nah i just thought it was funny XD i know juuust enough about nix to never want to deal with it tbqh...

i've been pretty quiet regarding work stuff lately, but finally have something to share!

here we have Qualcomm display drivers up and running, demo'd on the Ayaneo Pocket S2, but it also works on the SM8650 HDK.

This isn't relying on an existing framebuffer being set up, this is U-Boot as the first stage bootloader. So there unfortunately isn't much of a benefit here on most of the phones we run U-Boot on today since we already have a framebuffer xD

The pocket S2 was a "fun" first target since it uses dual DSI, so both DSI controllers are used to drive a single panel.

It's gonna take quite a lot of cleanup before this can go upstream (particularly in the clock drivers), but I hope we can expand this support to other platforms and enable additional functionality like DSC. This brings us one (big!) step closer to a viable alternative bootloader for Qualcomm mobile devices.

That all bring said, the current diff is ~10k LoC 😅

just saw someone write "quote on quote" instead of "quote unquote" (or just literally using quotes....

@dianea @shadowfals @blinry what exploit is that? EUD? personally definitely not gonna advocate for using anything that isn't particularly hardened if you're a target, if pmOS ever gets to that point it won't be for quite a long time 😅