Does PHP Have A Future, Or Are Twenty Five Years Enough?

In June, 1995, Rasmus Lerdorf made an announcement on a Usenet group. You can still read it.

Today, twenty five years on, PHP is about as ubiquitous as it could possibly have become. I’d be willing to bet that for the majority of readers of this article, their first forays into web programming involved PHP.

Announcing the Personal Home Page Tools (PHP Tools) version 1.0.

These tools are a set of small tight cgi binaries written in C.

But no matter what rich history and wide userbase PHP holds, that’s no justification for its use in a landscape that is rapidly evolving. Whilst PHP will inevitably be around for years to come in existing applications, does it have a future in new sites?

Continue reading “Does PHP Have A Future, Or Are Twenty Five Years Enough?”

What’s The Deal With Snap Packages?

Who would have thought that software packaging software would cause such a hubbub? But such is the case with snap. Developed by Canonical as a faster and easier way to get the latest versions of software installed on Ubuntu systems, the software has ended up starting a fiery debate in the larger Linux community. For the more casual user, snap is just a way to get the software they want as quickly as possible. But for users concerned with the ideology of free and open source software, it’s seen a dangerous step towards the types of proprietary “walled gardens” that may have drove them to Linux in the first place.

Perhaps the most vocal opponent of snap, and certainly the one that’s got the most media attention, is Linux Mint. In a June 1st post on the distribution’s official blog, Mint founder Clement Lefebvre made it very clear that the Ubuntu spin-off does not approve of the new package format and wouldn’t include it on base installs. Further, he announced that Mint 20 would actively block users from installing the snap framework through the package manager. It can still be installed manually, but this move is seen as a way to prevent it from being added to the system without the user’s explicit consent.

The short version of Clement’s complaint is that the snap packager installs from a proprietary Canonical-specific source. If you want to distribute snaps, you have to set up an account with Canonical and host it there. While the underlying software is still open source, the snap packager breaks with long tradition of having the distribution of the software also being open and free. This undoubtedly makes the install simple for naive users, and easier to maintain for Canonical maintainers, but it also takes away freedom of choice and diversity of package sources.

Continue reading “What’s The Deal With Snap Packages?”

Ask Hackaday: Is Our Power Grid Smart Enough To Know When There’s No Power?

Just to intensify the feeling of impending zombie apocalypse of the COVID-19 lockdown in the British countryside where I live, we had a power cut. It’s not an uncommon occurrence here at the end of a long rural power distribution network, and being prepared for a power outage is something I wrote about a few years ago. But this one was a bit larger than normal and took out much more than just our village. I feel very sorry for whichever farmer in another village managed to collide with an 11kV distribution pole.

What pops to mind for today’s article is the topic of outage monitoring. When plunged into darkness we all wonder if the power company knows about it. The most common reaction must be: “of course the power company knows the power is out, they’re the ones making it!”. But this can’t be the case as for decades, public service announcements have urge us to report power cuts right away.

In our very modern age, will the grid become smart enough to know when, and perhaps more importantly where, there are power cuts? Let’s check some background before throwing the question to you in the comments below.

Continue reading “Ask Hackaday: Is Our Power Grid Smart Enough To Know When There’s No Power?”

USB-C Is Taking Over… When, Exactly?

USB is one of the most beloved computer interfaces of all time. Developed in the mid-1990s, it undertook a slow but steady march to the top. Offering an interface with good speeds and a compact connector, it became the standard for hooking up interface devices, storage, and even became the de-facto way to talk old-school serial, too.

In late 2014, the USB Implementers Forum finalised the standard for the USB-C plug. Its first major application was on smartphones like the Nexus 5X, and it has come to dominate the smartphone market, at least if you leave aside the iPhone. However, it’s yet to truly send USB-A packing, especially on the desktop. What gives? Continue reading “USB-C Is Taking Over… When, Exactly?”

Hunting Neutrinos In The Antarctic

Neutrinos are some of the strangest particles we have encountered so far. About 100 billion of them are going through every square centimeter on Earth per second but their interaction rate is so low that they can easily zip through the entire planet. This is how they earned the popular name ‘ghost particle’. Neutrinos are part of many unsolved questions in physics. We still do not know their mass and they might even be there own anti-particles while their siblings could make up the dark matter in our Universe. In addition, they are valuable messengers from the most extreme astrophysical phenomena like supernovae, and supermassive black holes.

