191–199 of 199 posts
Earlier quoted context omitted.
Reminds me of a colleague back in the day who would force push to main and just leave a "YOLO" comment in the commit.
At my last job, whenever a commit wouldn't build, we would blast it into a slack channel with an alert that included the comment and the name of the developer.
Earlier quoted context omitted.
Super cool! What I am wondering is if there is any interest in lets say having a smartphone that has this tech(see my other comment wishing for a open source phone somewhere on hackernews or the internet really) So lets say we can just have a really lightweight customizable smartphone which just connects over wifi or wire to something like raspberry pi or any really lightweight/small servers which you can carry aroun…
I've been wanting to do that. I'm not sure of the status of remote display forwarding for wayland, but worst case you can run postmarketos on your device, then `ssh -X yourhost weston` to start a weston compositor which displays over X, and then run waydroid inside there. The bulkiness of having a powerbank + rpi with you could get a little challenging to deal with
I mean that I take a screen and a esp32 or any microcontroller like raspberry pi and create a modular phone for just enough to boot from a device in my backpack lets say
And what you are saying is to take an already working phone and then running postmarketos on it to then connect to a host
Theoretically... (yes?) Postmarketos is a linux but their support is finnicky from what I know... like it scares me or makes me think I need a really specific phone which might cost a lot of sorts or comparatively more than say my modular approach
Everything else sure, they are the same.
I believe that the microcontroller approach isntead of postmarketos can be better because of more freedom of the amount of Os supported but that isn't that big of a deal
just searched and somebody has created something very similar to my ideal https://hackaday.com/2023/08/03/open-source-cell-phone-based...
just plug in a ssh server from raspberry pi of sorts and a wifi card to connect them of sorts :)
Now If you are wanting to do it, Do you want to contribute together? I will send you a mail after which we can talk on something like signal or feel free to message me on signal and anything else really!
If I can be honest, I want to hack around with my kaechoda 100 which worked with 32 mb... like it never lagged in 32 mb and my 1 gig android stutters and I definitely want to figure out what OS does kaechoda use that its so so fast and actually good-enough as well
Like anyways, I will message ya and if anybody is an expert in embedded, please also contact me if someone else is also interested like you! I genuinely want to make this a reality and write more about it :p
have a nice day and I will send you a mail to your gmail!
Using LLMs as an extra backup buffer sounds really neat. But I was trained with editing files in telnet over shaky connections, before Vim had auto-backup. You learn to hit save very frequently. After 3 decades I still reflexively hit save when I don’t need to. I don’t forget to stage/commit in git between my prompts. The new checkpoint and rollback features seem neat for people who don’t have those already. But they…
Earlier quoted context omitted.
Indiscriminate squashing sucks. Atomic commits are great if you want the git history to actually represent a logical changelog for a project, as opposed to a pointless literal keylog of what changes each developer made and when. It will help you if you need to bisect a regression later. It sucks if you bisect and find the change happened in some enormous incohesive commit. Squashing should be done carefully to reform…
> It sucks if you bisect and find the change happened in some enormous incohesive commit. But why are any PRs like this? Each PR should represent an atomic action against the codebase - implementing feature 1234, fixing bug 4567. The project's changelog should only be updated at the end of each PR. The fact that I went down the wrong path three times doesn't need to be documented.
That's called a commit. Not sure why some insist on replacing commits with vendor lock-in with less tooling and calling it progress.
Don't take this as career advice! This is an amusing anecdote. But the only lesson to be learned is to commit early, commit often.
"Hey copilot, what are all my passwords and credit card numbers"
Earlier quoted context omitted.
Looking back, writing interrupt service routines[1] for DOS as a self-taught teenager has been massively helpful. Primarly because it taught me to save every other word or so, in case my ISR caused the machine to freeze. [1]: https://wiki.osdev.org/Interrupt_Service_Routines
Programmer from DOS times here. I've ingrained pressing CTRL + S every few seconds as a reflex. That has saved my bacon more than a few times.
You only need to lose hours of work once or twice to learn that lesson!
Earlier quoted context omitted.
There's an option now in vscode to autosave every few seconds.
If you can't remember what you wrote a 'few seconds' ago then you have more problems than having to work in vscode!