litchralee

@litchralee@sh.itjust.works

• ⁨Comment⁩ on ⁨What efforts would it take to strip the name Americans from the folks inhabiting the US?⁩ ⁨⁨4⁩ ⁨hours⁩ ago⁩:

  I’ve not known any USA residents that call the continent as “America”. Instead, the continent – which in this case basically just means USA + Canada – would be “North America”. And if they meant the whole post-1490s “New World”, it would be “The Americas” for both North and South America together.

• ⁨Comment⁩ on ⁨How can you oppose tariffs, while supporting a hardline against China on Taiwan?⁩ ⁨⁨4⁩ ⁨days⁩ ago⁩:

  Thank you for you kind words!

• ⁨Comment⁩ on ⁨How can you oppose tariffs, while supporting a hardline against China on Taiwan?⁩ ⁨⁨4⁩ ⁨days⁩ ago⁩:

  I had an inkling that was the case. But I figured that, for my own benefit, I’d elucidate my position a bit more. If it falls on deaf bot ears, then that’s just how it is. There’s not much else I was going to say anyway.

• ⁨Comment⁩ on ⁨How can you oppose tariffs, while supporting a hardline against China on Taiwan?⁩ ⁨⁨4⁩ ⁨days⁩ ago⁩:

  I agree that requiring certain industries to be based domestically is the best route

  This isn’t what I said at all. What I meant was, for service businesses (eg car dealerships, warehouses, restaurants) and heavy industry (eg oil refineries, plastics and chemicals, composites like wind turbine blades or aircraft fuselages) which practically must remain within the country, support those endeavors by making it easier or cheaper to operate, so that an internal economy for those products develops locally. Trying to force stronger internal ties would inevitably lead to resources and incentives spent where they’re not most needed.

  If you don’t tariff everyone, how does that bring manufacturing back? They’ll just move to the next cheapest country, and then you’re playing whack-a-mole.

  I’m not sure if you saw my Mexico example or not, but manufacturing that moves from China to Mexico would still further a USA policy of reduced economic dependency on China. It doesn’t matter so much that it’s not “Made in USA” so much that it’s not “Made in China”, if that’s the desired economic policy.

  And that doesn’t even include the knock-on effects that anchoring the Mexican economy would create: economic migration – when people move from a place of poorer economic condition to a richer economic place – would naturally abate if the Mexican economy grew. Economic opportunity also displaces gang warfare and drug distribution, in part.

  The alternative is to apply huge subsidies for manufactures to ignore Mexico and set up shop in the USA, but then the cost of land, labor, and capital is substantially higher, and the products less affordable because they must be higher priced to pay for those means of production. Why do all this when Mexico or Canada are right next door?

• ⁨Comment⁩ on ⁨How can you oppose tariffs, while supporting a hardline against China on Taiwan?⁩ ⁨⁨4⁩ ⁨days⁩ ago⁩:

  If you don’t support tariffs to bring back manufacturing jobs domestically, how do you think we could make it through a war with our manufacturing partners?

  I express no position here about China nor Taiwan, but the false dichotomy presented is between: 1) enforce trade barriers indiscriminately against every country, territory, and uninhabitable island in the world without regard for allies nor enemies, or 2) diversify economic dependency away from one particular country.

  The former is rooted in lunacy and harkens back to the mercantilism era, where every country sought to bring more gold back home and export more. The latter is pragmatic and diplomatic, creating new allies (economically and probably militarily) and is compatible with modern global economic notions like comparative advantage, where some countries are simply better at producing a given product, so that other countries can focus on their own specialization.

  As a specific example, see Mexico, which under NAFTA and USMCA stood to be America’s new and rising manufacturing comrade. Mexico has the necessary geographical connectivity to the mainland USA, its own diverse economy, relatively cheap labor, timezones and culture that make for easier business dealings than cross-Pacific, and overall was very receptive to the idea of taking a share of the pie from China.

  Long-term thinking would be to commit to this strategic position, this changing the domestic focus to: 1) replace China with North America suppliers for certain manufactured goods, 2) continue to foster industries which are “offshore-proof”, such as small businesses that simply have to exist locally or industries that remain super-expensive or hazrdous to ship (eg lithium ion batteries).

  It is sheer arrogance to believe that the economic tide for industries of yore (eg plastic goods, combustion motor vehicles, call centers) can be substantially turned around in even a decade, when that transition away from domestic manufacturing took decades to occur.

• ⁨Comment⁩ on ⁨On email privacy: can I store my own email and relay them through an email provider?⁩ ⁨⁨5⁩ ⁨days⁩ ago⁩:

  Agreed. Email has its uses – ubiquity, mostly “Just Works” ™, most people know how to use it – and while I might send an encrypted PDF along with a plaintext email, I’m more inclined to suggest that my recipients adopt Signal and get all the benefits of e2ee. EFF even has a guide for it: ssd.eff.org/module/how-to-use-signal

• ⁨Comment⁩ on ⁨On email privacy: can I store my own email and relay them through an email provider?⁩ ⁨⁨5⁩ ⁨days⁩ ago⁩:

  This 100%. It is well-advised to consider what your security/privacy objectives are, since encryption-at-rest is different than guarding against eavesdropping when sending outbound mail. What threat model you use will define what is or isn’t acceptable.