The neutrinos on earth have different origins: there are solar neutrinos produced in the fusion processes of our sun, atmospheric neutrinos produced by cosmic rays hitting our atmosphere, manmade reactor neutrinos created in the radioactive decays of nuclear reactors, geoneutrinos which stem from similar processes naturally occurring inside the earth, and astrophysical neutrinos produced outside of our solar system during supernovae and other extreme processes most of which are still unknown. Continue reading “Hunting Neutrinos In The Antarctic”

Loading Coils, The Heaviside Condition, And Pupin Coils

When we draw schematics, we have the luxury of pretending that wire is free. There are only a few cases where you have to account for the electrical characteristics of wire: when the wire is very long or the frequency on the wire is relatively high.

This became apparent after the first transatlantic cable went into service for telegraph communications. Even though the wire was linear, there was still distortion on the line so severe that dots and dashes would overlap each other. The temporary solution was to limit speeds so slow that operators had trouble sending and receiving at those speeds. How slow? An average character took two minutes to send! That’s not a typo. Two minutes per character. By custom, Morse code assumes a word is five characters, so you could send a word every 10 minutes.

The first transatlantic cable went into service in 1858 and was virtually the moon landing of its day. Frustrated with how slow the communications were, an electrician by the name of Whitehouse decided to crank up the voltage to over 1,000 volts which caused the cable to fail after only three weeks in service. Whoops. Later analysis showed the cable was probably going to fail quickly anyway, but Whitehouse took the public blame.

The wire back then wasn’t as good as what we have today, which led to some of the problems. The insulation was made from multiple coats of a natural latex, gutta percha, which is what dentists use to fill root canals. The jackets were made from tarred hemp and bound with iron wire. There was no way to build an underwater amplifier in 1858, so the cables were just tremendous wires laying on the ocean floor between Newfoundland and Ireland.

Continue reading “Loading Coils, The Heaviside Condition, And Pupin Coils”

Ask Hackaday: Are 80 Characters Per Line Still Reasonable In 2020?

Software developers won’t ever run out of subjects to argue and fight about. Some of them can be fundamental to a project — like choice of language or the programming paradigm to begin with. Others seem more of a personal preference at first, but can end up equally fundamental on a bigger scale — like which character to choose for indentation, where to place the curly braces, or how to handle line breaks. Latest when there’s more than one developer collaborating, it’s time to find a common agreement in form of a coding style guide, which might of course require a bit of compromise.

Regardless of taste, the worst decision is having no decision, and even if you don’t agree with a specific detail, it’s usually best to make peace with it for the benefit of uniformly formatted code. In a professional environment, a style guide was ideally worked out collaboratively inside or between teams, and input and opinions of everyone involved were taken into consideration — and if your company doesn’t have one to begin with, the best step to take is probably one towards the exit.

The situation can get a bit more complex in open source projects though, depending on the structure and size of a project. If no official style guide exists, the graceful thing to do is to simply adopt the code base’s current style when contributing to it. But larger projects that are accustomed to a multitude of random contributors will typically have one defined, which was either worked out by the core developers, or declared by its benevolent dictator for life.

In case of the Linux kernel, that’s of course [Linus Torvalds], who has recently shaken up the community with a mailing list response declaring an overly common, often even unwritten rule of code formatting as essentially obsolete: the 80-character line limitation. Considering the notoriety of his rants and crudeness, his response, which was initiated by a line break change in the submitted patch, seems downright diplomatic this time.

[Linus]’ reasoning against a continuing enforcement of 80-char line limits is primarly the fact that screens are simply big enough today to comfortably fit longer lines, even with multiple terminals (or windows) next to each other. As he puts it, the only reason to stick to the limitation is using an actual VT100, which won’t serve much use in kernel development anyway.

Allowing longer lines on the other hand would encourage the use of more verbose variable names and whitespace, which in turn would actually increase readability. Of course, all to a certain extent, and [Linus] obviously doesn’t call for abolishing line breaks altogether. But he has a point; does it really make sense to stick to a decades old, nowadays rather arbitrary-seeming limitation in 2020?

Continue reading “Ask Hackaday: Are 80 Characters Per Line Still Reasonable In 2020?”