Plus, for that other 99%, the developers probably tried out a new framework or language or something. They aren’t claiming to “know” something based on watching a YouTube vid. It wasn’t wasted time.
The kernel will figure something out. There are already lots of companies investing their own development resources into it. Would just need a new leader to emerge. Perhaps it’d be a rotating group of people who are responsible for managing a single release.
Tons of smaller but important projects don’t have this luxury, though.
Back in the day, the way it integrated with Apache was an evolutionary advantage to PHP. It found a strategy that worked in its environment and it thrived. That environment no longer exists, but PHP holds on vestigially.
We didn’t have AWS or other cheap, virtualized hosting way back when. It was all shared plans where you had a directory of your stuff, and it was there with a hundred other people on the same server and Apache instance. You could run whatever you wanted as a CGI, but that was even worse; it forks off a whole interpreter for the language, parses the code, and then used STDIN/STDOUT to communicate. Even if you implemented it in compiled C code (which had all the other problems you would expect), that fork is still expensive.
Projects like mod_perl and mod_python built an interpreter directly into Apache, but there was a problem with how it worked: it was too sophisticated. They could hook into the entire Apache API. That meant that there was no way to separate your stuff from every other thing on the same shared hosting plan. Any one instance would be able to fool around in all other accounts. That’s untenable, so your choices for those languages were to either get a dedicated plan at well over $100/month, or stick with a $5/month shared plan and put up with it being unscalable.
Enter mod_php. It builds the interpreter into Apache, but that’s all it does. Still have a parsing step, but it doesn’t have to fork. Doesn’t try do anything else. Its fast, and it can be hosted on cheap shared plans.
If you’re a startup at this time, operating on frozen pizza and office chairs from a thrift store, then you could get a cheap plan, develop it under CGI, and hope that you can refactor it later when you can afford a dedicated plan. Oh, and keep in mind that CGI doesn’t lend itself to converting easily to the Apache API or whatever else you’re going to use in the future. Alternatively, you could build it in PHP and it will be fast now and acceptable later.
It’s no great mystery why PHP was chosen at the time. There were limited options, and it was the cheap, get it done now option.
Nah, it’s historically been a special kind of shit. It started life as a Perl templating engine, then grew out to its own language where it repeated all of Perl’s mistakes while adding more of its own. Its community was single-handedly responsible for keeping SQL injection attacks in the OWASP Top 10 list for years. Notice that it’s now bundled with “injection attacks” as a generic label for a wider range of similar issues–SQL injection alone would no longer warrant being there. Its conflation of arrays and hash maps meant it took years to wrestle with algorithmic complexity attacks. Perl kept the two separate, and was able to get a patch out for algorithmic complexity almost immediately (though it turned out to have a few bugs of its own, and a true fix came in a few years later; still faster than PHP solved it).
The web from 1998 through 2010 or so was absolutely riddled with bad PHP programs. “But that’s not the language’s fault”, you say? Doesn’t matter. Community is an important and underappreciated feature of a language, and PHP had a special kind of shit community. It almost seemed designed to suck away the dross from all other communities.
Consider the plugin system for phpBB:
Its architecture doesn’t have any kind of hook system for plugins; they’re added by patching the code in place
This naturally leads to different plugins interfering with each other
Having done that, you might choose one of the patch formats already out there, but phpBB decide to create their own
There are, at first, no tools available to automatically patch in plugins, so administrators (often not developers themselves) need to hand edit the source files and modify the database (the plugin format specifies both together)
Tools start to emerge over the years to handle it automatically, but they’re buggy and unusable for a long time
Is it PHP’s fault that one major application was implemented so poorly? YES! Its community is a feature, and its community is what brought us to this.
You want to claim that the language has done better since PHP7? Alright, that’s fine. I still don’t care. There are so many better options available, and I don’t have time to keep up with all of them. I’m happy relegating PHP to being a long-tail language where it trails off slowly over the years like COBOL.
For internal communication on IPv4, everything has some unique internal IP. There are blocks reserved for private space. Usually people use 192.168.x.x or 10.x.x.x. DHCP hands it the address.
If you wanted this to work in the IPv6 world, you are assigned a prefix by your ISP, and everything is inside that prefix. Services still have to discover each other by some mechanism. Perhaps by DHCPv6, or perhaps broadcasting their existence.
Port forwarding is only necessary with NAT. If you have a gateway firewall that blocks incoming new connections by default, then you will need to open the port going to a specific device. Current home networking “routers” combine port forwarding and opening the firewall together as a convenience, but there’s no reason an IPv6 world would need to do that. UPnP can open the port the same way if you want that (though that’s a whole other security issue).
In a home networking “router”, the gateway firewall is already combined in. In fact, I’m putting the “router” in quotes because it’s really a firewall with NAT and some other services like DHCP. It doesn’t typically do things like BGP that we would normally see in a router outside of an edge network like your home. A router out there is an allow-by-default device.
Adding NAT to the gateway firewall makes the code more complicated. For example, here’s a command on Linux that activates NAT for the iptables firewall:
That “MASQUERADE” bit is handled as NAT, and iptables has to implement more code just to do that.
If we wanted to simply drop all new incoming connections, we would do:
<span style="color:#323232;">iptables -P INPUT DROP
</span><span style="color:#323232;">iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
</span>
Which tells it to drop packets by default that aren’t otherwise accepted, and then accept packets that are already part of a connection. Even with NAT, we typically want to do this, anyway, so we’re not making things any easier with NAT.
If we want to add a service listening on port 80 for host 10.0.0.5, we would do:
Which translates the stuff coming in from outside to port 80 to 10.0.0.5 on the same port, and then also translates replies going back the other way. And I might be getting some of the commands wrong, because it’s been a while since I’ve had to configure this.
Suffice it to say, dropping NAT greatly simplifies firewall rules. Your home router is still doing all this (many of them are just Linux iptables these days), but it’s hiding the details from you.
Edit: This doesn’t cover how protocols have been designed to work around NAT, and has resulted in a more centralized Internet that’s easier to spy on. That’s a whole other problem that is hidden from most people.
The US started phasing in roof crush requirements in 2012, which caused manufacturers to put in more metal for the frame. That meant reducing visibility and all but requiring backup cameras.
Why do we need roof crush requirements? Because those SUVs have a high center of gravity.
This has been the way of things. Cars are just plain unsafe, and trying to make them safe also makes them worse at everything else, including being affordable.
IPv6 has DHCP, but it doesn’t work like that. You generally get a prefix and other details about the network, like the gateway address and DNS, and autoconfiguration based on the MAC address does the rest. It was first hoped that DHCP wouldn’t be needed at all for IPv6, but it turned out to be still useful. There’s some more complications here, but suffice it to say that you shouldn’t try to take your knowledge of IPv4 and try to map it on top of IPv6. They’re separate beasts.
A gateway can block incoming traffic to the whole internal network if you want. It doesn’t need NAT to do that.
Because hiding addresses does very little. A gateway firewall does not need NAT to protect devices behind it.
In fact, NAT tends to make things more complicated, and complication is the enemy of security. It’s one extra thing that firewalls have to account for. Firewalls behind NAT also don’t know where traffic is originally coming from, meaning they have one less tool at their disposal. This gets even worse with CGNAT, which sometimes has multiple levels of NAT.
Security is a very common objection to getting rid of NAT, and it’s wrong.
Output quality is a reason. Even if you have headphone jack, it’s usually built as cheaply as possible. Granted, Bluetooth headsets can be OK these days.
Come to think of it, do Bluetooth headphones only use class D amplifiers? Seems like it’d be hard to fit any kind of decent class AB amp in there. Class D amps have improved a lot in recent years, but you still want to use an AB if you’re serious (not even audiophile nonsense, just somewhat serious).
I think there’s a distinction to be made between being a fan and being a fanboi. I like AMD, but I also know Bulldozer was a disaster, the GPU division tends to over promise and under deliver, and their marketing and naming is covered in self-inflected wounds. Then there’s people who bought the AMD-branded mountain bike, a cheap Chinese bike with some vinyl AMD logo stickers slapped on with a $300 markup, and I don’t get those people at all.
IIRC, France exports its excess nuclear power in the summer (little need for AC until recently), but imports during the winter (electric heat for the most part). Mostly to and from Germany, which uses some terribly dirty sources. Don’t know if that’s changed in the last few years, though.
Flip it around and look from the ISP’s point of view. Once fiber is connected to a house, there are few good reasons to use anything else. Whomever is the first to deploy it wins.
Now look at it from a monopoly ISP’s point of view. You’re providing 100Mbps service on some form of copper wire, and you’re quite comfortable leaving things like that. No reason to invest in new equipment beyond regular maintenance cycles. If some outside company tries to start deploying fiber, and if they start to make inroads, you’re going to have to (gasp) spend hundreds of millions on capital outlays to compete with them. Better to spend a few million making sure the city never allows them in.