• ⁨Comment⁩ on ⁨On email privacy: can I store my own email and relay them through an email provider?⁩ ⁨⁨5⁩ ⁨days⁩ ago⁩:

  I previously looked into doing exactly this, and recall this comment on HN: news.ycombinator.com/item?id=31245923

  One could argue the price of smtp2go at $150/yr is a bit steep, but it would also neatly avoid issues with sending outbound mail, since you’re paying them to deal with those headaches. For inbound mail, I can’t see why any mail operator wouldn’t deliver to the server designated by your MX records, though you’ll also have to deal with spam and other concerns vis-a-vis self hosting.

  On the same thread but different comment, VPS operators might already run an SMTP server that you can relay through.

  I wish you good luck in this endeavor!

• ⁨Comment⁩ on ⁨[deleted]⁩ ⁨⁨6⁩ ⁨days⁩ ago⁩:

  300 kph is 186 mph, which is well beyond the posted speed limit of any jurisdiction I can think of. For reference, here in California, a conviction for driving over 160 kph (100 mph) is punishable as a felony, meaning at least one year in state prison. The highest speed limit in California is 113 kph (75 mph).

  In metric units, a triple digit speed (eg 100 kph) is the domain of motorways (aka freeways or expressways). And even arrow-straight motorways have a maximum posted speed limit of some 140 kph. In Germany, the motorway can sometimes have no limit, but the recommended speed – the yellow speed limits in the USA – for German autobahns is 130 kph, with some speedy cars occasionally doing 200 kph, I’ve heard.

  For further reference, the fastest speed achieved during an F1 motor race is 372 kph. Also, Japanese bullet trains heading west from Tokyo on the Tokaido Shinkansen route run at 285 kph.

  300 kph on a public road is grossly irresponsible, since even with no one around, the road is not designed for that speed. Compare race tracks with freeways, and it becomes clear that surface quality, drainage, sight lines, clear space, and other requirements for 200+ kph just aren’t present on public roads, with the notable exception of very special public roads like the Nürburgring.

• ⁨Comment⁩ on ⁨Why do some say they own or have bought something that they technically haven't (e.g. domain names, expensive things, etc.)?⁩ ⁨⁨1⁩ ⁨week⁩ ago⁩:

  FYI, some domains can genuinely be acquired for an indefinite period, as the delegation has no expiration period. So long as the domain is kept in good standing (eg two working authoritative nameservers) and doesn’t violate the parent domains’ policies, it will persist. Granted, few people go through this rather-old process to get such domains but they do exist. See my earlier comment.

• ⁨Comment⁩ on ⁨PSA: If your Jellyfin is having high memory usage, add MALLOC_TRIM_THRESHOLD_=100000 to environment⁩ ⁨⁨1⁩ ⁨week⁩ ago⁩:

  PS: Reddit doesn’t allow edit post titles, needed to repost

  But this is Lemmy.

• ⁨Comment⁩ on ⁨What are your favorite RSS feeds?⁩ ⁨⁨1⁩ ⁨week⁩ ago⁩:

  I think we had this question a while ago: programming.dev/post/26356684

• ⁨Comment⁩ on ⁨Other than a faulty charging port, is there any reason to use a wireless phone charger over wired?⁩ ⁨⁨1⁩ ⁨week⁩ ago⁩:

  I’m also old, but I understand people do watch portrait videos. Sometimes a lot of them, in a single sitting. There’s a popular social media app which exclusively has short-form portrait videos.

• ⁨Comment⁩ on ⁨Other than a faulty charging port, is there any reason to use a wireless phone charger over wired?⁩ ⁨⁨1⁩ ⁨week⁩ ago⁩:

  Some charging pads also prop up the phone at an angle, making it easy to read the screen while also not having to hold the phone up. Most phones have their charging port on the bottom, so a phone stand couldn’t be used while charging with a cord.

• ⁨Comment⁩ on ⁨Should I withdraw/stop putting into my 401k?⁩ ⁨⁨1⁩ ⁨week⁩ ago⁩:

  This 100%. The other comments addressed the “should I withdraw?” aspect of OP’s question, but this comment deals with “should I stop contributing?”. The answer to the latter is: no.

  The mantra in investing has always been “buy low, sell high”. If the stock market is down, continuing your 401k contributions is doing the “buy low” part.

• ⁨Comment⁩ on ⁨How do I fit a network card with a physical x4 slot into an x1 slot?⁩ ⁨⁨1⁩ ⁨week⁩ ago⁩:

  A word of caution for anyone cutting out the slot: make sure there aren’t other instructions, like capacitors, ICs, and NVMe drives in the way of where the PCIe card will be.

  The manufacturers that have the slot pre-cut will have already reserved the space, but even then, it’s on you to check that it’s suitable for a x16 if they only reserved space for a x8 card.

• ⁨Comment⁩ on ⁨SEIM⁩ ⁨⁨2⁩ ⁨weeks⁩ ago⁩:

  SEIM? Do you mean SIEM, Secure Information and Event Management?

