Nicely done! Does it rattle at all? Or slide down the tub? If this works for you, then congrats!

“A rigid, one-size-fits-all power limit risks excluding riders who benefit most from additional assistance,” the company said.

The statement arrives as debate continues across the bike industry over rising motor outputs and whether increasingly powerful electric mountain bikes could attract greater regulatory scrutiny.

The last sentence precisely nails the issue: contrary to the headline, there is a very real threat to the industry, which would be realized if regulators decide to act due to public backlash. It is incredibly tone-deaf to ignore the very real problems that high power limits are directly responsible for, due to lax regulation thus far.

In the USA, we need only look to comic books in the mid 20th Century as an example. There was a point where comic books pushed against the edge of moral decency – even when a robust First Amendment should have meant that the government could not regulate such publications. And yet, due to a spate of comics that caused public furore, publishers realized that if they didn’t do something to reign in risque comics, the government would step in and force regulations upon them. Hence: https://en.wikipedia.org/wiki/Comics_Code_Authority

Related to this is what happens when an industry publicly thumbs its nose against the already enacted regulatory structure. It is, somewhat understandably, viewed poorly by the regulators, painting their conduct as bad faith. Even if it’s “just business”, it’s still an incredibly bad look. A finding of bad faith will poison any future advocacy in good faith, and burning political capital like this is ill advised.

I do agree with the technical merits of their argument, that power that is moderated by a capable rider is not an additional risk. And that electric mobility enables people who could never have ridden before. But the minuses cannot be so blaisely ignored, in the carte blanche name of innovation. For all their harm reduction benefits, vaping still has public hazards that, while much reduced from smoking cigarettes, must be addressed. In all other industries, such a convenient line of reasoning is correctly viewed as self-serving. Ref: Uber.

Can a manufacturer point out that underskilled riders are a major issue? Absolutely, and they should. Can a manufacturer work with regulators to get ahead of pending rules, to minimize disruption to supply chains during the compliance window? Yes, very much so. But issuing a press release that basically says “the public and regulators don’t understand us” is just raw, negative value.

The brilliance of the McMaster-Carr website is best appreciated when viewed alongside the print version of the McMaster-Carr catalog. As a child, I literally grew up on that bright yellow book, since my parents used it as my booster seat for the kitchen table. It is a thick tome, second only to the thinner Grainger catalog, which became the next booster seat after a few years.

Since your e-scooter has dual steering tubes, I would suggest a lock-holding accessory that attaches to both. One complaint I have with similar lock accessories to the one linked is that they have the lock – which necessarily is made of solid metal – cantilevered out, resulting in a large moment arm. This means during sharp bumps in the road, the unsupported end of the lock will apply a torque to the plastic accessory, which inevitably ends in fatigue and breakage.

Some of this is down to necessity, because there’s no great way to hold onto a U-shaped lock at just one point. And also because the stock accessory for U-locks use this poor design. But in your case, you have two vertical tubes that can spread the load.

I think the ideal accessory in your case would be shaped similar to a wide halyard cleat arranged vertically, so that when the U-lock is opened, the U portion can be slid underneath the lower cleat and then locked to the top of the lock, which slides underneath the upper cleat. The act of locking snugly to the cleat will pin the lock in place while preventing cantilevering and noisy wobbling. Sadly, I’m not aware of such a ready-made design, but perhaps that’s something that a 3D printer enthusiast can help draft.

As for the cargo trailer idea, be aware that weight-and-balance need to be taken seriously for smaller configurations. I’ve written about trailers before – although for moving bikes behind a small automobile – and this is the relevant section:

Even if tongue weight were fine, the arrangement of the bikes on a hitch carrier have their own impact: moment of inertia. That is to say, if six bikes were arranged parallel to the drive axle, they’d have to each be spaced at least 8 inches (20 cm) apart. For six bikes, that means the carrier extends beyond the rear bumper by 48 inches (1.2 meters). And that’s just too much inertia to exert on a small car’s hitch receiver. Any bump that the car drives over would cause the bikes to also bounce, but that bounce then reflects itself due to the long moment arm, which then affects the car again. This is an identical wagging-the-dog scenario as trailers have, but here it’s a vertical wag rather than a lateral wag with a trailer.

