iTranslated by AI
2022 Year in Review
Overall Summary
A year that didn't go as planned due to various unexpected events. From things I gave up on because of changes in international affairs, to ruining December with a "once-in-several-years" level terrible mistake...
I've been dabbling in various things, but it's tough because I haven't been able to produce results of just the right size. Well, I suppose it's inevitable to have periods like this.
Highlight of the Year
This year, the number of articles was low—just one experimental post. Next year, I want to wrap up more small tips into articles. I've been writing extremely detailed experiments in my Scraps, but based on my experience reporting a Scraps bug on GitHub, I get the feeling that I might be the only one using it this way... I'm really sorry about that...
The single article itself was very well-received, gathering a triple-digit number of likes.
With the introduction of Passkeys on iOS and Android, the LastPass leak, and My Number cards becoming a topic of conversation (for better or worse), this year saw authentication and its security come into the spotlight. The response to my article suggested that awareness of TOTP is growing, so I want to keep valuing my reflexes in turning ideas into articles.
However, unlike when I was in charge of kernels, security isn't really my main business now, so I'd like to write a wider variety of articles rather than just aiming for popularity. I describe my current main job as a "pro gamer" (playing games skillfully[1] to find bugs rather than high scores), but since that's ultimately a miscellaneous task, writing articles about it can be difficult...
Next year, for now, I won't chase the response per article, but I'll strive to ensure the total output exceeds what I did this year.
OTP is now gaining general recognition as "that thing where you enter a few extra mysterious digits."
However, as mentioned in the article, I expect OTP to be replaced by more "secure" (connected) authenticators in the future. Security and being "connected" are increasingly becoming synonymous. I feel this is a very dangerous sign that isn't getting much attention.
Looking at things around us that "cannot be done on a PC website but can be done from a mobile phone"—from McDonald's mobile orders to the Myna Portal—it's clear that vendor lock-in, shielded by "security," is increasing. In the short term, this trend is unlikely to change.
Project Progress
Progress has been quite slow. In my work, I set milestones and achieve things one by one, but since this is my own project funded by myself, I think the lack of necessity to report to others is a factor.
In that sense, the "article-driven" approach of needing to post on Zenn should be good, but I just haven't found many good angles...
War
When looking back later, I can't avoid mentioning this. A game I was personally making had a quite heavy war theme, and the current situation is so different from what I expected that I've shelved it for now.
I think games are a format relatively close to picture books (unlike manga, they assume full screen, etc.), and I feel like the timeliness of theme selection is also similar. Historically, picture books haven't avoided adult themes, but in reality, I feel that social circumstances have changed beyond that stage.
mosh(-scheme)
There is a Scheme implementation called Mosh[2] created by Mr. higepon (https://github.com/higepon/mosh). It was suddenly revived to support M1 Macs, including build fixes and R7RS (the current latest Scheme standard) support.
I wrote about my involvement with Mosh in my first Zenn article (2020):
For this release, I worked on setting up CI for multiple environments, bug hunting, and organizing build-related matters. Also, the R7RS runtime uses code originated from yuni. Because of this, yuni doesn't currently support Mosh, but I expect that to be resolved eventually.
And I still haven't figured out why it crashes on Intel Mac and FreeBSD when running complex scripts. Mosh uses Boehm GC, and since it runs normally when GC is disabled, I'm almost certain it's prematurely freeing objects currently in use...
Next year... maybe I can track this down by utilizing debugger scripting? Collecting all heap allocation/deallocation addresses and backtraces might be relatively easy...?
Schemes that dropped out of the M1 environment include historical implementations like Larceny and MIT/GNU Scheme. However, MIT-Scheme is still undergoing major development, cutting Win32 support completely and almost entirely rewriting syntax-rules. Although Mosh itself is not a JITC-based implementation, on M1 Macs, there is a so-called W^X requirement, where you need to switch modes using a dedicated API before writing out JIT-compiled code. JITC for languages like Scheme often involves very small compilation units, which can be problematic if instruction sequences cannot be written out via simple loads and stores. Chez Scheme, a well-known implementation, did not support M1 Macs directly, but it seems support will be added soon as they are moving towards incorporating basically all the changes made in Racket.
yuni
I've been investigating the Ribbit Scheme implementation, creating a clone, and making it compatible with other Scheme features.
Ribbit has a striking feature: it can be ported anywhere as long as you can represent an any-type array https://github.com/udem-dlteam/ribbit/tree/d0082a08df12efca921d37daf04d64fb4ad63b78/src/host. Its detailed characteristics are in last year's paper https://www.iro.umontreal.ca/~feeley/papers/YvonFeeleyVMIL21.pdf. In essence, by using a 3-length array (called a "rib") to represent Lisp-like cons cells and VM instruction sequences, it claims that a processing system with reasonable performance can be realized compactly even in environments like shell scripts.
However, Ribbit's functionality is a bit too limited to be used as a regular Scheme implementation, so I demonstrated that basic features like variable-length arguments and multiple return values could be added. Well, I don't use multiple values much, so I just used an emulation implementation that always triggers heap allocation.
Next year, I want to implement basic libraries and FFI on this extended Ribbit to make it practically usable on microcontrollers. ...To do that, I need to provide basic libraries like file I/O, which is a bit tedious...
yunipocket
In last year's review, I wrote about whether I could create a smartphone-like toy. Since then, I ended up walking all over the Kanto region for experiments, trying various methods. I doubt I'll ever have another year in my life where I walk this much.
Since handheld devices are heavily influenced by environmental factors, if it's intended for long periods of carrying and movement, it's necessary to actually move continuously as much as possible. For this reason, I've been walking tirelessly, choosing places like riverbanks or along highways where I can move for long periods without getting lost and without needing to look at a map.
As a result, I lost over 10kg. I was at a normal weight originally, so I've somewhat sacrificed my health. It's also been a sacrifice of money, so I'll have to stick to my neighborhood next year. I want to organize the experiment details in an article, but while things like onsite debugging and sensor waveform recording are interesting as topics, I'm holding off because I'm not confident in my ability to make an article about physically demanding tasks entertaining.
The "play" aspect as a toy is also a dilemma. With solar cells + supercapacitor power, a pedometer and Bluetooth are the limits. The fact that it needs to be worn somewhere it can charge makes the appearance look too bad. So I'm thinking maybe battery-powered with a camera + GPS...
This year, partly because the project didn't solidify, I ended up modifying existing products or using emulation. Next year, I want to start building the platform properly. If I cut down on the crazy transportation costs I wasted this year (costing 5,000 yen for one round trip x 5 times a month), I should be able to afford the budget for prototyping.
In the past, there was a concept like the Strap Phone, but I feel many people are skeptical about whether there is really a "second device demand" for something that functionally overlaps with a smartphone. However, a gadget you can toss in your bag and forget about might have potential... maybe? If it's battery-powered, unlike Li-ion, it'll be fine even if left alone for years.
yuniframe
Yuniframe has been used in small areas, and I hadn't been able to move it forward significantly, but as those commitments ended, I spent about two weeks updating the dependency libraries.
Yuniframe itself is pushing forward with the construction of a portability layer, as I wrote last year. While last year I focused on securing realistic games using Unity WebGL builds, this year I've also started investigating whether games from the Windows DirectX 9 generation (which WebGL can target) can be ported.
...However, to achieve that, Windows games must run on OpenGL ES, and I'm struggling quite a bit at that stage. In the past, Codeweavers made Wine for Android, so there should be a track record, but this time I'm working by attaching an OPENGL32.DLL compatibility layer to gl4es (https://github.com/ptitSeb/gl4es/) and using Wine's components directly for everything above OpenGL.
And this is not yet running on Yuniframe. Currently, I'm just using the Windows version of WineD3D (https://github.com/adolfintel/wined3d4win), so the game itself is running on Windows. That said, since Wine's compatibility (regarding games) is quite excellent, I'm not too worried about anything beyond GPU functionality. However, since the GPU is the one thing that can't be helped with CPU emulation, I need to find a web-friendly way to implement it.
The realization of research like Yuniframe—that is, a robust WebAssembly application framework for clients—is something I expect to be a solution for the "McDonald's mobile order cannot be done on PC" problem I mentioned above.
Disney+ already adopts such an architecture (separating logic into WebAssembly and implementing a separate platform abstraction layer for rendering, video, etc.):
This model has advantages such as making multi-platform deployment easier and allowing logic to be written in Rust, but it faces the challenge that the same framework cannot be used for applications other than video streaming.
When trying to make a wider range of apps, such as smartphone e-commerce apps, run on a platform like a web browser, rather than waiting for WASI to cover APIs like Payment or Web Push, I think it's more desirable to provide a platform that can efficiently mimic existing major APIs. In fact, WebGL was able to attract many applications by mimicking OpenGL.
Also, even if smartphone apps are ported as so-called HTML5 apps, analysis during crashes becomes difficult. If consumer apps are to be deployed on multiple platforms, WebAssembly should be chosen over JavaScript + DOM as the conversion target for logic (as in the case of Disney+), and a platform for that is likely required.
Both Google and Apple are maintaining and promoting web browsers as high-speed WebAssembly execution environments and rich API environments, so it's necessary to efficiently free-ride on these efforts.
Conversely, platformers like Google and Apple will likely change their APIs and packaging to increase platform dependency to hinder porting. In fact, Apple has stopped accepting LLVM bitcode in Xcode 14 and later, and Google's Integrity API, while not a feature directly related to networking, is part of Google Play and does not function without communicating with a server.
Next Year
Well, opportunities often come at times when you can't quite grasp them, but if you give up there, it's over...
Software Logistics
"Software Logistics" is a term I coined in the late 2000s for a software delivery strategy. I've presented it to high-ranking people in the past, but it didn't catch on at all, and I'm still searching for a way to make it resonate.
However, I believe the current situation is the biggest opportunity in the last ten years, and next year I hope to focus more on activities to persuade others, such as building a web app for analysis.
There is an idea that since software is created by people geographically distributed, it requires a logistics strategy similar to hardware products. In other words:
- If you don't take measures against people who are prone to introducing bugs, it becomes a hindrance to quality improvement.
- When development sites are dispersed globally, efficient delivery can be achieved by placing development and verification teams with time zones in mind.
- Ordering with lead times in mind—which in software means formulating and approving specifications—increases the certainty of delivery dates.
- Managing licenses for FOSS or purchased (externally procured) software and preventing contamination into other lines.
- Various expenses are opaque: distribution costs for application updates, analysis costs for crash reports, monitoring costs for SNS, etc., can all be costs stemming from software quality.
- ...
I believe we need to build tools to analyze these perspectives and make them work in coordination so that they can be handled collectively in one place as software logistics.
Individual solutions are supplied to the market in abundance. Products like Coverity can assign security warnings to individuals, and there are more than enough solutions like SBOM (Software BOM) to manage software created by others as a supply chain.
I have two main concerns:
-
There is a lack of observation tools directly linked to the build system, and the quality is insufficient. For example, while Coverity can refer to VCS history like Git to assign source code changes to individuals,
git blameis inherently weak against things like file renames, and there is no unified way to manually correct annotations. - There are no tools that truly cover the software lifecycle. Many companies use tools like JIRA to assign tasks to humans and manage progress. However, they rely on human operations to analyze data such as SBOMs and create tickets in JIRA.
Personally, I want to tackle the former problem more seriously. In the past, I've made proposals like build tracing, and I believe that inserting analysis into the build system is as important as improvements in a manufacturing setting.
As for the latter, I don't have a good idea at the moment. It might be better to train people who can oversee these things and aim for smooth operations rather than pursuing a software-based solution. In fact, whether it's the original logistics or its etymological root, military logistics, the part played by humans is quite large.
AR
This year, with the release of PICO 4 and major companies entering VRChat, I feel like VR was often in the news. However, personally, I believe AR has more potential than VR and the so-called "metaverse," and I think the "Year One of AR" might come within the next year or two. After all, humans cannot escape reality.
Humans exist physically.
While VR (excluding self-contained content like games) feels like it has ultimately become a competition for locking in users to communication platforms, I want to explore what the key technologies are to prevent that from happening with AR.
I think modern AR tends to be too preoccupied with successfully compositing CG onto camera images. There should be AR-like ideas that work in a broader scope, such as regular web browsing, and I believe the central effort will be proposing the next "reality" that gains public support.
Discussion