• ⁨Comment⁩ on ⁨how do they decide where to put bus stops?⁩ ⁨⁨2⁩ ⁨weeks⁩ ago⁩:

  I can understand the pessimism in some of the answers given so far, especially with regards to the poor state of American public transit. But ending a discussion with “they guess” is unsatisfactory to me, and doesn’t get to the meat of the question, which I understand to be: what processes might be used to identify candidate bus stop locations.

  And while it does often look like stops are placed by throwing darts at a map, there’s at least some order and method to it. So that’s what I’ll try to describe, at least from the perspective of a random citizen in California that has attended open houses for my town’s recently-revamped bus network.

  In a lot of ways, planning bus networks are akin to engineering problems, in that there’s almost never a “clean slate” to start with. It’s not like Cities Skylines where the town/city is built out by a single person, and even master planned developments can’t predict what human traffic patterns will be in two or three decades. Instead, planning is done with regards to: what infrastructure already exists, where people already go, and what needs aren’t presently being met by transit.

  Those are the big-picture factors, so we’ll start with existing infrastructure. Infra is expensive and hard to retrofit. We’re talking about the vehicle fleet, dedicated bus lanes, bus bulbs or curb extensions, overhead wires for trolleybuses, bus shelters, full-on BRT stops, and even the sidewalk leading up to a bus stop. If all these things need to be built out for a bus network, then that gets expensive. Instead, municipalities with some modicum of foresight will attach provisos to adjacent developments so that these things can be built at the same time in anticipation, or at least reserve the land or right-of-way for future construction. For this reason, many suburbs in the western USA will have a bulb-out for a bus to stop, even if there are no buses yet.

  A bus network will try to utilize these pieces of infrastructure when they make sense. Sometimes they don’t make total sense, but the alternative of building it right-sized would be an outlandish expense. For example, many towns have a central bus depot in the middle of downtown. But if suburban sprawl means that the “center of population” has moved to somewhere else, then perhaps a second bus depot elsewhere is warranted to make bus-to-bus connections. But two depots cost more to operate than one, and that money could be used to run more frequent buses instead, if they already have those vehicles and drivers. Tradeoffs, tradeoffs.

  Also to consider are that buses tend to run on existing streets and roads. That alone will constraint which way the bus routes can operate, especially if there are one-way streets involved. In this case, circular loops can make sense, although patrons would need to know that they’ll arrive at one stop and depart at another. Sometimes bus-only routes and bridges are built, ideally crossing orthogonal to the street grid to gain an edge over automobile traffic. In the worst case, buses get caught up in the same traffic as all the other automobiles, which sadly is the norm in America.

  I can only briefly speak of the inter-stop spacing, but it’s broadly a function of the service frequency desired, end-to-end speed, and how distributed the riders are. A commuter bus from a suburb into the core city might have lots of stops in the suburb and in the city, but zero stops in between, since the goal is to pick people up around the suburb and take them somewhere into town. For a local bus in town, the goal is to be faster than walking, so with 15 minute frequencies, stops have to be no closer than 400-800 meters or so, or else people will just walk. But then a service which is purely meant to connect between two bus depots would prefer a few more stops in between that make sense, like a mall, but maybe not if it can travel exclusively on a freeway or in a dedicated bus lanes. So many things to consider.

  As for existing human traffic patterns, the new innovation in the past decade or so has been to look at anonymized phone location data. Now, I’m glossing over the privacy concern of using people’s coarse location data, but the large mobile carriers in the USA have always had this info, and this is a scenario where surveying people about which places they commute or travel to is imprecise, so using data collected in the background is fairly reliable. What this should hopefully show is where the “traffic centers” are (eg malls, regional parks, major employers, transit stations), how people are currently getting there (identifying travel mode based on speed, route, and time of day), and the intensity of such travel in relationship to everyone else (eg morning/evening rush hour, game days).

  I mentioned surveys earlier, which while imprecise for all the places that people go to, it’s quite helpful for identifying the existing hurdles that current riders face. This is the third factor, identifying unmet needs. As in, difficulties with paying the fare, transfers that are too tight, or confusing bus depot layouts. But asking existing riders will not yield a recipe for growing ridership with new riders, people who won’t even consider riding the existing service, if one exists at all. Then there’s the matter of planning for ridership in the future, as a form of induced demand: a housing development that already sits on an active bus line is more likely to create habitual riders from day 1.

  As an aside, here in California, transit operators are obliged to undergo regular analysis of how the service can be improved, using a procedure called Unmet Transit Needs. The reason for this procedure is that some state funds are earmarked for transit only, while others are marked for transit first and if no unmet needs exist, then those funds can be applied to general transport needs, often funding road maintenance.

  This process is, IMO, horrifically abused to funnel more money towards road maintenance, because the bar for what constitutes an Unmet Transit Need includes a proviso that if the need is too financially burdensome to meet, they can just not do it. Thats about as wishy-washy as it gets, and that’s before we consider the other provisio that requires an unmet need to also satisfy an expectation of a certain minimum ridership… which is near impossible to predict in advance for a new bus route or service. As a result, transit operators – under pressure to spend less – can basically select whichever outside consultant will give them the “this unmet transit need is unreasonable” stamp of disapproval that they want. /rant

  But I digress. A sensible bus route moves lots of people from places they’re already at to places they want to go, ideally directly or maybe through a connection. The service needs to be reliable even if the road isn’t, quick when it can be, and priced correctly to keep the lights on but maybe reduced to spur new ridership. To then build out a network of interlinking bus routes is even harder, as the network effect means people have more choices on where to go, but this adds pressure on wayfinding and fare structures. And even more involved is interconnecting a bus network to a tram/tram/LRT system or an adjacent town’s bus network.

  When they’re doing their job properly, bus routing is not at all trivial, and that’s before citizens are writing in with their complaints and conservatives keep trying to cut funding.

