In the past, we did have a need for purpose-built skyscrapers meant to house dense racks of electronic machines, but it wasn’t for data centers. No, it was for telephone equipment. See the AT&T Long Lines building in NYC, a windowless monolith of a structure in Lower Manhattan. It stands at 170 meters (550 ft).

This NYC example shows that it’s entirely possible for telephone equipment to build up, and was very necessary considering the cost of real estate in that city. But if we look at the difference between a telephone exchange and a data center, we quickly realize why the latter can’t practically achieve skyscraper heights.

Data centers consume enormous amounts of electric power, and this produces a near-equivalent amount of heat. The chiller units for a data center are themselves estimated to consume something around a quarter of the site’s power consumption, to dissipate the heat energy of the computing equipment. For a data center that’s a few stories tall, the heat density per land area is enough that a roof-top chiller can cool it. But if the data center grows taller, it has a lower ratio of rooftop to interior volume.

This is not unlike the ratio of surface area to interior volume, which is a limiting factor for how large (or small) animals can be, before they overheat themselves. So even if we could mount chiller units up the sides of a building – which we can’t, because heat from the lower unit would affect an upper unit – we still have this problem of too much heat in a limited land area.

For my own networks, I’ve been using IPv6 subnets for years now, and have NAT64 translation for when they need to access Legacy IP (aka IPv4) resources on the public Internet.

Between your two options, I’m more inclined to recommend the second solution, because although it requires renumbering existing containers to the new subnet, you would still have one subnet for all your containers, but it’s bigger now. Whereas the first solution would either: A) preclude containers on the first bridge from directly talking to containers on the second bridge, or B) you would have to enable some sort of awful NAT44 translation to make the two work together.

So if IPv6 and its massive, essentially-unlimited ULA subnets are not an option, then I’d still go with the second solution, which is a bigger-but-still-singular subnet.

The French certainly benefitted from the earlier Jesuit work, although the French did do their own attempts at “westernizing” parts of the language. I understand that today in Vietnam, the main train station in Hanoi is called “Ga Hà Nội”, where “ga” comes from the French “gare”, meaning train station (eg Gare du Nord in Paris). This kinda makes sense since the French would have been around when railways were introduced in the 19th Century.

Another example is what is referred to in English as the “Gulf of Tonkin incident”, referring to the waters off the coast of north Vietnam. Here, Tonkin comes from the French transliteration of Đông Kinh (東京), which literally means “eastern capital”.

So far as I’m aware, English nor French don’t use the name Tonkin anymore (it’s very colonialism-coded), and modern Vietnamese calls those waters by a different name anyway. There’s also another problem: that name is already in-use by something else, being the Tokyo metropolis in Japan.

In Japanese, Tokyo is written as 東京 (eastern capital) in reference to it being east of the cultural and historical seat of the Japanese Emperor in Kyoto (京都, meaning “capital metropolis”). Although most Vietnamese speakers would just say “Tokyo” to refer to the city in Japan, if someone did say “Đông Kinh”, people are more likely to think of Tokyo (or have no clue) than to think of an old bit of French colonial history. These sorts of homophones exist between the CJKV languages all the time.

And as a fun fact, if Tokyo is the most well-known “eastern capital” when considering the characters in the CJKV language s, we also have the northern capital (北京, Beijing, or formerly “Peking”) and the southern capital (南京, Nanjing). There is no real consensus on where the “western capital” is.

Vietnamese speakers will in-fact say Bắc Kinh when referring to the Chinese capital city rather than “Beijing”, and I’m not totally sure why it’s an exception like that. Then again, some newspapers will also print the capital city of the USA as Hoa Thịnh Đốn (華盛頓) rather than “Washington, DC”, because that’s how the Chinese wrote it down first, and then brought to Vietnamese, and then changed to the modern script. To be abundantly clear, it shouldn’t be surprising to have a progression from something like “Wa-shing-ton” to "hua-shen-dun’ to “hoa-thinh-don”.

As a case study, I think Vietnamese is especially apt to show how the written language develops in parallel and sometimes at odds with the spoken language. The current alphabetical script of Vietnamese was only adopted for general use in the late 19th Century, in order to improve literacy. Before that, the grand majority of Vietnamese written works were in a logographic system based on Chinese characters, but with extra Vietnamese-specific characters that conveyed how the Vietnamese would pronounce those words.

The result was that Vietnamese scholars pre-20th Century basically had to learn most of the Chinese characters and their Cantonese pronunciations (not Mandarin, since that’s the dialect that’s geographically father away), and then memorize how they are supposed to be read in Vietnamese, then compounded by characters that sort-of convey hints about the pronunciation. This is akin to writing a whole English essay using Japanese katakana; try writing “ornithology” like that.

