Hackaday Links: March 3, 2024

March 3, 2024 by Dan Maloney 26 Comments

Who’d have thought that $30 doorbell cameras would end up being security liabilities? That’s the somewhat obvious conclusion reached by Consumer Reports after looking at some entry-level doorbell cameras available through the usual outfits and finding glaring security gaps which are totally not intentional in any way.

All these cameras appear to be the same basic hardware inside different enclosures, most supporting the same mobile app. Our favorite “exploit” for these cameras is the ability to put them into a pairing mode with the app, sometimes by pressing a public-facing button. Slightly more technically challenging would be accessing images from the app using the camera’s serial number, or finding file names being passed in plain text while sniffing network traffic. And that’s just the problems CR identified; who knows what else lurks under the covers? Some retailers have stopped offering these things, others have yet to, so buyer beware.

Speaking of our techno-dystopian surveillance state, if you’ve had it with the frustrations and expense of printers, has Hewlett-Packard got a deal for you. They want you to never own a printer again, preferring that you rent it from them instead. Their “All-In Plan” launched this week, which for $6.99 a month will set up up with an HP Envy inkjet printer, ink deliveries, and 24/7 tech support. It doesn’t appear that paper is included in the deal, so you’re on your own for that, but fear not — you won’t go through much since the entry-level plan only allows 20 prints per month. Plans scale up to 700 prints per month from an OfficeJet Pro for the low, low price of $36. The kicker, of course, is that ~~your~~ their printer has to be connected to the Internet, and HP can pretty much brick the thing anytime they want to. The terms of service also explicitly state that they’ll be sending your information to advertising partners, so that’ll be fun. This scheme hearkens back to the old pre-breakup days of AT&T, where you rented your phone from the phone company. That model made a lot more sense when the phone (probably) wasn’t listening in on everything you do. This just seems like asking for trouble.

“Enhance, enhance…” Credit: NASA/JPL-Caltech/LANL/CNES/IRAP/Simeon Schmauß

It’s been a while since Ingenuity‘s final rough landing on Mars permanently grounded the overachieving helicopter, long enough that it’s time for the post-mortem analyses to begin. The first photographic evidence we had was a shadowgram from one of the helicopter’s navigational cameras, showing damage to at least one of the rotor tips, presumably from contact with the ground. Then we were treated to a long-distance shot from Ingenuity‘s rover buddy Perseverance, which trained its MASTCAM instruments on the crash zone and gave us a wide view of its lonely resting place.

Now, geovisual design student [Simeon Schmauβ] has taken long shots made with the rover’s SuperCam instrument and processed them into amazingly detailed closeups, which show just how extensive the damage really is. One rotor blade sheared clean off on contact, flying 15 meters before gouging a hole in the regolith. Another blade looks to be about half gone, while the remaining two blades show the damaged tips we’ve already seen. That the helicopter is still on its feet given the obvious violence of the crash is amazing, as well as an incredible piece of luck, since it means the craft’s solar panel is pointing in roughly the right direction to keep it powered up.

Continue reading “Hackaday Links: March 3, 2024” →

Steampipe: All SQL All The Time

February 19, 2024 by Al Williams 23 Comments

Although modern Linux has slightly shifted, the old Unix mantra was: everything’s a file. With Steampipe, a better saying might be: everything’s a SQL table. The official tagline is “select * from cloud” which also works. The open-source program relies on plugins, and there are currently 140 sources ranging from GitHub to Google Sheets and more.

There are command line interfaces for the major platforms. You can also add the system to PostgresSQL or SQLite for even more SQL goodness. Continue reading “Steampipe: All SQL All The Time” →

Squish That Stack With Rampart

November 24, 2022 by Dave Rowntree 18 Comments

[P B Richards] and [Aaron Flin] were bemoaning the resource hunger of modern JavaScript environments and planned to produce a system that was much stingier with memory and CPU, that would fit better on lower-end platforms. Think Nginx, NodeJS, and your flavour of database and how much resource that all needs to run properly. Now try wedge that lot onto a Raspberry Pi Zero. Well, they did, creating Rampart: a JavaScript-based complete stack development environment.

The usual web applications have lots of tricks to optimise for speed, but according to the developers, Rampart is still pretty fast. Its reason for existence is purely about resource usage, and looking at a screen grab, the Rampart HTTP server weighs in at less than 10 MB of RAM. It appears to support a decent slew of technologies, such as HTTPS, WebSockets, SQL search, REDIS, as well as various utility and OS functions, so shouldn’t be so lightweight as to make developing non-trivial applications too much work. One interesting point they make is that in making Rampart so frugal when deployed onto modern server farms it could be rather efficient. Anyway, it may be worth a look if you have a reasonable application to wedge onto a small platform.

We’ve seen many JavaScript runtimes over the years, like this recent effort, but there’s always room for one more.

Scratching Out Business Intelligence

August 9, 2022 by Matthew Carlson 9 Comments

At Hackaday, we love things both from scratch and in Scratch, Scratch being the blocks building helpful language for teaching kids and the like how to program. However, when you have a large amount of data that needs to be processed, queried, and collated to get meaningful insights, it is a pain to rewrite a SQL query every time a new question arises that needs an answer. So perhaps a more elegant approach would be to give the people asking the questions the tools to answer them, but rather than teach them SQL, Mongo, GraphQL, or any other database, give them the tools to scratch out the answers themselves.