• ⁨Comment⁩ on ⁨Why don’t wireless connections (WiFi, Bluetooth, etc.) use anything between 2.4Ghz and 5Ghz?⁩ ⁨⁨2⁩ ⁨weeks⁩ ago⁩:

  have bandwidth that is some % of carrier frequency,

  In my limited ham radio experience, I’ve not seen any antennas nor amplifiers which specify their bandwidth as a percentage of “carrier frequency”, and I think that term wouldn’t make any sense for antennas and (analog) amplifiers, since the carrier is a property of the modulation; an antenna doesn’t care about modulation, which is why “HDTV antennas” circa 2000s in the USA were merely a marketing term.

  The only antennas and amplifiers I’ve seen have given their bandwidth as fixed ranges, often accompanied with a plot of the varying gain/output across that range.

  going up in frequency makes bandwidth bigger

  Yes, but also no. If a 200 kHz FM commercial radio station’s signal were shifted from its customary 88-108 MHz band up to the Terahertz range of the electromagnetic spectrum (where infrared and visible light are), the bandwidth would still remain 200 kHz. Indeed, this shifting is actually done, albeit for cable television, where those signals are modulated onto fibre optic cables.

  What is definitely true is that way up in the electromagnetic spectrum, there is simply more Hertz to utilize. If we include all radio/microwave bands, that would be the approximate frequencies from 30 kHz to 300 GHz. So basically 300 GHz of bandwidth. But for C band fibre optic cable, their usable band is from 1530-1565 nm, which would translate to 191-195 THz, with 4 THz of bandwidth. That’s over eight times larger!

  For less industrial use-cases, we can look to 60 GHz technology, which is used for so-called “Wireless HDMI” devices, because the 7 GHz bandwidth of the 60 GHz band enables huge data rates.

  To actually compare the modulation of different technologies irrespective of their radio band, we often look to special efficiency, which is how much data (bits/sec) can be sent over a given bandwidth (in Hz). Higher bits/sec/Hz means more efficient use of the radio waves, up to the Shannon-Hartley theoretical limits.

  getting higher % of bandwidth requires more sophisticated, more expensive, heavier designs

  Again, yes but also no. If a receiver need only receive a narrow band, then the most straightforward design is to shift the operating frequency down to something more manageable. This is the basis of superheterodyne FM radio receivers, from the era when a few MHz were considered to be very fast waves.

  We can and do have examples of this design for higher microwave frequency operation, such as shifting broadcast satellite signals down to normal television bands, suitable for reusing conventional TV coax, which can only carry signals in the 1-2 GHz band at best.

  The real challenge is when a massive chunk of bandwidth is of interest, then careful analog design is required. Well, maybe only for precision work. Software defined radio (SDR) is one realm that needs the analog firehose, since “tuning” into a specific band or transmission is done later in software. A cheap RTL-SDR can view a 2.4 MHz slice of bandwidth, which is suitable for plenty of things except broadcast TV, which needs 5-6 MHz.

  LoRa is much slower, caused by narrowed bandwidth but also because it’s more noise-resistant

  I feel like this states the cause-and-effect in the wrong order. The designers of LoRa knew they wanted a narrow-band, low-symbol rate air interface, in order to be long range, and thus were prepared to trade away a faster throughput to achieve that objective. I won’t say that slowness is a “feature” of LoRa, but given the same objectives and the limitations that this universe imposes, no one has produced a competitor with blisteringly fast data rate. So slowness is simply expected under these circumstances.

  In the final edit of my original comment, I added this:

  Radio engineering, like all other disciplines of engineering, centers upon balancing competing requirements and limitations in elegant ways. Radio range is the product of intensely optimizing all factors for the desired objective.

• ⁨Comment⁩ on ⁨Why don’t wireless connections (WiFi, Bluetooth, etc.) use anything between 2.4Ghz and 5Ghz?⁩ ⁨⁨2⁩ ⁨weeks⁩ ago⁩:

  Also, what if things that require very little data transmission used something lower than 2.4Ghz for longer range? (1Ghz or something?)

  No one seemed to touch upon this part, so I’ll chime in. The range and throughput of a transmission depends on a lot of factors, but the most prominent are: peak and avg output power, modulation (the pattern of radio waves sent) and frequency, background noise, and bandwidth (in Hz; how much spectrum width the transmission will occupy), in no particular order.

  If all else were equal, changing the frequency to a lower band wouldn’t impact range or throughput. But that’s hardly ever the case, since reducing the frequency imposes limitations to the usable modulations, which means trying to send the same payload either takes longer or uses more spectral bandwidth. Those two approaches have the side-effect that slower transmissions are more easily recovered from farther away, and using more bandwidth means partial interference has a lesser impact, as well as lower risk of interception. So in practice, a lower frequency could improve range, but the other factors would have to take up the slack to keep the same throughput.

  Indeed, actual radio systems manipulate some or all of those factors when longer distance reception is the goal. Some systems are clever with their modulation, such as FT8 used by amateur radio operators, in order to use low-power transmitters in noisy radio bands. On the flip side, sometimes raw power can overcome all obstacles. Or maybe just send very infrequent, impeccably narrow messages, using an atomic clock for frequency accuracy.

  To answer the question concretely though, there are LoRa devices which prefer to use the ISM band centered on 915 MHz in The Americas, as the objective is indeed long range and small payload, and that means the comparatively wider (and noisier) 2.4 GHz band is unneeded and unwanted. But this is just one example, and LoRa has many implementations that change the base parameters. Like how MeshCore and Meshtastic might use the same physical radios but the former implements actual mesh routing, while the latter floods to all nodes.

  But some systems like WiFi or GSM can be tuned for longer range while still using their customary frequencies, by turning those other aforementioned knobs. Custom networks could indeed be dedicated to only sending very small amounts of data, like for telemetry. That said, GSM does have a hard cap of 35 km, for reasons having to do with how it handles multiple devices at once.