Also, the modern Vietnamese script is a work of Portuguese Jesuit scholars, who were interested in rendering the Vietnamese language into a more familiar script that could be read phonetically, so that words are pronounced letter-by-letter. That process, however faithful they could manage it, necessarily obliterates some nuance that a logographic language can convey. For example, the word bầu can mean either a gourd or to be pregnant. But in the old script, no one would confuse 匏 (gourd) with 保 (to protect; pregnant) in the written form, even though the spoken form requires context to distinguish the two.

Some Vietnamese words were also imported into the language from elsewhere, having not previously existed in spoken Vietnamese. So the pronunciation would hew closer to the origin pronunciation, and then to preserve the lineage of where the pronunciation came from, the written word might also be written slightly different. For example, nhôm (meaning aluminum) draws from the last syllable of how the French pronounce aluminum. Loanwords – and there are many in Vietnamese, going back centuries – will mess up the writing system too.

I’m not a computer engineer, but I did write this comment for a question on computer architecture. At the very onset, we should clarify that RAM capacity (# of GBs) and clock rate (aka frequency; eg 3200 MHz) are two entirely different quantities, and generally can not be used to compensate for the other. It is akin to trying to halve an automobile’s fuel tank in order to double the top-speed of the car.

Since your question is about performance, we have to look at both the technical impacts to the system (primarily from reduced clock rate) and then also the perceptual changes (due to having more RAM capacity). Only by considering both together can be arrive as some sort of coherent answer.

You’ve described your current PC as having an 8 GB stick of DDR4 3200 MHz. This means that the memory controller in your CPU (pre-DDR4 era CPUs would have put the memory controller on the motherboard) is driving the RAM at 3200 MHz. A single clock cycle is a square wave that goes up and then goes down. DDR stands for “Double Data Rate”, and means that a group of bits (called a transaction) are sent on both the up and the down of that single clock cycle. So 3200 MHz means the memory is capable of moving 6400 million transactions per second (6400 MT/s). For this reason, 3200 MHz DDR4 is also advertised as DDR4-6400.

Some background about DDR versus other RAM types, when used in PCs: the DDR DIMMs (aka sticks) are typically made of 8 visually-distinct chips on each side of the DIMM, although some ECC-capable DIMMs will have 9 chips. These are the small black boxes that you can see, but they might be underneath the DIMM’s heatsink, if it has one. The total capacity of these sixteen chips on your existing stick is 8 GB, so each chip should be 512 MB. A rudimentary way to store data would be for the first 512 MB to be stored in the first chip, then the next 512 MB in the second chips, and so on. But DDR DIMMs do a clever trick to increase performance: the data is “striped” across all 8 or 16 chips. That is, to retrieve a single Byte (8 bits), the eight chips on one face of the DIMM are instructed to return their stored bit simultaneously, and the memory controller composes these into a single Byte to send to the CPU. This all happens in the time of a single transaction.

We can actually do that on both sides of the DIMM, so two Bytes could be retrieved at once. This is known as dual-rank memory. But why should each chip only return a single bit? What if each chip could return 4 bits at a time? If all sixteen chips support this 4-bit quantity (known as memory banks), we would get 64 bits (8 Bytes), still in the same time as a single transaction. Compare to earlier where we didn’t stripe the bits across all sixteen chips: it would have taken 16 times longer for one chip to return what 16 chips can return in parallel. Free performance!

But why am I mentioning these engineering details, which has already been built into the DIMM you already have? The reason is that it’s the necessary background to explain the next DDR hat-trick for memory performance: multi-channel memory. The most common is dual channel memory, and I’ll let this “DDR4 for Dummies” quote explain:

A memory channel refers to DIMM slots tied to the same wires on the CPU. Multiple memory channels allow for faster operation, theoretically allowing memory operations to be up to four times as fast. Dual channel architecture with 64-bit systems provides a 128-bit data path. Memory is installed in banks, and you have to follow a couple of rules to optimize performance.

Basically, dual-channel is kinda like having two memory controllers for the CPU, each driving half of the DDR in the system. On an example system with two 1 GB sticks of RAM, we could have each channel driving a single stick. A rudimentary use would be if the first 1 GB of RAM came from channel 1, and then the second 1 GB came from channel 2. But from what we saw earlier with dual-rank memory, this is leaving performance on the table. Instead, we should stripe/interlace memory accesses across both channels, so that each stick of RAM returns 8 Bytes, for a total of 16 Bytes in the time of a single transaction.

So now let’s answer the technical aspect of you question. If your system supports dual-channel memory, and you install that second DIMM into the correct slot to make use of that feature, then in theory, memory accesses should double in capacity, because of striping the access across two independent channels. The downside is that for that whole striping thing to work, all channels must be running at the same speed, or else one channel would return data too late. Since you have an existing 3200 MHz stick but the new stick would be 2400 MHz, the only thing the memory controller can do is to run the existing stick at the lower speed of 2400 MHz. Rough math says that the existing stick is now operating at only 75% of its performance, but from the doubling of capacity, that might lead to 150% of performance. So still a net gain, but less than ideal.

The perceptual impact has to do with how a machine might behave now that it has 16 GB of memory, having increased from 8 GB. If you were only doing word processing, your existing 8 GB might not have been fully utilized, with the OS basically holding onto it. But if instead you had 50 browser tabs open, then your 8 GB of RAM might have been entirely utilized, with the OS having to shuffle memory onto your hard drive or SSD. This is because those unused tabs still consume memory, despite not actively in front of you. In some very extreme cases, this “thrashing” causes the system to slow to a crawl, because the shuffling effort is taking up most of the RAM’s bandwidth. If increasing from 8 GB to 16 GB would prevent thrashing, then the computer would overall feel faster than before, and that’s on top of the theoretical 50% performance gain from earlier.

Overall, it’s not ideal to mix DDR speeds, but if the memory controller can drive all DIMMs at the highest common clock speed and with multi-channel memory, then you should still get a modest boost in technical performance, and possibly a boost in perceived performance. But I would strongly recommend matched-speed DDR, if you can.

Overall, it looks like you’re done your homework, covering the major concerns. What I would add is that keeping an RPi cool is a consideration, since without even a tiny heatsink, the main chip gets awfully hot. Active cooling with a fan should be considered to prevent thermal throttling.

The same can apply to a laptop, since the intended use-case is with the monitor open and with the machine perched upon a flat and level surface. But they already have automatic thermal control, so the need for supplemental cooling is not very big.

Also, it looks like you’ve already considered an OS. But for other people’s reference, an old x86 laptop (hopefully newer than i686) has a huge realm of potential OS’s, including all the major *BSD distros. Whereas I think only Ubuntu, Debian, and Raspbian are the major OS’s targeting the RPi.

One last thing in favor of choosing laptop: using what you have on hand is good economics and reduces premature ewaste, as well as formenting the can-do attitude that’s common to self hosting (see: [email protected]).

TL;DR: not insane. Don’t forget IPv6 support.

At the very minimum, gym in the morning (but after coffee/caffeine, plus the time for it to kick in) is the enlightened way. It helps if your gym is nearby or you have a [email protected] .

I personally also use the wee morning hours to reconcile my financial accounts, since ACH transactions in the USA will generally process a day faster if submitted before 10:30 ET.

The photos taken by the sorting machines are of the outside of the envelope, and are necessary in order to perform OCR of the destination address and to verify postage. There is no general mechanism to photograph the contents of mailpieces, and given how enormous the operations of the postal service is, casting a wide surveillance net to capture the contents of mailpieces is simply impractical before someone eventually spilled the beans.

That said, what you describe is a method of investigation known as mail cover, where the useful info from the outside of a recipient’s mail can be useful. For example, getting lots of mail from a huge number domestic addresses in plain envelopes, the sort that victims of remittance fraud would have on hand, could be a sign that the recipient is laundering fraudulent money. Alternatively, sometimes the envelope used by the sender is so thin that the outside photo accidentally reveals the contents. This is no different than holding up an envelope to the sunlight and looking through it. Obvious data is obvious to observe.

In electronic surveillance (a la NSA), looking at just the outside of an envelope is akin to recording only the metadata of an encrypted messaging app. No, you can’t read the messages, but seeing that someone received a 20 MB message could indicate a video, whereas 2 KB might just be one message in a rapid convo.

So no, no billion dollar company can make their own training data

This statement brought along with it the terrifying thought that there’s a dystopian alternative timeline where companies do make their own training data, by commissioning untold numbers of scientists, engineers, artists, researchers, and other specialties to undertake work that no one else has. But rather than trying to further the sum of human knowledge, or even directly commercializing the fruits of that research, that it’s all just fodder to throw into the LLM training set. A world where knowledge is not only gatekept like Elsevier but it isn’t even accessible by humans: only the LLM will get to read it and digest it for human consumption.

Written by humans, read by AI, spoonfed to humans. My god, what an awful world that would be.

A few factors:

• Human population centers historically were built by natural waterways and/or by the sea, to enable access to trade, seafood, and obviously, water for drinking and agriculture
• When the fastest mode of land transport is a horse (ie no railways or automobiles), the long-distance roads between nations which existed up to the 1700s were generally unimproved and dangerous, both from the risk of breakdown but also highway robbery. Short-distance roads made for excellent invasion routes for an army, and so those tended to fall under control of the same nation.
• Water transport was (and still is) capable of moving large quantities of tonnage, and so was the predominant form of trade, only seeing competition when land transport improved and air transport was introduced.

So going back centuries when all the “local” roads are still within the same country (due to conquest), and all the long-distance roads were treacherous, slow, and usually uncomfortable (ie dysentery on the Oregon Trail), the most obvious way to get to another country would have been to get a ride on a trading ship. An island nation would certainly regard all other countries as being “overseas”, but so would an insular nation hemmed in by mountains but sitting directly on the sea. When land transport is limited, sea routes are the next best. And whereas roads only connect places situated along the route, the sea (and the sky) allow point-to-point trading, exposing faraway countries to each other when their ships arrive at the port.

TL;DR: for most of human history, other countries were most reasonably reached by sea. Hence “overseas”.

Truly, it could be anything that unsettles the market. A bubble popping is essentially a cascading failure, where the dominos fall, when the house of cards collapses, when fear turns into panic, even when everyone is of sound mind.

The Great Depression is said to have started because of a colossally bad “short squeeze”, where investors tried to corner the market on copper futures, I think. That caused some investment firms to go broke, which then meant trust overall was shaken. And then things spiraled out of control thereafter, irrespective of whether the underlying industries were impacted or not.

So too did the Great Financial Crisis in 2008, where the USA housing market collapsed, and the extra leverage that mortgagees had against their home value worked against them, plunging both individuals and mortgage companies into financial ruin. In that situation, the fact that some people lost their homes, coupled with them losing their jobs due to receding market, was an unvirtuous cycle that fed itself.

I can’t speculate as to what will pop the current bubble, but more likely than not, it will be as equally messy as bubbles of yore. But much like the Big One – which here in California refers to another devastating earthquake to come – it’s not a question of if but when.

Until it (and the AI bubble popping) happens though, it is not within my power to do much about it, and so I’ll spend my time preparing. That doesn’t mean I’m off to move my retirement funds into S&P500 ex-AI though, since even the Dot Com bubble produced gains before it went belly up. I must reiterate that no one knows when the bubble will pop, so getting on or getting off now is a financial risk.

Preparation means to build resilience, to decouple my home from my job, to keep my family and community safe even when the shaking starts. For some, this means stocking food and water. For others, it means building mutual aid networks. And for some still, it means downsizing and making their lives more financially sustainable, before the choice is made for them.

This is a rollercoaster and we’re all strapped in, whether we like it or not.

All I can offer you are notable rail vs road innovations in the 18th Century, North American electricity supplies, and bicycle wheel construction.

I’ll take a stab at the question, but we will need to dive into a small amount of computer engineering to explain. To start, I am going to assume an x86_64 platform, because while ARM64 and other platforms do support hardware-virtualization, x86_64 is the most popular and most relevant since its introduction at the beginning of the 2000s. My next assumption is that we are using non-ancient hardware, for reasons that will become clear.

As a base concept, a virtual machine means that we have a guest OS that runs subordinate to a host OS on the same piece of hardware. The host OS essentially treats the guest OS as though it is just another userspace process, and gives the guest some time on the CPU, however the host sees fit. The guest OS, meanwhile, is itself a full-blown OS that manages its own userspace processes, divying out whatever CPU time and memory that it can get from the host OS, and this is essentially identical to how it would behave if the guest OS were running on hardware.

The most rudimentary form of virtual machine isolation was achieved back in the 1960s, with software-based virtual machines. This meant that the host emulated every single instruction that the guest OS would issue, recreating every side-effect and memory access that the guest wanted. In this way, the guest OS could run without change, and could even have been written in an entirely different CPU architecture. The IBM System/360 family of mainframes could do this, as a way of ensuring business customers that their old software could still run on new hardware.

The drawbacks are that the performance is generally less-than-stellar, but in an era that valued program correctness, this worked rather well. Also, the idea would carry into higher level languages, most notably the Java Virtual Machine (JVM). The Java language generally compiles down to bytecode suitable to run on the JVM (which doesn’t really exist), and then real machines would essentially run a JVM emulator to actually call the program. In this way, Java is a high-level language that can run anywhere, if provided a JVM implementation.

An advancement from software virtualization is hardware-assisted virtualization, where some amount of the emulation task is offloaded to the machine itself. This is most relevant when virtualizing the same CPU architecture, such as an x86_64 guest on an x86_64 host. The idea is that lots of instructions have no side-effects that affect the host, and so can be run natively on the CPU, then return control back to the host when reaching an instruction that has side-effects. For example, the basic arithmetic operation of adding two registers imposes no risks to the stability of the machine.

To do hardware-assisted virtualizaton requires that the hardware can intercept (or traps) such instructions as they appear, since the nature of branch statements or conditionals means that we can’t detect in-advance whether the guest OS will issue those instructions or not. The CPU will merrily execute all the “safe” instructions within the scope of the guest, but the moment that it sees an “unsafe” instruction, it must stop and kick back control to the host OS, which can then deal with that instruction in the original, emulated fashion.

The benefit is that the guest OS remains unmodified (yay for program correctness!) while getting a substantial speed boost compared to emulation. The drawback is that we need the hardware to help us. Fortunately, Intel and AMD rose to the challenge once x86-on-x86 software virtualization started to show its worth after the early 2000s, when VMWare et al demonstrated that the concept was feasible on x86. Intel VT-x and AMD-V are the hardware helpers, introducing a new set of instructions that the host can issue, which will cause the CPU to start executing guest OS instructions until trapping and returning control back to the host.

I will pause to note why same-on-same CPU architecture virtualization is even desirable, since compared to the emulation-oriented history, this might not seem immediately useful. Essentially, software-based virtualization achieved two goals, the latter which would become extremely relevant only decades later: 1) allow running a nested “machine”, and 2) isolate the nested machine from the parent machine. When emulation was a given, then isolation was practically assured. But for same-on-same virtualization, the benefit of isolation is all that remains. And that proved commercially viable when silicon hit a roadblock at ~4 GHz, and we were unable to make practical single-core CPUs go any faster.

