The Modern WWW, Or: Where Do We Want To Go From Here?

April 27, 2023 by Maya Posch 52 Comments

From the early days of ARPANET until the dawn of the World Wide Web (WWW), the internet was primarily the domain of researchers, teachers and students, with hobbyists running their own BBS servers you could dial into, yet not connected to the internet. Pitched in 1989 by Tim Berners-Lee while working at CERN, the WWW was intended as an information management system that’d provide standardized access to information using HTTP as the transfer protocol and HTML and later CSS to create formatted documents inspired by the SGML standard. Even better, it allowed for WWW forums and personal websites to begin to pop up, enabling the eternal joy of web rings, animated GIFs and forums on any conceivable topic.

During the early 90s, as the newly opened WWW began to gain traction with the public, the Mosaic browser formed the backbone of the WWW browsers (‘web browsers’) of the time, including Internet Explorer – which licensed the Mosaic code – and the Mosaic-based Netscape Navigator. With the WWW standards set by the – Berners-Lee-founded – World Wide Web Consortium (W3C), the stage appeared to be set for an open and fair playing field for all. What we got instead was the brawl referred to as the ‘browser wars‘, which – although changed – continues to this day.

Today it isn’t Microsoft’s Internet Explorer that’s ruling the WWW while setting the course for new web standards, but instead we have Google’s Chrome browser partying like it’s the early 2000s and it’s wearing an IE mask. With former competitors like Opera and Microsoft having switched to the Chromium browser engine that underlies Chrome, what does this tell us about the chances for alternative browsers and the future of the WWW?

Continue reading “The Modern WWW, Or: Where Do We Want To Go From Here?” →

Chatting With Local AI Moves Directly In-Browser, Thanks To Web LLM

April 24, 2023 by Donald Papp 7 Comments

Large Language Models (LLM) are at the heart of natural-language AI tools like ChatGPT, and Web LLM shows it is now possible to run an LLM directly in a browser. Just to be clear, this is not a browser front end talking via API to some server-side application. This is a client-side LLM running entirely in the browser.

The ability to run an LLM (natural language AI) directly in-browser means more ways to implement local AI while enjoying GPU acceleration via WebGPU.

Running an AI system like an LLM locally usually leverages the computational abilities of a graphics card (GPU) to accelerate performance. This is true when running an image-generating AI system like Stable Diffusion, and it’s also true when implementing a local copy of an LLM like Vicuna (which happens to be the model implemented by Web LLM.) The thing that made Web LLM possible is WebGPU, whose release we covered just last month.

WebGPU provides a way for an in-browser application to talk to a local GPU directly, and it sure didn’t take long for someone to get the idea of using that to get a local LLM to run entirely within the browser, complete with GPU acceleration. This approach isn’t just limited to language models, either. The same method has been applied to successfully create Web Stable Diffusion as well.

It’s a fascinating (and fast) development that opens up new possibilities and, hopefully, gives people some new ideas. Check out Web LLM’s GitHub repository for a closer look, as well as access to an online demo.

Signed Distance Functions: Modeling In Math

April 12, 2023 by Matthew Carlson 13 Comments

What if instead of defining a mesh as a series of vertices and edges in a 3D space, you could describe it as a single function? The easiest function would return the signed distance to the closest point (negative meaning you were inside the object). That’s precisely what a signed distance function (SDF) is. A signed distance field (also SDF) is just a voxel grid where the SDF is sampled at each point on the grid. First, we’ll discuss SDFs in 2D and then jump to 3D.

SDFs in 2D

