Hackaday Links: June 21, 2020

June 21, 2020 by Dan Maloney 19 Comments

When Lego introduced its Mindstorms line in 1998, in a lot of ways it was like a gateway drug into the world of STEM, even though that term wouldn’t be invented for another couple of years. Children and the obsolete children who begat them drooled over the possibility of combining the Lego building system with motors, sensors, and a real computer that was far and away beyond anything that was available at the time. Mindstorms became hugely influential in the early maker scene and was slowly but steadily updated over the decades, culminating with the recently released Mindstorms Robot Inventor kit. In the thirteen years since the last release, a lot has changed in the market, and we Hackaday scribes had a discussion this week about the continued relevancy of Mindstorms in a time when cheap servos, microcontrollers, and a bewildering array of sensors can be had for pennies. We wonder what the readers think: is a kit that burns a $360 hole in your pocket still worth it? Sound off below.

Are you looking for a way to productively fill some spare time? Plenty of people are these days, and Hackaday has quite a deal for them: Hackaday U! This series of online courses will get you up to speed on a wide range of topics, starting tomorrow with Matthew Alt’s course on reverse engineering with Ghidra. Classes meet online once a week for four weeks, with virtual office hours to help you master the topic. Beside reverse engineering, you can learn about KiCad and FreeCad, quantum computing, real-time processing of audio and sensor data, and later in the year, basic circuit theory. We’ve got other courses lined up to fill out the year, but don’t wait — sign up now! Oh, and the best part? It’s on a pay-as-you-wish basis, with all proceeds going to charity. Get smarter, help others while doing it — what’s not to love about that?

Speaking of virtual learning, the GNU Radio Conference will be moving online for its 10th anniversary year. And while it’s good news that this and other cons have been able to retool and continue their mission of educating and growing this community, it’s still a bummer that there won’t be a chance to network and participate in all the fun events such cons offer. Or perhaps there will — it seems like the Wireless Capture the Flag (CTF) event is still going to happen. Billed as “an immersive plot-driven … competition featuring the GNU Radio framework and many other open-source tools, satellite communications, cryptography, and surreal global landscapes,” it certainly sounds like fun. We’d love to find out exactly how this CTF competition will work.

Everyone needs a way to unwind, and sometimes the best way to do that is to throw yourself into a project of such intricacy and delicate work that you’re forced into an almost meditative state by it. We’ve seen beautiful examples of that with the wonderful circuit sculptures of Mohit Bhoite and Jiří Praus, but here’s something that almost defies belief: a painstakingly detailed diorama of a vintage IBM data center. Created by the aptly named [minatua], each piece of this sculpture is a work of art in its own right and represents the “big iron” of the 1400 series of computers from the early 1960s. The level of detail is phenomenal — the green and white striped fanfold paper coming out of the 1403 line printer has tiny characters printed on it, and on the 729 tape drives, the reels spin and the lights flash. It’s incredible, all the more so because there don’t appear to be any 3D-printed parts — everything is scratch built from raw materials. Check it out.

As you can imagine, the Hackaday tip line attracts a fair number of ideas of the scientifically marginal variety. Although we’re not too fond of spammers, we try to be kind to everyone who bothers to send us a tip, but with a skeptical eye when terms like “free energy” come across. Still, we found this video touting to Nikola Tesla’s free energy secrets worth passing on. It’s just how we roll.

And finally, aside from being the first full day of summer, today is Father’s Day. We just want to say Happy Father’s Day to all the dads out there, both those that inspired and guided us as we were growing up, and those who are currently passing the torch to the next generation. It’s not easy to do sometimes, but tackling a project with a kid is immensely important work, and hats off to all the dads who make the time for it.

Seeing Code: The Widescreen Rant

June 20, 2020 by Elliot Williams 114 Comments

A couple of weeks ago, Linus Torvalds laid down the law, in a particularly Linusesque sort of way. In a software community where tabs vs. spaces can start religious wars, saying that 80-character-wide code was obsolete was, to some, utter heresy. For more background on how we got here, read [Sven Gregori]’s history piece on Hackaday, and you’ll learn that sliced bread and the 80-character IBM punch card both made their debut in July, 1928. But I digress.

When I look at a codebase, I like to see its structure, and I’m not alone. That’s one of the reasons for the Linux Kernel style guide’s ridiculously wide 8-character tabs. Combined with a trend for variable names becoming more and more descriptive, which I take to be a good thing, and monitors’ aspect ratios growing seemingly without end, which I don’t, the 80-column width seems like a relic from the long-gone era of the VT-220.