That meant that growing compute would come in the form of multiple cores per CPU chip, and this overlapped with a problem in the server market where having a separate server for your web server, and database server, and proxy server, all of these cost money. But seeing as new CPUs have multiple cores, it would save a bunch of money to consolidate these disparate servers into the same physical machine, so long as they could be assured that they were still logically running independently. That is to say, if only they were isolated.

Lo and behold, Intel VT-X and AMD-V were introduced just as core counts were scaling up in the 2010s. And this worked decently well, since hardware-assisted virtualization was a fair order of magnitude faster than trying to emulate x86, which we could have done but it was just too slow for commercialization.

Some problems quickly emerged, due to the limitations of the hardware assistance. The first has to do with how the guest OS expects to operate, and the second to do with how memory in general is accessed in a performant manner. The fix for these problems involves more hardware assistance features, but also relaxing the requirement that the guest OS remain unchanged. When the guest OS is modified to be better virtualized, this is known as paravirtualization.

All modern multi-tasking OS with non-trivial amounts of memory (which would include all guest OS’s that we care about) does not organize its accessible memory as though it were a "flat’ plane of memory. Rather, memory is typically “paged” – meaning that it’s divvied out in pre-ordained chunks, such as 4096 Bytes – and frequently also makes use of “virtual memory”. Unfortunately, this is a clash in nomenclature, since “virtual memory” long predates virtualization. But understand that “virtual memory” means that userspace programs won’t see physical addresses for its pointers, but rather a fictional address which is cleverly mapped back to physical addresses.

