Great businesses can still be cash grabs. In fact, many of them are. Very few of those dress themselves up as a nonprofit (aside from Arduino and OpenAI).
I feel like this has to be a toolchain issue, there's no reason the pin number -> register table couldn't be resolved at compile time, similar with conditionally compiling certain things based on the CPU features.
I'm not saying it's not a real or an easy problem, just that I wonder if it truly is the reason Arduino is "bad"
It could and some cores do. Many do not and you get a runtime lookup unless you explicitly call digitalWriteFast which is also supposed to resolve to a single inline instruction. It usually does not and instead emits a function call in assembly.
The gpio thing is really just my personal pet peeve. There are a lot of things like this though. For example, the arduino core will consume several milliseconds doing something in between calls to your main function. I2C and similar drivers are typically not well designed and either use too much memory or just operate not-quite-right.
Which brings up another point, the Arduino ecosystem is not at all unified. If you use a chip that is not popular enough to be mainlined, you have to go out and find an Arduino core that supports it and try to plug that into your compiler. Such cores frequently are not API compatible and have slightly different behaviors. It's all a big mess.
There are a lot of features that are compile time conditional based on CPU, but the actual implementation of this is horrible. I once had to modify someone else's custom Arduino core to tweak some low level behavior and despite the change being very minimal, it took three days to find all the places and all the conditionals that needed tweaking.
But really my main complaint is that Arduino is incredibly slow and hides far too much from you. Firmware developers should know about CPU registers and hardware features. This is very important for understanding the machine! A lack of awareness of the machine and what its doing is (IMO) one of the major factors in how awful modern programs are.
I agree with you, with the caveat that the awful software that's written by an inexperienced programmer ends up getting used, and the perfect efficient well-tuned software I want to write never gets finished (or even started, usually). It's so much more work.
I actually have no idea what you mean with the example, all the toolbars on the page fit 4 or more buttons, I tried viewing it in various window widths, can you be a bit more specific?
As for the article, I'm also a bit confused because I'm really not sure whether people write that sort of code at the beginning "very commonly" - match and `ok_or` to handle None by turning them into proper Errors is one of the first things you learn in Rust.
Somewhat tangential, but there are much better options if you're looking for opportunities for optimization. It's literally trying to improve efficiency by skimping on safety features, like trying to save on vehicle weight by removing unnecessary seatbelts or crumple zones. Eliminating side channels concincingly is very difficult, you're just better off taking the tiny performance hit and virtually* eliminating that vector instead of trying to come up with a novel low-density seatbelt.
(I say virtually, because even constant time crypto isn't bulletproof - GoFetch, a recent Apple M-series CPU vulnerability inadvertently broke the "constant" part because of a quirk of the prefetcher. Side channels are hard, no need to make it harder.)
The project met the exact same end its predecessor (the PirateBox) did, and for pretty much the same reason. However, the project is quite old, and the focus on reflashing portable routers was a necessity then, but not so anymore - specifically, PirateBox (2011) actually predates the first Raspberry Pi (2012), and especially the first Pi with an onboard Wi-Fi (2016).
I'm just wondering, why hasn't a SBC-based alternative popped up yet? I think the project is/was awesome, I actually did maintain 2 public PirateBoxen for a while. Is it a simple lack of interest? The fact LibraryBox tried to pick up after PirateBox kind of suggests otherwise. I feel like it's actually easier now than ever to build a Libary/PirateBox-like project (although I do imagine an on-board network card probably has way worse performance than even those old portable routers).
I've even tried to put together an image like that in the past but I couldn't find a reproducible solution for creating raspi images so that put me off, maybe it's time to give it another try...
The main problem with these projects - which was not much of an issue when the projects started - is that mobile phones of today seek access to web servers at vendors, including the OS source and possibly others such as the phone manufacturer and ISP. The phones balk if they don't connect to those servers. PirateBox and LibraryBox are not just captive portals to Internet connections, they are local content and app servers and don't need the Internet.
So when you connect to a Box via Wi-Fi your phone demands to connect to Internet hosts even though this is unnecessary for this use case. This behavior is confusing to the user. Some early solutions involved trying to spoof Apple servers for example, but the names and IPs of these servers kept changing and this kluge became ineffective.
The only solution I am aware of is to pre-inform users of a local IP address to browse to once their Wi-Fi is connected to the Box. But depending on the occasion and venue, getting such instructions to the audience and having them follow it, can be its own problem.
You can setup DNS on the box to redirect users and to give a friendly name to your box. That's what we do for butter box (https://likebutter.app/box/). To make it a step easier, we provide a QR code. But even that is a little clumsy since you must first connect to WiFi, then scan the code.
Captive portals sound nice until you find out how limited they are -- a lot of styling, JS and browser features are simply unavailable. So, you need to tell users "Close this, then go open this site in your real browser"...
Of course, you can't and probably don't want to redirect HTTPS traffic since you don't have the matching cert for e.g. https://google.com
I actually have a "MonsterOTG" portable WAP. https://www.youtube.com/watch?v=THnT-rWFnE8 ...their pitch was "put your kids movies on an SD card and they can navigate to them from their iPad (on a road-trip)"... or have all the media on one SD-card and not have to have them on all your phones (like a proto-NAS, kindof).
I used it actually while on a trip to "fake" being a web-server. eg: `scp index.html 10.1.10.1:/media/files/public` (or whatever) and then I could have my phone navigate to it. Chromebook => "OTG-Wifi" && Phone => "OTG-Wifi". Chrombook.push(); Phone.fetch(...);
I couldn't connect directly from phone to chromebook, but if they were both on the same (captive) wifi, I could actually have the phone navigate to the server running on the chromebook via that little device as a "wifi mediator" (even while in the middle of nowhere with no internet for 50 miles around). I had some episodes of Twilight Zone that I'd ripped and could connect to it while on a flight. You could take the SD-Card out of your camera and fetch pictures over to the macbook-without-sd-card situation, then clear the card and take more pics (or keep them on and just be guaranteed that you have a backup).
There's really some non-pirate use cases of things like that, and the overall concept is pretty cool! Got me thinking of something like a neighborhood "Captive SSID", like a LAN that you opt in to vs the WAN that's always connected. It's really instructive to think through for yourself personally: if you were on the moon, and all you had was a wifi access point that held SD-Cards
> when you connect to a Box via Wi-Fi your phone demands to connect to Internet hosts
I don't follow: When my phone connects to a wlan, it will try to connect to the Internet, and if the phone can't do that then the phone won't function on the wlan?
> The only solution I am aware of is to pre-inform users of a local IP address to browse to once their Wi-Fi is connected to the Box.
What is the response from this local IP address that solves the problem above?
The goal was to make LibraryBox, but with just a little more frontend and a little more flexibility. It had a lot of the earliest things: Simple wifi support, and was built to enable you to add services like Gopher, maybe Gemini, IRC, etc.
In the end, there was not quite enough interest. Jason moved up in the ranks of the then Berkman Kline center, 2018 became a very touchy time for things.
You can easily run Alexandria, which at its core is a very basic directory browser, the admin panel can be turned off. I wanted to add the ability to upload & expand archives of files, but couldn't find a good way to do that at the time.
Butter Box (https://likebutter.app/box/) and Internet In a Box are two modern descendants of the concept. Both run on RPis (and, nominally, some other hardware).
Putting together the images isn't terribly difficult. For Butter Box, we just run a script to install all the things we want, then make an .iso of that, which we distribute on our site and in hardware form.
Those onboard network cards are indeed a problem. You can get single-digit # of simultaneous users. But other than that, they tend to be very fast for large files since you're not going out over the Internet and can saturate the WiFi connection.
Thanks for situating this in history! It's easy for people to look at the project and be like "why no RPi?" without understanding that when LibraryBox started, Raspberry Pi's didn't have onboard wifi, and the travel routers we chose to support were SIGNIFICANTLY less expensive as well. We're in a very different hardware world now.
I don't doubt the boards could've been sold cheaper, but they clearly were doing something right given how much it changed the hobbyist landscape