Systems with mod_perl (or just Perl allowing normal CGI) installed, especially shared hosting was so common as to be the norm in the late 90s and early 00s.
I think instead the biggest reason PHP took off was it had far less deployment friction and better aesthetics than Perl did on machines where you didn't have admin access, basically ever shared web hosting ever.
Typically CGI scripts on shared hosting were limited to explicit cgi-bin directories that had +ExecCGI. At the same time hosts would often not enable mod_rewrite because it could get computationally expensive on hardware of the era.
This all meant that all your dynamic content had to live at some "/cgi-bin/" path. It could be difficult to have a main landing page be dynamic without an empty index HTML just having an HTTP-Refresh meta tag to your "/cgi-bin/" path.
Contrast with PHP which would be processed from any directory path and was its own built-in templating language. It was also usually included in the DirectoryIndex list so an index.php would act as a directory index leading to cleaner URLs.
In the era when deployment mean MPUT in an FTP client those small differences made a difference for people trying to make their first dynamic website and look "professional".
The cult of RTFM is so painful to interact with and off putting. The concept is sound, reading documentation is important. However simply responding to all questions with "RTFM" is not only not helpful but as often as not useless advice.
The documentation for something may not exist, may not be clear, or may just be wrong. Unless you specifically know the answer to a question is laid out clearly in the documentation, blindly telling someone to read the documentation is just being a dismissive asshole.
A much more productive and helpful response is "did you RTFM?" or "check section X of the manual". But those sorts of questions require the desire to not be a dismissive asshole.
The cult of RTFM has always been an impediment to Linux becoming more popular. When I was first learning Linux...almost thirty years ago now...the cult of RTFM nearly put me off the whole endeavor. I was asking for help with "Xwindows" on IRC and the responses were either RTFM (which I had done) or pedant diatribes about "it's X, not Xwindows newbie! It's not micro$oft!" Which was a super fun to deal with. The experience steeled my resolve to at least ask someone if they read the manual before assholishly telling them to do so.
Hey XML is ucky, we wouldn't want to just serve it directly and let XSL "hydrate" it in the native browser engine. It's a way better idea to download Doom 2 worth of JavaScript and use a data serialization format without built-in schema validation.
Why get all that capability for inside a native browser engine? We should reinvent all of it to run as JavaScript!
> But ChatGPT doesn't have that problem because you can see and "discuss" the buying decisions.
If OpenAI is accepting money from advertisers to push products then ChatGPT is just a salesman. You won't be having "discussions" you'll be actively sold stuff at all times. What an awful yet banal dystopia.
USB-C is a worse mechanical connector for a device plugged in thousands of times over its lifetime. The female port of a USB-C connector has a relatively fragile center blade. Lightning's layout was the opposite which makes it more robust and easier to clean.
> USB-C is a worse mechanical connector for a device plugged in thousands of times over its lifetime.
USB-C connectors are usually rated for 10k cycles. Do you have any evidence that lighting connectors are rated for more cycles than that?
> The female port of a USB-C connector has a relatively fragile center blade. Lightning's layout was the opposite which makes it more robust and easier to clean.
This is very weak a priori arguing. I could just as well argue that USB-C has the center blade shielded instead of exposed and so is more durable.
Unless you have some empirical evidence on this I don't see a strong argument for better durability from either connector.
I did wind up replacing the USB C ports on a 4 year old computer recently because it was dodgy as hell. When i got it under the microscope it the longer bus power pin contacts (and one or two of the others) had been badly worn/squished/stretched in a way that I guess was causing them to bridge to other pins. I assume some USB-C cable had some gunk in the connector which was hard enough to damage the contacts on the center blade, and the user didn't notice (because how often do you look into the end of your USB-C cable?). It probably presented as a cable that wasn't seating right or didn't go all the way in and whatever was inside probably fell out when it was removed and they tried again.
And for what it's worth, damage to the center blade does seem to be a common failure mode for USB-C and mini-usb connectors. Less frequent for something like HDMI but it does seem to happen from time to time. Lightning never felt like it locked in as securely as USB connectors do, but at the same time, every time I saw a damaged lightning connector it was always on the male (and therefore usually cheaper accessory) side.
I've had multiple USB-C chargers broken like this.
Now, admittedly, "being yanked by a robot vacuum and falling on the ground" is outside the design parameters for a port; but I absolutely had USB-C ports fail in a way that Lightning would have not.
(Not the person you're replying to, but also a "Lightning was a better physical connector than USB-C" weirdo.)
I have seen multiple USB-C ports break on Lenovo and HP laptops. About 1 in every 50 laptops over the span of 2-3 years. I don't know if it was the users fault or a manufacturing issue. But the manufacturers fixed these under the extended warranty.
It might be an issue with the USB-C port used in these laptops since the ports on MacBooks feel less wobbly to me. But in the end this is just speculation and anecdotal.
At the same time, if the springs on the iPhone-side connector loosen and can't hold onto the cable, you have to replace the whole phone and not just the cable.
So Apple had to use pretty strong springs, resulting in a lot of friction on the pins. That made them easier to damage, so they had to switch from gold to a crazy super-resistant rhodium-based alloy for contact coating.
My Pixel 8 certainly hasn't gone through 10k cycles and it barely holds on to any USB-C connector I put inside it. They all fall out even when laying still on a flat surface.
There's always outliers, of course, but I had this issue with USB Micro-B on at least one other device and never saw it with a Lightning connector.
I find it's often lint in the USB-C port. Cleaning it out with a non-conductive tool like a toothpick or a dry toothbrush usually solves it for me when that happenens.
I've had dozens of devices with USB-C. I've yet to have even a single one that had any problems with them. To be fair, I'm using iPhones mostly for app testing, so I also had very few issues with them.
Your Pixel 8 could be about two years old. The connector performed way under spec and you should send it in for repair (assuming your are in a country with a 2 year warranty period)
This is probably lint buildup. You can scrape it out with any thin and stiff object like a safety pin.
A small amount of lint gets into the hole. You pack it in when you plug in the cable. Repeat a thousand times and now you have a stiff “plug” of lint that prevents the connector from fully entering your device.
My experience is that plugs from the same manufacturer as the device tend to keep holding tightly, but mixing makers is unreliable. Apple plugs in particular tend to slide out of my samsung phone really easily. I guess whoever speced usbc didn't bother with the details of how it would stay in, and every manufacturer figured out their own solution.
The 10K cycle insertion rating for USB-C is an idealized metric that does not include lateral force, torque, device movement, or real-world wear patterns. These non-axial forces are a known cause of USB-C port failures and are explicitly not accounted for in the standard 10k-cycle durability claim.
USB-C center tongue female design means that the port will break before the cable. With lightning, the cable plug takes all the stress.
Apple doesn’t publish insertion cycles rating for Lightning connectors, so it’s impossible to provide empirical evidence of that.
In my personal experience, I’ve had two USB-C ports go bad on two MacBooks. I’ve yet to own a USB-C-charging phone, but I’ve never had a Lightning port fail.
> These non-axial forces are a known cause of USB-C port failures and are explicitly not accounted for in the standard 10k-cycle durability claim.
I agree and that's par for the course for any standard, they have to limit the requirements to something that is economically manufacutrable and testable.
Meanwhile, lightning connectors have no public standard to speak of so this is a mute point.
> USB-C center tongue female design means that the port will break before the cable. With lightning, the cable plug takes all the stress.
This is another a priori armchair expert argument which I just put very little weight on without data to back it up.
> Apple doesn’t publish insertion cycles rating for Lightning connectors, so it’s impossible to provide empirical evidence of that.
That conclusion does not follow. We can still obtain empirical evidence through direct testing without Apple publishing anything.
> In my personal experience, I’ve had two USB-C ports go bad on two MacBooks. I’ve yet to own a USB-C-charging phone, but I’ve never had a Lightning port fail.
That's fair, everyone has different anecdotal experiences as a foundation for their opinion here. The problem is that anecdotal data is just not very informative to others, that's all.
> USB-C center tongue female design means that the port will break before the cable. With lightning, the cable plug takes all the stress.
Are you sure it's the center tongue which takes all the stress, and not the round shell?
AFAIK, USB-C is designed so that the cable breaks before the port, because the parts which wear the most with use (the contact and retention springs) are in the cable, not on the device.
Incorrect. You want springy bits on part that is easily replaceable - the cable. USB-C does that, the springy bits are in the connector, not the socket.
My phone is now 6 years old, zero problems on usb-c connector
In all seriousness mod_php killed Perl, or at least struck the fatal blow. In the late 90s I wanted to make dynamic web content, just simple CRUD stuff. The most reliable way to do this was Perl. As long as your hash bang and permissions were correct you could drop a script in a cgi-bin directory and it would work. It didn't matter if the server was Solaris, Linux, or some other Unix. Most hosts that supported Perl also at least had the CGI module installed as well.
It was worth fighting with Perl's syntax because it was the best option for web programming (for random amateurs like myself). Web hosts often didn't have C compilers available so C wasn't an option. TCL was workable but not as prevalent as Perl on web hosts. Same with PHP3. Keep in mind this was an era where you were deploying on machines you didn't on which you didn't have admin access. Most of the time you didn't have shell access on machines you'd deploy on.
As Linux adoption on servers exploded so did the deployment of PHP. It was easy to deploy PHP web apps since they could be readily dropped in your htdocs or public_html directory and be handled by the server. Enabling other CGI outside cgi-bin directories was uncommon.
So by 2000 or so there was no reason to learn Perl to do web stuff easily. You could do it in PHP which was already a templating language. The younger version of me that wanted to do web CRUD stuff bought a PHP book instead of a Perl book. With Python 2's release at that same time if you wanted to do portable non-web stuff you had a much nicer language than Perl available as well.
People use CloudFlare because it's a "free" way for most sites to not get exploited (WAF) or DDoSed (CDN/proxy) regularly. A DDoS can cost quite a bit more than a day of downtime, even just a thundering herd of legitimate users can explode an egress bill.
It sucks there's not more competition in this space but CloudFlare isn't widely used for no reason.
AWS also solves real problems people have. Maintaining infrastructure is expensive as is hardware service and maintenance. Redundancy is even harder and more expensive. You can run a fairly inexpensive and performant system on AWS for years for the cost of a single co-located server.
You're using confusing terminology so you look very wrong. What you mean to say is direct modem-to-modem connections were not laggy because there was no packet switching. This is a true statement.
What the GP comment was talking about was dial-up Internet being most people's exposure to TCP/IP gaming in the 90s. That was most assuredly laggy. Even the best dial-up Internet connections had at least 100ms of latency just from buffering in the modems.
The QuakeWorld network stack was built to handle the high latency and jitter of dial-up Internet connections. The original Quake's network was fine on a LAN or fast Internet connection (e.g. a dorm ResNet) but was sub-par on dial-up.
I think instead the biggest reason PHP took off was it had far less deployment friction and better aesthetics than Perl did on machines where you didn't have admin access, basically ever shared web hosting ever.
Typically CGI scripts on shared hosting were limited to explicit cgi-bin directories that had +ExecCGI. At the same time hosts would often not enable mod_rewrite because it could get computationally expensive on hardware of the era.
This all meant that all your dynamic content had to live at some "/cgi-bin/" path. It could be difficult to have a main landing page be dynamic without an empty index HTML just having an HTTP-Refresh meta tag to your "/cgi-bin/" path.
Contrast with PHP which would be processed from any directory path and was its own built-in templating language. It was also usually included in the DirectoryIndex list so an index.php would act as a directory index leading to cleaner URLs.
In the era when deployment mean MPUT in an FTP client those small differences made a difference for people trying to make their first dynamic website and look "professional".
reply