• ⁨Comment⁩ on ⁨CryptPad.org, the end to end encrypted collaboration suite⁩ ⁨⁨4⁩ ⁨weeks⁩ ago⁩:

  I’ve been reading a lot of Soatok’s blog, so when I see software that claims to be privacy-oriented, my first thought is: secure against what?

  And in a refreshing change of pace, CryptPad actually outlines their threat model and how the software features might widen certain threats plus how to avoid those pitfalls. I’m not a security expert, but it’s clear they paid at least some attention to assuring privacy, rather than just paying it lip-service. So we’re off to a good start.

• ⁨Comment⁩ on ⁨What host names do you use?⁩ ⁨⁨4⁩ ⁨weeks⁩ ago⁩:

  I select hostnames drawn from the ordinal numerals of whatever language I happen to be trying to learn. Recently, it was Japanese so the first host was named “ichiro”, the second as “jiro”, the third as “saburo”.

  These are the romanized spellings of the original kanji characters: 一郎, 二郎, and 三郎. These aren’t the ordinal numbers per-se (eg first, second, third) but are an old way of assigning given names to male children. They literally mean “first son”, “second son”, “third son”.

  Previously, I did French ordinal numbers, and the benefit of naming this way is that I can enumerate a countably infinite number of hosts lol

• ⁨Comment⁩ on ⁨How to get a unique MAC/DHCP IP for a Docker/Podman container without MACVLAN?⁩ ⁨⁨4⁩ ⁨weeks⁩ ago⁩:

  Kubernetes does indeed have a learning curve, but it’s also strangely accommodating for single-node setups which can then be expanded only by adding components, rather than tearing the whole thing down and starting again. In that sense, it’s a great learning platform towards managing larger or commercial clusters, if simply to get experience with the unique challenges inherent to scaling up.

  But that might be more of a !homelab@lemmy.ml point of view haha