When combining virtual memory with pages, the OS is able to give userspace programs the appearance of near-unlimited, contiguous memory, even though the physical memory behind those virtual addresses are scattered all over the place. This is a defining feature of an OS: to organize and present memory sensibly.

The problem for virtualization is that if the host OS is already doing virtual+paged memory management, then it forces the guest OS to live within the host’s virtual+paged environment, all while the guest OS also wants to do its own virtual+paged memory management to service its own processes. While the host OS can rely upon the physical MMU to efficiently implement virtual+paged memory management, the guest OS cannot. And so the guest OS is always slowed down by the host having to emulate this job.

The second issue relates to caching, and how a CPU can accelerate memory accesses if it can fetch larger chunks of memory than what the program might be currently accessing, in anticipation. This works remarkably well, but only if the program has some sense of locality. That is, if the program isn’t reading randomly from the memory. But from the hardware’s perspective, it sees both the host OS and guest OS and all their processes, which starts to approximate a Gaussian distribution when they’re all running in tandem, and that deeply impacts caching performance.

The hardware solution is to introduce an MMU that is amenable to virtualization, one which can manage both the host OS’s paged+virtual memory as well as any guest OS’s paged+virtual memory. Generally, this is known as Second Level Address Translation (SLAT) and is implemented as AMD’s Rrapid Virtualizaion Indexing or Intel’s Extended Page Tables. This feature allows the MMU to consider page tables – the basic unit of any MMU – that nest below a superior page table. In this way, the host OS can delegate to the guest a range of pages, and the guest OS can manage those pages, all while the MMU gives the guest OS some acceleration because this is all done in hardware.

