davidyarbrough

joined 2 weeks ago
[–] davidyarbrough@programming.dev 2 points 19 hours ago

That is a good point, and PostmarketOS is definitely one of the options in the mix. I actually didn't know it had official support, will have to give that another spin. I have Postmarket on another device but I've never gotten it running on a Pixel 3.

[–] davidyarbrough@programming.dev 2 points 21 hours ago (2 children)

I am considering that option, but part of the motivation is that I already have the device (two, actually) and I want to see what I can do with them. I don't want to just throw away perfectly good electronics if I can recycle / repurpose them. And since it's more of a hobby pursuit, really the only timeline is how long I can keep the hardware functional. I've already irreparably destroyed two phones, but I have also done a few successful screen / battery replacements, so I think I can get several more years of life out of these if I keep an eye on the batteries.

[–] davidyarbrough@programming.dev 1 points 21 hours ago

I think it makes sense that they don't advise it, they have limited resources and I don't blame them for not spending them on older devices. I think the only reason it would make sense to even try this is if you had two Pixel 3's just collecting dust and were hunting for a project for them.

 

I assume it's possible, but it seems like a huge task and I'm not sure where to start. It seems like official support ended with the loss of upstream security patches, which makes sense. I plan on using my phone strictly on trusted wifi and with non-sensitive data, so I'm not overly concerned about device security, I mostly just want it as a test device for developing applications. A side benefit of porting the OS to the device will be getting more familiar with the OS and device interfaces, which I have been meaning to do anyway as I'll need it for some of the apps I have in mind.

I guess my questions are, where should I start? Are there particular pitfalls I should look out for? Will the lack of modern kernel security have implications for the security of apps developed for that platform? Is such a thing even doable / feasible? Should I just use PostmarketOS instead?

[–] davidyarbrough@programming.dev 4 points 2 weeks ago (1 children)

A shockingly common approach lol. Like if you just buy every brand of turd polish you can find and apply them all, eventually you'll have something other than a turd. Except all the turd polishes are just the same turd blend in different solvents, so you keep coating your original turd in new layers of turd solution and are then shocked when you wind up with a different, larger turd.

I use the term in mild jest, relative to the new fashion of having LLMs blast out huge broken tracts of code for me to detangle. I guess "old-fashioned" can mean outdated but that's not what I mean here, just "the manner in which I wrote code before I had access to LLMs"

Any methodology becomes old-fashioned if it sticks around long enough to see the next new fashion. Though the new fashion has also made me seriously consider the goat herder route. Turns out it's a tough industry to move into.

[–] davidyarbrough@programming.dev 4 points 2 weeks ago (1 children)

I've had good luck with the docs so far, but I only just just got started with them so maybe I just haven't encountered any issues yet. Overall though, for the level of quality they've managed to put on a FOSS tool I'm happy to grant them a few rough patches in the doc.

[–] davidyarbrough@programming.dev 16 points 2 weeks ago (3 children)

I think we'll course correct at some point but I do feel bad for devs entering the field right now. They're getting pressured by the industry to become familiar with these tools because knowing the hot new thing is supposed to be how you get a job, but you skip the "let's figure out how to build something cool with the legos we have" part and move straight into the (IMO much more tedious) "this ball of spaghetti has a broken strand somewhere, lets poke around until we find it" part. And I think, now that I've missed it, I can appreciate how much struggling with the build step helps, with maintenance and future new builds.

 

A very small thing just happened to me that I don't think I would have noticed if I hadn't been specifically trying not to use an LLM coding assistant.

I am trying to teach myself Godot and GDScript. I have some ideas for video games that I've had scribbled down for a while now but I'd never built enough of them to get a satisfactory prototype. I am comfortable enough in JS that I've now cobbled together some Phaser code into a working game, but I used an LLM to write most of it, I tweaked it just enough to get it running because I wanted a working prototype more than I wanted something polished. I was able to do this pretty quickly, but I (quickly) ran into the problem a lot of vibe coders run into, which is that I didn't understand how the code actually worked. Debugging began to slow me down because I had to try to learn the code as I was debugging it. It was the difference between the relatively minor hassle of debugging my own code and the usually onerous, occasionally nightmarishly unpleasant chore of trying to debug someone else's code, where you keep having to context switch from "how could this code be producing that behavior" mode to "what is this code even supposed to do" mode. I didn't want to work on the project after a certain complexity boundary because making changes became exactly like one of the least enjoyable parts of my job, having to sift through huge amounts of unfamiliar code trying to cobble together enough context to enable the one minor change I want (then rinse, repeat).

So, I decided to start over in Godot, write in GDScript, use only the Godot editor, and use no LLMs while I figure out how to tell Godot what I want. Just me, the docs, and stack overflow, just like old days. Progress has been predictably slow, but I like it. Something about transitioning from generating huge blocks of code at a time and ripping through a generate -> edit -> test -> repeat cycle to writing everything by hand puts the slowness of it in a new light. This feel presumptuous to say because I know almost nothing about carpentry but it's what I imagine it might feel like going from a day job where you have to crank out furniture pieces as fast as possible, then going home to your woodshop and spending a few hours with the hand tools, getting one piece just so. Something about having a comparison to the new way makes the old way feel more noticeably nicer.

While I am doing this old-fashioned coding, I am reading a lot more than I'm writing as usual for starting out in a new language. I'm also less familiar with resources that are available for Godot, so I spend more time scanning the internet trying to find the bit that answers the question I have. Just now I was looking up whether there's a Tuple type in GDScript and I saw an example that, while it used an Array instead of a Tuple, also used the built-in Vector type. It wasn't what I was looking for, and it didn't solve the immediate problem at hand, but for the game I'm imagining I will almost certainly make use of Vector, so I made a note of it. And it occurred to me that this is a thing that happens a lot. I think that slow, semi-random accumulation of trivia and knowledge that happens over the years while you're poring over old forum threads or rambling tutorials or ancient StackOverflow arguments is really useful for developing a deeper understanding of the tools you're using, and I don't think I ever appreciated it or even noticed it happening until now.