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
237
Joined
3 yr. ago

  • Immich vs Ente ?

    Jump

  • Downside: breaking changes are fairly common AFAIK.

    By my extremely cursory reading, this stopped being a problem after the v2.0.0 release, when they adopted semantic versioning. According, breaking changes would only occur when the major version number is rolled. And version v3.0.0 was just released 5 days ago, whereas v2.0.0 was released in October 2025.

    It may be down to taste, but I view 9 months as being acceptable, given the breadth of features offered and the folks willing to put effort into the project.

  • Agentic coding from Galapagos Island (what is the appeal to this?)

    Jump

  • You can, of course, engineer reliable things from unreliable components.

    I think the only way this statement can hold true in all circumstances is if we select an arbitrary boundary for what constitutes "reliable". And that's no small matter, because the threshold of reliability in a consumer IoT device would be inappropriate in a commercial or automotive setting, would be deeply wrong for industrial personnel safety, would be manifestly unlawful for a military or aerospace application, and potentially fatal for medical use.

    Engineering is all about balancing a set of objectives, be it cost, time to market, efficiency, size, weight, or competitive advantage, and more. Doubling up as a way to improve reliability necessarily implicates size, complexity, and efficiency, but that's tolerable for large data centers where the customer counts servers by the number of floors, not the number of Rack Units (RU). But no one would accept installing two pacemakers because one of them might fail early; that's an intolerable solution to the product's base objective.

    As it happens, most USA jurisdictions only require a single brake on a bicycle, and it doesn't even have to be on the more-effective front wheel. But the idea in law is to enforce the absolute minimum of requirements: having no brakes at all is where the line has been drawn, for a mode of transport that rarely gets above 50 kph (~30 MPH). But even then, all commercial bicycles for sale must have two brakes, so the law implicitly allows for some lost redundancy, because even one brake should be enough.

    Could a bicycle brake be developed such that it is inherently always able to stop? Likely yes. Would it appreciably improve macro safety objectives such as by reducing collisions with stationary objects? No, not really.

    And that's the rub: just because engineers can double up things to get more redundancy, is this any better than the alternative? If an LLM is used as a search engine, is that appreciably better than using "grep", a battle tested, secure, locally-ran application with a lineage harkening back to the 70s?

    The drawback with inherent unreliability is that it can only be statistically reduced, but never eliminated. NASA understands this risk better than most, because cost pressures mean they can't be using military-grade hardware for everything. Perhaps then, it can be better said that engineers also have to balance risk in their decisions, and as it stands right now, the risk/uncertainty for LLM output is unquantifiable by any existing approach.

    Academics have long been researching ways to make LLMs "safe", so that their outputs are constrainted in concrete ways. But I believe they've long concluded that the current approach of generative transformers simply cannot have safety "bolted on" after the fact. New constructions for machine learning will have to be invented with safety from day zero. The academics continue to work on that, while the commercial AI vendors are barreling ahead with LLMs, in spite of their risks and in the pursuit of a return.

    I've not seen anything that would suggest the academics are wrong, nor that industry has managed to produce large safety or reliability improvements, so at this point, I only see a plateau and dead end for the industry. Maybe if the industry would put more into R&D and theoretical work, this would be a lot more graceful as they run up against the buffer stops.

  • Self hosting on retro computer?

    Jump

  • If a Nintendo Wii counts as retro, there's at least one person hosting a website using one: https://infosec.exchange/@alexhaydock/114377262481451962

    But that was (incredibly!) able to run a prebuilt version of NetBSD, which had drivers for the official Wii USB LAN adapter. If instead there's a piece of hardware that can boot an OS but doesn't have a network interface device, then SLIP could be useful. Here's a vape hosting a website: https://bogdanthegeek.github.io/blog/projects/vapeserver/

    And if still, said retro device has no concept of IP or networking, can it at least speak serial over a 300 baud modem?

  • To beat the heat, I installed a custom AC on my lawn tractor.

    Jump

  • I've heard of hardware hacking for John Deere tractors, but I like this one the most haha

  • Selfhosted & AI

    Jump

  • IMO, abandonware means software that is a dead-end upon its very release, with no hopes or plans for anyone to every build upon it. Abandonware is generally not extensible, follows no good design philosophy that would let someone else build it up, and embodies essentially nothing.

    Even a 100-line throwaway Python script has more utility to someone when it is published on PasteBin or whatever. But something like a binary executable released with no source code, with no support, and with no intent by the developer to ever make anything more of it, that's abandonware.

  • Can gzip be a language model?

    Jump

  • New line and circuit for dishwasher. First time connecting to the load center

    Jump

  • TIL Leviton makes breaker panels. I always thought they just made switches, outlets, and home automation stuff.

  • Where is the love for conduit? Everybody is preferring continuwuity or tuwunel?

    Jump

  • some ominous comments stating that it is practically unmaintained (which is not true)

    Objectively, I can see that the last commit to the default branch was in March 2026, and that the 10th newest commit was back in September 2025. Of these 10, 3 are new features and 6 are fixes and 1 is documentation. I also see in the issue tracker that no project developer replied to the two newest reports, which were reported 2 weeks and 2 months ago.

    As a subjective opinion, the explanation that Conduit is essentially rock-solid and this doesn't need much upkeep or commits, that is just not credible. The Git history shows fixes and new features, but at a rate that averages just one commit per month. And some of those commits are literally one-line changes.

    But let's suppose that the maintainers are uninterested in small UI or quality-of-life features, and only make changes when it crosses their threshold for what is "important" enough. That's a choice, sure, but let's see if that holds water. Here is the project's response to an issue opened in January, with the response being in February that confirms a logic bug and schedules it for the next release.

    That was three months ago. No updates. No mentioned branches or PRs or merges. All while this bug remains in place. And that's understandable for FOSS project developers, for whom the project is not their day job.

    But in any circumstances, the totality of the evidence does not inspire confidence, let alone a determination that Conduit is "rock solid". And that's even before looking at the code.

    TL;DR: the premise of the question is wrong. Conduit is not maintained.

  • Using enums to make flat-file parsing in Java more maintainable

    Jump

  • If the data is already delimited, why does the implementation need to have fixed offsets? Why not just count the fields, as 0, 1, 2, etc?

    Your post speaks of brittle code but using fixed offsets is almost always guaranteed to be brittle.

  • Using enums to make flat-file parsing in Java more maintainable

    Jump

  • I have two questions: 1) was this written using an AI/LLM? And 2) can you give an example input text that this parser is meant to parse?

  • PSA: Flow Control and Port Buffers are key to fix poor uplink speeds

    Jump

  • Given that your original problem was related to WAN upload performance, why did your investigation lead you to Ethernet flow-control? An ISP connection generally deals in packets at Layer 3 ("network", eg IP) of the OSI model, whereas Ethernet is a Layer 2 ("data-link") layer technology.

    If there is a bottleneck at your WAN modem, then that will cause congestion at layer 3, but Ethernet flow-control can only deal with congestion that exists at layer 2. What has likely happened is that you have configured your gateway so that congestion at layer 3 is mirrored onto your layer 2 LAN. And if flow-control is enabled, then that would result in back-pressure propagating back to your VMs. Your VMs will then slow down their layer 2 rate, which conveniently forces the layer 3 traffic to also slow down.

    This is an incredibly round-about and inefficient way to do traffic shaping. You should not configure a network so that L3 and L2 issues bleed into each other. A major consequence of using flow-control in this way is that it reduces the capacity of your LAN, even for traffic that isn't going out to the WAN.

    The customary approach for keeping L2 and L3 separate is to perform traffic shaping solely at the threshold where your LAN meets the bottleneck. This would be OpenWRT, since after OpenWRT would be the WAN (50 Mbps upload). OpenWRT would be configured with some sort of QoS feature so that certain L3 packets are selectively dropped.

    You cannot do effective L3 traffic shaping without dropping packets. In fact, all competent L3 protocols expect dropped packets in order to slow down their data rate: SCTP and TCP have their own exponential congestion control mechanism, UDP simply accepts that some packets won't make it through, and QUIC has its own mechanism as well. Simply put, all L3 protocols only understand one signal that tells them to slow down, and it is to drop a few packets. They will adjust accordingly, finding the stable equilibrium where traffic flows at the very cusp of congestion.

    The Main reason for this problem seems to be the down-stepping of 10Gbit traffic to 1Gbit devices

    This is a red-herring, for the reasons I've outlined above. With 1+ Gbps connections on your LAN, your L2 network is an order of magnitude faster than your WAN upload. It cannot be the case that a fast LAN makes a slow WAN slower. This is not RF impedance where step-transitions cause reflections; we are dealing in packet-switched networks, where queuing theory controls.

    TL;DR: please try OpenWRT QoS instead

  • NSFW Deleted

    You already know why you're reading this.

    Jump

  • The latter part of Rule 3 is the issue:

    If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.

    There is exactly one sentence in the post which relates to self hosting, buried in the middle of a paragraph, and one which could be plausibly understood in two ways: 1) we (Anonymous) are recruiting the working-class people who maintain the infrastructure that keeps the world running, or 2) we (Anonymous) are seeking people that know how to build self-sufficient infrastructure. Only the latter might be vaguely self-hosting. And in no circumstance would I say the sentence is "obvious".

    I won't rules-lawyer the other points, but I repeat the old adage: when you hear hooves, think horses, not zebras. If a post is skirting multiple community rules, and the community is downvoting it into oblivion, then all signs point to a post that shouldn't be here.

  • Continuwuity

    Jump

  • This is not a good idea: having to search means an implicit reliance on a search engine. Even with a trustworthy web search -- and those are becoming fewer and fewer -- why add this complication? The URL doesn't even have to be large; it just has to be readable.

    Even worse is when there's an adversary: what would stop someone from buying getcontinuwuity.org but have it be pro-Big Tech propaganda, with tracking cookies galore, and then pay Google or Bing to put it at the top of the web search results?

    Whereas in 2026, a URL is not confusing at all to include. People know what http:// or https:// mean. Even big brands might not own their own product name's domain. This exact problem came up just six days ago: https://www.neowin.net/news/paintnet-can-finally-be-downloaded-from-the-right-place/

    The whole point of marketing is to reduce the barriers for people to find something useful or valuable. Adding an accessibility barrier is antithetical to that objective.

  • NSFW Deleted

    You already know why you're reading this.

    Jump

  • I think this is a Rule 5 violation for this community, and maybe even Rules 3, 4, and 7.

  • Continuwuity

    Jump

  • This is the homeserver written in Rust, right?

    A suggestion: wherever a QR code is included, the human-readable content should be included next to it. Not everyone has a QR code reader handy, or their reader has the bad habit of immediately opening links or apps. In this case, I see that it just goes to https://continuwuity.org/ and is benign, but others may be apprehensive at naked QR codes.

    (there's obviously an exception for QR codes that are intended to convey machine info, like TOTP codes)

  • License to ask for for custom software?

    Jump

  • Intriguing. Upon rereading, that is also a plausible interpretation. But I think the issue still stands, but in reverse: if the software is produced by SWF, is licensed to ACQ for use (but not modification), then there will be a need for ACQ (not SG) to negotiate a source-code license with SWF.

    If OP's question is now about what sort of license terms would be workable, that's entirely up to SWF. They would be within their rights to not even answer the phone, once they've completed their delivery per whatever contract they have worth ACQ.

  • License to ask for for custom software?

    Jump

  • I'm not sure I'm understanding the situation. You (Skullgrid; SG) were asked by an acquaintance (ACQ) to help work on a software package that ACQ would deliver to a software firm (SWF). So far, these are the relations that I see:

    • SG is doing a favor for ACQ
    • ACQ has a contract with SWF

    Now at the "handoff time", which I presume is when SWF accepts the software as complete and delivered, SWF is complaining about how the software package will be maintained.

    If I understand all of that correctly, why does SWF's complaints involve you? You do not have a relationship to SWF. And SWF (correctly) will not let a third-party have source-code access to software that SWF paid for, unless you (SG) are working as a contractor under ACQ.

    The real question is how ACQ is handling these concerns: ACQ should demand that SWF negotiate a maintenance contract, one which allows ACQ to use any contractor of their choice (which could include SG).

    The idea that SG -- someone with no relationship to SWF -- can use a software license to keep source-code access in order to do future maintenance, that idea is likely dead-on-arrival: SWF owns the software upon delivery, in full. Unless the contractual agreement between SWF and ACQ allows for ACQ to retain a license, ACQ cannot then extend a personal license to SG.

    A maintenance contract, however, would grant such a license to ACQ. And if such contract allows for subcontractors to access the source code, then formalizing SG as an unpaid contractor would be a way forward.

  • Fed up with vibe coders, dev sneaks data-nuking prompt injection into their code

    Jump

  • The person who coined the term "prompt injection" has the same gripe, because the original term genuinely did mean an attack using untrusted user input, a la SQL injection. But it's been conflated with jailbreak attacks in general, muddying the term.

    Example of a bona fide prompt injection: white text in the background of a resume PDF, attacking a job application portal that uses LLMs to filter applicants. No privilege escalation is involved to give the candidate top marks on their resume screening.

    Whereas a non-prompt injection jailbreak would be bypassing a safety filter, such as how Morse code might get past the filter and allow a user to request other people's cryptocurrency be transfered away. This is more akin to finding a poorly-secured, public facing API and then exploiting it.

  • Another reason to self host your own AI

    Jump

  • I'd like to draw a comparison: a cozy wood fire versus central heating. In the right time and place (eg camping in the woods), a wood fire is both very practical and very useful. Meanwhile, most homes built in the past 70+ years in the USA have central heating (or are somewhere that doesn't need heating at all) and the benefits are quite obvious: automatic temperature regulation, supplied by a utility, and low or no local emissions. And yet, there will still be rural homes that are heated exclusively by a wood stove, located in the middle of the living room, whose iron construction stores and radiates heat well after the fire has gone out.

    Do I bemoan individual homes that use a wood fire? No, not really. The reality is that a grand, overwhelming majority of people don't have wood fires anymore. Even when air quality is poor, prohibiting wood fires in a few rural homes isn't exactly what would clear up the air.

    Now, it would be a vastly different story if city-dwellers all had wood fires. When every home in a neighborhood is building and burning a wood fire, the results are disastrous: horrific PM2.5 in the air, soot coating everything, substantially reduced energy efficiency, and mass logging just to keep the wood supply. A mole-hill quickly becomes a mountain of problems when it's at scale.

    So to that end, I would very much like to see commercial-scale AI reigned in, as the external costs have already gotten out of hand. What they have built is more correctly called a wildfire, not a wood fire. But where does that leave small-scale AI/LLM users? They can weigh the cost/benefits for themselves, provided that they don't harm other people or resources in the process.

    But that brings us back to a cozy wood fire versus central heating: at small scale, a wood fire struggles to heat an entire modern American home (ie 2500 sq ft; or 232 sq m). Yet central heating does it with ease. Who then will be interested in this endeavor? Probably only those with a love for the camping aesthetic, and other enthusiasts.

    At this point, it has become more clear what the utility of small LLM models is, and they do pale in comparison to larger LLM models. If small LLMs are what sensibly survives into the future, then that's essentially a cap on their capabilities, given a want to avoid burning the planet to run anything larger. The only way out would be for substantial developments in the energy efficiency of small LLM models, but that's not where the interest is.

    No one is seeking to build a more efficient wood fire.