A signed distance function in 2D is more straightforward to reason about so we’ll cover it first. Additionally, it is helpful for font rendering in specific scenarios. [Vassilis] of [Render Diagrams] has a beautiful demo on two-dimensional SDFs that covers the basics. The naive technique for rendering is to create a grid and calculate the distance at each point in the grid. If the distance is greater than the size of the grid cell, the pixel is not colored in. Negative values mean the pixel is colored in as the center of the pixel is inside the shape. By increasing the size of the grid, you can get better approximations of the actual shape of the SDF. So, why use this over a more traditional vector approach? The advantage is that the shape is represented by a single formula calculated at many points. Most modern computers are extraordinarily good at calculating the same thing thousands of times with slightly different parameters, often using the GPU. GLyphy is an SDF-based text renderer that uses OpenGL ES2 as a shader, as discussed at Linux conf in 2014 . Freetype even merged an SDF renderer written by [Anuj Verma] back in 2020. Continue reading “Signed Distance Functions: Modeling In Math” →

It Isn’t WebAssembly, But It Is Assembly In Your Browser

April 11, 2023 by Al Williams 18 Comments

You might think assembly language on a PC is passe. After all, we have a host of efficient high-level languages and plenty of resources. But there are times you want to use assembly for some reason. Even if you don’t, the art of writing assembly language is very satisfying for some people — like an intricate logic puzzle. Getting your assembly language fix on a microcontroller is usually pretty simple, but on a PC there are a lot of hoops to jump. So why not use your browser? That’s the point of this snazzy 8086 assembler and emulator that runs in your browser. Actually, it is not native to the browser, but thanks to WebAssembly, it works fine there, too.

No need to set up strange operating system environments or link to an executable file format. Just write some code, watch it run, and examine all the resulting registers. You can do things using BIOS interrupts, though, so if you want to write to the screen or whatnot, you can do that, too.

The emulation isn’t very fast, but if you are single-stepping or watching, that’s not a bad thing. It does mean you may want to adjust your timing loops, though. We didn’t test our theory, but we expect this is only real mode 8086 emulation because we don’t see any protected mode registers. That’s not a problem, though. For a learning tool, you’d probably want to stick with real mode, anyway. The GitHub page has many examples, ranging from a sort to factorials. Just the kind of programs you want for learning about the language.

Why not learn on any of a number of other simulated processors? The 8086 architecture is still dominant, and even though x86_64 isn’t exactly the same, there is a lot of commonalities. Besides, you have to pretend to be an 8086, at least through part of the boot sequence.

If you’d rather compile “real” programs, it isn’t that hard. There are some excellent tutorials available, too.

Wolverine Gives Your Python Scripts The Ability To Self-Heal

April 9, 2023 by Donald Papp 38 Comments

[BioBootloader] combined Python and a hefty dose of of AI for a fascinating proof of concept: self-healing Python scripts. He shows things working in a video, embedded below the break, but we’ll also describe what happens right here.

The demo Python script is a simple calculator that works from the command line, and [BioBootloader] introduces a few bugs to it. He misspells a variable used as a return value, and deletes the subtract_numbers(a, b) function entirely. Running this script by itself simply crashes, but using Wolverine on it has a very different outcome.

In a short time, error messages are analyzed, changes proposed, those same changes applied, and the script re-run.

Wolverine is a wrapper that runs the buggy script, captures any error messages, then sends those errors to GPT-4 to ask it what it thinks went wrong with the code. In the demo, GPT-4 correctly identifies the two bugs (even though only one of them directly led to the crash) but that’s not all! Wolverine actually applies the proposed changes to the buggy script, and re-runs it. This time around there is still an error… because GPT-4’s previous changes included an out of scope return statement. No problem, because Wolverine once again consults with GPT-4, creates and formats a change, applies it, and re-runs the modified script. This time the script runs successfully and Wolverine’s work is done.

LLMs (Large Language Models) like GPT-4 are “programmed” in natural language, and these instructions are referred to as prompts. A large chunk of what Wolverine does is thanks to a carefully-written prompt, and you can read it here to gain some insight into the process. Don’t forget to watch the video demonstration just below if you want to see it all in action.

While AI coding capabilities definitely have their limitations, some of the questions it raises are becoming more urgent. Heck, consider that GPT-4 is barely even four weeks old at this writing.

