VecGS
Chaotic good
No bio...
User ID: 599
I have had an evolving set of view on the conflict in Ukraine that seems to annoy just about everyone. With the news today about Trump and Zelenskyy it's even more relevant.
I’m going to start with the present state of the conflict. This is, for this exercise, going to be called…
Option A - Stalemate and Attrition
Where we are now is an attritional battle with relatively static front lines. What I’ve observed is that there are many “red lines” that the supporters of Ukraine have. This leads to aid being sent simply to preserve the status quo. Ukraine, as much as it would want to win, is prohibited from actually winning because that might give Russia a sad and lead to world war 3.
This is a similar position we were in while in Vietnam. We were fighting for the same hills over and over again. There was no effort to actually win. Unlike Vietnam, where the U.S. faced a guerrilla insurgency, Ukraine’s conflict involves a nuclear-armed Russia, raising the stakes and complicating any path to outright victory.
In my mind, this is the worst option. Unless you get Russia to capitulate, Ukraine will not get enough concessions to maintain her previous borders. This war can go on as long as both sides have men to throw into the meat grinder. Simply because providing enough support for Ukraine to win is off the table.
Clearly both sides will continue to fight on mostly static lines indefinitely.
This isn’t just from a US perspective, all of the arms donations that were given to Ukraine up to this point by basically everyone includes clauses to not attack Russia. We, as a world, are telling the Ukrainian people to fight with one arm behind their proverbial backs. It’s a scenario that they can’t win with.
This option might eventually weaken Putin internally if Russia’s economy or morale crumbles, but banking on that is a gamble with long odds. They seem to have a deep bench of people who share the same values and motivations as Putin himself. Based on surveys and polls I’ve seen, this conflict still has much popular support from the people of Russia.
One has to ask, who is the winner in this scenario? The only plausible answer I have is only the military-industrial complex. Ukraine isn’t winning. Russia isn’t winning. Arms manufacturers are winning. With static front lines fueling endless demand for weapons, defense contractors profit while neither Ukraine nor Russia gains ground.
A prolonged stalemate, which is what this leads to, could erode NATO’s credibility, leave Ukraine a fractured state, and embolden other aggressors watching the West’s indecision.
This leads to…
Option B - Full Commitment
Here’s where we would treat Ukraine as the ally that they should be. This is where you own up to the Budapest Memorandum that was signed by Yeltsin and Clinton to provide security guarantees for the territorial integrity of Ukraine. (The 1994 Budapest Memorandum saw Ukraine give up nukes for security guarantees from Russia, the U.S., and others—guarantees now in tatters.)
To be clear, this has been my position since basically day 1 of the conflict. Day 1, for me, is Russia’s 2014 annexation of Crimea, not just the 2022 escalation, per the Budapest Memorandum’s promises. A direct conflict between nuclear powers is historically unprecedented. Sometimes, the correct moral choice entails risks.
Russia’s 2022 invasion, unlike 2014, exposed Putin’s broader ambitions, forcing the West to rethink its hesitation.
This option would entail actual support from allied nations, not just good wishes and materiel, but boots on the ground. Short of that, Option B could include bolder support, like unrestricted use of Western weapons, though even this risks Russian retaliation.
Here’s the thing, you have two options, either Russia is an existential threat or it’s not. If they are a real threat, then the answer should always be to support the morally right answer. If that leads to a broader conflict, then so be it — it’s a just war based on the reality. If they are not an actual threat… and Ukraine isn’t really an ally, why are we even talking?
Winding back a bit to option A, to put things into perspective, what we’re presently doing is pretty much what led to WW2. Chamberlain and the rest of the west were in a stance of appeasement. By not actually fighting evil, we let it grow. Just as appeasement emboldened Hitler to push further, letting Russia keep gains now might signal to Putin—and others—that aggression pays.
The broad statement here is that you can’t simply spend your way to victory. No amount of donations of money or supplies will get Ukraine back without Russia losing the conflict they started.
This option is, for all intents and purposes, completely off the table.
So…
Option C - Negotiated Settlement
Here’s the unpopular one. Negotiated peace to end the conflict. Neither Ukraine nor Russia is happy with this. With this Ukraine will lose territory and some level of autonomy.
Given that we, as a world, can’t seem to stomach the concept of Russia losing, which takes Option B out as a solution, you’re left with Option A or C.
Since Option A does nothing but throw more men into the meat-grinder for no gains by either side, I think it’s the worst outcome. I don’t like Option C in any way, but it seems fare less bad than having the same outcome, but more death.
That said, a negotiated peace ceding territory might end the fighting but could set a precedent that territorial conquest pays off, weakening the global order.
Option C feels like a bitter pill; it’s pragmatic but forces Ukraine to sacrifice land and pride, a tough ask for a nation fighting for its survival. Some might say a negotiated peace stabilizes the region short-term, but history—like Munich in 1938—warns that rewarding conquest invites more.
…but wait, a surprise…
Option B’ - Two-Front War Risk
Ok, let’s pretend that we actually have the balls to go fight Russia and curb-stomp them out of Ukraine (including, of course, Crimea). Does the US and her allies really have the ability to fight a two-theater war? I would question this.
If the U.S. commits fully to fighting Russia in Ukraine, it might leave Taiwan exposed to China. This would be the ideal time for China to do what they’ve been threatening to do for decades — invade and annex Taiwan.
We have to be really careful with how we’re throwing around our might.
A decisive victory could reshape Europe’s security landscape, but a two-theater war might strain U.S. and allied resources, leaving vulnerabilities elsewhere. If the U.S. goes all-in on Ukraine, China might see a green light to hit Taiwan, stretching allied forces thin across two continents.
Some historical context for a moment. When Russia attacked and annexed Crimea in 2014, the world’s reaction was an annoyed “tut tut.” Nothing happened. Russia shot down a commercial airliners and the sentiment was echoed again.
Nothing happened. Russia’s takeover was internationally condemned — tut tut — but met with limited Western response at the time.
Why is that?
Well, Obama was coming off a victory two years prior against Mitt Romney. All of the rhetoric was that Russia was not a threat.
“The 1980s are now calling to ask for their foreign policy back” in response to Romney saying that Russia is the biggest existent threat to the US and the world.
It would come off as almost comical to have the Obama administration immediately walk that back.
In Europe, Russia was also the supplier of natural gas to power the industrial nations there. Germany was committed to the absurd tactic of closing down their nuclear generation facilities so they were also against any action against Russia.
Tut tut.
Beyond these options, could intensified sanctions, diplomatic isolation, or mediation by neutral parties shift the dynamic? These might pressure Russia without the risks of Option B. Personally, I doubt it. Putin is in too deep to risk pulling out without something that can be claimed as a victory — and any victory would invariably put the scenario into Option C.
There are no good answers.
A continuation of the status quo, Option A, is, in my mind the worst outcome of all. It maximizes human suffering while having the same outcome as Option C.
Option B, my simple-minded “best” option, isn’t on the table because Russia has nukes. By the way, this shows that simply having nuclear weapons makes you unable to lose in the eyes of the world. It’s a non-ideal precedent in my mind.
Option B could also easily lead to B’ as well. That would also be a very not good outcome.
The one that disgusts me the least is Option C.
There are no good answers. Option A drags out the suffering with no end, Option B courts global chaos, and Option C trades Ukraine’s dreams for peace. I lean toward C as the least awful. It sucks. Royally.
Honestly, I would still lean towards B as the correct and moral choice, but I'm very much not in control of any of this.
Weirdly, I think the biggest non-Google winner is OEMs that make widgets that need some UI. I'm thinking of the infotainment systems in cars, thermostats, all of the IoT randomness that's around. It's a lot easier to start with a base that at least has a head start on drawing to a screen and accepting inputs than from base Linux. Even if you start with a Raspberry Pi, you still have a bunch more work to do if you want to not only output bitmaps, but also accept user input.
I'm in basically the same boat as you are. But I'm mostly commenting on the "normal" people using Android.
My stance is that the base OS itself, Linux, is open. AOSP is a pretty thin veneer on top. It's helpful for some OEMs, phone and otherwise.
I totally agree on everything else. Having toyed with the idea of procuring chips, then looking at the lead times of some unique ones... I didn't really go too far on that side other than buying way too many USB jacks that I doubt I'll ever use.
But the last bit is kind of interesting. AI is going to be replacing things that, up until now, humans were uniquely suited for.
I'll use a present project as an example. I'm working on a side project that is heavily reliant on AI. Without getting too far into the weeds, it's a system to allow "smart" replaying of sets of related API calls to enable better testing. I could get 90% of the way to success pretty easily without any AI help. Sure, things like variables would get named "var1," "var2," etc., but it worked. Then there's weirder cases where you need to be able to take some context cues to figure out how to select the right value to use in a replay.
{
documents: {
{
type: ticket
number: 123456
},
...
}
}
On a subsequent call, we need to find the ticket number, but it might not be in the same place every time. (The API I'm working with is... meh.) You may have multiple documents and they may not be in the same order (think JSONPath selectors to get the document's number where the type is "ticket").
Now, I can, in lieu of AI, present that to a human to make that decision. The end result is the same. I have the inputs that went to either the AI or the human, and I have the answer provided. In neither case do I have an audit trail of how the answer was arrived at. I would argue that you might be able to get more of an audit trail from the AI because there may be logged "reasoning" ideas used in the process. I know I can't audit what I did to come to the answer other than "it felt right."
My prediction: even in OSS, there will be an increasing reliance on AI -- both in the generation of the code itself, as well as the actual invocation of services from that code.
I have no issue with open-source or making money. In fact I do programming for fun (not just for work) and I'm making and releasing OSS. I use one of the least restrictive licenses for the stuff I make: the MIT license.
Having been close enough to smell the code in question, I have to say that you're underplaying the power that Google has. Amazon is, to my knowledge, the only US company that forked AOSP and has a real product. The main other players are Chinese as they're not allowed to have Google-influence.
The thing with Google is they really do wield the license like a bludgeon. You are generally allowed to add things, and most everyone does, but you're not allowed to remove or replace any of the core functionality they provide. Excluding the edge cases of nerds (like me, if I used Android) rooting the devices, it's pretty locked down. And in many cases rooted devices can't participate in many things -- banking apps, for instance, seem to want to live on non-rooted devices. Many games as well.
Things like alternate app stores exist. You can side-load the Amazon Appstore on any Android -- as long as you turn on developer mode. But it's such a niche case IMO.
So yes, it is more open in an absolute sense. But from a practical standpoint, they have almost as walled a garden as Apple enjoys. That said, around the periphery, they allow fare more customization of your experience. But actual openness in the ways that matter, loading apps, paying for things, etc., they are quite walled off.
Certainly. I'm not arguing that. But the way they've done things is kind of like a Trojan Horse. You get a bunch of stuff, but you also lose nearly all control.
They're giving it away because it drives more revenue to them based on what's required from the licenses. They not only make money with licensing the Google tech, but they get their 30% cut on app sales, and everything else.
They ceded the hardware market, smartly, and kept the money-making parts.
I'm far from where those decision-makers worked so take this with the appropriate-sized grain of salt.
Amazon, like most companies, is a profit-maximizing entity. The thing that separates them from most other companies is the types of decisions that people are allowed to make. The leadership principles they have, as much as I made fun of them while I was there, truly are a driving force on the inside.
Here's what I'm figuring happened. I have zero knowledge that it happened this way, but it tracks based on my time there. (seven years)
- We already have the Kindle line of e-readers and it's driving a lot of purchases of content, except that content is solely limited to books -- purely black & white books.
- As Amazon, we already have things like Amazon Video, Comixology (the comic book distributor we bought), Amazon Music. All sorts of things.
- We need to have another platform to make money on that. Let's make something in a similar form factor to an iPad.
- It needs to run things. We can't just make something that solely consumes only Amazon content because that's not a compelling enough product. The only other viable avenue is Android, which already has some middling adoption for the tablet market.
- If we ship the Android that people expect, we need to pay Google (realistically a competitor in many ways) money for ever unit sold. Not only that we lose control over the platform since the Google Play Store pushes products that compete with our own. The economics of the razor blade model don't work if you don't lock in your customers to your brand of razor blades.
- The licensing of Android insists that it's the Google way or the highway. You can't pick and choose what Google things you want -- it's all or nothing.
- Hey, we're Amazon -- we have an endless supply of really good programmers. We can do this ourselves.
So, to have any hope of getting third-party apps on a startup platform, you only had Android to choose from. The thing is, we were hounding the third-party publishers to even engage with us. Even though we're one of the biggest companies in the world, and we're selling a large fraction of the Android tablets out there, no one even cared. Even if we could get a publisher to put something in our app store, they would ignore it and it would become wildly out of date typically.
And that's with Android. The publishing process was typically upload your APK and press a few buttons. And it was like pulling teeth to get that done.
I think even Amazon realized that, despite their size, asking devs to make new apps was a bridge too far.
Could Amazon have just stuck with a base Linux distribution and built something from that. Yes. Easily. Arguably easier than making an Android clone in many ways. Yes, it's "Android," but from so much of the public Play Store APIs needed to be reverse engineered and reimplemented.
And I'm 100% sure they would have used Linux. The institutional knowledge of Linux in there is astonishing -- especially when you start engaging the AWS folks.
Android is weird.
The actual open-source parts of Android barely, if at all, work as an actual phone. Sure, it's running Linux under the covers so from that perspective it's open-source. Android builds on that with a very very bare UI and some of the plumbing. The thing is, any phone that is actually sold is running on not just the stock Android code, but an absolutely massive collection of proprietary code to deal with everything that makes the devices useful. Things like an app store, maps, messaging, running the physical phone hardware, making it pretty and usable.
I used to work at Amazon in their App Store. Amazon, with their Kindle tablets and the ill-conceived Fire Phone, run Android. But they forked off the open-source version because they didn't want to pay Google the licensing. Literally everything had to be reimplemented to get a device that works in any way. All of that is, of course, proprietary.
Of course, Amazon's effort to not have the licensing costs came with an absolute mountain of work. A building full of people doing all the custom code to get Android to something that is usable. Everything from a new app store, maps, push notifications, payment processing, the skins, everything. Ok, depending on the era, we either filled a building or a large chunk of one depending on which building we resided at. The hardware and base OS was handled by another group, Lab126, down in the Bay Area. And to top it off, since there's another app store, you have to get developers to submit their apps to that as well -- which was hard.
The tl;dr is that Android is the stone soup of OSS. It "works," but not in a way that is useful to end users.
I had time to attack the issue today. I bought the MiSTer FPGA and Jammix on eBay, so someone had previously set it up. Maybe the biggest mistake I made was not redoing the setup myself... the issue was a rogue newline in a config file. Removing that fixed the whole thing toot sweet.
At this point, there's nothing between now and applying finish to the whole thing. Though I want to invite my brother over to have a play on it before I take a bunch of it apart for the staining process.
My arcade cabinet build mostly works. I have everything hooked up and running fine with one player. But when I try to use the second set of controls for player two, bupkiss. I'm nearly positive it's some whacky software or configuration problem. I just have to spend some time looking at logs to troubleshoot. (this, unfortunately, feels far too close to my day job -- lol)
I have to say that one of my favorite games, 1942, is way better played with a joystick than it is with gamepad! Just as God intended.
I think much of this is an effort to get out of a loop of analysis paralysis. I have a bad habit of overthinking things and not doing the things. A lot of this was (after getting frustrated of not doing things) just forcing myself to just take the next step. The worst likely outcome that may happen is I waste a pile of wood and time and trade that for experience.
I have a MiSTer FPGA with the Jammix card and a JAMMA (Japan Amusement Machine and Marketing Association) harness. So, in theory at least, it should be mostly plug and play. But there's a rats nest of wires so it's a bit intimidating.
It's a pretty standard two joystick and six buttons per side setup so there shouldn't be that much hardship. I do have to add a couple of wires myself since I'm going to wire it up using CHAMMA. (CHinese vs. Japanese -- The Chinese one support six buttons without an added harness)
The whole build was an adventure. I designed the basic outline of the cabinet and cut that. Basically everything else has been a matter of cut-to-fit after that. It's probably not the best way to do it, but it's fun and it's been a learning experience.
Update on the arcade cabinet from last week. The drawer has been fabricated and installed. It could be a tiny bit better, but it's Good Enough that only I really know the issue. It's maybe 2mm or so out of square... it's not the end of the world and it functions the way it should.
Next up will be all of the wiring. So many wires for all of the controls and buttons. I'm really hoping that I can get all that done by next week. It should be eminently doable. After that it's mainly going to be finishing the wood.
I lived in Seattle for seven years... the issue is that any racial disparity in outcomes is treated as an equity problem. To sweep things under the carpet, the solution that has been come up with is to stop enforcing the laws.
It is common to have many years expired registration, which is supposed to be paying a large share of the transit budget. It's also common for people to simply not pay on transit either. Seattle's light rail doesn't have turnstiles, so everyone is basically on the honor system. People have noticed that you don't need to pay. Any enforcement is met with cries of inequity.
The whole equity-based system that is put in place by "progressive" policies leads to all sorts of easily foreseen outcomes. But if you dare mention it in polite circles, you're deemed a right-wing Nazi.
Over the long holiday break (I had to burn a lot of PTO before the end of the year or lose it), I got mostly done with designing and building a video game arcade cabinet. I've built some stuff before, a long built-in window seat for my Florida room. But this felt like really jumping into the deep end because so much of this isn't square -- on purpose. I've learned a lot about both designing furniture and woodworking in general.
It felt cool using some of the tools I've acquired over the years in anger. The biggest enabler of this journey was the Shaper Origin, which is a hand-held CNC. Second was the new table saw I got last year.
https://imgur.com/M03FtuI https://imgur.com/Sz8Xqqd
I'm at the point where the only parts that are left are:
- Install the screen. Not pictured, but I have a mount for the monitor. It'll live on the cleats that are on the inside.
- Make and install the keyboard/mouse drawer. Of course I decided to walk the harder way by specing a push-to-open undermount drawer slide.
- Wire everything up and test. Central to this is a MiSTer FPGA that I already have.
- Install the back of the cabinet.
- Finish the cabinet and install the T-molding into the slots that I already routed.
I'm really hoping to get through all except finishing it over the weekend. The only part that really worries me is the drawer since that seems a bit annoying -- mostly because I've not done it before.
(and yes, the control panel was recut because it wasn't square; you can see a few mm gap in the front... since I had the bad one, I decided to install some controls to see how it'll feel.)
What idiot thought it was a good idea to add a DHCP server to a printer? That is peak anti-social.
In an office setting, I know it would take me so much time to try to figure that out. At least in a home setting, it's far easier to remember the answer to "what was the last thing that I (or spouse or kids) attached to the network in the past day or two?"
By default, absolutely nothing... you've found one of the common attack surfaces of ethernet! You can use this to do all sorts of malicious things. You can overload the switches by just spamming them with new MAC addresses. You can intercept traffic. General denial of service attacks. Circumventing security. All sorts of mayhem.
So, ways of dealing with this... you can have switches that are configured to only allow an interface with a certain MAC to connect to certain ports. Or you can have softer ways of dealing with this by feeding information from the switch to some variety of intrusion detection system. Similarly, a switch can be configured to ensure that a device DHCPing for an address can't suddenly start using a different MAC.
There's a host of enterprise-y tech being built in this arms race if you want to fund some hardcore security-focused teams. That said, I don't think I've ever encountered (maybe because I'm not an attacker) these in the run-of-the-mill office environments. This is including working at Amazon, which is a bit persnickety on security. I'm quite sure that they're running these things in the data centers though. For something like AWS, they have segregated networks for control-plane traffic (the back-end of the services and how they are configured) and customer traffic. And for customer traffic, everything is on its own VLAN to ensure that I can't make a malicious service that would attack neighboring instances on the same machine or subnet. They also have a bunch of security in place to ensure only trusted clients can connect to services and verify the servers' authenticity.
This is one of the underlying reasons that having good physical security is essential. Once you have access to a network you want to attack, you have a lot more surface area that you can use to attack it while (preferably from the attacker's perspective) remaining undetected.
How does it broadcast its request if it doesn't have an IP address?
This is where IP and ethernet get a bit blurry. ARP is operating at the raw ethernet level and it's sending out the raw ethernet packet to the ethernet broadcast address. In the packet it has it's IP and the requested IP. Implicit in the packet is the MAC address of the requesting machine. (Deeper dive: https://en.wikipedia.org/wiki/Ethernet_frame)
In most cases you think "I'm IP xxx sending something to IP yyy," the reality is at the ethernet level, the IP stuff is all payload the network really doesn't care about. Internally, everything on the actual network level is working with MAC addresses. IPs are just a really convenient abstraction on top of it. (in this case "network" is the layer 2 of the entire stack -- the data link layer)
The local network is defined by the network mask, right? So with 255.255.255.0 if I send something from 192.168.1.2 192.168.1.3 there's no need for the gateway to be set up, but 192.168.2.3 is outside the network and the packets will be routed to the gateway?
That's correct. Anything on the local subnet stays on your local network. Anything outside gets punted to the gateway to deal with.
This makes me wonder how the packets are routed within the local network, actually. Let's say I'm sending a request from my PC (192.168.1.5) to my NAS (192.168.1.2). The PC is connected to my wireless switch/AP (192.168.1.4), and both the switch/AP and the NAS are connected to the wired router (192.168.1.1). How does the switch/AP know it should send the request to the wired router and not to one of its other LAN ports?
I'm going to cavalierly ignore WiFi in this because it muddies things up and deal with layer 2 of the stack and up and just treat it as a switch. This is what's in my mental model of what's happening in some detail.
- You try to access "nas.orthoxerox.com"
- DNS lookup for that. Oops, we only have the IP of the DNS server: 192.168.1.254 (making something up)
- ARP on ethernet to get the MAC for ...254.
- This gets to the switch. It'll broadcast this packet to all its ports. (Once the switch knows that a certain MAC is on a port it remembers it. Most home-grade switches can remember a few thousand MAC addresses)
- NAS responds and then the switch and your machine know the MAC of the DNS.
- DNS lookup (several round-trips to do this) -- you now know the IP of the NAS. (Since the switch now knows the IP of the DNS, it sends it directly to the port it knows it's on)
- ARP for the IP of the NAS. (same as before)
- Finally, send an ethernet packet from your machine to the NAS. (Again, from the ethernet perspective, this is sending from your machine to the NAS based on it's MAC address when we're at the low level)
If there are multiple switches between you and the destination, the broadcast just keeps going.
If you want to have some "fun," look up "ARP storm." It's likely one of the few times most networking folks (I'm a programmer) even think about things at that level.
Much of this is really building on many decades worth of tech and it's hard to understand the why until you understand much of the whole stack.
Here's some of the whys, from my perspective in the order I would talk about them:
DHCP: when a device joins a network, it can broadcast on the network and ask for how it should configure it's network stack. Implicit in the request is the MAC (Media Access Control) address of the interface itself which provides the physical address of the interface. The DHCP server (in a home setting, usually in the router) assigns an IP from a block it manages and gives the rest of the networking details (gateway, subnet, etc) to the client. DHCP isn't strictly needed as the clients can be configured manually in many cases. Cheap IoT devices tend to rely on it.
Default Gateway: When you're sending any packet to something outside your local network, you send the packet to the gateway and it figures out how to get the packet to the destination. In a home setting, this will just be forwarding the packet upstream to your ISP. In a larger scale setting, it's going to consult things like BGP routing to figure out where to send things to. The beauty of IP is that the client doesn't need to worry about it and it's completely abstracted into the gateway itself.
Duplicate IPs: As mentioned before, every interface has a MAC address. When you're sending a packet on the network to another machine (i.e. not broadcast), you send the packet to the MAC address. But we're dealing with IP, not MACs. To translate from an IP address to a MAC address we send out a broadcast ARP (Address Resolution Protocol) request asking basically "will the device with IP xxx respond?" Broadcasts are received by all the machines on the network. The machine with the requested IP will respond. If there are multiple machines that are configured with the same IP, they'll all respond. What happens here is usually the first one wins. This is complicated by modern switches because they learn what IPs/MACs are on each of their ports. They'll likely assume there are two routes to the same host and weird things may happen. Lesson: don't do it, things break.
VLANs: From a switch perspective, it just controls what ports can talk to which other ports. If you have an 24-port switch, you can configure multiple VLANs such that, say, ports 1-12 can talk to each other, and 13-24 can talk to each other. It's setting up two "Virtual LANs." You can have a router that attaches to both of the VLANs to handle routing between them if you want. These are typically used to prioritize certain network traffic, or for security (e.g. a guest network can't talk to your servers).
UDP and NAT: Since there's no connection in UDP, the NAT device just remembers things like "when device XX using port YY sends a packet to internet address AA port BB, I sent the packet on my port PP. Later, if I get a packet from AA:BB on port PP, I'll look that up and forward the packet to XX:YY." The key here is that all IP packets have the source IP and port and destination IP and port. When it's doing NATing, it replaces the local IP (which isn't going to be publically routable) with it's own address and port. On the way back, it just does the reverse and replaces the destination IP/port (which is how the packet got to it in the first place) with the local network's addresses and ports and forwards.
Questions like this are pretty much in the wheelhouse of things like ChatGPT. It's really good at answering these high-level questions and providing good direction with the ability to dive deeper into each of the topics.
I asked on your behalf and everything looks pretty much like I would've written. https://chatgpt.com/share/677bd93a-310c-8004-9dcc-9b36c30fde8c
My take:
For home networking, unless you're setting up a homelab, you can probably ignore VLANs. Honestly, most of these are pretty much ignorable for what I'm expecting your use case of home network are concerned.
Anything vaguely modern in terms of a home router should handle all of these pretty transparently. Without getting into packet-level stuff, DHCP from the router will configure the clients and configure the default gateway to itself as well as prevent duplicate IPs (unless you're configuring them manually). DHCP itself tends to just work out of the box. UDP NATing, similarly, tends to just work. VLANs, at what I'm expecting is your scale, should likely just be ignored.
In my case, I have a small server rack that has a couple of NASes living in it along with a few switches (1GbE and 10GbE). The switches support VLANs, but even for what I'm doing, I'm far from needing any of the functionality it would provide. The router I'm using are a set of Eeros -- they can provide a mesh network, but for me all of them are hardwired to the switch.
If you're looking to experiment from a homelab perspective, that's another story. But it could be a really fun story. A common way of getting started there to get a solid grounding on the fundamentals is doing something like setting up a Raspberry Pi cluster and playing with those. It's a cheap and approachable way to learn these concepts.
Just for fun I asked: https://chatgpt.com/share/6773255e-8f74-8004-915d-56088ff34dc2
I'm not going to include the whole thing here so as not to fall afoul of the rules.
Now I want to get me some rutabagas...
Point taken. Some of the pics from the linked article have cow skulls strung up on a stick, so there's some contact with the outside world. But that said it still says something that the only photos of the tribe only have men. However, I sincerely doubt that the interaction with outsiders caused a shift in gender roles for this (or other) tribe(s).
It all reeks of starting from a conclusion and working backward to make an article to support it.
Another thing I just thought of which is unrelated to this: insurance rates. I'm a guy in my early 50s, which means at some point in the past I was a teenager. I've also worked in insurance for quite a while -- not the actual underwriting, but I had plenty of interactions with the people who did. There's a vast disparity between the accident rates for young men compared to young women, which leads to the disparate amount charged by the companies. There's something pretty obviously different in the behavior, in the aggregate, between men and women from a purely behavioral standpoint concerning risk-taking.
Similarly, all one has to do is look at the prison population and note that the vast majority of inmates are men. Some of this is caused by women getting lighter sentences for the same crimes, but that doesn't explain the order of magnitude difference between the behavior of men and women.
Even discounting differences in physical strength, there's something fundamentally different in our wiring.
Every once in a while we find yet another uncontacted tribe of people somewhere in the world. The most recent one I read about was in the Amazon.
Now, if these tribes were previously unconnected to the rest of the world, whatever "patriarchy" the rest of the world follows would not affect them. It's an unbiased sample. All of the published pictures I'm seeing are all men and no women.
The thing is that, in general, these tribes all seem to follow generally the same social schemes... the men seem to do the hunting, and the women tend to do the child-rearing and non-hunting activities. Now I'm sure there are some outliers where women are also doing hunting, but generally this isn't a thing.
From a purely physical perspective (and I'm assuming this isn't a controversial stand), being pregnant, giving birth, and the first year or so after giving birth to a child is hard and energy-intensive endeavor that would preclude many strenuous activities. Seeing as women are the only members of humanity that can do this, it would follow that societies would be set up around this. To be super specific, when I'm saying "women," I mean members of the human species who are adults and with a body form intended to produce the larger gametes we call "eggs" and gestate offspring internally and can produce nourishment for said offspring. The fact that I need to write this out, I find silly.
Men and women are different. Both men and women are needed and valuable. The progressive stance that men and women are entirely interchangeable and indistinguishable is laughable in my opinion. Men and women are different, and that's a good thing.
On the topic of SciAm, well, I dropped my subscription when they endorsed a candidate for the presidency last time around. To have science mix with politics takes away from the science aspect. Science is the search for truth -- not just "truth" that meshes with currently popular ideas.
Oh, I totally got that from your original post. I was just responding to the last bit thrownaway's comment above mine.
I also get really annoyed at all of the "emotional support dogs" that people claim are protected by the ADA, which they aren't really, hence "real service animals." Though I would love for someone to have an emotional support miniature horse just as a troll. (They also are mentioned by the ADA along with dogs as being eligible for being service animals)
It was also a big thing in Washington (at least Seattle) when I lived there... restaurants, grocery stores, whatever.
I worked at Amazon (office, not warehouse) and it was company policy that you could even bring your dogs to the office if they were well behaved. I honestly enjoyed it when my coworkers brought in their dogs -- but much of that was that they weren't random dogs so you got to know them. The 404 page on Amazon still has pics of people's dogs. The real differentiator here was that this was all done with permission and vetting.
I'm now in Nashville and I'm not seeing this effect as much here. Though people have a habit of not leashing their laws out where I live. Admittedly, I'm out in the exurbs, so that might have something to do with that phenomenon.
Dogs with jobs are a very different thing in any case. Real service animals are a true boon to their owners. Police dogs are in a similar boat.
The general feeling I get (not a dog owner myself, FWIW) is that people have been conditioned to think they are special in some way. Their dog (or kid, or whatever) is better than everyone else's. That mixed with a bit of main character syndrome and you get what we see now. Maybe this is what happens when you give everyone awards when growing up?
Another angle that would support this same outcome is that it seems to be considered rude to tell someone not to do something or that whatever they are doing is "weird." You make the accused a "victim," and suddenly, they have that as a bludgeon to wield against you. I'm not a proponent of bullying, but that tended to keep people more in line and enforced a sense of shared social norms.
I have no idea how to get back to "normal."

It's like that on his wiki page for what it's worth: https://en.wikipedia.org/wiki/Volodymyr_Zelenskyy.
The transliterations from Ukrainian to English have some gray areas from what I've read.
More options
Context Copy link