In Linus’ missive, we learn that he runs terminals at 100 x 50, and frequently drags them out to a screen-filling 142 x 76. (Amateur! I write this to you now on 187 x 48.) When you’re running this wide, it doesn’t make any sense to line-wrap argument lists, even if you’re using Hungarian notation.

And yet, change is painful. I’ve had to re-format code to meet 73-column restrictions for a book, only to discover that my inline comments were too verbose. Removing even an artificial restriction like the 80-column limit will have real effects. I write longer paragraphs, for instance, on a wider screen.

I see a few good things to come out of this, though. If single thoughts can be expressed on single lines, it makes the shape of the code better reflect its function. Getting rid of pointless wrapping takes up less vertical space, which is at a premium on today’s cinematic monitors. And if it makes inline comments better (I know, another holy war!) or facilitates better variable naming, it will have been worth it.

But any way you slice it, we’re no longer typing on the old 80-character Hazeltine. It’s high time for our coding style and practice to catch up.

Loading Coils, The Heaviside Condition, And Pupin Coils

June 19, 2020 by Al Williams 27 Comments

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” →

Hackaday Podcast 072: Robo Golf Clubs, Plastic Speedboats, No-Juice Flipdots, And Super Soakers

June 19, 2020 by Dan Maloney No comments

With Editor-in-Chief Mike Szczys on a well-earned vacation, Staff Writer Dan Maloney sits in with Managing Editor Elliot Williams to run us through the week’s most amazing hacks and answer your burning questions. What do you do when you can’t hit a golf ball to save your life? Build a better club, of course, preferably one that does the thinking for you. Why would you overclock a graphing calculator? Why wouldn’t you! Will an origami boat actually float? If you use the right material, it just might. And what’s the fastest way to the hearts of millions of kids? With a Super Soaker and a side-trip through NASA.

Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download (60 MB or so.)

Continue reading “Hackaday Podcast 072: Robo Golf Clubs, Plastic Speedboats, No-Juice Flipdots, And Super Soakers” →

This Week In Security: HaveIBeenPwned And Facebook Attack Their Customers

June 19, 2020 by Jonathan Bennett 27 Comments

We’re fans of haveibeenpwned.com around here, but a weird story came across my proverbial desk this week — [Troy Hunt] wrote a malicious SQL injection into one of their emails! That attack string was a simple ';--

Wait, doesn’t that look familiar? You remember the header on the haveibeenpwned web page? Yeah, it’s ';--have i been pwned?. It’s a clever in-joke about SQL injection that’s part of the company’s brand. An automated announcement was sent out to a company that happened to use the GLPI service desk software. That company, which shall not be named for reasons that are about to become obvious, was running a slightly out-of-date install of GLPI. That email generated an automated support ticket, which started out with the magic collection of symbols. When a tech self-assigned the ticket, the SQL injection bug was triggered, and their entire ticket database was wiped out. The story ends happily, thanks to a good backup, and the company learned a valuable lesson. Continue reading “This Week In Security: HaveIBeenPwned And Facebook Attack Their Customers” →

Inputs Of Interest: Curves Are The Key To My Type

June 18, 2020 by Kristina Panos 6 Comments

While I may have fallen in love aesthetically with the ErgoDox I built, beauty is only skin deep. And that’s funny, because you can see right through it. But the thing is, it’s just too big and knife-edged to be my daily driver. I keep missing the space bar and thumb-thumping the acrylic wasteland between the thumb cluster and the mainland.

The point was to make a nice portable keeb, even though all my trips for he foreseeable future are going to be limited to the bed or the couch. But it has to be comfortable, and the ErgoDox in its present state simply is not long-term comfortable. I’d take it over a rectangle any day, but it would probably end up being a half day.

Ergo isn’t so much a preference for me as it is a necessity at this point. I feel like I can honestly say that I might not be typing these words to you now if it weren’t for the Kinesis. I don’t want my fingers to do unnecessary legwork, or downgrade from the quality of typing life that concave keys have afforded me. So let me just say that using the ErgoDox made me want to build a dactyl even more than before.

Continue reading “Inputs Of Interest: Curves Are The Key To My Type” →

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

June 18, 2020 by Sven Gregori 186 Comments

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?” →