In your case, imagine if you had a trailer and then came up to a speed bump. The front and rear e-scooter wheels have suspension, so they can absorb most of the bump as you roll over it. But most trailers don’t, so the trailer will jump up at its axle. If the center of gravity (COG) for the trailer (including payload) is ahead of the axle, then the axle rising will cause a downward force at the hitch attachment to the e-scooter. This is generally desirable, but the hitch and rear wheel must be able to deal with this.

But if the COG is behind the trailer axle, the axle jumping up will cause a lever that tries to raise the hitch into the air. If it’s very forceful, it’ll lift your scooter’s rear wheel up too. This could easily lead to a crash, since all two-wheelers need two points of road contact to be stable. The physics is identical to automobiles pulling trailers improperly, either due to driving too fast or badly loading the trailer.

I don’t want to discourage the idea, but make sure your trailer is properly attached and properly loaded. The reality is that automobiles and trucks are more forgiving because they have lots of mass. But two-wheelers are a lot lighter and need careful attention, since upsetting the wheels will also deprive steering control, which topples all two-wheelers.

For the lock, I’ve seen designs on Thingiverse for 3d printed accessories that would mount the lock body to the stem of the escooter’s tiller (?), so that it doesn’t occupy space elsewhere. One concern I haven’t checked for is whether the lock would rattle too much, which could be a problem for a 3d printed attachment.

For the charger, I’m less certain, but maybe something like a cargo rack would work? I’ve seen a few which fit right above the rear wheel, with enough points to use a bungee cord to hold rectilinear objects in place.

Excellent! Have you also considered posting to !imadethis@lemmy.zip ?

Very nice! But caution: this is very nearly not-dull, which would be a rule violation /s

In all seriousness, is the idea to haul multiple bikes at once? I once considered a bike accessory that would allow me to hoist another bike behind mine, vertically, but that would only work for one bike. From the width of that trailer, it looks like two for-parts bikes could fit, right?

At least here in California, where a moped is still a distinct type that is closer to a motorcycle but isn’t one, an electric two-wheeler above 30 MPH (48 mph) would probably be called an “e-moto”.

Not to say that there’s as much sense in retaining the moped category (up to 30 MPH, up to 4 HP or 3 kW, automatic transmission mandatory if non-electric) than when it was introduced in the 70s, but some folks really do enjoy their mopeds as a middle ground that avoids motorcycle annual registration and insurance, while having access to on-street bike lanes. I don’t snub anyone else on two wheels if they’re operating safely.

TIL finite state transducers. The BurntSushi blog post is now in my browser tab queue. Thanks!

This blog post comes to me at an interesting time, for I’ve been gathering info to rebuild my router using FreeBSD. Specifically, I bought a hard-copy of The Book Of PF, 4th Edition, for configuring PF for routing and firewalling. Like with all good firewalls, the PF rulesets start with blocking all traffic. But unlike the VyOS-based rules used by my outgoing Ubiquiti router, PF does not implicitly include rules for common use-cases, such as enabling hairpin NAT for Legacy IP. Nor does the syntax assume that rules are only for inbound, as the shortest syntax will actually apply a rule in both directions on every interface.

To that end, one of the tenants for configuring a PF firewall is to also filter outbound traffic, as a matter of: 1) asserting control over the network, and 2) implementing the principle of least privilege. I can reasonably accept that my home’s guest WiFi network should be fairly free flowing for outbound traffic, but that shouldn’t apply to my IoT VLAN. Quite frankly, my IoT VLAN only allows outbound connections to four specific NTP servers hosted by ntp.org, because my thermostat has a badly-designed real-time clock and I refuse to allow network access for devices that historically never needed it.