This also helps with the caching situation, since if the MMU is aware that the memory is in a nested page table (ie guest OS memory), then that likely also means the existing cache for the host is irrelevant, and vice-versa. An optimization would be to split the cache space, so that it remains relevant only to the host or to the guest, without mixing up the two.

With all that said, we can now answer your question about what would happen .With hardware extensions like VT-x and SLAT, I would expect that cascading VMs would consume CPU and memory resources almost linearly, due to each guest OS adding its own overhead and running its own kernel. At some point, the memory performance would slow to a crawl, since there’s a limit on how much the physical cache can be split. But the CPU performance would likely be just fine, such as if you ran a calculation for digits of Pi on the 50th inner VM. Such calculations tend to use CPU registers rather than memory from DDR, and so could run natively on the CPU without trapping to any of the guests.

But I like the other commenter’s idea of just trying it and see what happens.

What if the ability to communicate freely with other drivers made the experience closer to walking in a crowd.

In a dense crowd, the information being exchanged amongst the crowd is enormous. It is a constant negotiation, of different parties trying to get somewhere but also trying (hopefully) to respect other people’s space. And the stakes are lower, because bumping into someone is fine at 1 kph but totally unacceptable at 50 kph. And humans are dynamically adjustable, like raising ones arms so that a stroller can pass more easily. Cars can’t really do that (except Transformers: Robots In Disguise).