That’s enough scratch puns for one article. [Tommy] ran into this situation in 2011 and recently wrote about it. Scratch came out in 2003 and has inspired several projects, such as Google’s Blockly. [Tommy] used Blockly to create a web app where users could drag and drop different blocks to form queries. These layouts were passed to a PHP-backed (though later HVVM for performance reasons) and executed as SQL.

Eventually, big data came around, and the company hired proper data scientists. Though [Tommy] notes that some of those who used his tool went on to learn proper SQL and do it themselves. Applying concepts from programs designed to teach children programming might sound a little odd in a business sense, but we love seeing projects that help someone become curious enough to peer inside the machine.

SQLite On The Web: Absurd-sql

August 24, 2021 by Matthew Carlson 12 Comments

Love it or hate it, the capabilities of your modern web browser continuously grow in strange and wild ways. The ability for web apps to work offline requires a persistent local storage solution and for many, IndexedDB is the only choice as it works across most browsers and provides a database-like interface. However, as [James Long] found, IndexedDB is painfully slow on chrome and limited in querying ability. He set out to bring a tool he was familiar with, SQLite, and bring it to the web browser as absurd-sql.

Why absurd? Partially because most browsers (not chrome) implement IndexedDB on top of SQLite. So for many browsers, it is just SQLite on top of IndexedDB on top of SQLite. Luckily for [James] there already was a project known as sql.js that uses emscripten to compile the C-based SQLite into WebAssembly. However, sql.js uses an in-memory storage backing and all data is lost when refreshing the page. [James] tweaked SQLite’s method of reading and writing blocks. Instead of being memory backed, he added a layer to read and write blocks from IndexedDB. This means that only sections of the database need to be read in, bringing in huge performance gains.

That brings us to the other reason why it’s absurd. On chrome (as well as Firefox), absurd-sql beats IndexedDB on almost every benchmark. A query like SELECT SUM(*) FROM kv led to stunning results.

So what’s the downside? Other than a somewhat large WebAssembly file that needs to get downloaded (409KB) and cached, there really isn’t. Of course, it’s not all roses when it comes to web development. Native SQLite runs 2-3 times faster than absurd-sql, which demonstrates how slow IndexedDB really is.

There are other storage standards on the horizon for web browsers, but locking becomes an issue. SQLite expects synchronous reads and writes because it’s just simple C. IndexedDB and other storage solutions are asynchronous as the event loop of Javascript lends itself well to that model. Absurd-sql gets around that by creating a SharedArrayBuffer that is shared with a worker process. The atomics API is used to communicate with the buffer. In particular, atomics.wait() allows the worker to block main thread execution until the read or write has finished. From the perspective of SQLite, the operations are synchronous. IndexedDB provides transactions so multiple connections can happen (for example multiple tabs open). Multiple readonly transactions can occur in parallel but only one readwrite transaction can be in flight.

Why not pull up your browser and start playing around with it? You’re already doomed to learn WebAssembly anyway.

Linux Fu: Databases Are Next-Level File Systems

June 8, 2021 by Al Williams 63 Comments

It is funny how exotic computer technology eventually either fails or becomes commonplace. At one time, having more than one user on a computer at once was high tech, for example. Then there are things that didn’t catch on widely like vector display or content-addressable memory. The use of mass storage — especially disk drives — in computers, though has become very widespread. But at one time it was an exotic technique and wasn’t nearly as simple as it is today.

However, I’m surprised that the filesystem as we know it hasn’t changed much over the years. Sure, compared to, say, the 1960s we have a lot better functionality. And we have lots of improvements surrounding speed, encoding, encryption, compression, and so on. But the fundamental nature of how we store and access files in computer programs is stagnant. But it doesn’t have to be. We know of better ways to organize data, but for some reason, most of us don’t use them in our programs. Turns out, though, it is reasonably simple and I’m going to show you how with a toy application that might be the start of a database for the electronic components in my lab.

You could store a database like this in a comma-delimited file or using something like JSON. But I’m going to use a full-featured SQLite database to avoid having a heavy-weight database server and all the pain that entails. Is it going to replace the database behind the airline reservation system? No. But will it work for most of what you are likely to do? You bet. Continue reading “Linux Fu: Databases Are Next-Level File Systems” →

Get Your SQL Statements Right The First Time With SQL Lint

August 18, 2020 by Sven Gregori 11 Comments

What’s your average success rate of getting a SQL statement right on the first try? In best case, you botched a simple statement without side effects and just have to try again with correct syntax or remove that typo from a table name, but things can easily go wrong fast here. But don’t worry, the days of fixing it on the fly can be over, thanks to [Joe Reynolds] who wrote a linter for SQL.

A linter parses code to tell you where you screwed up. While checking SQL syntax itself is somewhat straightforward, [Joe]’s sql-lint tool will also check the semantics of it by looking up the actual database and performing sanity checks on it. Currently supporting PostgreSQL and MySQL, it can be either run on a single SQL file or a directory of files, or take input directly from the command line. Even better, it also integrates within your editor of choice — assuming it supports external plugins — and the documentation shows how to do that specifically for Vim.

If you can look past the fact that it’s written in TypeScript and consequentially results in a rather large executable (~40 MB), it might serve as an interesting starting point for the language itself, or adds a new perspective on writing this type of analyzer. And if databases aren’t your terrain, how about shell scripts?

Continue reading “Get Your SQL Statements Right The First Time With SQL Lint” →