Before containers, firewalls implemented the DMZ idea, where any host that runs an externally-accessible service would be within the DMZ, to prevent infiltrating the broader LAN if something goes wrong. Your solution achieves a sort-of DMZ, but does it at the Docker host. Whereas a true DMZ would segment the rest of your network off, so as to further reduce risk, since iptables is the only line of defense.

That said, zooming out, this caught my attention:

The breaking point came when I wanted to host Gemini FastAPI, a project that wraps Google’s internal Gemini API into an OpenAI-compatible interface, useful for using your Gemini Pro subscription outside Google’s walled garden. The catch: it needs your browser cookies, which means full access to your Google account.

The very premise of Gemini FastAPI seems flawed to me, if it’s trying to create a wrapper when Google clearly does not want that to exist. The challenges that you observed, such as the brittleness of IP allowlists, would suggest to me that the overall endeavor is going to be brittle, by Google’s design.

To be clear, that doesn’t mean you shouldn’t pursue this, in the same way that yt-dlp exists for the legitimate use for accessing YouTube. But what both yt-dlp and Gemini FastAPI will never escape is that they only exist because Google hasn’t cracked down on it further. When every indication is showing that this is the road with even more trouble beyond the next curve, is this what you want to invest time and effort into? There are other platforms and protocols that replace YouTube, or at least minimize one’s dependency on a clearly antagonistic host.

At bottom, I think the question is whether connecting to Gemini is really worth all of this trouble, when they evidently don’t want you to do this, and it adds yet another dependency upon Google. Even if you believe Google is 100% benevolent and their lack of a built-in support for using Gemini externally is just a minor oversight, you will have to pick which services you will base your own infrastructure upon. This is, after all, c/selfhosted.

The premise is good, but the linked article is too short to explain why protocols encourage decentralization, which protects against authoritarism, censorship, and promotes bona-fide free speech (not to be confused with “BuH mAh FrEe SpEeCH!” morons that only like free speech when it agrees with them and don’t when it doesn’t).

For a more lengthy discussion, which includes Internet history, the legacy of the USA’s Section 230 of the CDA and how that impacts the modern web, and what precisely a protocol should avoid doing to successfully achieve the goal of practical decentralization, Mike Masnick’s 2019 paper “Protocols, not Platforms” is particular apt.

Yes, I know I’ve mentioned him a number of times in my comments, but there aren’t too many people who are abreast of technologcal history, the legal framework surrounding the internet, and are skilled writers to condense into words the necessary clarity upon which to build an internet that works for everyone, not just the rich or few.

As a note, BlueSky was directly inspired by his paper and he now sits on the board of BlueSky. Is that antithetical to his 2019 paper? I don’t think so, since commercial success of a protocol is how it has staying power: Amazon’s S3 API, email’s SMTP, and QUIC are all examples of protocols where everyone benefits by their ubiquity, but they had to be commercialized first, by the likes of AWS, AOL and CompuServe, and Google. BlueSky’s opponent is not another protocol like ActivityPub, but rather they challenge the platform formerly known as Twitter. The very existence of a bridge between the ATmosphere and the Fediverse proves that platforms are the real enemy, and we all need to keep that in mind.

No enemies to the left.

Your understanding is not wrong, but “within namespaces” is doing a lot of the heavy lifting. After all, there isn’t just one namespace but many simultaneous namespaces at play. A process namespace is where process IDs (PIDs) begin from 1 and fork()'d processes are assigned incrementing PIDs. These values are meaningless outside of the namespace, and might even get mapped to different values in the parent namespace. A process namespace gives the appearance that the process with PID 1 is the init process, which is customarily the first userspace process started once the kernel is running.

There are also network namespaces, where network interfaces (netif) can be switched (Layer 2) or routed (Layer 3), independent of what the global/default/parent network namespace is doing. This gives the appearance that all the network configuration is wholly independent, and allows neat things like crafting specialty routing (eg Kubernetes overlay networks).