In a crowded bazaar, the bandwidth from reading people’s facial cues, from seeing whether they’re distracted by goods on display or from their Instagram posts, plus what people actually say – and what they don’t say – and how quickly or slowly they walk. All of that is context that is necessary to participate in the activity of passing through the crowd, and I think that cost-optimized technology to exchange the same amount of info while also needing to react 50x faster and deterministically, with safety standards suitable for 2-tonne machines that already kill and maim thousands per year, that’s not really feasible.

Exactly this. I’ve long had a thought that if all automobiles were like the Invisible Boatmobile from SpongeBob, then most of the suble cues between humans would make it easier to understand intentions, with corresponding reduction in misapprehension and collisions.

That said, humans simply are poorly adapted to traveling at 100 kph, so who’s to say if these cues are even understandable at high speed. And of course, it’s downright impossible to see those details when blinded by mutual headlights on a rural highway at night.

As a thought experiment, I’m prepared to momentarily set aside the practical and societal issues to see whether a mechanism for motorists to communicate to any other nearby motorists would have a use.

To set some ground rules, I think it’s fair to assert that such a communication mechanism is not meant for lollygagging, but would be used for some sort of operational reason that is related to driving a motor vehicle. So the use-cases would be broader than just safety or traffic management, and could include coordination between drivers all heading to the same place. This criteria means we won’t require the generality of a mobile phone network (which can call anyone) and instead is very local.

Some examples that might use this mechanism:

1. Broadcasting a safety hazard to motorists further behind, such as objects in the road or right after a sharp curve
2. Telling a specific car that their trailer has lost a strap, that it is flailing in the wind, and it might get caught under the rear wheels
3. Informing all cars in the camping group platoon that you’ll be stopping at Micky-D’s for a bathroom break, and they should keep going
4. For two cars that already drove over some sharp road debris, they can look at each other’s cars to relay any observable damage, to decide whether to stop on the shoulderless highway or keep driving to an exit

This selection of examples represent exigent circumstances that arise while driving, rather than something which could have been planned/coordinated in advance. More over, they cover scenarios that are one-to-many or one-to-one, as well as unilateral messages or bilateral conversations.

We need to also consider what existing cues already exist between motorists, some of which are quite dated:

