Sorry, i am not very much into kernel/netstack development, but a question. So does it mean that even if an alternative NAT system will be available in Linux (kernel module with a switch or whatever) - it will not be adopted by industry because everyone (and every device) is used to how it works now?
NAT itself was a hack to let everything keep working like it already was despite there being more computers than IPv4 addresses.
The Internet Protocol only concerns itself with IP addresses. The idea is that each computer has an IP address, so computers can communicate by sending IP packets; each IP packet says, "Message from computer with IP address X to computer with IP address Y".
But computers have multiple processes, so there's a need to know which process at the receiving computer is the recipient and which process on the sending computer is the sender. This is why transport protocols (TCP and UDP) add a port field. A port uniquely identifies a particular socket opened by a particular process on a computer. So a TCP or UDP message sent via the Internet Protocol contains the information, "From the socket with port 41590 on the computer with IP address X, to the socket with port 443 on the computer with IP address Y".
NAT is a giant hack which is primarily implemented in routers. It makes a whole household (or office building, or university campus) look to the outside world like one big computer with one IP address.
Say we have a computer with IP address L, a router with public IP address X, and a public server with IP address Y. The computer will send a message to the router which says, "From port 41590 @ L, to port 443 @ Y". The router will invent a new random port number (say 41200), add an entry to its NAT table which says "port 41200 means port 41590 @ L", then send a message to the public Internet: "From port 41200 @ X to port 443 @ Y".
When someone then sends back a message "to port 41200 @ X", the router looks that up in its NAT table and rewrites the packet to say "to port 41590 @ L", then sends it to the computer with that local IP address.
The computer doesn't really know that it's speaking through a router. It needs to know that "packets to the public Internet should be sent via the router" but that's it, the packets it sends and receives looks the same as if the router wasn't there. The rest of the world doesn't know that it's speaking to the computer behind the router; from their perspective, it looks like they're just speaking directly to the router. All the special network address translation logic lives only within the router.
Already back then, you couldn't easily deploy solutions which required all computers and middle-boxes on the Internet to change. That's why NAT exists in the first place.
You could deploy a new NAT implementation, but the problem NAT solves is fundamentally that there aren't enough IPv4 addresses for every computer to have an IPv4 address so you need multiple computers to share. I don't think there's a better solution to that problem other than switching everything over to IPv6 (which has been in progress for the past 30 years and has barely reached 50%).
As an aside, you see the term "CGNAT" sometimes as well. This stands for Carrier-Grade NAT and is an evolution of the NAT concept to much bigger contexts; a whole city could share a handful of public IP addresses, making large regions effectively one "local network" behind a "router". Multiple streets could look to the outside world like they're just one gigantic computer. Each household in that area will then probably do its own layer of NAT, making it look to the CGNAT router like the household is one big one computer. This configuration can be called "double NAT". Since each router doing NAT only needs to know about its own NAT, there's really no limit to how deeply you can nest it.
thanks to the author of the article, it inspired me to try making a small gui app i wanted for long time - it simply reads and shows the contents of the system clipboard in a window. and it was really super easy, i didn't need xcode, only `swiftc` from command line. honestly i didn't know i can make an app without opening xcode, now i want to make more :) so i made the app with approx 500 lines of Swift, with keyboard hotkeys for navigation and style change (fonts, colors, window size), just the way i love it.
cmd+U scroll to beginning
cmd+I scroll to end
cmd+u page up
cmd+i page down
cmd+j one line up
cmd+k one line down
cmd+- font size decrease
cmd+= font size increase
cmd+0 font size reset to default
cmd+3 default font
cmd+4 alternative monospace font
cmd+[ grow left window border
cmd+] grow right window border
cmd+{ shrink right window border
cmd+} shrink left window border
cmd+9 switch background and foreground color
all this in one day, with huge help of duck.ai which is completely free. the app size is approx 300kb. using it feels great because i can do the whole cycle with keyboard only:
- cmd+space to open spotlight search
- type the name of the app, enter, it opens a new window with clipboard contents, i inspect it with keyboard hotkeys only
- cmd+q to exit or cmd+tab to switch back to the prev app
for me personally the standard gui apps are annoying because of the standard kb shortcuts - they are hard to remember and even hard to reach. i prefer "sort of vi navigation" because i can keep my hands for navigation at the same position as for typing.
this is an example of overcomplicated solutions that could be avoided with the tool we already have for years - file system - why do this "heroic" effort of "cleverly" putting everything in one file from many sessions if we could just write command history of every session into a new separate file in a directory and read all history files from the dir instead of reading one file.
>why do this "heroic" effort of "cleverly" putting everything in one file from many sessions if we could just write command history of every session into a new separate file in a directory
For "normal" use in the terminal, a unified single history file is easier to deal with. For example, yesterday I was doing some forensics on the existence of mystery files in my backups from years ago and it was nice just loading up a single history file in the editor ... page up and page down repeatedly to eventually reconstruct the sequence of commands that explained the mystery files. The alternate idea of separate history files is less ergonomic for that. I'd have to open each history file (potentially hundreds) one by one in the editor. Trying to treat separate history files as "virtual single file" by using grep on the whole batch wouldn't work because I didn't know ahead of time what string to grep for. It required manually eyeballing the commands to consider which ones were the culprit. (Yes, if history files were separate, I could also concatenate "cat" them all to a temp file and load that into an editor ... but a history file that's already unified means I don't have to bother with that step and delete that temp file after I'm done.)
>HISTFILE="$HOME/zsh/$(date '+%y:%m%d:%H%M')-$$"
However, for "not normal" usage of a shell in a coding editor, I do create separate history files with a timestamp like your suggestion. In dev environments, I tend to create lots of dirty throwaway shell commands and I don't want them polluting the "normal" shell history.
It's still inconvenient because the .bash_history and .zsh_history files I was studying were inside of .tar.xz and .zip backup files. I wouldn't want to crack open those archives just to concatenate a hypothetical set of separate history files to single temp files. Instead, the GUI archive browser I used just highlights a single history file and loads it into the editor.
Or replace fopen with a SQLite database :-) like IPython does [1], but now it becomes more complicated to read and edit it including from other programs, say a text editor [2].
i cannot trust tech advices from a guy who puts three ad banners (left, right and bottom, taking approx quarter of my screen space) on his personal blog.
can you please suggest any alternatives to switch to? i hardly can find any alternative which provides free service and is a non-profit org at the same time.
even this "ascii" (i expected raw text but still got html+css) was hardly readable for me, had to reach to the reader view, finally readable, ohh... looks much like ai-generated, why did i spend so much time jumping over obstacles...
reply