What actually triggered me most was the apparently big salary bump you can get for "golang" in the UK? That makes no sense, and I'm guessing this is due to small sample sizes.
It's the median salary: 50% of people earn more than 62.4k. 10% earn more than 80k. It's still low compared to the US, but what isn't?
For this, you get proper health and unemployment insurance, usually 30 days of paid vacation, up to 6 weeks of sick leave with full salary, up to 10 days to take care of sick children with full salary, paternal leave, the right to work part-time if desired, and so on. I don't know where you get the "people can be let go anytime" have from, because Germany is pretty famous for its "Kündigungsschutz" and it's very hard to let people go because of performance issues alone, which is why things like stack ranking and performance improvement plans pretty much do not exist here.
I can understand if young people without kids do not care about these things and just want the money. However, once you get older, you'll see the advantages.
I agree with you partly. The benefits are great & fairly above international norms. But I do not agree with the "firing protection" anymore. Last year alone I saw thousands let go in Berlin in fairly large organizations like neobanks for example. I myself saw my previous employer let go of 30% of the staff over the year. A simple Google search of - "Berlin IT firings 2025" will give you a picture.
"The union" should be "a union", of which, companies are rarely a part of ie zero.
Their workforce may be a member of a union, some equals in grade may belong to different unions.
This is just half of what Time Machine does. What people are constantly missing is that Apple Time Machine is fast, as it does not need to walk through the whole filesystem to find changed files. Thanks to FSEvents, introduced in Mac OS X Leopard, it knows which directories actually contain changed files and hence usually only needs to check a small fraction of the filesystem. (Not sure if it still works that way after the switch to APFS).
This would of course also be possible on Linux (using *notify), and there are some projects which try to do this, but it's really hard to do it reliably. You might argue that this feature is less important nowadays because NVME SSDs are so fast, but still, I remember very well how astonished I was that creating a new time machine snapshot on OS X Leopard took mere seconds.
I lost all my files to Time Machine in 2008. I don't remember exactly what happened. But since then I'll take a slightly slower, observable command-line copy over sparkly magic.
Yes, I do not trust TM. That's why I have both a backup with TM for convenience and also to have all the files (including system files), and a mirror of the important files (basically my home directory) with `rsync`.
No, the right way to do this on Linux and FreeBSD is to use zfs with zfs send/receive. Creating snapshots and sending them is efficient enough to use it as the underlying storage for moderately loaded databases and VMs.
They are atomic and require zero downtime. They can be encrypted and resent to other machines. Cloning whole machines from them is easy and efficient.
Well, not really because it’s portable, as despite being a “POSIX script”, most of the date and sed tricks I do don’t work on the BSD versions of those commands, with comrak, additionally, being a dependency.
He's obviously a smart guy, so he definitely should've known better. It's weird how these AI evangelists use AI for everything, but somehow he didn't ask ChatGPT what all of this means and if it may have reputational damage, because I just asked if I should claim these trading fees, and it said:
Claiming could be interpreted as:
* Endorsing the token
* Being complicit if others get rugged later
* This matters if your X account has real followers.
and in the end told me to NOT claim these fees unless I'm OK with being associated with that token.
When you're under a lot of stress, your internal evaluation function for what is moral can start to break down. It may have been hard for him to turn the money down, especially if he's addicted to the sense of power he's getting from his coding agent spend. As he said, his wife suggested they can't afford it.
There's another thing. A certain type of engineer seems to get sucked into Amazon's pressure culture. They either are, or end up, a bit manic. Laid back and relaxed one day (especially after holidays), but wound up and under a lot of internal pressure to produce the next, and a lot more of the latter. Something like Gas Town must be a crazy fix when you're feeling that pain. Combined with the vision that if you don't, you're unemployed/unemployable in 12 to 24 months, you might feel you have no choice but to spend every waking minute at it.
It's a bit (more than a bit) rude to analyse someone at a distance. And to be honest, I think something like Gas Town is probably one of the possible shapes of things to come. I don't think what I can observe looks super healthy, is all.
> Indeed, the Gas-Town token is down 97% from all-time high,
What else could possibly have happened? Surely every one put their money in with the express intention of participating in a pump and dump.
Not taking the money would have been the high road. I don't think basing the economy on gambling and scams is good for society. But who could realistically claim to be a 'victim' here?
* NAT can still filter traffic (and practically always does)
* NAT can hence still provide security features
* The real world often does not care about original definitions of a term. NAT was originally meant to just do address translation, but it has evolved.
* Of course, ipv6 is not less secure because it doesn't have NAT, as the same filtering behavior can be replicated with a firewall. That may even have advantages over NAT.
RFC 4787 does not really describe how real world implementations behave. As almost all SOHO routers are Linux-based, i prefer to discuss Linux netfilter-based NAT behavior than some hypothetical RFC 4787 NAT. There are clear differences. For example, RFC 4787 says:
> REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior
While Linux netfilter behavior is "Address and Port-Dependent Mapping".
As Linux netfilter implements both NAT and firewall behavior, it is relevant for the discussion which parts of overall netfilter behavior falls into 'NAT part' and which into 'firewall part'. There is clear distinction - DNAT/SNAT rules in nat table represent NAT behavior, while REJECT/DROP rules in filter table represent firewall behavior.
As Linux-based SOHO routers are usually configured with both NAT and firewall netfilter rules to implement both NAT and firewall behavior, one cannot answer question 'Does NAT filter traffic?' based on external behavior of such SOHO routers, but has to analyze which part of the network stack is responsible for such behavior, or how the same network stack configured with just NAT rules and no firewall rules would behave. And here the answer is no, it would pass traffic (that do not match existing connections) unmodified.
The problem is: what is an implementation detail, and what is NAT as a concept? This line is very blurry. The RFC does not really distinguish this and also doesn't want to. As it says, it tries to document behavior and explicitly uses the term "NAT filtering". When we say "This box here does NAT", then we implicitly assume this behavior. You might argue that implicit is not good, and I would agree (this is the advantage of ipv6 with firewall: filtering is explicit rather than implicit). However, if someone tells me "Well actually, NAT does not do filtering, the firewall does", then to me this is similar to arguing with staff in a supermarket that the tomato belongs in the berries section.
I also want to make clear that I fully agree with the article's main point: NAT's primary purpose was and still is address conservation, and that ipv6 is no less secure than ipv4. I do disagree though with the notion that "NAT does not do filtering" or that "NAT does not provide any security".
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state --state INVALID -j DROP
iptables -A FORWARD -i lan0 -j ACCEPT
iptables -A FORWARD -j REJECT --reject-with icmp-admin-prohibited
If you omit the first line, you get firewalling without NAT. If you omit the second set of lines, you get NAT without firewalling. This should make it pretty clear that they're orthogonal features.
If NAT functioned as an inbound firewall, the second set of lines wouldn't be necessary and removing them wouldn't let you make inbound connections. But you can just test it yourself, and you'll see that NATing your outbound connections doesn't block new inbound ones.
LAN IP address spoofing is indeed a valid attack vector, if the ISP is compromised.
Internal daemons on machines other than the router itself in the LAN network listening on 0.0.0.0 are not insecure (unless you have the problem from point 1, malicious/compromised ISP). The router won't route packets with IPs that are not in its LAN to them. Of course, the router itself could be compromised if it accidentally listens on 0.0.0.0 and accepts malicious packets.
Not sure what you mean by reflection amplification attacks, but unless they are attacking the router itself, or they are arriving on WAN with LAN IPs (again, compromised/malicious ISP), I don't see how they would reach LAN machines.
Whichever machine has the NAT's external IP assigned to it will accept or refuse the connection, depending on whether they have a server running on that port or not.
The machine that has the NAT's external IP to it is, well, the NAT, by definition. So you admit that the NAT box will act almost exactly like a connection tracking firewall, even if only NAT is enabled.
No, I'm not going to "admit" that, because I know full well that it won't.
It's not like I'm sat here thinking "I know it does block traffic, but I'm going to lie to everyone that it won't". NAT in fact, actually, really and honestly, doesn't block traffic, and I think I've been pretty consistent in saying as much.
You've been consistently wrong, yes. A NAT router box will NOT translate a packet coming from the Internet (so, a packet with a globally routable IPv4 address) arriving on its WAN to the RFC1918 IPv4 address of any box sitting behind it on the LAN side, unless it is arriving on a previously open connection, or on a port the user explicitly asked to be allowed and forwarded - exactly the same behavior of a regular stateful firewall.
Of course it won't do that -- when did I ever claim it would? But that's not the same behavior as a stateful firewall at all.
A stateful firewall would block packets addressed to the router, or to machines behind it. NAT not translating a packet won't do either of those things.
I can only repeat myself: you are talking about the NAT module in the Linux netfilter. I, and the RFC, are talking about NAT as a concept: what behavior do you expect when you say "this device does NAT". Of course you can still have "pure NAT", but if someone tells you "set up a device that does NAT" and you omit that first line and later explain that this is historically and technically accurate, well, good luck with that.
All the Linux routers I've used utilize Endpoint-Independent mapping with Address- and Port-Dependent _filtering_.
This means you can still establish direct P2P connectivity behind a Linux-based NAT device with users behind other Linux-based NAT devices. The only time it becomes an issue is when attempting to communicate with users behind NAT devices that do Address-Dependent _mapping_ or Address and Port-Dependent _mapping_. Some *BSD-based NAT implementations are this way.
Endpoint-independent _filtering_ is only a good idea for CGNAT implementations. Having an EIM/EIF NAT/firewall setup without additional firewalling makes it possible and easy for devices to run public-facing UDP-based servers without anyone's knowledge. With EIM/EIF, once you create a NAT mapping, so long as you send out periodic keepalives, _any_ IP address with _any_ source port can make unsolicited connections to a server that the NAT mapping points to. The best compromise is Endpoint-independent mapping with Address- (but not port-) dependent filtering.
> Of course, ipv6 is not less secure because it doesn't have NAT, as the same filtering behavior can be replicated with a firewall. That may even have advantages over NAT.
I don't think this follows - defaults matter after all. More precise would be to say that IPv6 setups can be as secure as IPv4 setups.
That whole section is talking about outbound connections:
When an internal endpoint opens an outgoing session through a NAT,
the NAT assigns a filtering rule for the mapping between an internal
IP:port (X:x) and external IP:port (Y:y) tuple.
When you connect outwards, the NAT creates a state table entry which matches inbound packets corresponding to that outbound connection, and this section is discussing which packets will match those entries.
Don't get distracted by its use of the word "filtering". It's not talking about unsolicited inbound connections, which is what we're talking about in this thread.
> That whole section is talking about outbound connections
Erm... no? Immediately after the paragraph you cited, it continues with
The key behavior to describe is what criteria are used by the NAT to
filter packets originating from specific external endpoints.
and then, on "Address-Dependent Filtering", it says
Additionally, the NAT will filter out packets
from Y:y destined for the internal endpoint X:x if X:x has not
sent packets to Y:any previously [...]. In other words, for receiving packets from a
specific external endpoint, it is necessary for the internal
endpoint to send packets first to that specific external
endpoint's IP address.
Meaning: unsolicited inbound connections will be filtered out.
And if I think back to my 30 years of IT, environments with NAT end up with lazy engineering from systems and application folks. It doesn't provide an environment that forces folks to understand their problems holistically. Thus, relying on perimeter firewalling and NAT as a large catch all. It's a bad security practice imo
The correct way is hard. You either have to manage firewalls on each host, or your switches need to have firewalls (I assume that’s a thing?). Hosts on the same subnet never hit layer 3 so IP-based firewalls don’t see them.
You either need very static infrastructure so you can hard-code firewalls on the hosts, or you need a system to dynamically manage the firewalls on each host, or an SDN that can sanely manage layer 2 flows. Little things like moving an app to a new server become a whole project unless you have really good tools to reconfigure the firewalls on everything that touches the app.
Then you need a way to let people self-service those rules or else security has to be involved in like everything just to do firewall rules.
It’s a good idea, but a huge pain and I’ve not seen good solutions
That's why I like mesh overlay networks (things like Tailscale, Nebula, etc.). You can largely set host firewalls to deny all, and access services over the overlay network which is software defined and more easily managed and deployed at scale.
It doesn't solve all problems, but its a good start, and modern MDMs & Group Policy (on the Windows side) make managing host firewalls easy enough.
It doesn't solve your self-service problem, though I'd argue self-service when it comes to host firewalls or otherwise shouldn't be a thing anyway.
Yep, rfc19188 addressing leads to accumulating complexity due to workarounds (end-to-end addressing is simple, there are very good reasons for that design), addressing ambiguity, and various practical security problems.
I think you're on my side in this discussion, but I have to say you can't really point at an RFC and say it settles an argument; RFCs can also be wrong about stuff, and the further you get from bits laid out on the wire, the less trustworthy they are.
> you can't really point at an RFC and say it settles an argument
This is pretty much the opposite of what I'm doing. I'm saying: look at that RFC, where they write that NAT filters incoming traffic! If even people writing RFCs say this, it is obviously an established notion of the term "NAT".
What I'm arguing against is this obsession with being technically correct; that NAT can only be literally "network address translation" and nothing else, and that you are incompetent if you think otherwise (plenty of examples for this further down).
What I'm saying is: look, things in the real world are messy, and terms can change their meaning.
I see this backwards. If my machine is only secure because of the magical firewall that practically blocks everything, then it isn't really secure, especially in a world were so many devices make it physically past the NAT and can be compromised by looking at old CVEs
If you really feel you must have NAT, there is IPv6 NAT. Unlike IPv4 NAT, V6 affords enough address space that IPv6 NAT can do 1:1 IP:IP mapping between internal and external. This eliminates entire classes of issues around port exhaustion and port remapping and allows P2P applications to work fine. P2P NAT traversal with simple 1:1 NAT has a nearly 100% success rate on the first attempt.
It's scary how many supposed hackers have never even looked up an RFC before making grandiose statements. There is such a thing as "NAT filtering", see RFC 4787, section 5: https://datatracker.ietf.org/doc/html/rfc4787#section-5
A NAT is not a firewall, yes. At the same time, the NAT boxes out there in the wild absolutely do filter traffic, and yes, it is the NAT that does it, not a separate firewall. Practically all NAT boxes in the wild do stateful filtering. It is not really standardized how they do it, but this is how the real world often works. People argue that the filtering part of NAT is "actually a firewall", but what's the point? From the outside, you will not be able to tell if there's a firewall that filters traffic for which no established connection can be found, or if this is done by a NAT.
Many people are so fixated on the definition that NAT is only address translation and nothing else, they refuse to interact with the real world out there.
'Baba is you' is one of the greatest puzzle games ever. The sheer amount of levels and variations is just staggering, although I must say that it absolutely does become quite frustrating at the end, and you can see from achievements that very few people actually stick with the game. While 8% have technically "beaten" it on Steam, you can get that achievement quite early. I have given up after about 60 hours with the game, because it simply stopped being fun, but I still recommend this gem to anyone, just don't be a completionist...
EDIT: Just looked up at 'time to beat' that completionist average is 48h and now I feel very stupid... I find that kind of hard to believe, there were some levels I literally spend 2 hours on, and the full game has over 200 levels... (and I would guess at least 10% of those are very hard).
reply