Threads for banna
-
banna
6 days ago
|
link
| on:
In Defense of Crusty Old Swiss Army Knives - An Exploration of Django & HTMX
I feel like this needs to be said, and I’ll say it here. I don’t believe the statement to be entirely true: “In software, there aren’t a lot of tools that are allowed to get old”
What the author might may be claiming is that old tools don’t get the spotlight as much as new tools. That seems to ring a bit more true in my ear.
-
-
I’m personally interested in the exposition of ideas or projects that revolve around low power consumption, recycled hardware, as well as general examples of accomplishing technical goals with minimal resources.
-
Then people need to make it easier to not use GitHub. I get the idea behind doing everything with email, email is vendor neutral. However the user experience is horrible. If they made it a lot easier to use, I would be all over that.
But, it’s hard to use. Especially with how email is restricted these days for reducing spam. I don’t think there’s a good option here. I end up using GitHub for things because it’s less effort out of my limited effort pool.
Edit: to be more succinct, if using email for git contributions is actually easier, then why is it more effort than using GitHub?
-
-
Mailing lists are a small component of the overall problem that a central platform like github attempts to solve in a single service. The organization is externalized with mailing lists, and aspects like public discoverability are just not accomplished with mailing lists alone. Examples of efficient organization around mailing lists can be seen in the wild, however most likely not as visually popular as that one github issue you see pop up in a google search.
-
-
It’s really an accessibility nightmare outside of centralized platforms… I agree 100% on the basis that GitHub is more convenient. However I was just outlining how mailing lists themselves are a portion of the tooling required to accomplish what GitHub provides in their centralized platform for git :)
-
I don’t care about your Apple device. That aside, the original intended workflow (outside of kernel development, for git in general) was for contributors to publish their own git repositories via HTTP, and for maintainers to pull patchsets from contributors by pulling branches from those repositories directly. Even in communities that have mailing lists set up, contributors often prefer to publish feature branches this way and not use email-based patch management. This method is forge-agnostic.
-
-
I appreciate your use of the word “shitty” and the
-1 unkindflag. I can use more words, if you like.The mention of iPads is intentionally disingenuous. Even when jailbroken, iPads are not general-purpose development platforms, and although there is an iPad Linux project, I don’t feel that I could endorse it right now as a way to make iPads into development platforms. This is not a new problem; I used to have an iPod, I ran iPod Linux on it, and I would not consider it a usable platform for anything besides playing music. Apple does make general-purpose computers, but the iPad is not among them. If the question is about how to contribute to Free Software from an iPad, then my reply is that success will be found by finding a different device for development.
-
My guy I did not flag you, I am simply not alone in thinking you were out of line. Your original reply can be broken down into:
I dismiss your iPad concern. Here is a description of the thing that I like, which does not address your other concerns, either.
You go on to legit ascribe deliberate dishonesty to the person you were originally replying to:
The mention of iPads is intentionally disingenuous.
That’s a pretty shitty way to respond to someone.
-
Let’s recap the points made so far in this thread:
- Email is not as convenient as GitHub for contributing to git repositories
- Email vs GitHub is a false dichotomy
- iPads can’t be used to contribute via email
- Contributions to a git repository can be published as another git repository
- My words are shitty
I don’t want to question your reading comprehension, but I really do think that you’re just farming for upvotes. For what it’s worth, I’ve given you as many upvotes as I can. Good luck.
-
-
-
-
-
-
-
-
I caught the bug to start tinkering on a toy project with higher intensity, where this toy project is an extremely minimal instruction set architecture implementation in Logisim. The architecture is based around a modified form of the classical Von Neumann architecture with an 8-bit instruction set. The most recent chunk of work involved re-working the existing immediate load instructions. I hope to continue to elaborate features within the assembler, and perhaps support a debugger implementation of sorts to make the thing easier to work with for educational purposes. The repository is hosted on github if anyone is curious: https://github.com/bannatech/tisc
Haven’t actually posted anything on my site (so I haven’t crafted CSS for it or anything), but I’ve collected a short list of homages and related posts (including a link to commentary on inspirations) here:
https://www.illucid.net/posts/homages-to-aphyrs-technical-interview-series.html
Left out a repo that translates the same Queen’s post into Rust because it wasn’t in narrative form, which felt important to me at the time, but idk, that’s cool too and available here:
https://github.com/insou22/typing-the-technical-interview-rust
The format is fun, I like how people adapt the themes from Aphyr’s original blogs. It’s a bit of a colorful show and tell without being too dry about the subject matter. Props to collecting all these formats into a repository!