Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)L

litchralee

@ litchralee @sh.itjust.works

Posts
4
Comments
240
Joined
3 yr. ago

  • Your thoughts on Code Reviews

    Jump

  • people that work on the same things can need each other['s] changes to move on

    If this is such a regular occurrence, then the overarching design of the code is either: 1) not amenable to parallelized team coding at all, or 2) the design has not properly divided the complexity into chunks that can be worked on independently.

    I find that the latter is more common than the former. That is to say, there almost always exists a better design philosophy that would have allowed more developers to work without stepping on each other's toes. Consider a small group designing an operating system. Yes, there have to be some very deep discussions about the overall design objectives at the beginning, but once the project is rolling, the people building the filesystem won't get in the way of the UI people. And even the filesystem people can divide themselves into logical units, with some working on the actual storage of bits while others work on implementing system calls.

    And even when a design has no choice but to have two people working in lock-step -- quite a rarity -- there are ways to deal with this. Pair programming is the most obvious, since it avoids the problem of having to swap changes with each other.

    I've seen pair programming done well, but it was always out of choice (such as to train interns) rather than being a necessary mandate from the design. Generally, I would reject designs that cannot be logically split into person-sized quantities of work. After all, software engineering is ultimately going to be performed using humans; the AIs and LLMs can figure out their own procedures on their own, if they're as good as the pundits say (I'm doubtful).

    TL;DR: a design that requires lock-step development with other engineers probably is a bad design

  • Your thoughts on Code Reviews

    Jump

  • Ah, I see that OP added more details while I was still writing mine. Specifically, the detail about having only a group of 5 fairly-experienced engineers.

    In that case, the question still has to focus on what is an acceptable risk and how risk decisions are made. After all, that's the other half of code reviews: first is to identify something that doesn't work, and second is to assess if it's impactful or worth fixing.

    As I said before, different projects have different definitions of acceptability. A startup is more amenable to shipping some rather ugly code, if their success criteria is simply to have a working proof of concept for VCs to gawk at. But a military contractor that is financially on the hook for broken code would need to be risk-adverse. Such a contractor might impose a two-person rule (ie all code must have been looked at by at least two pairs of eyeballs, the first being the author and the second being someone competent to review it).

    In your scenario, you need to identify: 1) what your success criteria is, 2) what sort of bugs could threaten your success criteria, 3) which person or persons can make the determination that a bug falls into that must-fix category.

    On that note, I've worked in organizations that extended the two-person rule to also be a two-person sign-offs: if during review, both persons find a bug but also agree that the bug won't impact the success criteria, they can sign off on it and it'll go in.

    Separately, I've been in an organization that allows anyone to voice a negative opinion during a code review, and that will block the code from merging until either that person is suitably convinced that their objections are ameliorated, or until a manager's manager steps in and makes the risk decision themselves.

    And there's probably all levels in between those two. Maybe somewhere has a 3-person sign-off rule. Or there's a place that only allows people with 2+ years of experience to block code from merging. But that's the rub: the process should match how much risk is acceptable for the project.

    Boeing, the maker of the 737 MAX jetliner that had a falty MCAS behavior, probably should use a more conservative process than, say, a tech startup that makes IoT devices. But even a tech startup could be on the hook for millions if their devices mishandle data in contravention to data protection laws like the EU's GDPR or California's CCPA. So sometimes certain parts of a codebase will be comparmentalized and be subject to higher scrutiny, because of bugs that are big enough to end the organization.

  • Your thoughts on Code Reviews

    Jump

  • With regards to the given list, I think #2 would be the most forgiving, in the sense that #1 suggests that code reviews are viewed solely negatively and are punishable if undertaken. But that minor quibble aside, I have some questions about what each of these would even look like.

    For example, #3 seems to be that code can be committed and pushed, and then review sought after-the-fact, but any results of the code review would not be binding for the original commit author to fix, nor apparently tracked for being fixed later. If that's a correct description, I would describe that as the procedurally worst of the bunch, since it expends the effort to do reviews but then has such an open-loop process that the results of the review can be swept under the rug.

    On the note of procedure, it is always preferable to have closed loops, where defects are: a) found, b) described, c) triaged, d) assigned or deferred, e) eventually fixed, and f) verified and closed out. At least with your examples #1 and #2, they don't even bother to undertake any of the steps for a closed loop. But #3 is the worst because it stops right after the first step.

    Your example #4 is a bit better, since in order to keep to a specified timeframe, the issues found during review have to at least be recorded in some fashion, which can satisfy the closed-loop steps, however abbreviated. If the project timeline doesn't allow for getting all the code review issues fixed, then that's a Won't Fix and can be perfectly reasonable. The issue has been described and a risk decision (hopefully) was made to ship with the issue anyway. All things in life are a balance of expected risk to expected benefit. Ideally, only the trivial issues would be marked as Won't Fix.

    But still, this means that #4 will eventually accumulate coding debt, probably quite quickly. And as with all debt, interest will accrue until it is either paid down or the organization succumbs to code insolvency, paralyzed because the dust under the rug is so large that it jams the door shut. I hope you'll allow me to use two analogies in tandem.

    Finally, there is #5 which is the only one that prevents merging code that still has known issues. No doubt, code that is merged can still have further bugs that weren't immediately obvious during code review. But the benefit is that #5 maintains a standard of functionality on the main branch. Whereas #4 would wilfully allow the main branch to deteriorate, in the name of expediency.

    No large organization can permit any single commit to halt all forward progress on the project, so it becomes imperative to keep the main branch healthy. At a minimum, that means the branch can be built. A bit higher would be to check for specific functionality as part of automated checks that run alongside the code review. Again, #4 would allow breaking changes onto the branch due to expediency, whereas #5 will block breaking changes until either addressed, abandoned, or a risk decision is made and communicated to everyone working on the project to merge the code anyway.

    TL;DR: software engineering processes seek to keep as many people working and out of each other's way as possible, but it necessarily requires following steps that might seem like red-tape and TPS reports

  • I vibe coded a driver to monitor and control the temperatures and fans in my Aoostar WTR PRO.

    Jump

  • I've even seen people vibe code ethernet drivers for freeBSD.

    Please make sure to read what considerations that developer had before undertaking that effort using an LLM: https://github.com/Aquantia/aqtion-freebsd/issues/32#issuecomment-3997341698

    Specifically, they (the human) were kept in the loop for the entire process, which included referencing the working Linux driver to do a clean-room reimplementation. This already means they have some experience with software engineering to spot any issues in the specifications that the LLM might generate.

    Also, Aquantia (before the merger) already had a published FreeBSD driver but it hasn't been updated. So this port wouldn't have to start from zero, but would be a matter of addition support for new NICs that have been released since, but Aquatia hadn't updated the driver.

    This is very much not an example of an Ethernet NIC driver being "vibe coded" from scratch, but a seasoned engineer porting Linux support over to FreeBSD, a kernel that already has a lot of support for easily adding new drivers in a fairly safe manner, and then undertaking a test plan to make sure the changes wouldn't be abject slop. That's someone using their tools with reasonable care. In the industry, this is called engineering.

    Admiration for what people can do with the right tools must always be put into the right context. Even with the finest tools, it's likely that neither you nor I could build a cathedral.

  • Booklore is officially dead

    Jump

  • I don't think they can be force applied to everyone who contributes

    This is certainly an opinion, but here is a list of major projects that have a code of conduct: https://opensourceconduct.com/projects . How well those projects enforce their CoCs, idk. But they are applied, otherwise they wouldn't bother writing out a CoC.

    it's not fair to hold people to standards they didn't personally agree to

    Software development is not the only place which holds people to standards. The realm of criminal and civil law, education, and business all hold people to standards, whether those people like it or not. In fact, it's hard to think of any realm that allows opt-out for standards, barring the incel-ridden corners of the web.

    this guy might have just decided to make a project

    Starting any project -- as in, inviting other people to join in -- is distinct from just publishing a public Git repo. I too can just post my random pet projects to Codeberg, but that does not mean I will necessarily accept PRs or bug reports, let alone even responding to those. But to actually announce something, that where the project begins. And to do so recklessly does reflect poorly upon the maintainer.

  • Booklore is officially dead

    Jump

  • I've not heard of Booklore or the critiques against it until seeing this post, but I don't think this take is correct, in parts. And I think much of the confusion has to do with what "open source" means to you, versus that term as a formal definition (ie FOSS), versus the culture that surrounds it. In so many ways, it mirrors the term "free speech" and Popehat (Ken White) has written about how to faithfully separate the different meanings of that term.

    Mirroring the same terms from that post, and in the identical spirit of pedantry in the pursuit of tractable discussion, I posit that there are 1) open source rights, 2) open source values, and 3) community decency. The first concerns those legal rights conferred from an open-source (eg ACSL) or Free And Open Source (FOSS, eg MIT or GPL) license. The details of the license and the conferred rights are the proper domain of lawyers, but the choice of which license to release with is the province of contributing developers.

    The second concerns "norms" that projects adhere to, such as not contributing non-owned code (eg written on employer time and without authorization to release) or when projects self-organize a process for making community-driven changes but with a supervising BDFL (eg Python and its PEPs). These are not easy or practical to enforce, but represent a good-faith action that keeps the community or project together. These are almost always a balancing-act of competing interests, but in practice work -- until they don't.

    Finally, the third is about how the user-base and contributor-base respect (or not) the project and its contributors. Should contributors be considered the end-all-be-all arbiters for the direction of the project? How much weight should a developer code-of-conduct carry? Can one developer be jettisoned to keep nine other developers onboard? This is more about social interactions than about software (ie "political") but it cannot be fully divorced from any software made by humans. So long as humans are writing software, there will always be questions about how it is done.

    So laying that foundation, I address your points.

    Open source should mean that anyone can write anything for fun or seriously, and we all have the choice to use it or not. It doesn’t matter if it’s silly or useful or nonsense or horrible, open source means open. Instead we shut down/closed out someone who was contributing.

    This definition of open-source is mixing up open-source rights ("we al have the choice to use it or not" and "anyone can write anything") with open-source values ("for fun or seriously" and "doesn't matter if it's silly or useful"). The statement of "open source means open" does not actually convey anything. The final sentence is an argument in the name of community decency.

    To be abundantly clear, I agree that harassing someone to the point that they get up and quit, that's a bad thing. People should not do that. But a candid discussion recognizes that there has been zero impact to open source rights, since the very possibility that "Some contributors are working together on an unnamed replacement project" means that the project can be restarted. More clearly, open-source rights confer an irrevocable license. Even if the original author exits via stage-left, any one of us can pick up the mic and carry on. That is an open-source right, and also an open-source value: people can fork whenever they want.

    How they were contributing is irrelevant

    This is in the realm of community decency because other people would disagree. Plagiarism would be something that violates both the values/norms of open-source and also community decency. AI/LLMs can and do plagiarize. LLMs also produce slop (ie nonfunctioning code), and that's also verbotten in most projects by norm (PRs would be rejected) or by community decency (PRs would be laughed out).

    We should all feel ashamed that an open source project was shuttered because of how our community acted.

    I would draw the focus much more narrowly: "We should all feel ashamed that an open source project was shuttered because of how our community acted". Open-source rights and open-source values will persevere beyond us all, but how a community in the here-and-now governs itself is of immediate concern. There are hard questions, just like all community decency questions, but apart from Booklore happening to be open-source, this is not specific at all to FOSS projects.

    To that end, I close with the following: build the communities you want to see. No amount of people-pleasing will unify all, so do what you can to bring together a coalition of like-minded people. Find allies that will bat for you, and that you would bat for. Reject those who will not extend to you the same courtesy. Software devs find for themselves new communities all the time through that wonderful Internet thing, but they are not without agency to change the course of history, simply by carefully choosing whom they will invest in a community with. Never apologize for having high standards. Go forth and find your place in this world.

  • Fast Software: More Programmers, Not Fewer

    Jump

  • Just like fast fashion replaced tailors with factory workers

    I'm not sure this is right. If I wanted cheap clothes in the 1980s, I would go to a thrift store, not a tailor. If I wanted to hem up some pants I bought, I go to a tailor. In the 2020s, the former might have changed to online fast fashion behemoths, but there's no replacement for a tailor to do up some pants.

    If I generously assume "tailors" is shorthand for a fashion designer that can also sew their own designs from fabric, then it's still wrong because fast fashion has never been about enabling designers that have no hand-sewing skills. Instead, it's about churning out mind-boggling amounts of product, irrespective of demand. Post-scarcity capitalism theory says that any product will sell at the right price, and the price for fast fashion is rock bottom.

    fast software will replace programmers with AI operators

    If "fast software" is going to mean shoddy software that's churned out just for the sake of it, then this is the only apt comparison to fast fashion. Even without AI, I don't think most modern software engineering or programming is comparable to tailoring or even fashion design.

    When the opening comparison is so deeply flawed, I'm not exactly keen on reading the rest of the article.

  • Considering self hosting my own git repositories. What are some options?

    Jump

  • I second the option of Git + SSH. That will scale to one hundred repos. And if you don't want the repos to be checked out, use "git clone -n" to not do that. It'll just be dozens of repos which only have the minimal .git/ directory. All other repos that specify this one as the upstream will have no issues pulling or pushing code.

    You won't have PR features nor a web UI though.

  • Projects are shutting down due to Microslop's Github CoPilot making AI contributions easy and plentiful

    Jump

  • This is indeed practical advice on how to do a transition, but my answer was primarily in response to the OP's question, which was about the reasons why people don't even try to transition. I don't at all suggest that a slow transition is in any way invalid. But to even get to that, the reasons for not transitioning have to be overcome. And for any sizable project, community cohesion is going to come first, or else the result will be less than the sum of its parts.

  • Projects are shutting down due to Microslop's Github CoPilot making AI contributions easy and plentiful

    Jump

  • In a nutshell, the network effect. At an individual level, if someone wants to leave GitHub, they absolutely can. But unless they're a repo owner or a BDFL, the project(s) they were working on would still be on GitHub. And that means they can't access the GitHub PR process for development, or open tickets for new issues, or any other number of interactions, except for maybe pulling code from the repo.

    On the flip side, at a project level, if the project owners agree that it's time to leave GitHub, they absolutely can. And while they could convince the primary developers to also leave with them, the occasional contributors might still be left behind on GitHub. Moving away from GitHub could potentially cut the number of contributors down by a lot. And what's guaranteed is that the project will have to retool for the new space they move to. And if it's self-hosted, that's even more work to do, all of which is kinda a distraction from whatever the project was meant to do.

    The network effect is the result of the sum being more useful than its parts. When the telephone was invented, a single telephone on its own is entirely useless, because nobody else has one to use. But with ten telephone, one person has the potential to call any of 9 other people. With 10,000 telephones, that's over 9000 people they could call, or those people calling them. At a million phones, the telephone is well entrenched into common usage. Even when more and more people despise making phone calls, the telephone is still around, having changed forms since the 1980s into the modern smartphone.

    Why? Because networks are also stable: if a few thousand people give up their smartphones per year, the utility of the telephone is not substantially changed for the grand majority of telephone users. The threshold to break the network effect varies, but I hazard a guess that if 1/3 of telephone users gave up their numbers, then the telephone's demise would be underway. Especially in the face of modern replacements.

    I would regard GitHub as having a network effect, in the same way that Twitter should have collapsed but hasn't. Too many local governments are invested into it as their sole social media presence, and in doing so, also force their citizens to also subscribe to Twitter. GitHub is not a monopoly in the sense that anti-trust laws would apply. But they are a monopoly in that they own the platform, and thus own the network.

    But there's an upside: communities of people are also networks. Depending on how cohesive the contributors to a particular GitHub repo are, enough people can make the move away and would sway the unwilling to also move with them. This is no different than convincing family members to move to Signal, for example. Yes, it's hard. But communities look out for their common interests. And if AI slop is affecting a community, then even though they didn't want to deal with it, they have to make a choice.

    Be the community member you want to see. Advocate for change in your network of people, however big or small. Without critical mass, a community will only splinter when acting unilaterally.

  • Deleted

    Permanently Deleted

    Jump

  • Having spent much of my software engineering career training and mentoring interns, new-hires, and transfers from other departments, and having toiled with some of their truly inexplicable questions that reveal shaky technical foundations, I can understand why so-called AI would be appealing: inexhaustible, while commanding the full battery of information stores that I could throw at it.

    And yet, the reason I don't use AI is precisely because those very interns, new-hires, and transfers invariably become first-class engineers that I have no problem referring to as my equals. It is my observation that I've become better at training these folks up with every passing year, and that means that if I were to instead spend my time using AI, I would lose out on even more talented soon-to-be colleagues.

    I have only so much time of my mortal coil remaining, and if the dichotomy is between utilizing inordinate energy, memory, and compute for AI, or sharing my knowledge and skills to even just 2 people per year for the rest of my career, I'll happily choose the latter. In both circumstances, I will never own the product of their labor, and I don't really care to. What matters to me is that value is being created, and I know there is value in bringing up new software engineers into this field. Whereas the value of AI pales in comparison, if it's even a positive value at all.

    If nothing else, the advent of AI has caused me to redouble my efforts, to level-up more engineers to the best of my ability. It is a human legacy that I can contribute to, and I intend to.

  • Network Security Audit

    Jump

  • Fair, though I personally don't let my ISP indirectly dictate what I do with my LAN. If I didn't already have a v6-enabled WAN, I would still manage my LAN using IPv6 private range addresses. There are too many benefits to me, like having VMs and containers be first-class citizens on my LAN, rather than sitting behind yet another layer of NAT. That lets me avoid port forwarding at the border of my home Kubernetes cluster (or formerly, my Docker Swarm), and it means my DNS names correctly resolve to a valid IP address that's usable anywhere on my network (because no NAT when inside the LAN).

    I will admit that NAT64 is kinda a drag to access v4-only resources like GitHub, but that's only necessary because they've not lit up support for v6 (despite other parts of their site supporting v6).

    This is my idea of being future-ready: when the future comes, I'm already there.

  • Network Security Audit

    Jump

  • The approach isn't invalid, but seeing as you already have the framework set up to deny all and log for IPv4, the same could be done with IPv6.

    That is to say, your router advertises an IPv6 gateway to the global internet, but you then reject it because your VPN doesn't support v6 (sadly). I specifically say reject, rather than drop, because you want that ICMP Unreachable (administratively prohibited) message to get returned to any app trying to use v6. That way, Happy Eyeballs will gracefully and quickly fall back to v6. Unless your containers have some exceptionally weird routing rules, v6 connections will only be attempted once, and will always use the route advertised. So if your router denies this attempt, your containers won't try again in a way that could leak. v6 leaks are more likely when there isn't even a route advertised.

    This makes your apps able to use v6, for that day when your VPN supports it, and so it's just a question of when the network itself can be upgraded. IMO, apps should always try for v6 first and the network (if it can't support it) will affirmatively reply that it can't, and then apps will gracefully fall back.

    This also benefits you by logging all attempted v6 traffic, to know how much of your stuff is actually v6-capable. And more data is always nice to have.

  • Element/Matrix Official Docker Install Method?

    Jump

  • Firstly, I wish you the best of luck in your community's journey away from Discord. This may be a good time to assess what your community needs from a new platform, since Discord targeted various use-cases that no single replacement platform can hope to replace in full. Instead, by identifying exactly what your group needs and doesn't need, that will steer you in the right direction.

    As for Element, bear in mind that their community and paid versions do not exactly target a hobbyist self-hosting clientele. Instead, Element is apparently geared more for enterprise on-premises deployment (like Slack, Atlassian JIRA, Asterisk PBX) and that's probably why the community version is also based on Kubernetes. This doesn't mean you can't use it, but their assumptions about deployments are that you have an on-premises cloud.

    Fortunately, there are other Matrix homeservers available, including one written in Rust that has both bare metal and Docker deployment instructions. Note that I'm not endorsing this implementation, but only know of it through this FOSDEM talk describing how they dealt with malicious actors.

    As an aside, I have briefly considered Matrix before as a group communications platform, but was put off by their poor E2EE decisions, for both the main client implementation and in the protocol itself. Odd as it sounds, poor encryption is worse than no encryption, because of the false assurance it gives. If I did use Matrix, I would not enable E2EE because it doesn't offer me many privacy guarantees, compared to say, Signal.

  • Using an engineering notebook

    Jump

  • I don't currently have any sort of notebook. Instead, for general notes, I prefer A3-sized loose sheets of paper, since I don't really want to use double the table surface to have both verso and recto in front of me, I don't like writing on spiral or perfect bound notebooks, and I already catalog my papers into 3-ring binders.

    if I'm debugging something, and I'm putting silly print statements to quickly troubleshoot, should I document that?

    My read of the linked post is that each discrete action need not be recorded, but rather the thought process that leads to a series of action. Rather than "added a printf() in constructor", the overall thrust of that line of investigation might be "checking the constructor for signs of malformed input parameters".

    I don't disagree with the practice of "printf debugging", but unless you're adding a printf between every single operative line in a library, there's always going to be some internal thought that goes into where a print statement is placed, based on certain assumptions and along a specific line of inquiry. Having a record of your thoughts is, I think, the point that the author is making.

    That said, in lieu of a formal notebook, I do make frequent Git commits and fill in the commit message with my thoughts, at every important juncture (eg before compiling, right before logging off or going to lunch).

  • I made a way to remotely control my homelab without any internet access required

    Jump

  • I made a way to remotely control my homelab without any internet access required

    Jump

  • Are ham radio operators in the EU able to use LoRa radios and be exempt from duty cycle limitations?

  • I made a way to remotely control my homelab without any internet access required

    Jump

  • Admittedly, I haven't finished reflashing my formerly-Meshtastic LoRA radios with MeshCore yet, so I haven't been able to play around with it yet. Although both mesh technologies are decent sized near me, I was swayed to MeshCore because I started looking into how the mesh algorithm works for both. No extra license, since MeshCore supports roughly the same hardware as Meshtastic.

    And what I learned -- esp from following the #meshtastic and #meshcore hashtags on Mastodon -- is that Meshtastic has some awful flooding behavior to send messages. Having worked in computer networks, this is a recipe for limiting the max size and performance of the mesh. Whereas MeshCore has a more sensible routing protocol for passing messages along.

    My opinion is that mesh networking's most important use-case should be reliability, since when everything else (eg fibre, cellular, landlines) stops working, people should be able to self organize and build a working communications system. This includes scenarios where people are sparsely spaced (eg hurricane disaster with people on rooftops awaiting rescue) but also extremely dense scenarios (eg a protest where the authorities intentionally shut off phone towers, or a Taylor Swift concert where data networks are completely congested). Meshtastic's flooding would struggle in the latter scenario, to send a distress message away from the immediate vicinity. Whereas MeshCore would at least try to intelligently route through nodes that didn't already receive the initial message.

  • Help learning low-level dev

    Jump

  • I personally started learning microcontrollers using an Arduino dev kit, and then progressed towards compiling the code myself using GCC and loading it directly to the Atmel 328p (the microcontroller from the original Arduino dev kits).

    But nowadays, I would recommend the MSP430 dev kit (which has excellent documentation for its peripherals) or the STM32 dev kit (because it uses the ARM32 architecture, which is very popular in the embedded hardware industry, so would look good on your resume).

    Regarding userspace drivers, because these are outside of the kernel, such drivers are not kept in the repositories for the kernel. You won't find any userspace drivers in the Linux or FreeBSD repos. Instead, such drivers are kept in their own repos, maintained separately, and often does unusual things that the kernel folks don't want to maintain, until there is enough interest. For example, if you've developed an unproven VPN tunnel similar to Wireguard, you might face resistance to getting that into the Linux kernel. But you could write a userspace driver that implements your VPN tunnel, and others can use that driver without changing their kernel. If it gets popular enough, other developers might put the effort into getting it reimplemented as a mainline kernel driver.

    For userspace driver development, a VM running the specific OS is fine. For kernel driver development, I prefer to run the OS within QEMU, since that allows me to attach a debugger to the VM's "hardware", letting me do things like adding breakpoints wirhin my kernel driver.