I’ve seen the suggestion of buying a GUA subnet, purely to use as a routable-but-unique prefix that will never collide, and will always win over ULA or Legacy IP routes. When I last checked, it was something like €1 for a /48 off of someone’s /32 prefix, complete with a letter of authorization and reverse IP delegation. So it could be routable, if one so chooses.

https://ipv6now.com.au/primers/IPv6Reasons.php

Basically, Legacy IP (v4) is a dead end. Under the original allocation scheme, it should have ran out in the early 1990s. But the Internet explosion meant TCP/IP(v4) was locked in, and so NAT was introduced to stave off address exhaustion. But that caused huge problems to this day, like mismanagement of firewalls and the need to do port-forwarding. It also broke end-to-end connectivity, which requires additional workarounds like STUN/TURN that continue to plague gamers and video conferencing software.

And because of that scarcity, it’s become a land grab where rich companies and countries hoard the limited addresses in circulation, creating haves (North America, Europe) and have-nots (Africa, China, India).

The want for v6 is technical, moral, and even economical: one cannot escape Big Tech or American hegemony while still having to buy IPv4 space on the open market. Czechia and Vietnam are case studies in pushing for all-IPv6, to bolster their domestic technological familiarity and to escape the broad problems with Business As Usual.

Accordingly, there are now three classes of Internet users: v4-only, dual-v4-and-v6, and v6-only. Surprisingly, v6-only is very common now on mobile networks for countries that never had many v4 addresses. And it’s an interop requirement for all Apple apps to function correctly in a v6-only environment. At a minimum, everyone should have access to dual-stack IP networks, so they can reach services that might be v4-only or v6-only.

In due course, the unstoppable march of time will leave v4-only users in the past.

You might also try asking on !ipv6@lemmy.world .

Be advised that even if a VPN offers IPv6, they may not necessarily offer it sensibly. For example, some might only give you a single address (aka a routed /128). That might work for basic web fetching but it’s wholly inadequate if you wanted the VPN to also give addresses to any VMs, or if you want each outbound connection to use a unique IP. And that’s a fair ask, because a normal v6 network can usually do that, even though a typical Legacy IP network can’t.

Some VPNs will offer you a /64 subnet, but their software might not check if your SLAAC-assigned address is leaking your physical MAC address. Your OS should have privacy-extensions enabled to prevent this, but good VPN software should explicitly check for that. Not all software does.

Connection tracking might not be totally necessary for a reverse proxy mode, but it’s worth discussing what happens if connection tracking is disabled or if the known-connections table runs out of room. For a well-behaved protocol like HTTP(S) that has a fixed inbound port (eg 80 or 443) and uses TCP, tracking a connection means being aware of the TCP connection state, which the destination OS already has to do. But since a reverse proxy terminates a TCP connection, then the effort for connection tracking is minimal.

For a poorly-behaved protocol like FTP – which receives initial packets in a fixed inbound port but then spawns a separate port for outbound packers – the effort of connection tracking means setting up the firewall to allow ongoing (ie established) traffic to pass in.

But these are the happy cases. In the event of a network issue that affects an HTTP payload sent from your reverse proxy toward the requesting client, a mid-way router will send back to your machine an ICMP packet describing the problem. If your firewall is not configured to let all ICMP packets through, then the only way in would be if conntrack looks up the connection details from its table and allows the ICMP packet in, as “related” traffic. This is not dissimilar to the FTP case above, but rather than a different port number, it’s an entirely different protocol.

And then there’s UDP tracking, which is relevant to QUIC. For hosting a service, UDP is connectionless and so for any inbound packet we received on port XYZ, conntrack will permit an outbound packet on port XYZ. But that’s redundant since we presumably had to explicitly allow inbound port XYZ to expose the service. But in the opposite case, where we want to access UDP resources on the network, then an outbound packet to port ABC means conntrack will keep an entry to permit an inbound packet on port ABC. If you are doing lots of DNS lookups (typically using UDP), then that alone could swamp the con track table: https://kb.isc.org/docs/aa-01183

It may behoove you to first look at what’s filling conntrack’s table, before looking to disable it outright. It may be possible to specifically skip connection tracking for anything already explicitly permitted through the firewall (eg 80/443). Or if the issue is due to numerous DNS resolution requests from trying to look up spam sources IPs, then perhaps either the logs should not do a synchronous DNS lookup, or you can also skip connection tracking for DNS.

https://github.com/Overv/vramfs