• Honking (so that someone else will do something that fixes the situation)
• Waving through (to indicate that you are yielding and they can proceed)
• Turning an invisible crank (asking them to roll down their window, despite manual windows being very uncommon now in the USA)
• High-beam flashing (to request they change lanes so that you can pass them; or at an intersection, that you’re yielding and they can proceed)
• Stopping and opening the hood (the time-tested signal that your car has malfunctioned and you need assistance)
• Turning on hazard lights (you have unexpectedly stopped somewhere and cannot move; or you are traveling very slowly; or otherwise, some unspecified hazard exists and you need space to manoeuvre and everyone should be on-alert)
• Left/right indicators (you are going to turn or change lanes; if a parking space, you are claiming that parking space)

Before we even check if these existing cues can be used for the examples above, we can see there are already a fair amount of them. The problem with cues, though, is that they might not be universally understood (eg a motorist from flat Nebraska might not understand the hazard lights on a slow-going truck climbing up Tejon Pass heading in/out of Los Angeles). Moreso, some cues are downright dangerous in certain circumstances, such as waving a motorist into an intersection but neither could see the oncoming fire truck that strikes them.

Notice that for all these cues, only fairly simply messages can be conveyed, and for anything more complicated, it is necessary to “turn the invisible crank”, meaning that you and them need to roll down your windows and talk directly about what the complex situation is. So if a situation is simple, then it’s likely one of the existing cues will work. But if not, then maybe our new car-to-car system might turn out to be useful. Let’s find out.

Scenario 1 is partially addressed by one very long honk or using hazard lights, depending on if the hazard is avoidable or if the hazard requires all traffic to halt. If it is about a small object in the road, then perhaps no message is needed at all, since we assume all motorists are paying attention to the road. If the hazard is a hidden one – such as behind a curve or it’s black-ice – then only hazard lights would help, but it might not be clear to following motorists what the issue is. They would only know to remain alert.

A broadcast system could be effective, but only to a point: motorists cannot spend more than a sentence or maybe even a few words to understand some situation that may only be seconds away. We know this from how roadway signs are written: terse and unambiguous. So if a broadcast system did exist for hazards, then it must be something which can be described in fewer than maybe 5 words. This means the system isn’t useful for info about which parking lots at LAX have room, for example.

Scenario 2 involves a hazard that is moving, and can be addressed by honking and high-beams to get the motorist’s attention. There is no ability to convey the precise nature of the hazard, but outside of nighttime environments where people may be hesitant to stop just because someone is trying to tell them something on a rural Interstate, this generally is enough to prevent a roadway calamity.

But supposing we did want to use our new system to send that motorist a message, the same concern from earlier must be respected: it is improper to flood a motorist with too much info when the driving task doesn’t really allow for much time to do anything else. An apt comparison would be to air transport pilots, where a jetliner at cruising altitude actually does have a lot of spare time, but not when preparing for takeoff or landing. Driving an automobile is a continual task, and for the time when a car is stopped at a traffic light, then there is virtually no need for a car-to-car communication system; just yell. The need for ACARS for automobiles [pun intended] is looking less useful, so far.

Scenario 3 is similar to Scenario 2, but is a one-to-many message. But given how such exchanges tend to also become multilateral (“can you get me a Big Mac as well?” and “well, we don’t have to be at the camp site until 4:20”), this once again starts to become a distraction from the driving task.

Scenario 4 is probably the most unique, because it rarely happens: motorists always have the option of stopping, although stopping can itself create a hazard if the location is not great (eg left lane on an American freeway). It would be truly unusual for two cars to have struck something AND then need to quickly decide if they can press on toward the nearest exit (eg minor body damage) or if they must stop immediately (eg a fuel rupture that starts a small fire beneath the vehicle) AND there is someone else who can mutually exchange info about the damage.

It’s such a contrived scenario, because I actually made it up, based on the similar situation that occurs for aircraft that suffer damage while in the air. In such situations, the pilot would need external support, which can come from a nearby aircraft, or ATC, or an escort fighter jet. For example, if an aircraft cannot confirm safe extension of the landing gear, diagnosing the problem is helped by a nearby news helicopter confirming that the landing gear is clearly visible and locked.

Alternatively, if a departing aircraft has struck a piece of metal dropped by an earlier Continental Airlines DC-10, and that bit of metal causes the left tire to explode, further causing a fuel rupture from the left tank and an uncontrollable fire slowly destroying the wing, it would be very useful if ATC can tell the pilots ASAP before the aircraft is going too fast to abort the takeoff, resulting in an inability to remain fly and an eventual crash into a hotel.

I bring up my contrived automobile Scenario 4 because it shows how things could always be slightly different if a small factor was simply changed, if maybe there were better warnings to the pilots from their aircraft, or if the Continental plane was better maintained, or if Charles de Gaulle ATC was just a little bit faster to radio to the pilots. So it’s perfectly natural to think that by having this one aspect of the driving experience changed, maybe there’s a lot of value we could get from it. Indeed, the Swiss Cheese Model of accident causation tells us that any one layer could have been different and thus stop the holes from lining up.