Then there are user namespaces, where the root user has the appearance of total authority, and normal users can be created, but these are entirely distinct from the global/default/parent users and groups on the machine. This pairs well with filesystem namespaces, where a sub-tree of the real filesystem is treated as though it is a full tree, which allows the namespaced users to do standard manipulations like changing file ownership or permissions. This is essentially what UNIX chroot() does, but IIRC, chroot() did not also create user namespaces.

Taken together, namespaces in Linux are less about isolation – although they certainly work for that – and more about abstracting everything else in userspace away: no need to deal with other people’s processes, netifs, files. It’s like having the whole machine to yourself. In the history of computer science, isolation is often achieved precisely by making everything else invisible and out of the way. Virtual Memory did that, as did x86 Protected Mode, as did Virtual Machines. And so too does namespacing. Containers are the result of namespacing all the key kernel interfaces.

Perhaps the crucial thing then is what interfaces aren’t namespaced. In Linux, a big one is device drivers. Folks that want to share a USB TV capture card or a PCIe GPU or even a sub-NIC using SR-IOV, will find that /dev files are not namespaces. They exist in the global space and aren’t isolated. So the only thing that can be done is to pretend to “move” the device file into a container, with everyone else promising not to try using that device anyway. This is not isolation because accidental or malicious action will break it. To do “device isolation” would require every driver to be namespace aware, so that it could treat requests from two different namespaces as distinct. That does not exist at all in Linux, and such low-level work continues to be difficult with containers, often surprising people that think that Linux containers are complete abstractions. They are not.

There are terminology issues here, both in the Lemmy post title, in the article body, and in the article’s TL;DR. Basically, nothing is internally consistent except maybe the OCI Runtime spec itself, although its terminological relevancy is a separate issue.

Lemmy title: Containers are not Linux containers

Article title: What Is a Standard Container: Diving Into the OCI Runtime Spec

Both titles imply the existence of non-Linux containers, yet only the latter actually describes the contents of the article, specifically naming the “other” type of container, being “Standard Containers” defined by the OCI Runtime spec. As a title, I greatly prefer the latter, whereas the former is unnecessarily antagonistic.

That aside, the article could really be helped by a central glossary section, as it refers to all of these as containers, without prefacing that these can all validly be called “containers”:

• OCI-compliant containers
• Standard containers
• Linux containers
• Docker containers
• Kata VM-based containers
• Other VM-based containers that have been deprecated

If the goal was to distinguish what each of these mean, the article doesn’t do that great of a job, other than to say “these exist and aren’t Linux containers, except Linux containers are obviously Linux containers”.

Reframing what I think the article tried to convey, while borrowing some terminology from C++/Python, the OCI Runtime specification defines an Abstract Base Class known as a Standard Container. A Standard Container supports the most minimal functions of starting and stopping an execution runtime. For Linux, FreeBSD, Kata, etc, those containers are subclasses of the Standard Container.

For the most part, unless your containerized application is purely computational and has zero dependencies upon the OS, your container will be one of the subclasses. There are essentially zero practical container images that can meet the zero-dependency requirements of being a Standard Container. So while it’s true that any runtime capable of running the container subclasses could also run a Standard Container, it is of little value in production. Hence why I assert that it’s an abstract base class: it cannot really be instantiated in real life.

This is the reality of containers: none can abstract away an application’s dependency upon the OS. The container will still rely upon Win32 calls, POSIX calls, /proc, BSD sockets, or whatever else. So necessarily, all practical containers need a kernel layer. Even the case of Kata’s VM-based containers just mean that the kernel is included within the container. Portability in this context just means that the kernel version can change beneath, but you cannot take a Linux container and run it on FreeBSD, not without shims and other runtime kludges.

