These days you can run Doom anywhere on just about anything, with things like porting Doom to JavaScript these days about as interesting as writing Snake in BASIC on one’s graphical calculator. In a twist, [Patrick Trainer] had the idea to use SQL instead of JS to do the heavy lifting of the Doom game loop. Backed by the Web ASM version of the analytical DuckDB database software, a Doom-lite clone was coded that demonstrates the principle that anything in life can be captured in a spreadsheet or database application.
Rather than having the game world state implemented in JavaScript objects, or pixels drawn to a Canvas/WebGL surface, this implementation models the entire world state in the database. To render the player’s view, the SQL VIEW feature is used to perform raytracing (in SQL, of course). Any events are defined as SQL statements, including movement. Bullets hitting a wall or impacting an enemy result in the bullet and possibly the enemy getting DELETE-ed.
The role of JavaScript in this Doom clone is reduced to gluing the chunks of SQL together and handling sprite Z-buffer checks as well as keyboard input. The result is a glorious ASCII-based game of Doom which you can experience yourself with the DuckDB-Doom project on GitHub. While not very practical, it was absolutely educational, showing that not only is it fun to make domain specific languages do things they were never designed for, but you also get to learn a lot about it along the way.
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.
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.
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.
[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.
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.
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.
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”→
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 
