I’m not even sure this warrants a blog post. The only thing that was wrong with it was a loose ribbon cable connecting one of the two analog boards to the logic board.
Symptoms: LED and backlights power on, but no logo, no menu. If you connect a VGA cable, the monitor is identified correctly and can be enabled, but no picture.
So… just in case anyone needs board pictures, here they are:
Yay, 1024×768. It was an upgrade from 800×600 back when I got it…
Just a thing I quickly made a short while ago. There’s nothing special going on. The board on the left has one resistor per LED, on the board on the right, two LEDs and one resistor are each wired as a series circuit.
Note: I don’t leave this running unattended — I’m reasonably sure the entire thing would fall to the floor in a medium~major earthquake and the risk of causing a short is relatively high. Not that the short would necessarily cause a fire, but better safe than sorry.
There are probably a million other reasons you could get this error, but I didn’t see anyone document the case I got it: I wrote some raw assembly (i.e., hexadecimal machine code) and got the instruction length wrong. I.e., something like this:
__asm volatile(
".byte 0x00 \n"
);Well, AVR instructions are 16 bits, so clearly the one-byte thing above wouldn’t encode a valid instruction and would ruin alignment, so it would have to look at this:
__asm volatile(
".byte 0x00 \n"
".byte 0x00 \n"
);In these dark ages, a lot of software (mostly chat apps) only work on smartphones. While it’s easy to connect a USB-OTG hub to most smartphones (even my dirt-cheap Android smartphone supports this (now three years old)), having two keyboards on your desk can be kind of annoying.
While there are a bunch of possible solutions to this problem, many of these solutions do not fix the problem when you’re not on your home setup. Which is why I often just use QR codes to send URLs to my phone, and there are a lot of QR code generator sites out there.
QR code generator sites are useful because they work everywhere, but many are slow and clunky. Perhaps acceptable in a pinch, but… what if you could just generate QR codes on the terminal?
Well, some cursory googling revealed this library: https://github.com/qpliu/qrencode-go, which doesn’t have any external (non-standard library) dependencies, is short enough to skim over for malicious code, and comes with an easily adapted example. (I am reasonably confident that there is no malicious code at ad8353b4581fa11fc01a50ebf56db3833462fc13.)
Note: I very rarely use Go. Here is what I did to compile this:
$ git clone https://github.com/qpliu/qrencode-go
$ mkdir src
$ mv qrencode/ src/
$ cat > qrcodegenerator.go
package main
import (
"bytes"
"os"
"qrencode"
)
func main() {
var buf bytes.Buffer
for i, arg := range os.Args {
if i > 1 {
if err := buf.WriteByte(' '); err != nil {
panic(err)
}
}
if i > 0 {
if _, err := buf.WriteString(arg); err != nil {
panic(err)
}
}
}
grid, err := qrencode.Encode(buf.String(), qrencode.ECLevelQ)
if err != nil {
panic(err)
}
grid.TerminalOutput(os.Stdout)
}
$ GOPATH=$PWD go build qrcodegenerator.go
$ ./qrcodegenerator test
// QR CODE IS OUTPUT HERE
Note: the above code is adapted from example code in the README.md file and is therefore LGPL3.
Since Go binaries are static (that’s what I’ve heard at least), you can then move the executable anywhere you like (e.g. ~/bin) and generate QR codes anywhere. Note that they’re pretty huge, i.e. for ‘https://blog.qiqitori.com’ (26 bytes) the QR code’s width will be 62 characters. For e.g. ‘https://blog.qiqitori.com/2020/10/outputting-qr-codes-on-the-terminal/’ (this post) the width is 86 characters.
Skype for Business:
Accept any substitute.
If it's broke, don't fix it.
If it ain't broke, fix it.
Form follows malfunction.
The Cutting Edge of Obsolescence.
The trailing edge of software technology.
Armageddon never looked so good.
Japan's secret weapon.
You'll envy the dead.
Making the world safe for competing communication tools.
Let it get in YOUR way.
The problem for your problem.
If it starts working, we'll fix it. Pronto.
It could be worse, but it'll take time.
Simplicity made complex.
The greatest productivity aid since typhoid.
Flakey and built to stay that way.
One thousand monkeys. One thousand Windows 8 machines. One thousand years.
Skype for Business.
%
Skype for Business:
It's not how slow you make it. It's how you make it slow.
The communication tool preferred by masochists 3 to 1.
Built to take on the world... and lose!
Don't try it 'til you've knocked it.
Power tools for Power Fools.
Putting new limits on productivity.
The closer you look, the cruftier we look.
Design by counterexample.
A new level of software disintegration.
No hardware is safe.
Do your time.
Rationalization, not realization.
Old-world software cruftsmanship at its finest.
Gratuitous incompatibility.
Your mother.
THE user interference management system.
You can't argue with failure.
You haven't died 'til you've used it.
The environment of today... tomorrow!
Skype for Business.
%
Skype for Business:
Something you can be ashamed of.
30% more entropy than the leading communication tool.
The first fully modular software disaster.
Rome was destroyed in a day.
Warn your friends about it.
Climbing to new depths. Sinking to new heights.
An accident that couldn't wait to happen.
Don't wait for the movie.
Never use it after a big meal.
Need we say less?
Plumbing the depths of human incompetence.
It'll make your day.
Don't get frustrated without it.
Power tools for power losers.
A software disaster of Biblical proportions.
Never had it. Never will.
The software with no visible means of support.
More than just a generation behind.
Hindenburg. Titanic. Edsel.
Skype for Business.
%
Skype for Business:
The ultimate bottleneck.
Flawed beyond belief.
The only thing you have to fear.
Somewhere between chaos and insanity.
On autopilot to oblivion.
The joke that kills.
A disgrace you can be proud of.
A mistake carried out to perfection.
Belongs more to the problem set than the solution set.
To err is Skype for Business.
Ignorance is our most important resource.
Complex nonsolutions to simple nonproblems.
Built to fall apart.
Nullifying centuries of progress.
Falling to new depths of inefficiency.
The last thing you need.
The defacto substandard.
Elevating brain damage to an art form.
Skype for Business.
%
Skype for Business:
We will dump no core before its time.
One good crash deserves another.
A bad idea whose time has come. And gone.
We make excuses.
It didn't even look good on paper.
You laugh now, but you'll be laughing harder later!
A new concept in abuser interfaces.
How can something get so bad, so quickly?
It could happen to you.
The art of incompetence.
You have nothing to lose but your lunch.
When uselessness just isn't enough.
More than a mere hindrance. It's a whole new barrier!
When you can't afford to be right.
And you thought we couldn't make it worse.
If it works, it isn't Skype for Business.
%
Skype for Business:
You'd better sit down.
Don't laugh. It could be YOUR thesis project.
Why do it right when you can do it wrong?
Live the nightmare.
Our bugs run faster.
When it absolutely, positively HAS to crash overnight.
There ARE no rules.
You'll wish we were kidding.
Everything you never wanted in a communication tool. And more.
Dissatisfaction guaranteed.
There's got to be a better way.
The next best thing to keypunching.
Leave the thrashing to us.
We wrote the book on core dumps.
Even your dog won't like it.
More than enough rope.
Garbage at your fingertips.
Incompatibility. Shoddiness. Uselessness.
Skype for Business.Adapted from https://lwn.net/Articles/26612/.
Making new discoveries usually requires knowledge from previous discoveries. Discoveries are published as text in research papers. Scientists find these research papers using keywords they plug into a search engine or when other research papers cite them. Being able to search by keywords has obviously made scientific research much easier than before.
However, the research papers themselves are still written in natural languages, and unless the authors avoid using grammatical features like the words “it” or “them” to avoid repeating nouns over and over again, it’s difficult to extract meaning from them.
So perhaps people shouldn’t be writing research papers in (e.g.) English and instead use something that is easier for computers to parse. The research paper would contain claims, some numeric indicator for how certain these claims are (or from where they came), how these claims came about (e.g. experiment (with instructions for how and experiment was set up and why), logical reasoning (with the actual chain of reasoning), etc.). Then you could, for example, search for claims, instead of just keywords.
Instead of just using the keywords “ocean plastic waste”, you could search for “plastic waste in oceans negatively impacts ocean fauna”. Instead of typing in this query, you would choose every noun, verb and other qualifiers from a searchable menu. You would be able to display this menu in any language. The words in the menu would all mean a specific thing, and anybody would be able to look at the definitions and properties of every word. Eventually, the system could be programmed to (e.g.) look at two different claims and judge whether these claims might be related, based on common subjects or objects, and generate potential new claims all by itself. For example, claim 1: “Thunderstorms may under certain circumstances cause blackouts” and claim 2: “Certain atmospheric conditions cause thunderstorms” would logically mean that “certain atmospheric conditions cause blackouts”, which is true. The system probably shouldn’t let users use the word “certain” though.
How hard would it be to make such a system? Well, it’s best to start in a single niche and slowly expand the system. Here’s a very simple (completely static) example that is a bit different in that it just generates natural English or Japanese text based on what values are selected in the menus: https://blog.qiqitori.com/cve_generator/
Saving the selections would be a first step in the right direction. Currently, only one “allows attackers to:” is allowed, but you would probably want to 1) allow an arbitrary-length chain 2) something indicating the author’s degree of certainty (“may allow”), 3) add other verbs, other nouns, and 4) the reasoning behind a set of these claims (it gets complex here, but in the end you just have to select subjects, verbs, and objects, ifs, etc.).
Perhaps selecting things from a menu would get old quick (unless you just do it for the main claims). So the computer could try its best to analyze a sentence and ask the user to confirm that its interpretation is correct. The preceding sentence could be analyzed like this, but you’ll see that this could be tricky and just selecting something from a menu might be the better option after all: So [potential solution for previous follows:] the computer [the software] could try its best [could potentially (but probably wouldn’t manage to do this perfectly)] to analyze a sentence [analyze a given input sentence] and [afterwards] ask the user to [force the user] confirm that its [the software’s] interpretation [of the given input sentence] is correct [confirm … or force the user to edit the interpretation using a menu]. As you can see, there is a lot of context involved, which makes it hard to derive (e.g.) claims from natural text.
As you can see in the CVE generator, having the facts makes it somewhat easy for the system to generate text in any language for humans to read and think about