The other commenter have described the challenge, but I’d like to clarify the terminology, since the distinctions might not be obvious. For tech, we generally speak of the separate qualities of being Free (as in, use it however you want) and Open (aka being open to study, reimplement, and extend). If both qualities are had, then that’s called Free And Open.

The most common designation is for software, which if both Free and Open, then that’s Free And Open-Source Software (FOSS). Examples include the Linux kernel (GPL license) and FreeBSD in its entirety (MIT license). This means you can remake the software and use it how you like.

For hardware, there’s also the equivalent concept of Free And Open, and that means the PCB design can be remade and used for whatever you want. If you wish to use Free And Open hardware for war or for hobby use, that’s entirely up to you.

But there’s also the realm of silicon, which is the most esoteric and specialized, and there’s a lot less Free And Open silicon designs available. For example, the x86 CPU architecture is not Free nor Open. It is patented and its logic is proprietary and trade secrets of Intel, AMD, and Via. They document the behavior of registers, but they never publish the silicon designs so that you could make your own at home.

ARM is slightly different, in that they’ll gladly help you build your own ARM silicon (eg Apple Silicon system-on-chips) but you need to pay them a license. So it’s not Free nor Open because: 1) you have to pay money, and 2) the plans aren’t available for examination until you pay up.

LoRA silicon is more akin to x86, because they just don’t publish anything except the register behavior. The license to use the LoRA design is baked into the sale price that the LoRA Alliance charges. And yet still, you at home receive no right to remix or examine that silicon design yourself, unless you do actual reverse engineering. And even then, they have patents.

LoRA is not Open nor Free silicon. And it never claimed to be. Meshtastic and MeshCore use Free and Open hardware and software but that’s it. You do not have as many rights to the silicon as you do for the hardware and software.

The Linux kernel itself doesn’t really express an opinion – it’s a kernel, it enables you to do most things – but it’s Docker itself that imposes an opinion. And I say this after Docker Engine has basically delegated the runtime to containerd. At bottom, Docker has some serious baggage that needs to eventually be addressed, chiefly IMO the sorry state of networking.

What was done to make Docker usable initially has reared its ugly head a decade later, such as a focus on only supporting Legacy IP and NAT, with very little regard for IPv6. For example, Docker does do IPv6 today but only with NAT66 and zero support for DHCP6-PD upstream routing. This makes it incompatible to how actual v6 networks are set up, where NAT is neither desirable nor necessary. Docker’s idea of networking is so very 1990s that it’s genuinely stifling any improvements beyond the server/client TCP/UDP model.

All the meanwhile, Kubernetes is built atop sensible networking on Linux, and the BSDs have had solid networking primitives for decades. Linux is not the problem, IPv6 is not the problem, BSD is not the problem; it’s just Docker being stuck because of a lack of vision and too many users dependent on the existing behavior.

Credit where it’s due, Docker images defined as files and stores as artifacts in a central repository are a genuine innovation, and that’s precisely what BSD Bastille brings to BSD jails. So in 2026, where the OCI specification has genericized Docker images, anything that’s Docker-specific is slowly losing relevance.

The short answer is that Linux did not approach namespacing from a holistic view, but rather introduced each one at the time when they were deemed useful individually or necessary. Meanwhile, the BSDs looked at what they had from UNIX (ie chroot) and then thought about the fullest logical extent of that idea. And in doing so, looked at every kernel interface and added support to namespace (or jail) them all.

Sure, BSD jails have had their own bugs over the years, but as a design, it’s an incredible testament to building a framework that was ahead of its time by focusing on the fundamentals.

To be clear, there are sometimes use-cases where Docker containers are ran without creating separate namespaces (eg sharing the host’s network namespace) but it’s rarer than the equivalent in BSD jails, where it’s a neutral choices between isolate or reuse namespaces. In that sense, Docker is lightly opinionated into defaulting to all-isolation and makes it hard to remove all the layers, if that’s your jam.

Setting aside the Forgejo issues for a moment, I can’t quite see the logic behind the author’s description of a “carrot disclosure”.

