More from Computer Things
Short one this time because I have a lot going on this week. In computation complexity, NP is the class of all decision problems (yes/no) where a potential proof (or "witness") for "yes" can be verified in polynomial time. For example, "does this set of numbers have a subset that sums to zero" is in NP. If the answer is "yes", you can prove it by presenting a set of numbers. We would then verify the witness by 1) checking that all the numbers are present in the set (~linear time) and 2) adding up all the numbers (also linear). NP-complete is the class of "hardest possible" NP problems. Subset sum is NP-complete. NP-hard is the set all problems at least as hard as NP-complete. Notably, NP-hard is not a subset of NP, as it contains problems that are harder than NP-complete. A natural question to ask is "like what?" And the canonical example of "NP-harder" is the halting problem (HALT): does program P halt on input C? As the argument goes, it's undecidable, so obviously not in NP. I think this is a bad example for two reasons: All NP requires is that witnesses for "yes" can be verified in polynomial time. It does not require anything for the "no" case! And even though HP is undecidable, there is a decidable way to verify a "yes": let the witness be "it halts in N steps", then run the program for that many steps and see if it halted by then. To prove HALT is not in NP, you have to show that this verification process grows faster than polynomially. It does (as busy beaver is uncomputable), but this all makes the example needlessly confusing.1 "What's bigger than a dog? THE MOON" Really (2) bothers me a lot more than (1) because it's just so inelegant. It suggests that NP-complete is the upper bound of "solvable" problems, and after that you're in full-on undecidability. I'd rather show intuitive problems that are harder than NP but not that much harder. But in looking for a "slightly harder" problem, I ran into an, ah, problem. It seems like the next-hardest class would be EXPTIME, except we don't know for sure that NP != EXPTIME. We know for sure that NP != NEXPTIME, but NEXPTIME doesn't have any intuitive, easily explainable problems. Most "definitely harder than NP" problems require a nontrivial background in theoretical computer science or mathematics to understand. There is one problem, though, that I find easily explainable. Place a token at the bottom left corner of a grid that extends infinitely up and right, call that point (0, 0). You're given list of valid displacement moves for the token, like (+1, +0), (-20, +13), (-5, -6), etc, and a target point like (700, 1). You may make any sequence of moves in any order, as long as no move ever puts the token off the grid. Does any sequence of moves bring you to the target? This is PSPACE-complete, I think, which still isn't proven to be harder than NP-complete (though it's widely believed). But what if you increase the number of dimensions of the grid? Past a certain number of dimensions the problem jumps to being EXPSPACE-complete, and then TOWER-complete (grows tetrationally), and then it keeps going. Some point might recognize this as looking a lot like the Ackermann function, and in fact this problem is ACKERMANN-complete on the number of available dimensions. A friend wrote a Quanta article about the whole mess, you should read it. This problem is ludicrously bigger than NP ("Chicago" instead of "The Moon"), but at least it's clearly decidable, easily explainable, and definitely not in NP. It's less confusing if you're taught the alternate (and original!) definition of NP, "the class of problems solvable in polynomial time by a nondeterministic Turing machine". Then HALT can't be in NP because otherwise runtime would be bounded by an exponential function. ↩
I have a lot in the works for the this month's Logic for Programmers release. Among other things, I'm completely rewriting the chapter on Logic Programming Languages. I originally showcased the paradigm with puzzle solvers, like eight queens or four-coloring. Lots of other demos do this too! It takes creativity and insight for humans to solve them, so a program doing it feels magical. But I'm trying to write a book about practical techniques and I want everything I talk about to be useful. So in v0.9 I'll be replacing these examples with a couple of new programs that might get people thinking that Prolog could help them in their day-to-day work. On the other hand, for a newsletter, showcasing a puzzle solver is pretty cool. And recently I stumbled into this post by my friend Pablo Meier, where he solves a videogame puzzle with Prolog:1 Summary for the text-only readers: We have a test with 10 true/false questions (denoted a/b) and four student attempts. Given the scores of the first three students, we have to figure out the fourth student's score. bbababbabb = 7 baaababaaa = 5 baaabbbaba = 3 bbaaabbaaa = ??? You can see Pablo's solution here, and try it in SWI-prolog here. Pretty cool! But after way too long studying Prolog just to write this dang book chapter, I wanted to see if I could do it more elegantly than him. Code and puzzle spoilers to follow. (Normally here's where I'd link to a gentler introduction I wrote but I think this is my first time writing about Prolog online? Uh here's a Picat intro instead) The Program You can try this all online at SWISH or just jump to my final version here. :- use_module(library(dif)). % Sound inequality :- use_module(library(clpfd)). % Finite domain constraints First some imports. dif lets us write dif(A, B), which is true if A and B are not equal. clpfd lets us write A #= B + 1 to say "A is 1 more than B".2 We'll say both the student submission and the key will be lists, where each value is a or b. In Prolog, lowercase identifiers are atoms (like symbols in other languages) and identifiers that start with a capital are variables. Prolog finds values for variables that match equations (unification). The pattern matching is real real good. % ?- means query ?- L = [a,B,c], [Y|X] = [1,2|L], B + 1 #= 7. B = 6, L = [a, 6, c], X = [2, a, 6, c], Y = 1 Next, we define score/33 recursively. % The student's test score % score(student answers, answer key, score) score([], [], 0). score([A|As], [A|Ks], N) :- N #= M + 1, score(As, Ks, M). score([A|As], [K|Ks], N) :- dif(A, K), score(As, Ks, N). First key is the student's answers, second is the answer key, third is the final score. The base case is the empty test, which has score 0. Otherwise, we take the head values of each list and compare them. If they're the same, we add one to the score, otherwise we keep the same score. Notice we couldn't write if x then y else z, we instead used pattern matching to effectively express (x && y) || (!x && z). Prolog does have a conditional operator, but it prevents backtracking so what's the point??? A quick break about bidirectionality One of the coolest things about Prolog: all purely logical predicates are bidirectional. We can use score to check if our expected score is correct: ?- score([a, b, b], [b, b, b], 2). true But we can also give it answers and a key and ask it for the score: ?- score([a, b, b], [b, b, b], X). X = 2 Or we could give it a key and a score and ask "what test answers would have this score?" ?- score(X, [b, b, b], 2). X = [b, b, _A], dif(_A,b) X = [b, _A, b], dif(_A,b) X = [_A, b, b], dif(_A,b) The different value is written _A because we never told Prolog that the array can only contain a and b. We'll fix this later. Okay back to the program Now that we have a way of computing scores, we want to find a possible answer key that matches all of our observations, ie gives everybody the correct scores. key(Key) :- % Figure it out score([b, b, a, b, a, b, b, a, b, b], Key, 7), score([b, a, a, a, b, a, b, a, a, a], Key, 5), score([b, a, a, a, b, b, b, a, b, a], Key, 3). So far we haven't explicitly said that the Key length matches the student answer lengths. This is implicitly verified by score (both lists need to be empty at the same time) but it's a good idea to explicitly add length(Key, 10) as a clause of key/1. We should also explicitly say that every element of Key is either a or b.4 Now we could write a second predicate saying Key had the right 'type': keytype([]). keytype([K|Ks]) :- member(K, [a, b]), keytype(Ks). But "generating lists that match a constraint" is a thing that comes up often enough that we don't want to write a separate predicate for each constraint! So after some digging, I found a more elegant solution: maplist. Let L=[l1, l2]. Then maplist(p, L) is equivalent to the clause p(l1), p(l2). It also accepts partial predicates: maplist(p(x), L) is equivalent to p(x, l1), p(x, l2). So we could write5 contains(L, X) :- member(X, L). key(Key) :- length(Key, 10), maplist(contains([a,b]), L), % the score stuff Now, let's query for the Key: ?- key(Key) Key = [a, b, a, b, a, a, b, a, a, b] Key = [b, b, a, b, a, a, a, a, a, b] Key = [b, b, a, b, a, a, b, b, a, b] Key = [b, b, b, b, a, a, b, a, a, b] So there are actually four different keys that all explain our data. Does this mean the puzzle is broken and has multiple different answers? Nope The puzzle wasn't to find out what the answer key was, the point was to find the fourth student's score. And if we query for it, we see all four solutions give him the same score: ?- key(Key), score([b, b, a, a, a, b, b, a, a, a], Key, X). X = 6 X = 6 X = 6 X = 6 Huh! I really like it when puzzles look like they're broken, but every "alternate" solution still gives the same puzzle answer. Total program length: 15 lines of code, compared to the original's 80 lines. Suck it, Pablo. (Incidentally, you can get all of the answer at once by writing findall(X, (key(Key), score($answer-array, Key, X)), L).) I still don't like puzzles for teaching The actual examples I'm using in the book are "analyzing a version control commit graph" and "planning a sequence of infrastructure changes", which are somewhat more likely to occur at work than needing to solve a puzzle. You'll see them in the next release! I found it because he wrote Gamer Games for Lite Gamers as a response to my Gamer Games for Non-Gamers. ↩ These are better versions of the core Prolog expressions \+ (A = B) and A is B + 1, because they can defer unification. ↩ Prolog-descendants have a convention of writing the arity of the function after its name, so score/3 means "score has three parameters". I think they do this because you can overload predicates with multiple different arities. Also Joe Armstrong used Prolog for prototyping, so Erlang and Elixir follow the same convention. ↩ It still gets the right answers without this type restriction, but I had no idea it did until I checked for myself. Probably better not to rely on this! ↩ We could make this even more compact by using a lambda function. First import module yall, then write maplist([X]>>member(X, [a,b]), Key). But (1) it's not a shorter program because you replace the extra definition with an extra module import, and (2) yall is SWI-Prolog specific and not an ISO-standard prolog module. Using contains is more portable. ↩
My April Cools is out! Gaming Games for Non-Gamers is a 3,000 word essay on video games worth playing if you've never enjoyed a video game before. Patreon notes here. (April Cools is a project where we write genuine content on non-normal topics. You can see all the other April Cools posted so far here. There's still time to submit your own!) April Cools' Club
Logic for Programmers v0.8 now out! The new release has minor changes: new formatting for notes and a better introduction to predicates. I would have rolled it all into v0.9 next month but I like the monthly cadence. Get it here! Betteridge's Law of Software Engineering Specialness In There is No Automatic Reset in Engineering, Tim Ottinger asks: Do the other people have to live with January 2013 for the rest of their lives? Or is it only engineering that has to deal with every dirty hack since the beginning of the organization? Betteridge's Law of Headlines says that if a journalism headline ends with a question mark, the answer is probably "no". I propose a similar law relating to software engineering specialness:1 If someone asks if some aspect of software development is truly unique to just software development, the answer is probably "no". Take the idea that "in software, hacks are forever." My favorite example of this comes from a different profession. The Dewey Decimal System hierarchically categorizes books by discipline. For example, Covered Bridges of Pennsylvania has Dewey number 624.37. 6-- is the technology discipline, 62- is engineering, 624 is civil engineering, and 624.3 is "special types of bridges". I have no idea what the last 0.07 means, but you get the picture. Now if you look at the 6-- "technology" breakdown, you'll see that there's no "software" subdiscipline. This is because when Dewey preallocated the whole technology block in 1876. New topics were instead to be added to the 00- "general-knowledge" catch-all. Eventually 005 was assigned to "software development", meaning The C Programming Language lives at 005.133. Incidentally, another late addition to the general knowledge block is 001.9: "controversial knowledge". And that's why my hometown library shelved the C++ books right next to The Mothman Prophecies. How's that for technical debt? If anything, fixing hacks in software is significantly easier than in other fields. This came up when I was interviewing classic engineers. Kludges happened all the time, but "refactoring" them out is expensive. Need to house a machine that's just two inches taller than the room? Guess what, you're cutting a hole in the ceiling. (Even if we restrict the question to other departments in a software company, we can find kludges that are horrible to undo. I once worked for a company which landed an early contract by adding a bespoke support agreement for that one customer. That plagued them for years afterward.) That's not to say that there aren't things that are different about software vs other fields!2 But I think that most of the time, when we say "software development is the only profession that deals with XYZ", it's only because we're ignorant of how those other professions work. Short newsletter because I'm way behind on writing my April Cools. If you're interested in April Cools, you should try it out! I make it way harder on myself than it actually needs to be— everybody else who participates finds it pretty chill. Ottinger caveats it with "engineering, software or otherwise", so I think he knows that other branches of engineering, at least, have kludges. ↩ The "software is different" idea that I'm most sympathetic to is that in software, the tools we use and the products we create are made from the same material. That's unusual at least in classic engineering. Then again, plenty of machinists have made their own lathes and mills! ↩
I know I said we'd be back to normal newsletters this week and in fact had 80% of one already written. Then I unearthed something that was better left buried. Blog post here, Patreon notes here (Mostly an explanation of how I found this horror in the first place). Next week I'll send what was supposed to be this week's piece. (PS: April Cools in three weeks!)
More in programming
Right now, the General Union is handling cases at Japanese tech companies where well-established workplace practices have come under threat. These include businesses pushing for return-to-office mandates after years of remote work, eliminating flexible scheduling, and cutting bonuses and other forms of compensation. Sometimes these companies are altering work conditions that were never officially documented but had become standard practice. Other times, they’re trying to eliminate benefits explicitly written into contracts or work rules. In both cases, many workers believe they have no choice but to accept these changes. They’re wrong! Japanese labour law protects workers in two significant ways here. First, there’s the principle of established workplace practices (労使慣行, roudou kankou), protected through decades of court precedents, which can give unwritten customs the same legal weight as written rules. Then there’s Article 8 of the Labour Contract Law, which prevents employers from unilaterally changing documented working conditions. But having these legal protections is only half the battle. While the courts have established strong precedents, as an individual, pursuing these rights can be prohibitively difficult. Taking an employer to court is expensive, time-consuming, and potentially career-damaging. This is where collective action through unions becomes essential. Unions provide both the legal expertise and collective leverage needed to uphold these rights. For tech workers in Japan, these issues have never been more relevant. The tech industry’s desperate need for skilled workers, worth nearly 22 trillion yen in domestic investments, could create unprecedented leverage. By understanding their legal rights and organizing collectively, developers can effectively protect and even improve their workplace conditions in this critical moment. How the courts protect you A series of landmark cases in Japan created robust protections for workplace customs, also known as established employment practices. But what qualifies as an established employment practice? Yukiko Sadaoka, a regular collaborator with the General Union, explained how courts determine whether a workplace practice qualifies to be protected. “There are three main factors. One, a habit or fact must have been repeated and continued for a long period of time. Two, neither labour nor management has explicitly denied following the practice. And three, the practice must be supported by a normative awareness on both sides. The employers, especially those who control working conditions, must be aware of the practice.” Case 1: Post-Retirement Employment Practice (RECOGNISED) 東豊観光事件 (Toho Kanko), Osaka District Court 28, June 1990 In this order by the court, the company’s work regulations stated that the forced retirement age (定年, teinen) was 55. In practice, however, the company repeatedly kept employees on after they had reached this age. This custom continued for six years (1984–1990), during which 7 out of 8 employees who reached the age of 55 were retained. When the company terminated the 55 year-old plaintiff, citing the official retirement rule, the plaintiff sued for confirmation of employment status. The court stated that the practice of continued employment after 55 had become an established workplace custom. That custom overrode the written regulations, despite its relatively short period of practice, because it had been consistently applied to almost all employees who had reached the retirement age during that time. Case 2: Extra Pay for Substitute Holidays (DENIED) 商大八戸の里ドライビングスクール事件 (Syodai Yae-no-sato Driving School), Osaka High Court 25 June, 1993, and upheld by Supreme Court 9 March, 1995 Employees claimed entitlement to extra pay when working on a substitute holiday. The company’s policy was that every other Monday was a day off. If that particular Monday fell on a national holiday, Tuesday would become the substitute day off (振替休日, furikae kyuujitsu). The question was whether working on these Tuesday substitute holidays entitled workers to extra holiday pay. Although this practice had existed for 10 years, both the Osaka High Court, and the Supreme Court denied that it was an established workplace practice because the specific situation—working on a Tuesday substitute holiday—had only occurred 8–10 times during that period. This case demonstrates that frequency matters. Even when established over a lengthy period of time, if the actual instances of the practice are rare, it may not be considered established. Case 3: Bonus Amount Practice (PARTIALLY RECOGNISED) 立命館事件 (Ritsumeikan), Kyoto District Court 29 March 2012 (appealed, outcome uncertain) This case involved a bonus dispute. For 14 years, according to labour agreements (労働協約, roudou kyouyaku), the company had paid a bonus of 6.1 months’ salary plus 100,000 yen. However, there was no provision about bonuses in the company work rules (就業規則, shuugyou kisoku). When the employer announced the forthcoming bonus would be only 5.1 months’ salary, employees claimed the higher amount was an established practice. The court made an interesting distinction: It ruled that the specific amount (6.1 months + 100,000 yen) was NOT an established practice because there had been negotiations each year before agreeing on the amount, even though the final amount had always been the same. However, it recognised that “at least 6 months’ salary” had become an established practice, because the employer’s initial offer had never been lower than 6 months throughout the 14-year period. This case demonstrates the nuanced way courts examine whether a practice has created a legitimate expectation that can’t be unilaterally changed. These examples show that determining what constitutes an established workplace practice isn’t a simple matter of time. Courts look at consistency, frequency, specificity, and whether both sides understood the practice to be binding—even if they didn’t write it down. Other cases of interest The courts’ protection of established practices has occasionally been implemented in surprising ways. Take a case from 1968 that went all the way to the Tokyo High Court. The issue? Whether railway workers could continue their long-standing practice of using the company bath at 4 p.m. and clocking out at 4:30. At first glance, it might seem trivial—why fight over a bathing schedule? But the court’s decision was significant: after 13 years of this practice, with management’s knowledge and acceptance, it had become a legally-protected workplace custom that couldn’t be unilaterally changed. In the 1973 Shishido Shokai case (宍戸商会事件), the Tokyo District Court ruled that a company must pay severance to a voluntarily-resigned employee because consistent payment to other departing employees had established a binding workplace custom. The court classified these payments as deferred wages, confirming that consistent practices can create legal rights without written policies. Even when ruling in employers’ favour, courts have reinforced the importance of established practices. The 1982 Daiwa Bank case (大和銀行事件) upheld the bank’s long-standing practice of paying bonuses only to those still employed on payment dates, ruling that workers who left before payment weren’t entitled to bonuses despite working during the calculation period. These court precedents have established principles that apply universally across all industries. Whether a railway worker’s bathing schedule from the 1960s or solidifying employer rights, established employment practices are a real concept that can be parlayed into tech workers’ fight to maintain their working conditions. What does the law say? Article 8 of the Labour Contract Law also protects you against unilateral changes to working conditions. The law states, “A Worker and an Employer may, by agreement, change any working conditions that constitute the contents of a labour contract.” While the law is written in the positive, the inverse is what is important: “a worker and an employer cannot change working conditions without mutual agreement.” So, what constitutes the “contents of a labour contract”? Does this only deal with working conditions that are specifically written into your employment contract? According to General Union Chair Toshiaki Asari, “The idea that long-standing practices can become part of the employment contract and receive legal protection—even if they aren’t explicitly written—is well-established as a legal doctrine. Therefore, long-standing practices should also fall under the protections of Article 8 of the Labour Contract Law, just like written working conditions.” This perspective is supported by a significant 1991 Supreme Court ruling in the Hitachi Musashi Factory case (日立製作所武蔵工場事件). When an employee refused to work overtime during a production issue, claiming the request was unreasonable, the court found that the company’s consistent practice of requiring overtime in specific situations had become an implied term of employment—even without documentation. Because this practice was long-standing and implicitly accepted by employees over time, the court upheld the company’s disciplinary action. Though the ruling was in the employer’s favor, it also established that workplace customs, through consistent application and mutual understanding, can become legally binding components of employment contracts. Does this mean an employer can never change any working condition? The short answer is: they certainly can. This right of the employer to change working conditions is established in both Articles 9 and 10 of the Labour Contract Law. However, Article 9 also sets up a fundamental principle: employers cannot unilaterally change working conditions to workers’ disadvantage by modifying work rules without employee agreement. While Article 10 provides limited exceptions to this principle, it sets strict criteria that employers must meet. Any changes must be: Properly communicated to workers Reasonable given the degree of disadvantage to workers Necessary for the business Appropriate in their revised content Preceded by proper negotiations with unions or worker representatives This framework ensures that while employers can adapt to changing business needs, they cannot do so by simply imposing disadvantageous changes on workers without justification or prior consultation. The reality of defending your rights But what do these legal protections really mean in practice? Terms like disadvantages, reasonable, necessary, and appropriate sound reassuring on paper. Yet their practical meaning becomes far less clear when your employer suddenly demands you return to the office after five years of remote work, or changes how raises are calculated, or alters stock option arrangements. This is where the gap between legal rights and practical enforcement becomes stark. While the law provides a strong framework for protecting workplace practices, enforcing these rights as an individual is another matter entirely. Taking your employer to court is a long, expensive process that could take years to resolve, and that’s not only in the case of established employment practices. Even the seemingly clear prescriptions of the Labour Contract Law can only be enforced through court action. In the meantime, you’re stuck working under the contested conditions, while potentially damaging both your career and wellbeing. And remember, if you want to negotiate with your employer about changes to workplace practices, they have no legal obligation to even meet with you. They can simply ignore your requests or refuse outright. The power of collective action Unlike individual workers, who can be ignored or denied the chance to meet with management, employers cannot legally refuse to negotiate with a labour union. This right to collective bargaining is protected by the Trade Union Law. Even if you’re the only union member in your workplace, the company must negotiate with your union in good faith. The law also protects union members from retaliation or disadvantageous treatment. Unions offer multiple pathways for protecting workers’ rights and established employment practices. One key strategy is establishing prior consultation agreements (事前協議協定, jizen kyougi kyoutei), which require employers to inform and consult with the union before implementing changes to working conditions. By securing a seat at the table early, unions can influence decisions and propose alternatives before changes are implemented, rather than fighting them after the fact. Through collective bargaining, unions can also convert established workplace practices into written agreements, giving them stronger protection than relying on court precedents alone. By codifying these customs in collective agreements, they become immune to unilateral changes by employers. This matters because collective agreements sit at the top of the workplace rules hierarchy, superseding both individual contracts and company work rules—they’re the gold standard in protecting workers’ rights. True, an employer might still break a collective agreement, but unlike individual workers who can only turn to courts or government agencies, unions have multiple ways to respond. They can file complaints with the Labour Commission, as violating a collective agreement constitutes an unfair labour practice under the Trade Union Law. Most importantly, unions retain the right to take direct action through strikes and other collective measures—options simply not available to individual workers. As an individual, though, declaring union membership often shifts the power dynamic. When you’re backed by a union, you’re no longer facing the company alone. Many disputes are resolved at this early stage, as employers recognise that their actions will face greater scrutiny. While some employers might still attempt to violate the law, most understand that directly confronting unions by targeting their members creates more problems than it’s worth. Remember, your right to labour union representation is enshrined both in the Trade Union Law and Article 28 of the Constitution, which states that “The right of workers to organise and to bargain and act collectively is guaranteed.” Unions can also push beyond merely protecting existing rights, into negotiating improvements that particularly matter to tech workers—like expanded remote work options, clearer overtime compensation for project crunch times, training and skill development budgets, improved parental leave policies, and protections against excessive on-call rotations. Unions can also establish guidelines on emerging issues like AI implementation policies and the right to disconnect after working hours. Conclusion For developers, this situation presents a unique opportunity for collective action. Japan’s tech industry, worth nearly 22 trillion yen in domestic IT investments alone, mirrors the automotive industry of mid-20th century America—a wealthy, rapidly growing sector desperately in need of workers at all skill levels. Like the auto plants of Detroit, modern tech companies rely on a diverse workforce ranging from highly-paid specialists to entry-level developers. This combination—a wealthy industry, a significant labour shortage, and the critical role tech workers play in company operations—creates unprecedented leverage for collective action. Just as auto workers used their position to secure better wages and working conditions in the 1950s and 1960s, tech workers today could wield similar influence. The cost of lost productivity in tech companies can run into millions of yen per day, giving organised workers significant bargaining power. Moreover, unlike in traditional manufacturing where production delays might only affect future sales, many tech companies lose revenue immediately when work stops. By maintaining critical systems, supporting client operations, and keeping online services running, tech workers’ daily tasks directly impact their companies’ bottom lines. Even a small group of organised workers can effectively advocate for better conditions. That’s why understanding your legal rights under Japanese labour law is crucial—it provides the foundation for protecting established employment practices and knowing what you can rightfully demand. But knowledge alone isn’t enough. Whether these rights come from written contracts, established customs, or collective agreements, making them real requires more than just knowing they exist: it requires standing together to defend them. Through union membership, you combine legal protection with collective power—that is, you have both the law on your side and an active organisation working to protect your rights, with real mechanisms to enforce them.
Ahead of announcing the title and publisher of my thus-far-untitled book on engineering strategy in the next week or two, I put together a website for its content. That site is pretty much the same format as this blog, but with some improvements like better mobile rendering on / than this blog has historically had. After finishing that work, I ported the improvements back to lethain.com, but also decided to bring them to staffeng.com. That was slightly trickier because, unlike this blog, StaffEng was historically a Gatsby app. (Why a Gatsby app? Because Calm was using Gatsby for our web frontend and I wanted to get some experience with it.) Over the weekend, I took some time to migrate to Hugo and apply the same enhancements. which you can now see in the lethain:staff-eng repository or on staffeng.com. Here’s a screenshot of the old version. Then here’s a screenshot of the updated version. Overall, I think it’s slightly easier to read, and I took it as a chance to update the various links. For example, I removed the newsletter link and pointed that to this blog’s newsletter instead, given that one’s mailing list went quiet a long time ago. Speaking of going quiet, I also brought these updates to infraeng.dev, which is the very-stuck-in-time site for the book I may-or-may-not one day write about infrastructure engineering. That means that I now have four essentially equivalent Hugo sites running different content websites: this blog, staffeng.com, infraeng.dev, and the site for the upcoming book. All of these build and deploy automatically onto GitHub Pages, which has been an extremely easy, reliable workflow for me. While I was working on this, someone asked me why I don’t just write my own blog server to host my blogs. The answer here is pretty straightforward. I’ve written three blog servers for my blog over the years. The first two were in Python, and the last one was in Go. They all worked well enough, but maintaining them was eventually a pain point because they required a real build pipeline and deal with libraries that could have security issues. Even in the best case, the containers they run in would get end-of-lifed periodically as Ubuntu versions got deprecated. What I’ve slowly learned from that is that, as a frequent writer, you really want your content to live somewhere that can work properly for decades. Even small maintenance costs can be prohibitive over time, and I’ve seen some good blogs disappear rather than e.g. figure out a WordPress upgrade. Individually, these are all minor, but over decades they can really add up. This is also my argument against using hosted providers: I’m sure Substack will be around in five years, but I have no idea if Substack will be around in twenty years, but I know that I’ll still be writing then, and will also want my previous writing to still be accessible.
How can a business that is "spending to grow" determine whether it's truly profitable underneath all that "revenue acceleration?" Here's a way.
<![CDATA[I spoke too soon when I said I was enjoying the stability of Linux. I have been using Linux Mint Cinnamon on a System76 Merkaat PC with no major issues since July of 2024. But a few days ago a routine system update of Mint 22 dumped me to the text console. A fresh install of Mint 22.1, the latest release, brought the system back online. I had backups and the mishap luckily turned out as just an annoyance that consumed several hours of unplanned maintenance. It all started when the Mint Update Manager listed several packages for update, including the System76 driver and tools. Oddly, the Update Manager also marked for removal several packages including core ones such as Xorg, Celluloid, and more. The smooth running of Mint made my paranoid side fall asleep and I applied the recommend changes. At the next reboot the graphics session didn't start and landed me at the text console with no clue what happened. I don't use Timeshift for system snapshots as I prefer a fresh install and restore of data backups if the system breaks. Therefore, to fix such an issue apparently related to Mint 22 the obvious route was to install Mint 22.1. Besides, this was the right occasion to try the new release. On my Raspberry Pi 400 I ran dd to flash a bootable USB stick with Mint 22.1. I had no alternatives as GNOME Disks didn't work. The Merkaat failed to boot off the stick, possibly because I messed with the arguments of dd. I still had around a USB stick with Mint 22 and I used it to freshly install it on the Merkaat. Then I immediately ran the upgrade to Mint 22.1 which completed successfully unlike a prior upgrade attempt. Next, I tried to install the System76 driver with sudo apt install system76-driver but got a package not found error. At that point I had already added the System76 package repository to the APT sources and refreshing the Mint Update Manager yielded this error: Could not refresh the list of updates Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages Aside from the errors the system was up and running on the Merkaat, so with Nemo I reflashed the Mint 22.1 stick. This time the PC did boot off the stick and let me successfully install Mint 22.1. Restoring the data completed the system recovery. I left out the System76 driver as it's the primary suspect, possibly due to package conflicts. Mint detects and supports all hardware of the Merkaat anyway and it's only prudent to skip the package for the time being. Besides improvements under the hood, Mint 22.1 features a redesigned default Cinnamon theme. No major changes, I feel at home. The main takeaway of this adventure is that it's better to have a bootable USB stick ready with the latest Mint release, even if I don't plan to upgrade immediately. Another takeaway is the Pi 400 makes for a viable backup computer that can support my major tasks, should it take longer to recover the Merkaat. However, using the device for making bootable media is problematic as little flashing software is available and some is unreliable. Finally, over decades of Linux experience I honed my emergency installation skills so much I can now confidently address most broken system situations. #linux #pi400 a href="https://remark.as/p/journal.paoloamoroso.com/an-unplanned-upgrade-to-linux-mint-22-1-cinnamon"Discuss.../a Email | Reply @amoroso@fosstodon.org !--emailsub--]]>
Brace yourself, because I’m about to utter a sequence of words I never thought I would hear myself say: I really miss posting on Twitter. I really, really miss it. It’s funny, because Twitter was never not a trash fire. There was never a time when it felt like we were living through some kind […]