litchralee

I see my typo, and it's too funny and I'm just going to roll with it haha

As a practical matter, relative directions are already hard enough, where I might say that Colorado is east of California, and California is west of Colorado.

To use +/- East would mean there's now just a single symbol difference between relative directions. California bring -East of Folorado, and Colorado being +East of California.

Also, we need not forget that the conventional meridian used for Earth navigation is centered on Greenwich in the UK, and is a holdover from the colonial era where Europe is put front-and-center on a map and everything else is "free real estate". Perhaps if the New World didn't exist, we would have right-ascension based system where Greenwich is still 0-deg East and Asia is almost 160-deg East. Why would colonialists center the maps on anywhere but themselves?

Assuming this is in the USA, I want to note that there are many other available jobs in the protective services occupation, that can be public or private sector, that face the general public (or not), and that don't have any particular positive or negative connotation attached to the job, even after hours.

The Bureau of Labor Statistics (BLS) has a fantastic reference for available occupations:

https://www.bls.gov/ooh/protective-service/home.htm

Citizens != Their Government != The State

This is a fundamental proposition, even in a semi-functional democracy where the citizens elect the government.

I'm not any sort of expert in the laws of Canada, but having tourists come into the country and spend money, buy goods, form interpersonal relationships, and otherwise not be levying war against Ottawa nor the several provinces, that does not sound like any sort of definition of treason, whether in law or in casual usage of that word.

American tourists to Canada are explicitly rejecting spending that same money domestically at American tourist attractions, and are going to Canada to spend it instead. In times where the USA is battering its northern neighbor, I feel like the visiting tourists are coming as allies, not enemies.

But I defer to Canadians about how they feel, and pass no judgement from here in California.

Block, ignore, and continue living your non-bot life.

Restaurants (including franchises of chains) are indeed a major segment of small businesses. Looking more broadly, any industry which: 1) offers a service/product/utility, and 2) has proven to not have a tendency to inflate beyond its fundamental target audience, those are likely to be small businesses. Those are the parameters which stave off any sort of corporate takeovers and consolidations, because they won't invest in a small business if the prospect of infinite growth isn't there. So the business stays small. And small is often perfectly fine.

That is to say, restaurants (humans can only eat so much food), bicycle stores (humans can only ride so much per day), and local produce shops (even in the Central Valley of California, there's only so much produce to sell, and humans can't eat infinite quantities) have these qualities.

But compare those to a restaurant supply warehouse or music equipment store, since those items can be shipped and need no customization by the end user. Consolidation and corporate meddling is possible and probable.

Then you have industries which are often local and small but are prone to financial hazards, such as real estate agents and used car lenders. Because they get paid as a percentage of the transaction size, if the price of houses or cars go up in an unchecked fashion, the profit margins also increase linearly, which makes them more tempting for corporate involvement.

There are corporate-owned national chains of real estate agents, self storage, department stores, and payday loan offices in the USA. But I'm not aware of a national chain for bicycle or bicycle accessories. Even regional chains for bicycles are few and far between. Some consolidation has happened there, but by most definitions, a bicycle shop is very much a small business.

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?