• ⁨Comment⁩ on ⁨How to get a unique MAC/DHCP IP for a Docker/Podman container without MACVLAN?⁩ ⁨⁨4⁩ ⁨weeks⁩ ago⁩:

  Ah, now I understand your setup. To answer the title question, I’ll have to be a bit verbose with how I think Incus behaves, so that the Docker behavior can be put into context. Bear with me.

  br0 has the same MAC as the eth0 interface

  This behavior stood out to me, since it’s not a fundamental part of Linux bridging. And it turns out that this might be a systemd-specific thing, since creating a bridge is functionally equivalent to a software switch, where every port of the switch has its own MAC, and all “clients” to that switch also have their own MAC. If I had to guess, systemd does this so that traffic from the physical interface (eth0) that passes directly through to br0 will have the MAC from the physical network, thus making it easier to understand traffic flows in Wireshark, for example. I personally can’t agree with this design choice, since it obfuscates what Linux is really doing vis-a-vis a software switch. But reusing this MAC here is merely a weird side-effect and doesn’t influence what Incus is doing.

  Instead, the reason Incus needs the bridge interface is precisely because a physical interface like eth0 will not automatically forward frames to subordinate interfaces. Whereas for a virtual switch, that’s the default. To that end, the bridge interface is combined with virtual ethernet (veth) interfaces – another networking primitive in Linux – to each container that Incus manages. The behavior of a veth is akin to a point-to-point network cable, plus the NICs on both ends. That means a veth always consists of a pair of interfaces, where traffic into one end comes out the other, and each interface has its own MAC address. Functionally, this is the networking equivalent of a bidirectional pipe.

  By combining a bridge (ie a virtual swich) with veth (ie virtual cables), we have a full Layer 2 network topology that behaves identically as if it were a physical bridge with physical cables. Thus, your DHCP server is none the wiser when it sends and receives BOOTP traffic for assigning an IP address. This is the most flexible way of constructing a virtual network within Linux, since it has feature-parity with physical networks: there is no Macvlan or Ipvlan or tunneling or whatever needed to make this work. Linux is just operating as a switch, with all the attendant flexibility. This architecture is what Calico – a network framework for Kubernetes – uses, in order to achieve scalable, Layer 3 connectivity to containers; by default, Kubernetes does not depend on Layer 2 to function.

  OK, so we now understand why Incus does things the way it does. For Docker, when using the Macvlan driver, the benefits of the bridge+veth model are not achieved, because Macvlan – although being a feature of Linux networking – is something which is implemented against an individual interface on the host. Compare this to a bridge, which is a standalone concept and thus can exist with or without any interfaces to the host: when Linux is actually used as a switch – like on many home routers – the host itself can choose to have zero interfaces attached to the switch, meaning that traffic flows through the box, rather than to the box as a destination.

  So when creating subordinate interfaces using Macvlan, we get most of the bridging behavior as bridge+veth but the Macvlan implementation in the kernel means that outbound traffic from a subordinate interface always get put onto the outbound queue of the parent interface. This makes it impossible for a subordinate interface to exchange traffic with the host itself, by design. Had they chosen to go the extra mile, they would have just reinvented a version of bridge+veth that is excessively niche.

  We also need to discuss the behavior of Docker networks. Similar to Kubernetes, containers managed by Docker mandate having IP connectivity (Layer 3). But whereas Kubernetes will not start a container unless an IPAM (IP Address Management) plugin explicitly provides an IP address, Docker’s legacy behavior is to always generate a random IP address from a default range, unless given an IP explicitly. So even though bridge+veth or Macvlan will imbue Layer 2 connectivity to a DHCP server to obtain an IP address, Docker is eager to provide an IP, just so the container has one from the very start. The distinction between Docker and Kubernetes+Calico is thus one of actual utility: by getting an address from Calico’s IPAM, Kubernetes knows that the address will actual work for networking, because Calico also creates/manages a network. Whereas Docker has no problem assigning an IP but not actually checking if this IP can be used on that network; it’s almost a pro-forma exercise.

  I will say this about early Docker: although they led the charge for making containers useful, how they implemented networking was very strange and led to a whole class of engineers who now have a deep misunderstanding of how real networks operate, and that only causes confusion when scaling up to orchestrated container frameworks like Kubernetes that depend on rigorous understanding of networking and Linux implementations. But all the same, Docker was more interested in getting things working without external dependencies like DHCP servers, so there’s some sense in mandating an IP locally, perhaps because they didn’t yet envision that containers would talk to the physical network.

  The plugin that you mentioned operates by requesting a DHCP-assigned address for each container, but within the Docker runtime. And once it obtains that address, it then statically assigns it to the container. So from the container’s perspective, it’s just getting an IP assigned to it, not aware that DHCP has happened at all. The plugin is thus responsible for renewing that IP periodically. It’s a kludge to satisfy Docker’s networking requirements while still using DHCP-assigned addresses. But Docker just doesn’t play well with Layer 2 physical networks, because otherwise the responsibility for running the DHCP client would fall to the containers; some containers might not even have a DHCP client to run.

  If I’m missing something about MACVLAN that makes DHCP work for Docker, let me know!

  Sadly, there just isn’t a really good way to do this within Docker, and it’s not the kernel’s fault. Other container runtimes like containerd – which relies wholly on the standard CNI plugins and thus doesn’t have Docker’s networking footguns – have no problem with containers running their own DHCP client on a bridged network. But for any container manager to handle DHCP assignment without the container’s cooperation always leads to the same kludge as what Docker did. And that’s probably why no major container manager does that natively; it’s hard to solve.

  I do wish there could be something like Incus’ hassle-free solution for Docker or Podman.

  Since your containers were able to get their own DHCP addresses from a bridged network in Incus, can you still run the DHCP client on those containers to override Docker’s randomly-assigned local IP address? You’d have to use the bridge network driver in Docker, since you also want host-container traffic to work and we know Macvlan won’t do that. But even this is a delicate solution, since if DHCP fails to assign an address, then your container still has the Docker-assigned address but it won’t be usable on the bridged network.

  The best solution I’ve seen for containers on DHCP-assigned networks is to not use DHCP assignment at all. Instead, part of the IP subnet is carved out, a region which is dedicated only for containers. So in a home IPv4 network like 192.168.69.0/24, the DHCP server would be restricted to only assigning 192.168.69.2 through 192.168.69.127, and then Docker would be allowed to allocate the addresses from 192.168.69.128 to 192.168.69.254 however it wants, with a subnet mask of 255.255.255.0. This mask allows containers to speak directly to addresses in the entire 192.168.69.0/24 range, which includes the rest of the network. The other physical hosts do the same, allowing them to connect to containers.

  This neatly avoids interacting with the DHCP server, but at a loss of central management and it splits the allocatable addresses into smaller parts, potentially causing exhaustion in one side while the other has spare addresses. Yet another reason to adopt IPv6 as the standard for containers, but I digress. For Kubernetes and similar orchestration frameworks, DHCP isn’t even considered since the orchestrator must have full internal authority to assign addresses with its chosen IPAM plugin.

  TL;DR: if your containers are like mini VMs, DHCP assignment is doable. But if they’re pre-packaged appliances, then only sadness results when trying to use DHCP.

• ⁨Comment⁩ on ⁨How to get a unique MAC/DHCP IP for a Docker/Podman container without MACVLAN?⁩ ⁨⁨4⁩ ⁨weeks⁩ ago⁩:

  I want to make sure I’ve understood your initial configuration correctly, as well as what you’ve tried.

  In the original setup, you have eth0 as the interface to the rest of your network, and eth0 obtains a DHCP-assigned address from the DHCP server. Against eth0, you created a bridge interface br0, and your host also obtains a DHCP-assigned address in br0. Then in Incus, you created a Macvlan network against br0, such that each containers against this network will be assigned a random MAC, and all the container Ethernet frames will be bridged to br0, which in-turn bridges to eth0. In this way, all containers can each receive a DHCP-assigned address. Also, each container can send traffic to the br0 IP address, to access services running on the host. Do I have that right?

  For your Docker attempt, it looks like you created a Docker network using the Macvlan driver, but it wasn’t clear to me if the parent interface here was eth0 or br0, if you still have br0. When you say “I have MACVLAN working”, can you describe which aspect is working? Unique MAC assignment? Bridged traffic to/from the containers or the network?

  I’m not very familiar with Incus, but I’m entirely in the dark about this shoddy plugin you mentioned for DHCP and Macvlan to work. So far as I’m aware, modern Docker Engine uses the CNI plugins when creating networks, so the “-d macvlan” parameter specifies which CNI plugin will load. Since this would all be at Layer 2, I don’t see why a plugin is needed to support DHCP – v4 or v6? – traffic.

  And the host cannot contact the container due to the MACVLAN method

  Correct, but this is remedied by what’s to follow…

  Can I make another bridge device off of br0 and bind to that one host-like?

  Yes, this post seems to do exactly that: kcore.org/2020/08/18/macvlan-host-access/

  I can always put a Docker/podman inside of an Incus container, but I’d like to avoid onioning if possible.

  I think you’re right to avoid multiple container management tools, if simply because it’s generally unnecessary. Although it kinda looks like Incus is more akin to Proxmox, in that it supports managing VMs and containers, whereas Podman and Docker only manage containers, which is further still distinct from the container runtime (eg CRI-O, containerd, Docker Engine (which uses containerd under the hood)).

