You're conflating "predictable" with "reproducible".
"Predictable" assumes there is an observer making a guess, but we all live by the knowledge that our assumptions may be wrong. We care less about that, and more about whether the system behaves consistently.
Consistent behavior is either a bug or a feature depending on what was expected. The system just is, man, and that's what we need.
"Nobody sits like this rock sits. You rock, rock. The rock just sits and is. You show us how to just sit here and that's what we need."
Maybe I'm pulling at a fake distinction here but the progenitor blog posts of this format that I'm thinking of were incorrect models of constructs that almost everyone uses in their everyday life constantly ( names, dates, time etc )
Whereas I find it kinda unlikely that someone both knows what a DHCP server is, and holds a belief that there is only ever exactly one on their network?
Hmmm, In my experience programmers are often not particularly good at networking, and this can result in all kinds of bad assumptions (or awkward workarounds for things that could be much better solved at the network level).
Port- or Client-isolation on Ethernet switches and Wi-Fi access points respectively. Often seen in corporate environments and (properly configured) guest networks.
There are recent "client isolation" features that prevent P2P communication. Some hosting providers also block customers on the same LAN from attacking each other.
Did arp poisoning in school and used a tool to show images from websites people visited on the projector. Teacher thought it was fun until someone went to goatse.
Switches and firewalls can do all kinds of things. Probably the most common case is that public/guest wifi networks often have client isolation set up so that different devices on the network can't contact each other. Same subnet, but only access to the gateway and the internet in practice.
(Also can happen if ARP is not working correctly, which can be a right PITA to debug).
Most consumer wifi routers I’ve used have a setting to prevent peer-to-peer traffic. Whether this still counts as being on the same subnet is kind of a philosophical question.
An IP subnet is just a block of addresses anyway. Any two addresses both are and are not in the same block, depending on how big of a block you choose.
I get the idea, but this isn't necessarily useful as advice and toys with definitions. It's ESPN levels of conversation-baiting. Lots of assumptions can be reasonably made about residential LANs without being true of enterprise LANs/DMZs.
If a residential LAN is RFC1918 and has no NAT, then it is still a LAN... without internet access.
Then the "A & !A" fallacy of "MAC addresses can’t be changed. MAC addresses can be changed."
Just kind of a mess. Would be more interesting to explore the edge cases rather than throw out half-truths and 0.05% instances.
In theory it's fine to have multiple DHCP servers as long as they don't step on each other. But in reality a bunch of the things mentioned in this post are ways for the network to be hosed. Unfortunately, enough LANs are semi-hosed that it's worth working around known problems.
At work I manage a network with two DHCP servers. One is a dnsmasq that assigns the IP address, hostname, and basic network parameters to all network devices, and the other is a LTSP server (https://ltsp.org/) that provides network boot images only for certain devices that require it. It might not look pretty, but it works really well.
What really matters is that there's a coherent policy for assigning addresses, which is absolutely compatible with having multiple DHCP servers on the same subnet (e.g. each server configured to hand out non-overlapping IP ranges).
It's less about the IP ranges they're giving out not overlapping and more about the requests that they respond to not overlapping (or at least that they don't contradict one another). The classic 'someone plugged a consumer wifi router into the office/university network' problem often is made worse because the consumer wifi router gives out different addresses.
You don’t have to have one. My first LAN didn’t. I had no idea what I was doing and picked 17.0.0.0 addresses for local ones and I couldn’t connect to Apples website.
I've never heard of a LAN without IP addresses. Is that a thing? I'd assume that no IP addresses means you can't even use TCP/IP at all, right? Is there something else you'd use instead?
You can send packets over Ethernet, without IP. That's what people did before IP was invented and took over most networked communication. It's less convenient, because you can't reuse the IP stack, so almost nobody does.
Ethernet uses frames, not packets. A falsehood that programmers believe about networking is that everything is a packet. In fact, the "PDU" or protocol data unit for each OSI layer is defined and named differently.
So Ethernet communicates with frames. You can simply send frames across a purely Ethernet network. Or, you can take a PDU from an upper layer, encapsulate it as Ethernet frame, and send it across. Most LAN protocols are flexible like that.
A falsehood networkers believe about programming is that you have to call things what the relevant standard calls them, and you have to obey all the random differences that come from different people writing the different standards. IP packets and Ethernet packets aren't the same thing, but IP packets and IP frames are the same thing, because packets and frames are the same thing.
I suspect recentish versions of Windows still have the driver available, just not installed by default.
However the article is about falsehoods programmers believe about LANs. If you are writing some kind of driver and assume all traffic you receive is IP traffic and don't verify the header, you are going to have a bad time.
Falsehood People Believe about Programmers:
Programmers think the models they use are perfect.
Mostly programmers think a system will act predictably given the same inputs. Most of computing doesn't work without that assumption.
You're conflating "predictable" with "reproducible".
"Predictable" assumes there is an observer making a guess, but we all live by the knowledge that our assumptions may be wrong. We care less about that, and more about whether the system behaves consistently.
Consistent behavior is either a bug or a feature depending on what was expected. The system just is, man, and that's what we need.
"Nobody sits like this rock sits. You rock, rock. The rock just sits and is. You show us how to just sit here and that's what we need."
I’d say this one is frequently true, and is one of the things that distinguishes senior from junior programmers.
Programmers certainly believe that, but they quickly learn not to.
Unfortunately there are also (senior) programmers who believe that their model is correct and it’s the reality (spec, client, user, etc) that’s wrong.
Let’s be clear though: all of those other things are probably wrong too.
This feels like a bastardization of the already questionable "Falsehoods ___ believe about ___" format.
How so? It's pretty within the format IMO.
Maybe I'm pulling at a fake distinction here but the progenitor blog posts of this format that I'm thinking of were incorrect models of constructs that almost everyone uses in their everyday life constantly ( names, dates, time etc )
Whereas I find it kinda unlikely that someone both knows what a DHCP server is, and holds a belief that there is only ever exactly one on their network?
Hmmm, In my experience programmers are often not particularly good at networking, and this can result in all kinds of bad assumptions (or awkward workarounds for things that could be much better solved at the network level).
Falsehoods Programmers Believe about Weblog Posts
That format is considered harmful.
* there is something called a LAN
* two people who say they are on the same LAN agree on what the LAN is
This just lists every possible configuration permutation. Nothing insightful here.
>Two hosts on the same subnet can reach each other without leaving the LAN.
Barring "very buggy software," when is this false?
Port- or Client-isolation on Ethernet switches and Wi-Fi access points respectively. Often seen in corporate environments and (properly configured) guest networks.
I feel like the point of those is conceptually "take these things off the LAN." If we allow for that, what even is a LAN?
You are correct. It explicitly breaks the LAN, does not provide a LAN, only an internet gateway in most cases.
There are recent "client isolation" features that prevent P2P communication. Some hosting providers also block customers on the same LAN from attacking each other.
Indeed. You might share a subnet with other customers of your ISP, but your ISP probably doesn't let you ARP poison them.
This isn't even that recent. I remember doing ARP poisoning exactly once and then being surprised that it didn't work everywhere.
I think the falsehood here is that same IPv4 subnet = same link layer network, but that doesn't have to be the case.
Did arp poisoning in school and used a tool to show images from websites people visited on the projector. Teacher thought it was fun until someone went to goatse.
Indeed. You might share a subnet with other customers of your ISP, but your ISP probably doesn't let you ARP poison them.
This isn't even that recent. I remember doing ARP poisoning exactly once and then being surprised that it didn't work everywhere.
Switches and firewalls can do all kinds of things. Probably the most common case is that public/guest wifi networks often have client isolation set up so that different devices on the network can't contact each other. Same subnet, but only access to the gateway and the internet in practice.
(Also can happen if ARP is not working correctly, which can be a right PITA to debug).
LAN spread across sites with a WAN in the middle of it. But that's why I said in my comment that a LAN isn't actually a real thing.
I feel like the better of this is maybe "will" instead of "can"
Yeah… I feel like “falsehoods X believe about Y” need to omit anything a reasonable X would consider to be a bug.
Edit: fair point. Maybe not.
I think generally the point of the phrasing is to make you stop considering it a bug,
Falsehoods programmers believe about programming: you don’t have to work around other people’s bugs.
It might not be your fault but it sure as hell will be your problem.
Most consumer wifi routers I’ve used have a setting to prevent peer-to-peer traffic. Whether this still counts as being on the same subnet is kind of a philosophical question.
An IP subnet is just a block of addresses anyway. Any two addresses both are and are not in the same block, depending on how big of a block you choose.
Some tunnel that extends the subnet somewhere else. Guess it depends on how you define lan.
VPNs
I read that like the meme:
<guy with messy hair>Aliens</guy with messy hair>
I get the idea, but this isn't necessarily useful as advice and toys with definitions. It's ESPN levels of conversation-baiting. Lots of assumptions can be reasonably made about residential LANs without being true of enterprise LANs/DMZs.
If a residential LAN is RFC1918 and has no NAT, then it is still a LAN... without internet access.
Then the "A & !A" fallacy of "MAC addresses can’t be changed. MAC addresses can be changed."
Just kind of a mess. Would be more interesting to explore the edge cases rather than throw out half-truths and 0.05% instances.
I like the GNOME 2006 era though.
Read it as chain of thoughts not as a list
Both A and !A can be fallacies if sometimes A.
The biggest fallacy here, though, and not stated, is that "LAN" is a meaningful concept.
> There is one DHCP server.
There'd better be or your network is probably hosed.
In theory it's fine to have multiple DHCP servers as long as they don't step on each other. But in reality a bunch of the things mentioned in this post are ways for the network to be hosed. Unfortunately, enough LANs are semi-hosed that it's worth working around known problems.
At work I manage a network with two DHCP servers. One is a dnsmasq that assigns the IP address, hostname, and basic network parameters to all network devices, and the other is a LTSP server (https://ltsp.org/) that provides network boot images only for certain devices that require it. It might not look pretty, but it works really well.
https://datatracker.ietf.org/doc/html/draft-ietf-dhc-failove...
What really matters is that there's a coherent policy for assigning addresses, which is absolutely compatible with having multiple DHCP servers on the same subnet (e.g. each server configured to hand out non-overlapping IP ranges).
It's less about the IP ranges they're giving out not overlapping and more about the requests that they respond to not overlapping (or at least that they don't contradict one another). The classic 'someone plugged a consumer wifi router into the office/university network' problem often is made worse because the consumer wifi router gives out different addresses.
Windows supports dhcp failover, where multiple dhcp servers can exist on the same subnet.
Well, consumer Windowses (XP Home? It’s been a while) used to hose networks because they were "helpfully" running their own DHCP server.
You don’t have to have one. My first LAN didn’t. I had no idea what I was doing and picked 17.0.0.0 addresses for local ones and I couldn’t connect to Apples website.
That works mostly, you'll have problems if you have duplicate IP addresses though.
> My LAN uses IP addresses.
I've never heard of a LAN without IP addresses. Is that a thing? I'd assume that no IP addresses means you can't even use TCP/IP at all, right? Is there something else you'd use instead?
You can send packets over Ethernet, without IP. That's what people did before IP was invented and took over most networked communication. It's less convenient, because you can't reuse the IP stack, so almost nobody does.
Ethernet uses frames, not packets. A falsehood that programmers believe about networking is that everything is a packet. In fact, the "PDU" or protocol data unit for each OSI layer is defined and named differently.
So Ethernet communicates with frames. You can simply send frames across a purely Ethernet network. Or, you can take a PDU from an upper layer, encapsulate it as Ethernet frame, and send it across. Most LAN protocols are flexible like that.
https://en.wikipedia.org/wiki/Frame_(networking)
https://en.wikipedia.org/wiki/Network_packet
https://en.wikipedia.org/wiki/Protocol_data_unit#Internet_pr...
And TFA provides a list of upper-layer protocols that may be encountered on a LAN today: "IP, IPX/SPX, Phase IV, AppleTalk, VINES, NetBEUI, or SNA".
NetBIOS and NetBEUI are particularly interesting here, because NetBIOS Frames did use IEEE 802.2 LLC, while NBT uses TCP/IP for NetBIOS transport.
https://en.wikipedia.org/wiki/NetBIOS
A falsehood networkers believe about programming is that you have to call things what the relevant standard calls them, and you have to obey all the random differences that come from different people writing the different standards. IP packets and Ethernet packets aren't the same thing, but IP packets and IP frames are the same thing, because packets and frames are the same thing.
Quite common to run unnumbered IS-IS backbones. Whether this can rightfully be considered a "LAN" is up for debate.
IPX/SPX is not IP based.
Can that still be used from modern operating systems? Maybe only Linux?
I suspect recentish versions of Windows still have the driver available, just not installed by default.
However the article is about falsehoods programmers believe about LANs. If you are writing some kind of driver and assume all traffic you receive is IP traffic and don't verify the header, you are going to have a bad time.
Nothing burger of a post
[dead]