Oh, it’s a user space (FUSE) driver. I was rather hoping it was an out-of-tree Linux kernel driver, since using FUSE will: 1) always pass back to userspace, which costs performance, and 2) destroys any possibility of DMA-enabled memory operations (DPDK is a possible exception). I suppose if the only objective was to store files in VRAM, this does technically meet that, but it’s leaving quite a lot on the table, IMO.

If this were a kernel module, the filesystem performance would presumably improve, limited by how the VRAM is exposed by OpenCL (ie very fast if it’s just all mapped into PCIe). And if it was basically offering VRAM as PCIe memory, then this potentially means the VRAM can be used for certain RAM niche cases, like hugepages: some applications need large quantities of memory, plus a guarantee that it won’t be evicted from RAM, and whose physical addresses can be resolved from userspace (eg DPDK, high-performance compute). If such a driver could offer special hugepages which are backed by VRAM, then those application could benefit.

And at that point, on systems where the PCIe address space is unified with the system address space (eg x86), then it’s entirely plausible to use VRAM as if it were hot-insertable memory, because both RAM and VRAM would occupy known regions within the system memory address space, and the existing MMU would control which processes can access what parts of PCIe-mapped-VRAM.

Is it worth re-engineering the Linux kernel memory subsystem to support RAM over PCIe? Uh, who knows. Though I’ve always like the thought of DDR on PCIe cards. All technologies are doomed to reinvent PCIe, I think, said someone from Level1Techs.

Ok, I have to know: how is this done, and what do people use it for?

It might not be used frequently, but perhaps “incomprehension”?

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’ve used Ally in the past and it was perfectly fine. But now I keep accounts at American Express online bank. It’s mostly out of inertia, since it was convenient to have my credit cards and savings on the same dashboard, and the rates also fairly closely track Ally’s. It has been 7 years since I’ve changed savings accounts, so I’m less about chasing rates and more concerned about having a consistent financial process.

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: !selfhosted@lemmy.world).

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

I’ve personally witnessed the seventh entry to this meme: lines of code over 1000 columns wide.

I try to forget, but the horror never fades.

I use GnuCash, because it’s the only FOSS accounting package I’ve found that sensibly handles transactions that involve more than two accounts (aka “splits”) at a time. There’s a bit of a learning curve if you’re new to double-entry accounting, but it does support CSV import, can manually reconcile its records to whatever statement period you want, and can export to graphs or spreadsheets as needed. While highly capable, it can be used for simple cash-flow management as well.

It is, however, strictly a desktop app, and is wholly a separate endeavour to *GnuCash for Android". That said, one reason that I’ve continued to use GnuCash for the better part of a decade is because the UI basically doesn’t change. There’s not much room for enshittification when it’s all GTK-based. Anything else I want from this program, I can do using Python by crunching the data exported as a CSV file.

EDIT: to put into concrete terms why multi-split transactions are useful, I will offer two examples. The first is about granularity of expenses, such as a day at the thrift store. If I’ve acquired some home decor, a vintage shirt, and a trinket for my bicycle, then I would want to record the transaction as such:

• Assets:Cash: -$32
• Expenses:Home Furnishings: +$20
• Expenses:Clothes: +$7
• Expenses:Bicycle: +$5

This does take extra effort to break down into each expense category, but how granular you make your expenses is up to you. Certainly, some transactions wholly fall into one expense category (eg McDonalds as Expenses:Dining) and so there’s no big effort there.

The second example is about multiple money flows as part of the same logical action. Suppose that I treat my credit card as though it’s a debit card – to live within my means – and every time that I use the credit card, I move an equal amount of money from my checking account into my savings account, precisely to pay off the credit card bill at month’s end. This is how the transaction might look:

• Assets:Checking: -$67
• Assets:Savings: +$67
• Liabilities:Credit Card:American Express: -$67
• Expenses:Entertainment: +$67

When it comes time to reconcile (aka “balance my checkbook”), I can do that for each account, one at a time. So my checking account statement is reconciled to Assets:Checking, my savings account to Assets:Savings, and my American Express credit card statement reconciled to Liabilities:Credit Card:American Express. These can happen on their own cadence, since while the bank accounts might end on a calendar month, credit cards often use their own statement dates.

This seems like a lot of data entry, but seeing as GnuCash helpfully finds and clones fields when manually entering a new transaction, it’s almost like a copy/paste followed by a bit of cleanup. In my regular workflow, my typical transactions have two splits. The most irregular transaction I’ve ever created had 28 splits, because it involved donations to multiple charitable causes, split across cash, checks, credit cards, and US Treasury bonds (which paid interest upon withdrawal, and so had to be accounted as well).

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 !homegym@lemmy.world .

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”.