Category: Complaning
Snap is a failure
Ubuntu finally figured out that no one wanted the Unity desktop environment, but now they’re trying to fuck up software installation with “Snap”, which is apparently some kind of misbegotten blend of containerization and static linking.
Here’s what it looks like to the user: you install an application, like a text editor. It’s noticably slower to launch, and then go to open a file in the Documents folder in your home directory. Unfortunately, the text editor is a snap, so the Documents folder is in some random number’s home directory, not yours.
Then you delete the snap and install the text editor from a source that doesn’t use snap, and so is FUCKING COMPATIBLE WITH DIRECTORIES.
As a bonus, it runs faster now.
This feels a lot like how Firefox made a working browser, and then realized that once it was working, maintenance coding was boring and not profitable, so they divide their time between stupid but new things no one wants (Pocket) and breaking existing features (Open image in new tab).
It seems it’s never enough to do a good job, or once it’s done the project attracts useless hangers-on who have to appear to be doing something to justify their pay.
The Year of Linux on the Desktop is “Ha, Get Fucked”
People talk about usability, and in a lot of ways, Ubuntu is pretty close. It certainly beats Windows 10, at least for me, since you’re allowed to know what has gone wrong and fix it, instead of just rebooting whenever your computer gets infested with ghosts. I do complain about Ubuntu, but it’s usually because most things are decent, so the things that are bad are particularly egregious. And, after all, I did get what I paid for.
This time, though, I’m trying to work with a Raspberry Pi Zero W, and Raspbian. It has a little setup walkthrough that clearly took a serious blow to the head at some point, since it asks you to connect to WiFi, and then if you didn’t connect to a network, still asks if you want to download software. From what, I might ask, since there’s not a network connection?
Of course, the reason I didn’t connect to the network is that it’s hidden. Not a problem, I have the SSID on paper here… and no way to tell it to the Pi. There’s a network configurator, but it only lets you deal with unhidden networks, not enter your own SSIDs. Maybe this was done because “SSID” is one of those worrying “techie” terms, and this is supposed to be for somewhat less technical users? Protip: it’s not. It ships as a bare board in an antistatic bag, for fuck’s sake. Maybe this was not done because it’s somehow hard?
At any rate, the solution appears to be: manually edit wpasupplicant.conf. Manually edit a text file that only root can edit, in this, the Year of Our Lord 2019. I don’t have a problem with this. I have a PhD in making tiny robots go and have been using Linux for 15 years, because everything else is worse for my use cases. Normal humans, who are perhaps entering college and just want to check out Linux and maybe try writing a little Scratch or Python, they are going to have a problem with this.
Also, the same startup script asked me if my screen had black bars around the edges. It did, so I said yes (more fool me!). When I rebooted, the edges of the desktop (you know, where the UI goes) were mostly off the edge of the screen. Setting the hostname with the network config tool on the toolbar caused host name resolution errors every time I use sudo, apparently because sudo wanted “ouija1” but “ouija_1” got written into /etc/hosts. That’s not actually a valid hostname (my error), but it got written into /etc/hosts (an error by whoever wrote the alleged network config tool). Again, I know what /etc/hosts is, editing it isn’t an issue. I’m weird. For most people, this is an issue.
So in general, my experience with the Raspberry Pi and Raspbian is that it’s not ready for end users who want to use it to do things. If you want it in order to do things to it, rather than with it, and are already an experienced electronics enthusiast and Linux user, you’ll be fine.
IoTiocy
I may be the first to come up with this terrible neologism, but the time for it is certainly at hand. There have been a number of high-profile incidents where the security of stuff that was connected to the Internet was neglected in the rush to get it connected, or highly dubious design decisions were made in order to get an IoT “thing” to market.
The term originally came up when I was discussing this widget with a friend of mine. The NodeMCU boards are pretty sweet, and are based on the ESP-8266, which is also pretty sweet. The motor driver chip they used is from the 1970s, and there are far better ones available. The VNH2SP30 is a beast, and can supply 10x the current of the L293D, although you’d need two of them for dual motors, so there may be a horses for courses argument to be made there.
The DDoS that took out Krebs On Security, though, doesn’t really have a similar argument going for it. IoT security is hard because the devices don’t have a great interface for users to tighten up their security settings (if indeed, they have any security settings), and users don’t expect to have to tighten up the security of their appliances. As a result, insecure IoT stuff just kind of hangs out in dubious parts of the web, waiting for someone to make it a questionable offer of employment.
To the people who make things incomplete, weak, or insecure, I dedicate this new word:
IoTiot noun, informal
- A person or company that creates IoT devices lacking security, solid design, or even a purpose, usually in order to make a quick grab for cash.
- Any such device, once it starts behaving as it was designed (which is to say “badly”).
Similarly: IoTiotic, IoTiots, IoTiocy
ROS and OpenCV will fite u, m8
I recently wanted to do some computer vision stuff using OpenFace, which is a collection of face-processing computer vision algorithms and tools to use them. It uses OpenCV 3.0.something, which uses, among other things, vtk6, and friends libvtk6-dev and python-vtk6.
Normally, this wouldn’t be a problem, but I use ROS Indigo, as does the lab I work in. ROS Indigo uses some previous version of vtk, and so attempting to install OpenCV 3.0 blows away my ROS install, and makes apt freak out when I try to install it again. The actual error was something like “you have broken held packages”, only I didn’t actually have held packages OR broken packages.
Apt just gives up at this point. Aptitude, on the other hand, proposes removing the offending VTK packages and proceeding with the ROS install. Only time will tell if I’ve trashed my OpenCV install, but if I have, I can just go back to an older OpenCV version.
A Word of Warning
My PhD work (TinyRobo) uses a USB-Serial converter to talk to the ESP-8266 modules in the tiny robots. Normal FTDI cables have a cable that ends in a 0.1″ 6-pin header with this pinout:
- Black – Ground
- Brown – CTS
- Red – VCC
- Orange – TX
- Yellow – RX
- Green – RTS
It turns out that esptool can manipulate the DTR and RTS lines to reset the chip in bootloader mode, which is great for uploading code to it. It also means I can get away with not having any parts on the TinyRobo boards to handle the reset, which is great because it lets me keep the board small. Unfortunately, the FTDI cable I have doesn’t expose the RTS line, so I got a converter module for cheap off Amazon. The particular module I got is this one:
I added that red wire and cut a trace so that the pins would be:
- DTR
- RX
- TX
- VCC
- CTS
- Ground
So far, so good, but I can’t upload with it. I threw a scope on the lines, and it looks like instead of swinging from VCC to ground like well-behaved TTL serial lines, they swing from VCC to VCC minus some tiny voltage, less than a volt. Adding pull-downs on the lines doesn’t seem to have helped. It could be that the timing is of, but I suspect that somewhere, some cheapskate saved some fraction of a cent on this board, at the expense of it doing the one thing it was supposed to do (YOU HAD ONE JOB).
KiCad is Still a Shitshow
Six months ago, I designed a schematic and circuit board in KiCad. Yesterday, I tried to open it and got a list of errors so long that it didn’t fit on my screen from top to bottom. The reason is that KiCad loads the footprints of the parts you use from Github, so when (not if) the KiCad devs change how they store footprints, your install of KiCad breaks. In other words, installing KiCad gives the KiCad devs permission to break your workflow for no reason.
I fixed my KiCad package list by writing a little python script that goes through the KiCad github repo and generates a new footprint list based on however they happen to be organized and whatever they happen to be called today. Copy that over my previously working footprint list, and the error message went away.
However, since the last time I used it, my install of KiCad has stopped rendering in CVPCB. No error message or anything, just doesn’t render the copper layers, parts, etc. I got part of the ratsnest, and that’s it.
Clearly, the thing to do is to install the newest version of KiCad from the developer’s PPA.
Nope, that returns a 404.
Clearly, the thing to do is to install using the script the devs wrote to install and build KiCad.
Nope, the script fails because they use a version of WXWidgets that like no one else on earth uses.
So let’s recap: No method of installing KiCad works, and just LEAVING YOUR WORKING INSTALL ALONE is not sufficient to ensure that it continues to work.
Since I’m designing a small PCB, CadSoft’s Eagle is looking more and more tempting. Limited PCB sizes aren’t a problem if you’re making something small.
Recent Comments