As written, it’s a third option for disclosure, beyond 1) coordinated disclosure (often 90 days for the vendor to fix things) or 2) full disclosure (immediately going public, esp when the vulnerability is believed to be actively exploited). But what the author describes as the carrot is to publish only the output of a proof-of-concept, and then the onus is on the vendor to figure out both the vulnerability and the fixes.

This seems wildly irresponsible to me, to put the effort into writing a working PoC but then to willfully withhold it, so as to basically force the vendor into a wild goose chase. And that’s the best case scenario, when the PoC is actually legit. At worst, it’s a DoS against a vendor (causing them to re-audit code to find a bug that doesn’t actually exist, eg hallucinated AI slop) or is a form of defamation to scare users away.

Then there’s the issue of when it’s not a “vendor” per-se but a group of volunteers of an open-source project, which I will distinguish from commercial vendors as “maintainers”. Is it ethical to withhold an already-written PoC from FOSS maintainers, whom often do not have the material capabilities to do a full-scale audit when given basically no clues?

To be clear, I’m not a security researcher and have done zero disclosures of any form. But if I ever ran a project and received a so-called carrot disclosure, why shouldn’t I immediately call their bluff and treat it as full-disclosure? This situation seems like Schrodinger’s Cat, where the only way to rip away the uncertainty is to throw open the box. Worse case, the project suffers the reputational hit for having a legit vulnerability. But best case, the vulnerability is non-existent. But what this supposed “third way” purports to do is no different than sowing the seeds of fear, uncertainty, and doubt amongst users. Someone tell me how this isn’t one step away from extortion.

I think game theory would say that any and all recipients of “carrot” disclosures should always call the bluff, immediately and vocally. I don’t see any way for such disclosures to be anything but unnecessarily antagonistic. I refuse to credit the term with any legitimacy.

I find it funny how the news cycle gets multiple goes at the same story: the first is essentially rehashing their press releases uncritically, and the second comes a few weeks later after the sober reality has set in. I personally prefer to have only the later, but I suppose it’s better than never publishing the critical take.

In any case, we are witnessing yet another brand try their hand at a hardware-centric market, but entirely miss the point by being software-heavy, while also not developing the things consumers actually want: longer-life batteries, product safety, no subscriptions but unique offerings, and making it affordable.

For pointers in particular, this seems like a good starting point: https://sites.cs.ucsb.edu/~mikec/cs16/misc/ptrtut12/pointers.htm

As for compiling for old C/C++ versions, fortunately most compilers can be set to restrict what standard they will compile for. So you could turn the compiler all the way back to something like C99 and it should work, although you’ll have to avoid using modern syntax.

That said, with regards to compiling for an old platform, be advised that complete and functional toolchains will be harder to come across. They may not even work anymore, if they haven’t been upkept. That’s another complexity that you may have to deal with, and it will no doubt be aggravating, than working with a modern platform but limiting yourself to only older C/C++ standards and graphics libraries.

Basically, the starting effort is quite high for developing for older targets. Be certain that this is the direction you want to start with.

It could make sense, but what would be gained? A geographically-broader mesh sounds nice, until you realize that it means messages will go across the IP link and continue propagating on the other end, tying up the RF spectrum, even for traffic that didn’t need to cross the IP link.

It also detracts from what a fair number of people use the mesh for: comms without reliance on fallible singular links. Single points of failure are not ideal in a mesh, and an IP link would be adding exactly that.

Note that Reticulum has a much more developed routing structure, so that flood messages do not propagate everywhere uselessly. In that regard, Reticulum has learned what Ethernet and 802.11 WiFi have known for decades, while Meshtastic finds itself playing catch-up.

A managed flood is still a flood, so introducing a trunk link will increase the “broadcast domain”, to use Ethernet parlance. For two quiet, small meshes, a link between them might be alright. But for two busy, small meshes, the extra floods are just noise and drown out traffic.