But from this thought experiment, we can see that the existing cues between motorists already serve the most common reasons for needing to communicate while on the road. And anything more complicated messages than “I would like to pass” become a distraction and thus less useful and more dangerous in practice. Aviation knows full-well the dangers of introducing a fix which ends up causing more problems in the long-run.

Overstating the tax and then being charged less, that’s going to be less jarring to consumers than the opposite situation, where people are charged more than what it says on the can haha. They emboss cans with the worst-case tax rate because the tops are produced separately from the body of the can, so they genuinely don’t know what size of can it will be part of.

But I get it: taxes are hard, since even the supposed simplicity of a “flat tax” rate still requires exemptions and exceptions everywhere. Otherwise, people will get away with paying less tax than they ought, or more tax than is reasonably fair, or that the purpose of the tax is wholly defeated.

Taxation systems: simple to administer, easy to understand, fair. Pick at most two. Anyone who says they’ve come up with a system that achieves all three perfectly is a liar or doesn’t understand how taxes work.

Some background: retailers in California that sell taxable goods have the choice of either including sales tax in their posted prices (“tax incl”) or not (“+tax”). Whichever they choose, they must disclose which method they use and must be consistent. Retailers of tax-free goods obviously don’t need to make this choice. Vending machines invariably always include the sales tax (and CRV if packaged beverage) to make the price a round number.

non-prepared food items no longer have sales tax

This is mostly correct, since the sales tax on food is generally on hot food that is otherwise unprepared. If any other preparation occurs (like with a sandwich from a sandwich shop), then that added preparation makes the whole sandwich taxable, even though the individual food ingredients would have been tax-exempt.

The only taxes I know I would be paying for a canned soda would be the CRV/California Redemption Tax, which is a flat $0.10 per aluminum can.

Minor quibble: CRV is California Redemption Value and is a refundable fee. The tiny distinction from a tax is that fees are potentially refundable (and this is, upon recycling the container) whereas a tax is virtually never refunded in any scenario. That said, the California Constitution specifies that taxes and fees have the same requirements when it comes to approving them, since the payment of a tax or fee is mandatory. But I digress.

Anyway, the rates that you described is not correct. The current rates are:

5 cents for containers less than 24 ounces

10 cents for containers 24 ounces or larger

And only applies to aluminum, glass, plastic, and bi-metal.

So on a can of NOS (16 fl oz) pays just 5 cents, but a 24 fl oz can will pay 10 cents. I’m not sure which size can you were looking at, but I’m going to guess it was a 16 fl oz can.

If 16 fl oz priced at $1.98, then add 5 cents CRV, that’s $2.03. The California Department of Tax and Fee Administration (CDTFA) writes that:

Sales of noncarbonated drinks are generally not taxable, but their containers may be subject to the CRV. On the other hand, sales of carbonated and alcoholic beverages are generally taxable, and the CRV fee that is charged for their containers is taxable

And:

Under SNAP, we consider items purchased with CalFresh benefits as sales to the United States government, and those items are therefore exempt from tax in California.

And:

Sales of eligible food items purchased with CalFresh benefits are exempt from tax, even if the sale of the food item is normally taxable. For example, the sales of carbonated beverages, ice, and food coloring are exempt from tax when purchased with CalFresh benefit

So if you’re somewhere within, say, San Luis Obispo city where the sales tax rate is 8.75%, then that brings the $2.03 up to $2.21 if bought without CalFresh, since both sales tax and CRV apply, and CRV is itself taxable. But on CalFresh, neither sales tax nor CRV apply, so the total would just be $1.98.

This all appears to align with your observations.

For a link of 5.5 km and with clear LoS, I would reach for 802.11 WiFi, since the range of 802.11ah HaLow wouldn’t necessarily be needed. For reference, many WISPs use Ubiquiti 5 GHz point-to-point APs for their backhaul links for much further distances.

The question would be what your RF link conditions look like, whether 5 GHz is clear in your environment, and what sort of worst-case bandwidth you can accept. With a clear Fresnel zone, you could probably be pushing something like 50 Mbps symmetrical, if properly aimed and configured.

Ubiquiti’s website has a neat tool for roughly calculating terrain and RF losses.

I don’t have an answer for your woes, but MTU issues are notoriously difficult to investigate and mitigate, as Cloudflare found out: https://blog.cloudflare.com/increasing-ipv6-mtu/