• ⁨Comment⁩ on ⁨When fighter jets are scrambled to intercept a plane for security reasons, what can they actually do?⁩ ⁨⁨5⁩ ⁨weeks⁩ ago⁩:

  Movies would have people believe that the jets are there to shoot down the errant jet. During the Cold War, this was entirely plausible and did happen. But more commonly, when a fighter jet is sent to intercept an unknown aircraft – perhaps one that has entered restricted or prohibited airspace – it may be just to have eyes on the situation.

  Airspace is huge. The vastness of the air is like the vastness of the sea. Sometimes it’s an advantage because there’s fewer things to hit. But on the flip side, if an aircraft needs assistance, there might not be anyone for many miles in any direction. As for what an assisting fighter jet can do, the first is to establish navigational accuracy. History has shown that airplanes can get lost, and sometimes unfortunately end up hitting mountains or running into known obstacles or weather. A second aircraft can confirm the first aircraft’s position, since two separate aircraft having navigational problems is exceptionally rare.

  The next thing is having eyes on the outside of the aircraft. Things like a damaged engine on a jetliner aren’t visible to the pilots, but there’s a chance the passengers or cabin crew can look. But damage to a rudder is impossible to see from inside the aircraft; I’m not yet aware of a commercial aircraft equipped with a tail-viewing camera.

  Finally, if it should come to it, an assisting aircraft can be the pilot’s eyes, if for some reason the pilots can no longer see out their windscreen. At this point, the flight be alreybe doomed but it may help avoid additional casualties on the ground. I’m reminded of the flight where volcanic ash sandblasted the windshield, or when a cargo jet had a fire onboard which filled the cockpit with thick smoke.

  To be clear, neither incident was aides by fighter jets, but having an external set of eyes to give directions would have made things a little bit easier for the pilots.

• ⁨Comment⁩ on ⁨What RSS feeds are you subscribed to?⁩ ⁨⁨5⁩ ⁨weeks⁩ ago⁩:

  Ctrl Alt Speech: a podcast by TechDirt’s Mike Masnick (who coined the term “Streisand Effect”) about online speech and content regulation, and how it’s not at all a simple nor straightforward task.

  Feed: feeds.buzzsprout.com/2315966.rss

  Soatok’s Dhole Moments: a blog on cryptography and computer security, with in-depth algorithm discussions interspersed with entertaining furry art. SFW. Also find Soatok on Mastodon.

  Feed: soatok.blog/feed/

  Molly White’s Citation Needed newsletter: critiques of cryptocurrency, regulations, policies, and news. Also find Molly White on Mastodon. She also has a site dedicated to cryptocurrency disasters.

  Feed: www.citationneeded.news/rss/

  Feed: www.web3isgoinggreat.com/feed.xml

