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

  • Internet centralization and the original sin of NAT

    Jump

  • This and the comment it replies to make the categorical error which is to assume that NAT exists as part-and-parcel to firewalling. This is not the case. Many American university and corporate networks do still adhere to the end-to-end principle by giving every device a public IP address. They can do this because they are among the few legacy entities that actually have enough for their needs, such as a Class A (aka /8) subnet on Legacy IP. At the same time, these entities employ firewalls that don't allow unsolicited inbound traffic (and sometimes also block disallowed outbound traffic).

    NAT is not a firewall, and the OP correctly points out that by using NAT or CGNAT, the end to end principle is demolished, with no way for the victims to recover. OP mentions "firewalls" exactly twice, to compare how they are not firewalls and are still necessary in spite of NAT. Nobody is credibly suggesting that everyone should switch to IPv6 without a firewall. Every single domestic router for the past two decades has included a firewall, and that would not change in an all IPv6 world.

    I wish to reiterate an example I've used in the past, which is that the most famous address in the USA is 1600 Pennsylvania Ave, Washington DC. Anyone can send letters and parcels directly to this address as-written, with no need to rewrite the address to first arrive at the Secret Service. And yet, all such parcels and letters will be thoroughly scrutinized by the Secret Service anyway at an off-site facility, and some indeed will be let through to the occupants of the residence. NAT is address mutilation, and the United States Postal Service does not require nor allow that.

  • Do you know a remote NAS backup solution without Tailscale?

    Jump

  • What are these "built in listeners" that you speak of, and which OS's can I find this on?

    Also TCP will work before UDP. For whatever reason firewalls and such do weird things with UDP traffic.

    This doesn't really explain why troubleshooting is more difficult, but rather that firewalls often cause trouble for UDP. My question was "why would diagnosing a UDP problem be harder than anything else?", not "why is UDP more problematic?". I'm fully aware that some firewalls are configured with absurd parameters, like blocking ICMP, QUIC, or even TLS in some bizarre situations. But my tools for debugging network troubles have always been the same: tcpdump for passive tracing, nc to coerce an active response, and icmp/icmp6 ping for basic connectivity and MTU verification.

    Whether it's UDP or anything other protocol, those tools have proven sufficient for me. Do you use something else?

  • Internet centralization and the original sin of NAT

    Jump

  • I'll add some color to this post.

    The original FTP is, frankly, a monster of a protocol. Very useful, but an anomalous protocol that even without NAT breaking the end-to-end principle, it is unlikely to have survived modern corporate firewall rulesets in any case. The fact that FTP was even ported for TCP is its own historical quirk.

    BTW, that is the term which this post is missing: the end-to-end principle is the design philosophy that the network itself should not have to perform work on payloads transmitted, except to carry it towards the destination. This also implies that no fields or bits should be modified in transit, once it leaves the sender; encap/decap restores the fields so that the receiver is none the wiser.

    NAT breaks end-to-end in two respects: corruption of the original sender, and corruption of L4 port numbers. Note that Legacy IP also violated end-to-end, when packets are fragmented due to MTU issues. With IPv6, fragmentation by the network is disallowed outright, and the technical case for NAT is non-existent.

    There's something to be said about adopters of NAT, that they were facing a Hobson's choice: use NAT so that they could connect early dial-up users to the emerging Internet, or reinvent the 20 year experiment of the Internet so that it could scale properly. In 1995, IPv6 did not exist so they made the only real choice available.

    In the year 2026 though, that argument doesn't hold water: it is a choice to continue to ignore the dual-stack and IPv6-only internet. There's a quote that all sufficiently complex technical problems are in-fact political, and this is that: the modern case for Legacy IP and NAT is rooted in inertia, resource scarcity (eg hyperscale cloud companies buying up IP subnets), and recalcitrance by professionals that abdicate their responsibility to their clients to pursue the available technology.

    There is no colorable technical rationale for why IPv6 best practices cannot be adopted today for most organizations, when all network hardware, all major consumer and enterprise OS's, and all mobile phones support v6. Note that I said "best practices", because a minority of orgs such as certain American ISPs have undertaken truly bonkers decisions that are putting us on track for the very same sins as Legacy IP.

    The fact that some ISPs assign nothing but a single /128 via DHCP6 is absurd: this malpractice perpetuates the same problem as NAT44, except that there's no good excuse for it. Even the most delusional of ISPs will never run out of /128 addresses in their assigned /32. Per best practice, even handing out /48's to customers is not a problem either, because that's 65536 customers and if that's really a problem, just ask the RIR for another /32, which they can do as RIR dues-paying members. There is no practical limit, except that some people just cannot math properly to see that there's no practical limit. When a technical solution to a technical problem fails because of innumeracy by those tasked with implementing it, then that's so much worse than any 1990s workaround.

    I've harped a lot about IPv6 because its strength today is that it's technically competent, future-proofed, and most importantly, practitioners that saw the first travesty of NAT will not allow a redux to play out with IPv6. The technical reasons to deploy NAT66 are non-existent: it is always a workaround for political issues.

    I can (just barely) accept NPTv6 as a like subnet-for-subnet mapping that does not harm L4, but that's still glossing over a political issue. IPv6 gave network engineers real choices in numbers and administering their networks, and while some will squander it, I will be encouraging people to not let that happen.

  • Do you know a remote NAS backup solution without Tailscale?

    Jump

  • Why would UDP be any more difficult than TCP (or anything else) for troubleshooting? If nothing else, it should be easier because there are no stateful connections and every packet is "fire and forget". Now, as a tunneling technology, WG might be more difficult than a simple client/server socket-driven application, but that just means some routing tables need to be inspected and you have to understand IP subnets. In any case, you'd still want to obtain packet traces from both ends of the WG tunnel.

  • Do you know a remote NAS backup solution without Tailscale?

    Jump

  • The thing is, if you don't wish to port-forward on Legacy IP nor open firewall ports for IPv6, then the only other option is to reach out to some sort of relay server. But whether your own VPS fulfils that role or you use Tailscale's DERP/TURN relays, the same class of latency and bandwidth issues will still erupt. So you'd still have to debug them, although you presumably would have better visibility into diagnosing issues with your VPS relay.

    Generally speaking, if Tailscale isn't working for you, then all other solutions will increase in complexity, not decrease.

    Answering the ultimate question, I operate and secure my SSH server, with port 22 open only for IPv6 inbound. There's no NAT, so I don't have to deal with debugging odd port mangling. The SSH server only allows key auth, and all password attempts are logged and blocked, because there can't be any legitimate traffic like that. On this SSH server would be my mounts for backups.

  • A solar powered website that goes offline when there's no power

    Jump

  • IIRC, the USA Social Security Administration's website operates somewhat like this, because they seem to still do batch processing (a la mainframes) during the evening hours. As a result, they prevent people from logging in so that they don't get interstitial data about their public pension.

  • Torvalds: AI Is the New Compiler, Not the New Programmer - “100% of their code Is written by compilers too"

    Jump

  • Torvalds was careful to frame this as a correction of language rather than a rejection of the technology itself.

    You "paraphrased" into oblivion the very thing Mr. Torvalds was trying to be careful about, contorting it into click bait rather than the nuance that he and the article are trying to get across.

  • Torvalds: AI Is the New Compiler, Not the New Programmer - “100% of their code Is written by compilers too"

    Jump

  • Agreed. This post's current title does not appear in the link, and the link does not contain a quote that can be remotely matched to this post's title.

  • I'm learning to type

    Jump

  • For folks not willing to make the full leap away from QWERTY, there's also Colemak that preserves the common key combos, such as Ctrl C and Ctrl V.

    Also, a word of advice: all the keyboard formats which minimize finger reach compared to QWERTY (which essentially maximized finger reach to accommodate mechanical typewriters) will cause poor word prediction on Swype-style virtual keyboards on mobile phones. This is because optimized keyboard formats try to keep words as close to the home row as possible, so many words using Swype will just be sliding your finger left and right over the home row, which destroys accurate prediction. This is why I'm QWERTY on mobile but Colemak on desktop.

  • The GNU Compiler Collection will reject copyright-significant contributions derived from LLM output, with limited exceptions for trivial changes and test cases.

    Jump

  • Is the Linux kernel a project of the Linux Foundation though? I understood that Linus Torvalds still maintains the kernel under his original authority, and the Foundation's projects are all the ancillary specifications that the kernel should follow and related distros that make use of the kernel.

  • Would it be viable for me to start doing freelance web development in 2026?

    Jump

  • Having conducted technical interviews after managers have screened the candidates' resumes, I second this. Businesses absolutely look at example works, precisely because it's what they care about: it doesn't take a leap of the imagination that if someone has churned out excellent work for hire, that they can do it again once hired on.

    It's a bit harder for prospective employers to take someone at their word without works that they can point to, or can succinctly describe said works in sufficient detail.

  • AI and formal verification

    Jump

  • I'm more in the software side of things, but have worked with hardware engineers that use formal verification before committing to a design. How I understand the point of formal verification is to answer the question: does this implementation satisfy the given specification?

    With that in mind, I'm having trouble squaring away my definition with your passage:

    I can imagine a scenario where you no longer review the code but a simulation of all the behaviours of the system, perhaps before any code has been written, and then you can trust the output will have accordingly …?

    The whole point, I think, of formal verification is to verify a specific, concrete thing. Simulation doesn't seem to be remotely relevant at all, because it is not the thing itself. C'est nest pas une pipe. Likewise, formal verification isn't about stress testing either, such as hardware shock and vibration testing. At bottom, formal is about reducing the thing to its most basic assumptions, and checking those.

    If those assumptions turn out to violate the specification, then that answers the question posed earlier. If however the formal process proves that a specific signal within an FPGA will never take longer than 47 ns and another signal always takes longer than 68 ns, then it's provable that those two signals will not cause a race condition when they come together. And this too answers the question.

    Given that formal verification is rooted in mathematical proofs, I don't see how LLMs can help there. In terms if making formal easier to use regarding inputs and outputs, LLMs are still a poor fit. To trust an LLM to write or even audit the specification that will be inputted to formal verification, that's adding a very weak link at the very start of a very robust process, essentially negating all the guarantees of formal verification.

    As for the output side, I'm not seeing how a yes/no answer from formal could somehow benefit from the mis-confident elaborations of an LLM. Perhaps in the case of a failure result, an LLM can hone in on the exact hardware or software component that the spec violation is occurring. But my understanding is that formal verification software already does that, because that's the obvious thing to identify once an implementation is proven as faulty.

    What practical limits of formal verification are there for this?

    Formal verification definitely has limits, and one of the greatest limiting factors for its use in the software domain is the fact that compatible software (meaning it can target many platforms, OS, phones, etc) is an utter mindfield to prove correctness for. Just look at memory ordering: x86 and ARM, in the desktop and mobile spaces respectively, behave very different, yet an ideal formal verification would tell us if a race condition could ever arise. We don't have that today, because the test matrix to verify is outside the limits of our computational power, for any nontrivial example.

    Adding AI in any current form -- and maybe any future form too -- will not change this gap in what can be achieved by raw logic and induction. Formal is simply unbothered by LLMs, neither helped nor hindered.

  • experiments with isolation on blue pill (bare-metal in C)

    Jump

  • I skimmed this article, but I'll revisit it later because MPU protections have always intrigued me, in terms of being a much smaller subset of the protections afforded by an MMU. That said, for work projects, I've only ever been able to make use of MPU regions for coarse-grain protection (eg prevent the DMA-dedicated regions from being accessible by everything) and not for per-task protection. So I'm always interested in ways that more isolation can be applied, precisely because it keeps code honest, which isn't a bad thing. It's no different than having software asserts.

  • Deleted

    Halcyon Video — a walkable 3D video-rental-store frontend for Jellyfin (GPL-3.0)

    Jump

  • This looks amazing. That said, you may want to have a look at rules 7 and 8 for this community.

  • [AIP] I built three apps to automate and manage your manga/comics library

    Jump

  • Contributors: Claude

    Please kindly see Rule 8 of this community and its associated post.

  • I feel like people are sleeping on the Minisforum MS-R1 as a good value home server PC

    Jump

  • In the space of mini PCs/NUCs, this does seem comparable. But bear in mind that the entire space of "home server" is a lot bigger than NUCs. After all, not everyone just wants to host an NVMe drive or two; they might want to fit some cheaper SATA SSDs or even spinning rust, as part of a cascade of stroage, with caching on SSDs and other nice things.

    Likewise, the dual LAN ports with 802.3bz support is nice, but the reality is that most networks are only 1 Gbps with some devices supporting 2.5 Gbps. Quite frankly, for server use that actually needs one or both port's bandwidth, the link would likely be better served with SFP+ slots, because of better compatibility with cheap enterprise switches available online, and because SFP+ transceivers run less hot than their twisted pair counterparts at 10 Gbps. Heck, you could even use a 40 Gbps QSFP+ NIC, which only requires a x8 or X4 PCIe slot (depending on PCIe generation of the NIC). On that note, a single PCIe slot is nice, but it does preclude the use of a double-wide GPU for transcoding use.

    I would sum all this up as lacking expandability. Yes, it can be expanded somewhat. But for folks that want the capacity of an ATX-based build, this ain't it. And for folks with abundant solar power, electricity consumption for older gen chips isn't as much of a dealbreaker. It certainly checks off a lot of people's boxes, yours included, but that doesn't mean that people are "sleeping on" this, because at the end of the day, if it doesn't serve their purposes, it's not the right box for them. In terms of price, never underestimate the cost of $0.00 that is an old, unused laptop; they make remarkably decent servers for light loads.

    Also, as of this writing, only the 32 GB RAM variant is available on the USA website.

  • The GNU Compiler Collection will reject copyright-significant contributions derived from LLM output, with limited exceptions for trivial changes and test cases.

    Jump

  • Corporations even before AI have sued each other, precisely on the premise that "your code looks like ours. We think you stole it" and then have a petty fight in court because their lawyers couldn't hash out a settlement.

    Now with so-called AI washing, it's only going to get worse, because LLM generated code doesn't have to be 100% identical to be considered a derivative copy of the original. It all goes back to the central question: did this copy come from this original work?

    The corporate IP lawyers will be making bank off of the ambiguity.

  • The GNU Compiler Collection will reject copyright-significant contributions derived from LLM output, with limited exceptions for trivial changes and test cases.

    Jump

  • I've had similar trouble understanding this aspect in the past, so I'll share how it now makes sense to me, within the frameworks of existing IP law. IANAL.

    Copyright law protects a specific, tangible work from duplication, meaning that if someone directly derives an unauthorized copy from an original work (eg scanning a book), then that's copyright infringement. However, copyright law does not simply look at whether a copy is identical to the original. There must be an analysis of the provenance of the copy: did the copy come from the original?

    Two people can separately stand at the Grand Canyon visitor center and use their own cameras to take identical film photos from the same vantage point, such that the developed film is identical in every way. And yet, neither has violated each other's copyright, because neither photo came from the other. Person A can sell their copy to a magazine, while Person B distributes copies for free with their holiday cards. This is all A-OK.

    The trouble is when somebody suspects infringement, because they see a copy that looks unusual similar to an original. If they decide to raise a copyright lawsuit, then the defense would like a way to affirmatively show that "no, our copy didn't come from your original". How do they do this?

    In software, the approach would be to methods like the clean room approach. This is explicitly a method for legal reverse engineering, precisely to avoid copyright concerns. It works because while copyright protects a tangible work, it does not protect the ideas recorded by that work. So if somebody was given only the idea, and tasked with writing the software that re-implements that idea but without ever seeing the original, then the resulting work cannot possibly have been based on the original work. Rarher, it's just a take on the same idea, which is allowed to be similar, in the same way as the photo of the Grand Canyon. There is no straight line that connects the supposed copy to the original work, apart from the idea itself, which copyright does not cover.

    With LLMs, there is zero assurance that any clean room approach was followed. By training directly on original, copyrighted works, there is a cloud of uncertainty about whether the LLM is regurgitating parts of the original (which would be infringement) or if it actually reduced the user's prompt into an idea, and then independently generated code which implemented that idea.

    Copyright infringement poisons everything that is derived thereafter, so even the spectre of a doubt causes problems, because if GNU or whoever else builds atop questionable copyrighted software, that foundation collapse suddenly if someone brings a lawsuit to enforce their copyright. And those are pricey to defend, even if it's without merit.

    The clean room method, when followed faithfully, is a way to discourage potential litigants from even filing a lawsuit, because it's clearly obvious that they would fail to prove a connection to the original work. Patents are a different story (where ideas are protected).

    LLMs basically have the same problem as when an engineer quits and goes to work for a competitor. Will they have (accidentally or not) taken trade secrets with them and implemented those in the competitor's product? A well-advised company would go through great lengths to make sure that engineer isn't working directly on a competing product, to avoid a costly lawsuit. LLMs do no such mitigation.

  • Removed

    bisect run: hand the whole 'which commit broke it' search over to a script

    Jump

  • From memory, I believe it does. But that means the bisection would give the result that the merge commit is responsible for the bug. Which isn't wrong, but most workflows do not just blindly revert a whole merge, but would have to follow-up to surgically find and fix the bug in the merged-in branch.

    So that would be yet another invocation of Git bisect. The hazard is believing that bisect is an fully automated bug finder, when it would just stop at the first merge commit if the bug came in from elsewhere.

    The other hazard that I didn't mention is a presumption that every commit -- merge or not -- is individually buildable and testable. For good workflows, this is the case. For some... more casual workflows where broken code is pushed and then fixes thereafter, bisect will not be able to hone down to a singular commit.

  • Dullsters @dullsters.net
    litchralee @sh.itjust.works

    Packetized the cardboard recycling for next week's pickup

  • Dullsters @dullsters.net
    litchralee @sh.itjust.works

    Audited my home electricity consumption; found two "phantom" loads

  • Dullsters @dullsters.net
    litchralee @sh.itjust.works

    I made a "dial wheel" to try all 26^3 combinations on this mystery lock-box

  • Dullsters @dullsters.net
    litchralee @sh.itjust.works

    Removing the stock grease inside an ebike motor