Continue reading “Wolverine Gives Your Python Scripts The Ability To Self-Heal” →

Revisiting Borland Turbo C And C++

April 8, 2023 by Maya Posch 76 Comments

Looking back on what programming used to be like can be a fascinatingly entertaining thing, which is why [Tough Developer] decided to download and try using Turbo C and C++, from version 1.0 to the more recent releases. Borland Turbo C 1.0 is a doozy as it was released in 1987 — two years before the C89 standardization that brought us the much beloved ANSI C that so many of us spent the 90s with. Turbo C++ 1.0 is from 1991, which precedes the standardization of C++ in 1998. This means that both integrated development environments (IDEs) provide a fascinating look at what was on the cutting edge in the late 80s and early 90s.

Online help and syntax coloring in Turbo C++.

It wasn’t until version 3.0 that syntax highlighting was added, with the IDE’s focus being mostly on features such as auto-indentation and tool integration. Version 2.0 added breakpoints and further integration with the debugger and other tools, as well as libraries such as the Borland Graphics Interface (BGI). Although even editors like Notepad++ and Vim probably give these old IDEs a run for their money nowadays, they were totally worth the money asked.

Those of us that have been around long enough to have gotten their start in C++ by using the free Turbo command line tools in the 1990s, or lived through the rough, early days of GCC 2.x+ on Linux, will remember that a development environment that Just Worked^© was hard to obtain without shelling out some cash. Within that environment Turbo C and C++ and later Visual Studio and others served a very grateful market indeed.

Beyond the IDE itself, these also came with language documentation, as in the absence of constant internet access, referencing APIs and syntax was done using dead-tree reference books or online documentation. Here “online” meaning digital documentation that came provided on a CD and which could be referenced from within the IDE.

[Tough Developer] walks the reader through many features of the IDE, which includes running various demos to show off what the environment was capable of and how that in turn influenced contemporary software and games such as Commander Keen in Keen Dreams. While we can’t say that a return to Turbo C is terribly likely for the average Hackaday reader, we do appreciate taking a look back at older languages and development environments — if for no other reason than to appreciate how far things have come since then.

Minecraft Finally Gets Multi-Threaded Servers

April 3, 2023 by Matthew Carlson 33 Comments

Minecraft servers are famously single-threaded and those who host servers for large player bases often pay handsomely for a server that has gobs of memory and ripping fast single-core performance. Previous attempts to break Minecraft into separate threads haven’t ended successfully, but it seems like the folks over at [PaperMC] have finally cracked it with Folia.

Minecraft is one of (if not the most) hacked and modded games in history. Mods have been around since the early days, made possible by a dedicated group who painstakingly decompiled the Java bytecode and reverse-engineered it. Bukkit was a server mod back in the Alpha days that tried to support plugins and extend the default Minecraft. From Bukkit, Spitgot was forked. From Spitgot, Paper was forked, which focused on performance and gameplay mechanics. And now from Paper, Folia is a new fork focused on multi-threading.

A Minecraft world is split up into worlds (such as the nether or the overworld) and chunks. Chunks are 16x16xZ vertical columns of blocks. Folia breaks up sections of chunks into regions that can be ticked independently. Of course, moving to a multi-threaded model will cause existing plugins to fail. Very little was made thread-safe and the idea is that data cannot move easily across ticking regions. Regions tick in parallel, not synchronously.

Naturally, the people benefiting from Folia the most are those running servers that support hundreds of players. On a server with a vanilla-like configuration only around a hundred or so players can be online. Increasing single-core performance isn’t usually an option past this point. By moving to other cores, suddenly you can scale out significantly without restoring to complex proxying. Previous attempts have had multiple Minecraft servers and then synced players and entities between them. Of course, this can cause its own share of issues.

It’s simply incredible to us what the modding community continues to develop and create. It takes deep patience to reverse-engineer the system and rearchitect it from the outside. The Folia codebase is available on GitHub under a GNU GPL 3.0 license if you’d like to look through it.