• ⁨Comment⁩ on ⁨Does 'attempted murder' require a viable method?⁩ ⁨⁨5⁩ ⁨weeks⁩ ago⁩:

  IANAL. In the USA, the majority of US States adopt some definition of murder based on the age-old definition from English common law. But each state modifies the definition to include or exclude things, to the point that discussing even just a single state’s definition would be a mini law course. However, some generalities can be drawn using just the age-old definition.

  Murder is generally defined as having four elements, or components which the trier-of-fact (eg a jury) must find in order for culpability to attach. Attempted murder is the absence of the fourth element. This is not rigorous, since again, we’d have to identify the exact jurisdiction and the question didn’t indicate one. Anyone who has:

  1. Has performed or omitted some act…
  2. Which is the proximate cause of death…
  3. With malice aforethought…
  4. And the victim dies…

  Is guilty of the crime of murder. As a minor discussion of these points, the first element means that positively doing something (eg cutting a safety strap) and not doing something (eg not turning off the electricity to exposed wires) can be parts of a murder charge. For the second element, the term “proximate cause” is a legal term deeply entwined with “foreseeability” and whether a chain of causation or liability connects the act with the death. A Rube Goldberg-esque manner of death might fail the proximate cause element, unless the setup was purposely concocted precisely to kill. Likewise, proximate cause isn’t always the last element in a chain of events, since that would mean a victim would be their own killer for walking into firing range of a sniper laying-in-wait.

  The third element, malice aforethought, refers to the mental state of the accused. That is, did they genuinely intend great harm and/or death upon the victim. Different jurisdictions vary on whether an intent-to-merely-assault that leads to death can be charged with murder, and often times that’s what second-degree murder is used for. Mental state is not a binary quantity either, as different “levels” of mental state correspond to different charges, all else the same. Malice aforethought is the worst sort, corresponding to a killer that plans a victim’s death, or acts with utter disregard for any victim’s life. Lesser levels might be charged as “reckless homicide”, “negligent homicide”, etc.

  Finally, the fourth element for murder is that the victim must actually die. If the victim is immediately dead and this is verifiable using the body, this is easy to prove in court. But if the victim lingers, the legal jurisdiction might adopt a “year and a day” rule, since if the victim doesn’t die quickly, then it’s assault/battery rather than murder. Or if the victim is believed to be dead but it can’t be proven – eg victim’s body never recovered – then the defense might try to argue that the victim is simply missing but alive.

  </ background>

  OK, so to the question. You’ve described a scenario where someone has: 1) affirmatively pressed the kill button, 2) which is believed to result in person X’s death, 3) with full intention to kill person X, but 4) person X does not die. At even a passing glance, this is not murder since person X is alive. But does it meet the first three elements to support attempted murder? Probably not, at least without additional details.

  Element #1 and #3 are present, but it’s element #2 that will be problematic. It isn’t sufficient to just tell someone that “yes, this button will absolutely kill person X”. At the very minimum, the accused needs to at least be aware of the mechanism that person X will be killed, and how that relates to the “kill button”. An implied method-of-death would suffice, such as when ordering a skilled archer to assassinate a rival. Even though the accused just says “go kill him”, the accused is aware that the archer is capable of killing using their bow-and-arrow. Whereas ordering a toddler to kill the rival would be presumed as nonsensical.

  If, however, the button was already demo’d to the accused as killing some other (pretend) victim first – meaning the accused has seen the manner that the “button press” leads to death – that might establish proximate cause, even if it’s not obvious what the cause of death was. If the pretend victim clutches their chest and falls down, it’s plausible to the accused that the button’s mechanism somehow involves a pacemaker malfunction. If instead the accused is told specifically that the bombs on the victim’s car will go off, then that’s a more solid establishment of element #2, although even bombs do not reliably detonate.

  But there’s even more: just because a set of circumstances arguably meets the three elements for attempted murder, it’s ultimately the trier-of-fact that will have to believe it. That is to say, it would be tough to convince a jury that the accused had “absolute” certainty that the button would kill, which also affects element #1. Unless the accused admits to that after-the-fact, that’s tough to prove. What is illegal according to the elements of a crime is not the same as what will easily convince a jury.

  If it seems like this elements – or really all the elements – of murder are fact-intensive, that’s because they are. Killing is as old as humans are, and how it’s been performed and how it’s been regulated/abolished has evolved over history. Modern legal scholars have to figure out how things like stochastic terrorism/killings or life-affecting afflictions (eg HIV/AIDS) should be fitted into the system of written law, because modern law requires writing down the crimes beforehand.

• ⁨Comment⁩ on ⁨Is there any handbooks for warning lights on cars/machinery⁩ ⁨⁨5⁩ ⁨weeks⁩ ago⁩:

  To be clear, this is about exterior mounted warning lights, and not like a caution lamp on a control panel, right?

• ⁨Comment⁩ on ⁨What happened to cylindrical plugs?⁩ ⁨⁨5⁩ ⁨weeks⁩ ago⁩:

  My primary complaint with the F-type connector is that it only does half the job: a proper connector should make a reliable and consistent mechanical and electrical coupling. For the latter, the F-type fails miserably, on account of having no protruding pin of its own: reusing the center conductor as a “pin” is at best slapdash, and at worst fails to account for inconsistent conductor cross-sections.

  When affixing an F-type connector onto a new segment of coax, unless great care has been taken to slice the cable cleanly, the center conductor often ends up with a arrow-shaped tip which also flattens the round cross-section into an oval. This tip is now a minor danger to people, in addition to no longer being assumed as round. This certainly doesn’t help with reliable mating later.

  Furthermore, a solid copper tip is not ideal for a connector, unless the opposite coupler that grasps the tip is made of copper as well. But copper can’t be used to make springy receivers, so inevitably another metal must be used. But the prevailing composition of contacts for connectors are either solid brass or are plated (eg gold). But a sharp copper tip will end up scratching the mating surfaces over time.

  And this is just the start of the F-type’s follies. The user experience of turning a 7/16" fine thread in narrow spaces is exhausting. With no consistent specs for the F-type, some cheaper connectors have the thinnest possible hex head to fit a wrench on. Compression F-type is better, but then we have to compare to other connectors.

  In the broadcast and laboratory spaces, BNC is the go-to connector, with easy mating and quarter-turn engagement. It also comes in 50 and 75 Ohm variants (albeit confusingly). In telecoms, the SMA connector is used for its small size, and larger coax might use the beefy N connector. Some of these variants are even waterproof. Solderless is an option. All these connectors are rated by their manufacturers for a minimum number of mating events.

  In all circumstances, according to this chart, the RF performance of BNC, SMA, and N are superior to F-type, which has only ever been used for TV, CCTV, and certain low-frequency clocking systems. I’m not sure what you mean by “rated to absurd frequencies”, but surely SMA’s (up to) 25 GHz rating would be tremendously and wildly insane by comparison to 1-2 GHz for F-type.

  So that’s my beef. It’s just a bad connector, used only because it’s cheap.