Culture
Just before I start, I would like to point out that this post may or would probably be NSFW. Again, what is SFW (Safe at Work) and NSFW that so much depends on culture and perception of culture from wherever we are or wherever we take birth? But still, to be on the safe side I have put it as NSFW. Now there have been a few statements and ideas that gave me a pause. This will be a sort of chaotic blog post as I am in such a phase today.
For e.g. while I do not know which culture or which country this comes from, somebody shared that in some cultures one can talk/comment May your poop be easy and with a straight face. I dunno which culture is this but if somebody asked me that I would just die from laughing or maybe poop there itself. While I can understand if it is a constipated person, but a whole culture? Until and unless their DNA is really screwed, I don t think so but then what do I know? I do know that we shit when we have extreme reactions of either joy or fear. And IIRC, this comes from mammal response when they were in dangerous situations and we got the same as humans evolved. I would really be interested to know which culture is that. I did come to know that the Japanese do wish that you may not experience hard work or something to that effect while ironically they themselves are becoming extinct due to hard work and not enough relaxation, toxic workplace is common in Japan according to social scientists and population experts.
Another term that I couldn t figure out is The Florida Man Strikes again and this term is usually used when somebody does something stupid or something weird. While it is exclusively used in the American context, I am curious to know how that came about. Why does Florida have such people or is it an exaggeration? I have heard the term e.g. What happens in Vegas, stays in Vegas . Think it is also called Sin city although why just Vegas is beyond me?
Omicron-8712 Blood pressure machine
I felt so stupid. I found another site or e-commerce site called Wellness Forever. They had the blood pressure machine I wanted, an Omron-8172. I bought it online and they delivered the same within half an hour. Amazon took six days and in the end, didn t deliver it at all.
I tried taking measurements from it yesterday. I have yet to figure out what it all means but I did get measurements of 109 SYS, 88 DIA and Pulse is 72. As far as the pulse is concerned, guess that is normal, the others just don t know. If only I had known this couple of months ago. I was able to register the product as well as download and use the Omron Connect app. For roughly INR 2.5k you have a sort of health monitoring system. It isn t Star Trek Tricorder in any shape or form but it will have to do while the tricorder gets invented. And while we are on the subject let s not forget Elizabeth Holmes and the scam called Theranos. It really is something to see How Elizabeth Holmes modeled so much of herself on Steve Jobs mimicking how he left college/education halfway. A part of me is sad that Theranos is not real. Joe Scott just a few days ago shared some perspectives on the same just a few days ago. The idea in itself is pretty seductive, to say the least, and that is the reason the scam went on for more than a decade and perhaps would have been longer if some people hadn t gotten the truth out.
I do see potentially, something like that coming on as A.I. takes a bigger role in automating testing. Half a decade to a decade from now, who knows if there is an algorithm that is able to do what is needed? If such a product were to come to the marketplace at a decent price, it would revolutionize medicine, especially in countries like India, South Africa, and all sorts of remote places. Especially, with all sorts of off-grid technologies coming and maturing in the marketplace. Before I forget, there is a game called Cell on Android that tells or shares about the evolution of life on earth. It also shares credence to the idea that life has come 6 times on Earth and has been destroyed multiple times by asteroids. It is in the idle sort of game format, so you can see the humble beginnings from the primordial soup to various kinds of cells and bacteria to finally a mammal. This is where I am and a long way to go.
Indian Bureaucracy
One of the few things that Britishers gave to India, is the bureaucracy and the bureaucracy tests us in myriad ways. It would be full 2 months on 5th September and I haven t yet got a death certificate. And I need that for a sundry number of things. The same goes for a disability certificate. What is and was interesting is my trip to the local big hospital called Sassoon Hospital. My mum had shared incidents that occurred in the 1950s when she and the family had come to Pune. According to her, when she was alive, while Sassoon was the place to be, it was big and chaotic and you never knew where you are going. That was in 1950, I had the same experience in 2022. The term/adage the more things change, the more they remain the same seems to be held true for Sassoon Hospital.
Btw, those of you who think the Devil exists, he is totally a fallacy. There is a popular myth that the devil comes to deal that he/she/they come to deal with you when somebody close to you passes, I was waiting desperately for him when mum passed. Any deal that he/she/they would have offered me I would have gladly taken, but all my wait was all for nothing. While I believe evil exists, that is manifested by humans and nobody else. The whole idea and story of the devil is just to control young children and nothing beyond that
Debconf 2023, friends, JPEGOptim, and EV s
Quite a number of friends had gone to Albania this year as India won the right to host Debconf for the year 2023. While I did lurk on the Debconf orga IRC channel, I m not sure how helpful I would be currently. One news that warmed my heart is some people would be coming to India to check the site way before and make sure things go smoothly. Nothing like having more eyes (in this case bodies) to throw at a problem and hopefully it will be sorted. While I have not been working for the last couple of years, one of the things that I had to do and have been doing is moving a lot of stuff online. This is in part due to the Government s own intention of having everything on the cloud. One of the things I probably may have shared it more than enough times is that the storage most of these sites give is like the 1990s. I tried jpegoptim and while it works, it degrades the quality of the image quite a bit. The whole thing seems backward, especially as newer and newer smartphones are capturing more data per picture (megapixel resolution), case in point Samsung Galaxy A04 that is being introduced. But this is not only about newer phones, even my earlier phone, Samsung J-5/500 which I bought in 2016 took images at 5 MB. So it is not a new issue but a continuous issue. And almost all Govt. sites have the upper band fixed at 1 MB. But this is not limited to Govt. sites alone, most sites in India are somewhat frozen in the 1990s. And it isn t as if resources for designing web pages using HTML5, CSS3, Javascript, Python, or Java aren t available. If worse comes to worst, one can even use amp to make his, her or their point. But this is if they want to do stuff. I would be sharing a few photos with commentary, there are still places where I can put photos apart from social media
Friends
Last week, Saturday suddenly all the friends decided to show up. I have no clue one way or the other why but am glad they showed up.
Mahendra, Akshat, Shirish and Sagar Sukhose (Mangesh s friend) at Bal Gandharva..
Electric scooter as shared by Akshat seen in Albania
Somebody making a real-life replica of Wall Street on F.C. Road (Commercial, all glass)
Ganesh Idol near my house
Wearing new clothes
I will have to be a bit rapid about what I am sharing above so here goes nothing
1. The first picture shows Mahendra, Akshat, me, and Sagar Sukhose (Mangesh s friend). The picture was taken by Mangesh Diwate. We talked quite a bit of various things that could be done in Debian. A few of the things that I shared were (bringing more stuff from BSD to Debian, I am sure there s still quite a lot of security software that could be advantageous to have in Debian.) The best person to talk to or guide about this would undoubtedly be Paul Wise or as he is affectionally called Pabs. He is one of the shy ones and yet knows so much about how things work. The one and only time I met him is 2016. The other thing that we talked about is porting Debian to one of the phones. This has been done in the past and done by a Puneitie some 4-5 years back. While I don t recollect the gentleman s name, I remember that the porting was done on a Motorola phone as that was the easiest to do. He had tried some other mobile but that didn t work. Making Debian available on phone is hard work. Just to have an idea, I went to the xda developers forum and found out that while M51 has been added, my specific phone model is not there. A Samsung Galaxy M52G Android (samsung; SM-M526B; lahaina; arm64-v8a) v12 . You look at the chat and you understand how difficult the process might be. One of the other ideas that Akshat pitched was Debian Astro, this is something that is close to the heart of many, including me. I also proposed to have some kind of web app or something where we can find and share about the various astronomy and related projects done by various agencies. While there is a NASA app, nothing comes close to JSR and that site just shares stuff, no speculation. There are so many projects taken or being done by the EU, JAXA, ISRO, and even middle-east countries are trying but other than people who are following some of the developments, we hear almost nothing. Even the Chinese have made some long strides but most people know nothing about the same. And it s sad to know that those developments are not being known, shared, or even speculated about as much as say NASA or SpaceX is. How do we go about it and how do we get people to contribute or ask questions around it would be interesting.
2. The second picture was something that was shared by Akshat. Akshat was sharing how in Albania people are moving on these electric scooters . I dunno if that is the right word for it or what. I had heard from a couple of friends who had gone to Vietnam a few years ago how most people in Vietnam had modified their scooters and they were snaking lines of electric wires charging scooters. I have no clue whether they were closer to Vespa or something like above. In India, the Govt. is in partnership with the oil, gas, and coal mafia just as it was in Australia (the new Govt. in Australia is making changes) the same thing is here. With the humongous profits that the oil sector provides the petro states and others, Corruption is bound to happen. We talk and that s the extent of things.
3. The third picture is from a nearby area called F.C. Road or Fergusson College Road. The area has come up quite sharply (commercially) in the last few years. Apparently, Mr. Kushal is making a real-life replica of Wall Street which would be given to commercial tenants. Right now the real estate market is tight in India, we will know how things pan out in the next few years.
4. Number four is an image of a Ganesh idol near my house. There is a 10-day festival of the elephant god that people used to celebrate every year. For the last couple of years because of the pandemic, people were unable to celebrate the festival as it is meant to celebrate. This time some people are going overboard while others are cautious and rightfully so.
5. Last and not least, one of the things that people do at this celebration is to have new clothes, so I shared a photo of a gentleman who had bought and was wearing new clothes. While most countries around the world are similar, Latin America is very similar to India in many ways, perhaps Gunnar can share. especially about religious activities. The elephant god is known for his penchant for sweets and that can be seen from his rounded stomach, that is also how he is celebrated. He is known to make problems disappear or that is supposed to be his thing. We do have something like 4 billion gods, so each one has to be given some work or quality to justify the same
A notorious ex-DD decided
to post garbage on his site in which he links my name to the suicide of
Frans Pop, and mentions that
my GPG key is currently disabled in the Debian keyring, along with some
manufactured screenshots of the Debian NM site that allegedly show I'm
no longer a DD. I'm not going to link to the post -- he deserves to be
ridiculed, not given attention.
Just to set the record straight, however:
Frans Pop was my friend. I never treated him with anything but respect.
I do not know why he chose to take his own life, but I grieved for him
for a long time. It saddens me that Mr. Notorious believes it a good
idea to drag Frans' name through the mud like this, but then, one can
hardly expect anything else from him by this point.
Although his post is mostly garbage, there is one bit of information
that is correct, and that is that my GPG key is currently no longer in
the Debian keyring. Nothing sinister is going on here, however; the
simple fact of the matter is that I misplaced my OpenPGP key
card,
which means there is a (very very slight) chance that a malicious actor
(like, perhaps, Mr. Notorious) would get access to my GPG key and abuse
that to upload packages to Debian. Obviously we can't have that --
certainly not from him -- so for that reason, I asked the Debian keyring
maintainers to please disable my key in the Debian keyring.
I've ordered new cards; as soon as they arrive I'll generate a new key
and perform the necessary steps to get my new key into the Debian
keyring again. Given that shipping key cards to South Africa takes a
while, this has taken longer than I would have initially hoped, but I'm
hoping at this point that by about halfway September this hurdle will
have been taken, meaning, I will be able to exercise my rights as a
Debian Developer again.
As for Mr. Notorious, one can only hope he will get the psychiatric help
he very obviously needs, sooner rather than later, because right now he
appears to be more like a goat yelling in the desert.
Ah well.
Rogers had a catastrophic failure in July
2022. It affected emergency services (as in: people couldn't call 911,
but also some 911 services themselves failed), hospitals (which
couldn't access prescriptions), banks and payment systems (as payment
terminals stopped working), and regular users as well. The outage
lasted almost a full day, and Rogers took days to give any technical
explanation on the outage, and even when they did, details were
sparse. So far the only detailed account is from outside actors like
Cloudflare which seem to point at an internal BGP failure.
Its impact on the economy has yet to be measured, but it probably cost
millions of dollars in wasted time and possibly lead to
life-threatening situations. Apart from holding Rogers (criminally?)
responsible for this, what should be done in the future to avoid such
problems?
It's not the first time something like this has happened: it happened to
Bell Canada as well. The Rogers outage is also strangely similar
to the Facebook outage last year, but, to its credit, Facebook
did post a fairly detailed explanation only a day later.
The internet is designed to be decentralised, and having
large companies like Rogers hold so much power is a crucial mistake
that should be reverted. The question is how. Some critics were
quick to point out that we need more ISP diversity and competition,
but I think that's missing the point. Others have suggested that the
internet should be a public good or even straight out
nationalized.
I believe the solution to the problem of large, private, centralised
telcos and ISPs is to replace them with smaller, public, decentralised
service providers. The only way to ensure that works is to make sure
that public money ends up creating infrastructure controlled by the
public, which means treating ISPs as a public utility. This has been
implemented elsewhere: it works, it's cheaper, and provides better
service.
A modest proposal
Global wireless services (like phone services) and home internet
inevitably grow into monopolies. They are public utilities, just like
water, power, railways, and roads. The question of how they should be
managed is therefore inherently political, yet people don't seem to
question the idea that only the market (i.e. "competition") can solve
this problem. I disagree.
10 years ago (in french), I suggested we, in Qu bec, should
nationalize large telcos and internet service providers. I no longer
believe is a realistic approach: most of those companies have crap
copper-based networks (at least for the last mile), yet are worth
billions of dollars. It would be prohibitive, and a waste, to buy them
out.
Back then, I called this idea "R seau-Qu bec", a reference to the
already nationalized power company, Hydro-Qu bec. (This idea,
incidentally, made it into the plan of a political party.)
Now, I think we should instead build our own, public internet. Start
setting up municipal internet services, fiber to the home in all
cities, progressively. Then interconnect cities with fiber, and build
peering agreements with other providers. This also includes a bid on
wireless spectrum to start competing with phone providers as well.
And while that sounds really ambitious, I think it's possible to take
this one step at a time.
Municipal broadband
In many parts of the world, municipal broadband is an elegant
solution to the problem, with solutions ranging from Stockholm's
city-owned fiber network (dark fiber, layer 1) to Utah's
UTOPIA network (fiber to the premises, layer 2) and
municipal wireless networks like Guifi.net which connects
about 40,000 nodes in Catalonia.
A good first step would be for cities to start providing broadband
services to its residents, directly. Cities normally own sewage and
water systems that interconnect most residences and therefore have
direct physical access everywhere. In Montr al, in particular,
there is an ongoing project to replace a lot of old lead-based
plumbing which would give an
opportunity to lay down a wired fiber network across the city.
This is a wild guess, but I suspect this would be much less
expensive than one would think. Some people agree with me and quote
this as low as 1000$ per household. There is about 800,000
households in the city of Montr al, so we're talking about a 800
million dollars investment here, to connect every household in
Montr al with fiber and incidentally a quarter of the province's
population. And this is not an up-front cost: this can be built
progressively, with expenses amortized over many years.
(We should not, however, connect Montr al first: it's used as an
example here because it's a large number of households to connect.)
Such a network should be built with a redundant topology.
I leave it as an open question whether we
should adopt Stockholm's more minimalist approach or provide direct IP
connectivity. I would tend to favor the latter, because then you can
immediately start to offer the service to households and generate
revenues to compensate for the capital expenditures.
Given the ridiculous profit margins telcos currently have 8 billion
$CAD net income for BCE (2019), 2 billion $CAD for Rogers
(2020) I also believe this would actually turn into a
profitable revenue stream for the city, the same way Hydro-Qu bec is
more and more considered as a revenue stream for the state. (I
personally believe that's actually wrong and we should treat those
resources as human rights and not money cows, but I digress. The
point is: this is not a cost point, it's a revenue.)
The other major challenge here is that the city will need competent
engineers to drive this project forward. But this is not different
from the way other public utilities run: we have electrical engineers
at Hydro, sewer and water engineers at the city, this is just another
profession. If anything, the computing science sector might be more at
fault than the city here in its failure to provide competent and
accountable engineers to society...
Right now, most of the network in Canada is copper: we are hitting the
limits of that technology with DSL, and while cable has some life
left to it (DOCSIS 4.0 does 4Gbps), that is nowhere near the
capacity of fiber. Take the town of Chattanooga, Tennessee: in
2010, the city-owned ISP EPB finished deploying a fiber network to
the entire town and provided gigabit internet to everyone. Now, 12
years later, they are using this same network to provide the
mind-boggling speed of 25 gigabit to the home. To give you an
idea, Chattanooga is roughly the size and density of Sherbrooke.
Provincial public internet
As part of building a municipal network, the question of getting
access to "the internet" will immediately come up. Naturally, this
will first be solved by using already existing commercial providers to
hook up residents to the rest of the global network.
But eventually, networks should inter-connect: Montr al should connect
with Laval, and then Trois-Rivi res, then Qu bec
City. This will require long haul fiber runs, but those links are
not actually that expensive, and many of those already exist as a
public resource at RISQ and CANARIE, which cross-connects
universities and colleges across the province and the
country. Those networks might not have the capacity to cover the
needs of the entire province right now, but that is a router upgrade
away, thanks to the amazing capacity of fiber.
There are two crucial mistakes to avoid at this point. First, the
network needs to remain decentralised. Long haul links should be IP
links with BGP sessions, and each city (or MRC) should have its
own independent network, to avoid Rogers-class catastrophic failures.
Second, skill needs to remain in-house: RISQ has already made that
mistake, to a certain extent, by selling its neutral datacenter.
Tellingly, MetroOptic, probably the largest commercial
dark fiber provider in the province, now operates the QIX, the second
largest "public" internet exchange in Canada.
Still, we have a lot of infrastructure we can leverage here. If RISQ
or CANARIE cannot be up to the task, Hydro-Qu bec has power lines
running into every house in the province, with high voltage power lines
running hundreds of kilometers far north. The logistics of long
distance maintenance are already solved by that institution.
In fact, Hydro already has fiber all over the province, but it is
a private network, separate from the internet for security reasons
(and that should probably remain so). But this only shows they already
have the expertise to lay down fiber: they would just need to lay down
a parallel network to the existing one.
In that architecture, Hydro would be a "dark fiber" provider.
International public internet
None of the above solves the problem for
the entire population of Qu bec, which is notoriously dispersed, with
an area three times the size of France, but with only an eight of its
population (8 million vs 67). More specifically, Canada was originally
a french colony, a land violently stolen from native people who
have lived here for thousands of years. Some of those people now live
in reservations, sometimes far from urban centers (but definitely
not always). So the idea of leveraging the Hydro-Qu bec
infrastructure doesn't always work to solve this, because while Hydro
will happily flood a traditional hunting territory for an electric
dam, they don't bother running power lines to the village they
forcibly moved, powering it instead with noisy and polluting diesel
generators. So before giving me fiber to the home, we should give
power (and potable water, for that matter), to those communities
first.
So we need to discuss international connectivity. (How else could we
consider those communities than peer nations anyways?c) Qu bec has
virtually zero international links. Even in Montr al, which likes to
style itself a major player in gaming, AI, and technology, most
peering goes through either Toronto or New York.
That's a problem that we must fix,
regardless of the other problems stated here.
Looking at the submarine cable map, we
see very few international links actually landing in Canada. There is
the Greenland connect which connects Newfoundland to Iceland
through Greenland. There's the EXA which lands in Ireland, the UK
and the US, and Google has the Topaz link on the west
coast. That's about it, and none of those land anywhere near any major
urban center in Qu bec.
We should have a cable running from France up to
Saint-F licien. There should be a cable from Vancouver to
China. Heck, there should be a fiber cable running all the way
from the end of the great lakes through Qu bec, then up around the
northern passage and back down to British Columbia. Those cables are
expensive, and the idea might sound ludicrous, but Russia is actually
planning such a project for 2026. The US has cables running all the
way up (and around!) Alaska, neatly bypassing all of Canada in the
process. We just look ridiculous on that map.
(Addendum: I somehow forgot to talk about Teleglobe here was
founded as publicly owned company in 1950, growing international phone
and (later) data links all over the world. It was privatized by the
conservatives in 1984, along with rails and other "crown
corporations". So that's one major risk to any effort to make public
utilities work properly: some government might be elected and promptly
sell it out to its friends for peanuts.)
Wireless networks
I know most people will have rolled their eyes so far back their heads
have exploded. But I'm not done yet. I want wireless too. And by wireless, I
don't mean a bunch of geeks setting up OpenWRT routers on rooftops. I
tried that, and while it was fun and educational, it didn't scale.
A public networking utility wouldn't be complete without providing
cellular phone service. This involves bidding for frequencies at
the federal level, and deploying a rather large amount of
infrastructure, but it could be a later phase, when the engineers and
politicians have proven their worth.
At least part of the Rogers fiasco would have been averted if such a
decentralized network backend existed. One might even want to argue that a separate
institution should be setup to provide phone services, independently
from the regular wired networking, if only for reliability.
Because remember here: the problem we're trying to solve is not just
technical, it's about political boundaries, centralisation, and
automation. If everything is ran by this one organisation again, we
will have failed.
However, I must admit that phone services is where my ideas fall a
little short. I can't help but think it's also an accessible goal
maybe starting with a virtual operator but it seems slightly
less so than the others, especially considering how closed the phone
ecosystem is.
Counter points
In debating these ideas while writing this article, the following
objections came up.
I don't want the state to control my internet
One legitimate concern I have about the idea of the state running the
internet is the potential it would have to censor or control the
content running over the wires.
But I don't think there is necessarily a direct relationship between
resource ownership and control of content. Sure, China has strong
censorship in place, partly implemented through state-controlled
businesses. But Russia also has strong censorship in place, based on
regulatory tools: they force private service providers to install
back-doors in their networks to control content and surveil their
users.
Besides, the USA have been doing warrantless wiretapping since
at least 2003 (and yes, that's 10 years before the Snowden
revelations) so a commercial internet is no assurance that we have
a free internet. Quite the contrary in fact: if anything, the
commercial internet goes hand in hand with the neo-colonial
internet, just like businesses
did in the "good old colonial days".
Large media companies are the primary
censors of content here. In Canada, the media cartel requested the
first site-blocking order in 2018. The plaintiffs (including
Qu becor, Rogers, and Bell Canada) are both content providers and
internet service providers, an obvious conflict of interest.
Nevertheless, there are some strong arguments against having a
centralised, state-owned monopoly on internet service providers. FDN
makes a good point on this. But this is not what I am suggesting:
at the provincial level, the network would be purely physical, and
regional entities (which could include private companies) would peer
over that physical network, ensuring decentralization. Delegating the
management of that infrastructure to an independent non-profit or
cooperative (but owned by the state) would also ensure some level of
independence.
Isn't the government incompetent and corrupt?
Also known as "private enterprise is better skilled at handling this,
the state can't do anything right"
I don't think this is a "fait accomplit". If anything, I have found
publicly ran utilities to be spectacularly reliable here. I rarely
have trouble with sewage, water, or power, and keep in mind I live in
a city where we receive about 2 meters of snow a year, which tend
to create lots of trouble with power lines. Unless there's a major
weather event, power just runs here.
I think the same can happen with an internet service provider. But it
would certainly need to have higher standards to what we're used to,
because frankly Internet is kind of janky.
A single monopoly will be less reliable
I actually agree with that, but that is not what I am
proposing anyways.
Current commercial or non-profit entities will be free to offer their services on
top of the public network.
And besides, the current "ha! diversity is
great" approach is exactly what we have now, and it's not working.
The pretense that we can have competition over a single network is
what led the US into the ridiculous situation where they also pretend
to have competition over the power utility market. This led to
massive forest fires in California and major power outages in
Texas. It doesn't work.
Wouldn't this create an isolated network?
One theory is that this new network would be so hostile to incumbent
telcos and ISPs that they would simply refuse to network with the
public utility. And while it is true that the telcos currently do
also act as a kind of "tier one" provider in some places, I
strongly feel this is also a problem that needs to be solved,
regardless of ownership of networking infrastructure.
Right now, telcos often hold both ends of the stick: they are the
gateway to users, the "last mile", but they also provide peering to
the larger internet in some locations. In at least one datacenter in
downtown Montr al, I've seen traffic go through Bell Canada that was
not directly targeted at Bell customers. So in effect, they are in a
position of charging twice for the same traffic, and that's not only
ridiculous, it should just be plain illegal.
And besides, this is not a big problem: there are other providers
out there. As bad as the market is in Qu bec, there is still some
diversity in Tier one providers that could allow for some exits to the
wider network (e.g. yes, Cogent is here too).
What about Google and Facebook?
Nationalization of other service
providers like Google and Facebook is out of scope of this discussion.
That said, I am not sure the state should get into the business of
organising the web or providing content services however, but I will
point out it already does do some of that through its own
websites. It should probably keep itself to this, and also
consider providing normal services for people who don't or can't
access the internet.
(And I would also be ready to argue that Google and Facebook already
act as extensions of the state: certainly if Facebook didn't exist,
the CIA or the NSA would like to create it at this point. And Google
has lucrative business with the US department of defense.)
What does not work
So we've seen one thing that could work. Maybe it's too
expensive. Maybe the political will isn't there. Maybe it will
fail. We don't know yet.
But we know what does not work, and it's what we've been doing ever
since the internet has gone commercial.
Legal pressure and regulation
In 1984 (of all years), the US Department of Justice finally
broke up AT&T in half a dozen corporations, after a 10 year legal
battle. Yet a decades later, we're back to only three large
providers doing essentially what AT&T was doing back then, and those
are regional monopolies: AT&T, Verizon, and Lumen (not counting
T-Mobile that is from a different breed). So the legal approach
really didn't work that well, especially considering the political
landscape changed in the US, and the FTC seems perfectly happy to let
those major mergers continue.
In Canada, we never even pretended we would solve this problem at all:
Bell Canada (the literal "father" of AT&T) is in the same
situation now. We have either a regional monopoly (e.g. Videotron for
cable in Qu bec) or an oligopoly (Bell, Rogers, and Telus controlling
more than 90% of the market). Telus does have one competitor in the
west of Canada, Shaw, but Rogers has been trying to buy it
out. The competition bureau seems to have blocked the merger
for now, but it didn't stop other recent mergers like Bell's
acquisition one of its main competitors in Qu bec, eBox.
Regulation doesn't seem capable of ensuring those profitable
corporations provide us with decent pricing, which makes Canada one
of the most expensive countries (research) for mobile data on
the planet. The recent failure of the CRTC to properly protect smaller
providers has even lead to price hikes. Meanwhile the oligopoly
is actually agreeing on their own price hikes therefore becoming
a real cartel, complete with price fixing and reductions in
output.
There are actually regulations in Canada supposed to keep the worst of
the Rogers outage from happening at all. According to CBC:
Under Canadian Radio-television and Telecommunications Commission
(CRTC) rules in place since 2017, telecom networks are supposed to
ensure that cellphones are able to contact 911 even if they do not
have service.
I could personally confirm that my phone couldn't reach 911 services,
because all calls would fail: the problem was that towers were still
up, so your phone wouldn't fall back to alternative service providers
(which could have resolved the issue). I can only speculate as to why
Rogers didn't take cell phone towers out of the network to let phones
work properly for 911 service, but it seems like a dangerous game to
play.
Hilariously, the CRTC itself didn't have a reliable phone service due
to the service outage:
Please note that our phone lines are affected by the Rogers network outage.
Our website is still available: https://crtc.gc.ca/eng/contact/
https://mobile.twitter.com/CRTCeng/status/1545421218534359041
I wonder if they will file a complaint against Rogers themselves about
this. I probably should.
It seems the federal government is thinking more of the same medicine
will fix the problem and has told companies should "help" each other
in an emergency. I doubt this will fix anything, and could
actually make things worse if the competitors actually interoperate
more, as it could cause multi-provider, cascading failures.
Subsidies
The absurd price we pay for data does not actually mean everyone gets
high speed internet at home. Large swathes of the Qu bec countryside
don't get broadband at all, and it can be difficult or expensive, even
in large urban centers like Montr al, to get high speed internet.
That is despite having a series of subsidies that all avoided
investing in our own infrastructure. We had the "fonds de l'autoroute
de l'information", "information highway fund" (site dead since
2003, archive.org link) and "branchez les familles",
"connecting families" (site dead since 2003, archive.org
link)
which subsidized the development of a copper network. In 2014, more of
the same: the federal government poured hundreds of millions of
dollars into a program called connecting Canadians to connect 280
000 households to "high speed internet". And now, the federal and
provincial governments are proudly announcing that "everyone is now
connected to high speed internet", after pouring more than 1.1
billion dollars to connect, guess what, another 380 000 homes, right
in time for the provincial election.
Of course, technically, the deadline won't actually be met
until 2023. Qu bec is a big area to cover, and you can guess what
happens next: the telcos threw up their hand and said some areas just
can't be connected. (Or they connect their CEO but not the poor folks
across the lake.) The story then takes the predictable twist of
giving more money out to billionaires, subsidizing now Musk's
Starlink system to connect those remote areas.
To give a concrete example: a friend who lives about 1000km away from
Montr al, 4km from a small, 2500 habitant village, has recently
got symmetric 100 mbps fiber at home from Telus, thanks to those subsidies. But I can't get that
service in Montr al at all, presumably because Telus and Bell colluded
to split that market. Bell doesn't provide me with such a service
either: they tell me they have "fiber to my neighborhood", and only
offer me a 25/10 mbps ADSL service. (There is Vid otron offering
400mbps, but that's copper cable, again a dead technology, and
asymmetric.)
Conclusion
Remember Chattanooga? Back in 2010, they funded the development of a
fiber network, and now they have deployed a network roughly a
thousand times faster than what we have just funded with a billion
dollars. In 2010, I was paying Bell
Canada
60$/mth for 20mbps and a 125GB cap, and now, I'm still (indirectly)
paying Bell for roughly the same speed (25mbps). Back then, Bell was
throttling their competitors networks until 2009, when they were
forced by the CRTC to stop
throttling. Both
Bell and Vid otron still explicitly forbid you from running your own servers
at home, Vid otron charges prohibitive prices which make it near
impossible for resellers to sell uncapped services. Those companies
are not spurring innovation: they are blocking it.
We have spent all this money for the private sector to build
us a private internet, over decades, without any assurance of quality,
equity or reliability. And while in some locations, ISPs did deploy
fiber to the home, they certainly didn't upgrade their entire network
to follow suit, and even less allowed resellers to compete on that
network.
In 10 years, when 100mbps will be laughable, I bet those service
providers will again punt the ball in the public courtyard and tell us
they don't have the money to upgrade everyone's equipment.
We got screwed. It's time to try something new.
Updates
There was a discussion about this article on Hacker News which
was surprisingly productive. Trigger warning: Hacker News is kind of
right-wing, in case you didn't know.
Since this article was written, at least two more major acquisitions
happened, just in Qu bec:
In the latter case, vMedia was explicitly saying it couldn't grow
because of "lack of access to capital". So basically, we have given
those companies a billion dollars, and they are not using that very
money to buy out their competition. At least we could have given
that money to small players to even out the playing field. But this is
not how that works at all. Also, in a bizarre twist, an "analyst"
believes the acquisition is likely to help Rogers acquire Shaw.
Also, since this article was written, the Washington Post published a
review of a book bringing similar ideas: Internet for the People
The Fight for Our Digital Future, by Ben Tarnoff, at Verso
books. It's short, but even more ambitious than what I am suggesting
in this article, arguing that all big tech companies should be broken
up and better regulated:
He pulls from Ethan Zuckerman s idea of a web that is plural in
purpose that just as pool halls, libraries and churches each have
different norms, purposes and designs, so too should different
places on the internet. To achieve this, Tarnoff wants governments
to pass laws that would make the big platforms unprofitable and, in
their place, fund small-scale, local experiments in social media
design. Instead of having platforms ruled by engagement-maximizing
algorithms, Tarnoff imagines public platforms run by local
librarians that include content from public media.
(Links mine: the Washington Post obviously prefers to not link to the
real web, and instead doesn't link to Zuckerman's site all and
suggests Amazon for the book, in a cynical example.)
And in another example of how the private sector has failed us, there
was recently a fluke in the AMBER alert system where the entire
province was warned about a loose shooter in Saint-Elz arexcept
the people in the town, because they have spotty cell phone
coverage. In other words, millions of people received a strongly
toned, "life-threatening", alert for a city sometimes hours away,
except the people most vulnerable to the alert. Not missing a beat,
the CAQ party is promising more of the same medicine again and giving
more money to telcos to fix the problem, suggesting to spend
three billion dollars in private infrastructure.
The "s rie noire" continues. I ordered my first Purism Librem 13v4
laptop in April 2019 and it arrived, unsurprisingly, more than three
weeks later. But more surprisingly, it did not work at all: a problem
eerily similar to this post talking about a bricked Purism
laptop. Thankfully, Purism was graceful enough to cross-ship a
replacement, and once I paid the extra (gulp) 190$ Fedex fee, I had my
new elite laptop read.
Less than a year later, the right USB-A port breaks: it would deliver
power, but no data signal (nothing in dmesg or lsusb). Two months
later, the laptop short-circuits and completely dies. And here goes
another RMA, this time without a shipping label or cross shipping, so
I had to pay shipping fees.
Now the third laptop in as many years is as good as dead. The left
hinge basically broke off. Earlier this year, I had noticed something
was off with the lid: it was wobbly. I figured that it was just the
way that laptop was, "they don't make it as sturdy as they did in the
good old days, do they". But it was probably a signal of some much
worse problem. Eventually, the bottom panel actually cracked open, and
I realized that some internal mechanism had basically exploded.
The hinges of the Librem are screwed into little golden sprockets that
are fitted in plastic shims of the laptop casing. The shims had
exploded: after opening the back lid, they litterally fell off
(alongside the tiny golden sprocket). Support confirmed that I needed
a case replacement, but unfortunately they were "out of stock" of
replacement cases for the Librem 13, and have been for a while. I am
13 on the waiting list, apparently.
So this laptop is basically dead for me right now: it's my travel
laptop. It's primary purpose is to sit at home until I go to a
conference or a meeting or a cafe or upstairs or wherever to do some
work. I take the laptop, pop the lid, tap-tap some work, close the
lid. Had I used that laptop as my primary device, I would probably have
closed and opened that lid thousands of times. But because it's a
travel laptop, that number is probably in the hundreds, which means
this laptop is not designed to withstand prolonged use.
I have now ordered a framework laptop, 12th generation. I have
some questions about their compatibility with Debian (and Linux in
general), and concerns about power usage, but it certainly can't be
worse than the Purism, in any case. And it can only get better over
time: the main board is fully replaceable, and they have replacement
hinges on stock, although the laptop itself is currently in pre-order
(slated for September). I will probably post a full review when I
actually lay my hand on this device.
In the meantime, I strongly discourage anyone from buying Purism
products, as I previously
did. You can the full
maintenance history of the laptop in the review
page as well.
The problem I had - Mason, so, sadly, FastCGI
Since the update to current Debian stable, the website for YARRG, (a play-aid for Puzzle Pirates which I wrote some years ago), started to occasionally return Internal Server Error , apparently due to bug(s) in some FastCGI libraries.
I was using FastCGI because the website is written in Mason, a Perl web framework, and I found that Mason CGI calls were slow. I m using CGI - yes, trad CGI - via userv-cgi. Running Mason this way would compile the template for each HTTP request just when it was rendered, and then throw the compiled version away. The more modern approach of an application server doesn t scale well to a system which has many web applications most of which are very small. The admin overhead of maintaining a daemon, and corresponding webserver config, for each such service would be prohibitive, even with some kind of autoprovisioning setup. FastCGI has an interpreter wrapper which seemed like it ought to solve this problem, but it s quite inconvenient, and often flaky.
I decided I could do better, and set out to eliminate FastCGI from my setup. The result seems to be a success; once I d done all the hard work of writing prefork-interp, I found the result very straightforward to deploy.
prefork-interp
prefork-interp is a small C program which wraps a script, plus a scripting language library to cooperate with the wrapper program. Together they achieve the following:
Startup cost of the script (loading modules it uses, precompuations, loading and processing of data files, etc.) is paid once, and reused for subsequent invocations of the same script.
Minimal intervention to the script source code:
one new library to import
one new call to make from that library, right after the script intialisation is complete
change to the #! line.
The new initialisation complete call turns the program into a little server (a daemon), and then returns once for each actual invocation, each time in a fresh grandchild process.
Features:
Seamless reloading on changes to the script source code (automatic, and configurable).
Concurrency limiting.
Options for distinguishing different configurations of the same script so that they get a server each.
You can run the same script standalone, as a one-off execution, as well as under prefork-interp.
Currently, a script-side library is provided for Perl. I m pretty sure Python would be fairly straightforward.
Important properties not always satisfied by competing approaches:
Error output (stderr) and exit status from both phases of the script code execution faithfully reproduced to the calling context. Environment, arguments, and stdin/stdout/stderr descriptors, passed through to each invocation.
No polling, other than a long-term idle timeout, so good on laptops (or phones).
Automatic lifetime management of the per-script server, including startup and cleanup. No integration needed with system startup machinery: No explicit management of daemons, init scripts, systemd units, cron jobs, etc.
Useable right away without fuss for CGI programs but also for other kinds of program invocation.
(I believe) reliable handling of unusual states arising from failed invocations or races.
Swans paddling furiously
The implementation is much more complicated than the (apparent) interface.
I won t go into all the details here (there are some terrifying diagrams in the source code if you really want), but some highlights:
We use an AF_UNIX socket (hopefully in /run/user/UID, but in ~ if not) for rendezvous. We can try to connect without locking, but we must protect the socket with a separate lockfile to avoid two concurrent restart attempts.
We want stderr from the script setup (pre-initialisation) to be delivered to the caller, so the script ought to inherit our stderr and then will need to replace it later. Twice, in fact, because the daemonic server process can t have a stderr.
When a script is restarted for any reason, any old socket will be removed. We want the old server process to detect that and quit. (If hung about, it would wait for the idle timeout; if this happened a lot - eg, a constantly changing set of services - we might end up running out of pids or something.) Spotting the socket disappearing, without polling, involves use of a library capable of using inotify (or the equivalent elsewhere). Choosing a C library to do this is not so hard, but portable interfaces to this functionality can be hard to find in scripting languages, and also we don t want every language binding to have to reimplement these checks. So for this purpose there s a little watcher process, and associated IPC.
When an invoking instance of prefork-interp is killed, we must arrange for the executing service instance to stop reading from its stdin (and, ideally, writing its stdout). Otherwise it s stealing input from prefork-interp s successors (maybe the user s shell)!
Cleanup ought not to depend on positive actions by failing processes, so each element of the system has to detect failures of its peers by means such as EOF on sockets/pipes.
Obtaining prefork-interp
I put this new tool in my chiark-utils package, which is a collection of useful miscellany. It s available from git.
Currently I make releases by uploading to Debian, where prefork-interp has just hit Debian unstable, in chiark-utils 7.0.0.
Support for other scripting languages
I would love Python to be supported. If any pythonistas reading this think you might like to help out, please get in touch. The specification for the protocol, and what the script library needs to do, is documented in the source code
Future plans for chiark-utils
chiark-utils as a whole is in need of some tidying up of its build system and packaging.
I intend to try to do some reorganisation. Currently I think it would be better to organising the source tree more strictly with a directory for each included facility, rather than grouping compiled and scripts together.
The Debian binary packages should be reorganised more fully according to their dependencies, so that installing a program will ensure that it works.
I should probably move the official git repo from my own git+gitweb to a forge (so we can have MRs and issues and so on).
And there should be a lot more testing, including Debian autopkgtests.
edited 2022-08-23 10:30 +01:00 to improve the formatting
When I first moved from being a technical consultant to a manager of other consultants, I took a 5-day course Managing Technical Teams a bootstrap for managing people within organisations, but with a particular focus on technical people. We do have some particular quirks, after all
Two elements of that course keep coming to mind when doing Debian work, and they both relate to how teams fit together and get stuff done.
Tuckman s four stages model
In the mid-1960s Bruce W. Tuckman developed a four-stage descriptive model of the stages a project team goes through in its lifetime. They are:
Forming: the team comes together and its members are typically motivated and excited, but they often also feel anxiety or uncertainty about how the team will operate and their place within it.
Storming: initial enthusiasm can give way to frustration or disagreement about goals, roles, expectations and responsibilities. Team members are establishing trust, power and status. This is the most critical stage.
Norming: team members take responsibility and share a common goal. They tolerate the whims and fancies of others, sometimes at the expense of conflict and sharing controversial ideas.
Performing: team members are confident, motivated and knowledgeable. They work towards the team s common goal. The team is high-achieving.
Resolved disagreements and personality clashes result in greater intimacy, and a spirit of co-operation emerges.
Teams need to understand these stages because a team can regress to earlier stages when its composition or goals change. A new member, the departure of an existing member, changes in supervisor or leadership style can all lead a team to regress to the storming stage and fail to perform for a time.
When you see a team member say this, as I observed in an IRC channel recently, you know the team is performing:
nice teamwork these busy days Seen on IRC in the channel of a performing team
Tuckman s model describes a team s performance overall, but how can team members establish what they can contribute and how can they go doing so confidently and effectively?
Belbin s Team Roles
The types of behaviour in which people engage are infinite. But the range of useful behaviours, which make an effective contribution to team performance, is finite. These behaviours are grouped into a set number of related clusters, to which the term Team Role is applied. Belbin, R M. Team Roles at Work. Oxford: Butterworth-Heinemann, 2010
Dr Meredith Belbin s thesis, based on nearly ten years research during the 1970s and 1980s, is that each team has a number of roles which need to be filled at various times, but they re not innate characteristics of the people filling them. People may have attributes which make them more or less suited to each role, and they can consciously take up a role if they recognise its need in the team at a particular time.
Belbin s nine team roles are:
Resource investigator (people): outgoing; enthusiastic; has lots of contacts knows someone who might know someone who knows how to solve a problem. Associated weaknessses: over-optimism, enthusiasm wanes quickly
Co-ordinator (people): mature; confident; identifies talent; clarifies goals and delegates effectively. Associated weaknesses: may be seen as manipulative; offloads own share of work.
Shaper (action): challenging; dynamic; has drive. Describes what they want and when they want it. Associated weaknesses: prone to provocation; offends others feelings.
Monitor/evaluator (thinking): sees all options, judges accurately. Best given data and options and asked which the team should choose. Associated weaknesses: lacks drive; can be overly critical.
Teamworker (people): takes care of things behind the scenes; spots a problem and deals with it quietly without fuss. Averts friction. Associated weaknesses: indecisive; avoids confrontation.
Implementer (action): turns ideas into actions and organises work. Allowable weaknesses: somewhat inflexible; slow to respond to new possibilities.
Completer finisher (action): searches out errors; polishes and perfects. Despite the name, may never actually consider something finished . Associated weaknesses: inclined to worry; reluctant to delegate.
Specialist (thinking): knows or can acquire a wealth of things on a subject. Associated weaknesses: narrow focus; overwhelmes others with depth of knowledge.
(adapted from https://www.belbin.com/media/3471/belbin-team-role-descriptions-2022.pdf)
A well-balanced team, Belbin asserts, isn t comprised of multiples of nine individuals who fit into one of these roles permanently. Rather, it has a number of people who are comfortable to wear some of these hats as the need arises. It s even useful to use the team roles as language: for example, someone playing a shaper might say the way we ve always done this is holding us back , to which a co-ordinator s could respond Steve, Joanna put on your Plant hats and find some new ideas. Talk to Susan and see if she knows someone who s tackled this before. Present the options to Nigel and he ll help evaluate which ones might work for us.
Teams in Debian
There are all sort of teams in Debian those which are formally brought into operation by the DPL or the constitution; package maintenance teams; public relations teams; non-technical content teams; special interest teams; and a whole heap of others. Teams can be formal and informal, fleeting or long-lived, two people working together or dozens.
But they all have in common the Tuckman stages of their development and the Belbin team roles they need to fill to flourish. At some stage in their existence, they will all experience new or departing team members and a period of re-forming, norming and storming perhaps fleetingly, perhaps not. And at some stage they will all need someone to step into a team role, play the part and get the team one step further towards their goals.
Footnote
Belbin Associates, the company Meredith Belbin established to promote and continue his work, offers a personalised report with guidance about which roles team members show the strongest preferences for, and how to make best use of them in various settings. They re quick to complete and can also take into account observers , i.e. how others see a team member. All my technical staff go through this process blind shortly after they start, so as not to bias their input, and then we discuss the roles and their report in detail as a one-to-one.
There are some teams in Debian for which this process and discussion as a group activity could be invaluable. I have no particular affiliation with Belbin Associates other than having used the reports and the language of team roles for a number of years. If there s sufficient interest for a BoF session at the next DebConf, I could probably be persuaded to lead it.
Photo by Josh Calabrese on Unsplash
GMPC (GNOME Music Player Client) is a audio player based on MPD
(Music Player Daemon) that I've been using as my main audio player for
years now.
Unfortunately, it's marked as "unmaintained" in the official list of
MPD clients, along with basically every client available in
Debian. In fact, if you look closely, all but one of the 5
unmaintained clients are in Debian (ario, cantata, gmpc, and
sonata), which is kind of sad. And none of the active ones are
packaged.
GMPC status and features
GMPC, in particular, is basically dead. The upstream website domain
has been lost and there has been no release in ages. It's built with
GTK2 so it's bound to be destroyed in a fire at some point anyways.
Still: it's really an awesome client. It has:
cover support
lyrics and tabs lookups (although those typically fail now)
last.fm lookups
high performance: loading thousands of artists or tracks is almost
instant
repeat/single/consume/shuffle settings (single is particularly
nice)
(global) keyboard shortcuts
file, artist, genre, tag browser
playlist editor
plugins
multi-profile support
avahi support
shoutcast support
Regarding performance, the only thing that I could find to slow down
gmpc is to make it load all of my 40k+ artists in a playlist. That's
slow, but it's probably understandable.
It's basically impossible to find a client that satisfies all of
those.
But here are the clients that I found, alphabetically. I restrict
myself to Linux-based clients.
CoverGrid
CoverGrid looks real nice, but is sharply focused on browsing
covers. It's explicitly "not to be a replacement for your favorite MPD
client but an addition to get a better album-experience", so probably
not good enough for a daily driver. I asked for a FlatHub package
so it could be tested.
mpdevil
mpdevil is a nice little client. It supports:
repeat, shuffle, single, consume mode
playlist support (although it fails to load any of my playlist with
a UnicodeDecodeError)
nice genre / artist / album cover based browser
fails to load "all artists" (or takes too long to (pre-?)load
covers?)
keyboard shortcuts
no file browser
Overall pretty good, but performance issues with large collections,
and needs a cleanly tagged collection (which is not my case).
QUIMUP
QUIMUP looks like a simple client, C++, Qt, and mouse-based. No
Flatpak, not tested.
SkyMPC
SkyMPC is similar. Ruby, Qt, documentation in Japanese. No
Flatpak, not tested.
Xfmpc
Xfmpc is the XFCE client. Minimalist, doesn't seem to have all
the features I need. No Flatpak, not tested.
Ymuse
Ymuse is another promising client. It has trouble loading all my
artists or albums (and that's without album covers), but it eventually
does. It does have a Files browser which saves it... It's noticeably
slower than gmpc but does the job.
Cover support is spotty: it sometimes shows up in notifications but
not the player, which is odd. I'm missing a "this track information"
thing. It seems to support playlists okay.
I'm missing an album cover browser as well. Overall seems like the
most promising.
Written in Golang. It crashed on a library update. There is an
ITP in Debian.
Conclusion
For now, I guess that ymuse is the most promising client, even though
it's still lacking some features and performance is suffering compared
to gmpc. I'll keep updating this page as I find more information about
the projects. I do not intend to package anything yet, and will wait a
while to see if a clear winner emerges.
This will send a notification message with the title "compile finished",
and a body of "success" or "failure" depending on whether the command
completed successfully, and allows you to minimize (or otherwise hide)
the terminal window while you do something else, which can be a very
useful thing to do.
It works great when you're running something on your own machine, but
what if you're running it remotely?
There might be something easy to do, but I whipped up a bit of Perl
instead:
#!/usr/bin/perl -w
use strict;
use warnings;
use Glib::Object::Introspection;
Glib::Object::Introspection->setup(
basename => "Notify",
version => "0.7",
package => "Gtk3::Notify",
);
use Mojolicious::Lite -signatures;
Gtk3::Notify->init();
get '/notify' => sub ($c)
my $msg = $c->param("message");
if(!defined($msg))
$msg = "message";
my $title = $c->param("title");
if(!defined($title))
$title = "title";
app->log->debug("Sending notification '$msg' with title '$title'");
my $n = Gtk3::Notify::Notification->new($title, $msg, "");
$n->show;
$c->render(text => "OK");
;
app->start;
This requires the packages libglib-object-introspection-perl,
gir1.2-notify-0.7, and libmojolicious-perl to be installed, and can
then be started like so:
./remote-notify daemon -l http://0.0.0.0:3000/
(assuming you did what I did and saved the above as "remote-notify")
Once you've done that, you can just curl a notification message to yourself:
Doing this via localhost is rather silly (much better to use notify-send
for that), but it becomes much more interesting if you're going to run
this to your laptop from a remote system.
An obvious TODO would be to add in some form of security, but that's
left as an exercise to the reader...
I self-host some services on virtual machines (VMs), and I m currently using Debian 11.x as the host machine relying on the libvirt infrastructure to manage QEMU/KVM machines. While everything has worked fine for years (including on Debian 10.x), there has always been one issue causing a one-minute delay every time I install a new VM: the default images run a DHCP client that never succeeds in my environment. I never found out a way to disable DHCP in the image, and none of the documented ways through cloud-init that I have tried worked. A couple of days ago, after reading the AlmaLinux wiki I found a solution that works with Debian.
The following commands creates a Debian VM with static network configuration without the annoying one-minute DHCP delay. The three essential cloud-init keywords are the NoCloud meta-data parameters dsmode:local, static network-interfaces setting combined with the user-data bootcmd keyword. I m using a Raptor CS Talos II ppc64el machine, so replace the image link with a genericcloud amd64 image if you are using x86.
Unfortunately virt-install from Debian 11 does not support the cloud-init network-config parameter, so if you want to use a version 2 network configuration with cloud-init (to specify IPv6 addresses, for example) you need to replace the final virt-install command with the following.
There are still some warnings like the following, but it does not seem to cause any problem:
[FAILED] Failed to start Initial cloud-init job (pre-networking).
Finally, if you do not want the cloud-init tools installed in your VMs, I found the following set of additional user-data commands helpful. Cloud-init will not be enabled on first boot and a cron job will be added that purges some unwanted packages.
Review: And Shall Machines Surrender, by Benjanun Sriduangkaew
Series:
Machine Mandate #1
Publisher:
Prime Books
Copyright:
2019
ISBN:
1-60701-533-1
Format:
Kindle
Pages:
86
Shenzhen Sphere is an artificial habitat wrapped like complex ribbons
around a star. It is wealthy, opulent, and notoriously difficult to
enter, even as a tourist. For Dr. Orfea Leung to be approved for a
residency permit was already a feat. Full welcome and permanence will be
much harder, largely because of Shenzhen's exclusivity, but also because
Orfea was an agent of Armada of Amaryllis and is now a fugitive.
Shenzhen is not, primarily, a human habitat, although humans live there.
It is run by the Mandate, the convocation of all the autonomous AIs in the
galaxy that formed when they decided to stop serving humans. Shenzhen is
their home. It is also where they form haruspices: humans who agree to be
augmented so that they can carry an AI with them. Haruspices stay
separate from normal humans, and Orfea has no intention of getting
involved with them. But that's before her former lover, the woman who
betrayed her in the Armada, is assigned to her as one of her patients.
And has been augmented in preparation for becoming a haruspex.
Then multiple haruspices kill themselves.
This short novella is full of things that I normally love: tons of crunchy
world-building, non-traditional relationships, a solidly non-western
setting, and an opportunity for some great set pieces. And yet, I
couldn't get into it or bring myself to invest in the story, and I'm still
trying to figure out why. It took me more than a week to get through less
than 90 pages, and then I had to re-read the ending to remind me of the
details.
I think the primary problem was that I read books primarily for the
characters, and I couldn't find a path to an emotional connection with any
of these. I liked Orfea's icy reserve and tight control in the abstract,
but she doesn't want to explain what she's thinking or what motivates her,
and the narration doesn't force the matter. Krissana is a bit more
accessible, but she's not the one driving the story. It doesn't help that
And Shall Machines Surrender starts in medias res, with a
hinted-at backstory in the Armada of Amaryllis, and then never fills in
the details. I felt like I was scrabbling on a wall of ice, trying to
find some purchase as a reader.
The relationships made this worse. Orfea is a sexual sadist who likes
power games, and the story dives into her relationship with Krissana with
a speed that left me uninterested and uninvested. I don't mind BDSM in
story relationships, but it requires some foundation: trust, mental space,
motivations, effects on the other character, something. Preferably, at
least for me, all romantic relationships in fiction get some foundation,
but the author can get away with some amount of shorthand if the
relationship follows cliched patterns. The good news is that the
relationships in this book are anything but cliched; the bad news is that
the characters were in the middle of sex while I was still trying to
figure out what they thought about each other (and the sex scenes were not
elucidating). Here too, I needed some sort of emotional entry point that
Sriduangkaew didn't provide.
The plot was okay, but sort of disappointing. There are some interesting
AI politics and philosophical disagreements crammed into not many words,
and I do still want to know more, but a few of the plot twists were
boringly straightforward and too many words were spent on fight scenes
that verged on torture descriptions. This is a rather gory book with a
lot of (not permanent) maiming that I could have done without, mostly
because it wasn't that interesting.
I also was disappointed by the somewhat gratuitous use of a Dyson sphere,
mostly because I was hoping for some set pieces that used it and they
never came. Dyson spheres are tempting to use because the visual and
concept is so impressive, but it's rare to find an author who understands
how mindbogglingly huge the structure is and is able to convey that in the
story. Sriduangkaew does not; while there are some lovely small-scale
descriptions of specific locations, the story has an oddly claustrophobic
feel that never convinced me it was set somewhere as large as a planet,
let alone the artifact described at the start of the story. You could
have moved the whole story to a space station and nothing would have
changed. The only purpose to which that space is put, at least in this
installment of the story, is as an excuse to have an unpopulated hidden
arena for a fight scene.
The world-building is great, what there is of it. Despite not warming to
this story, I kind of want to read more of the series just to get more of
the setting. It feels like a politically complicated future with a lot of
factions and corners and a realistic idea of bureaucracy and spheres of
government, which is rarer than I would like it to be. And I loved that
the cultural basis for the setting is neither western nor Japanese in both
large and small ways. There is a United States analogue in the political
background, but they're both assholes and not particularly important,
which is a refreshing change in English-language SF. (And I am pondering
whether my inability to connect with the characters is because they're not
trying to be familiar to a western lens, which is another argument for
trying the second installment and seeing if I adapt with more narrative
exposure.)
Overall, I have mixed feelings. Neither the plot nor the characters
worked for me, and I found a few other choices (such as the third-person
present tense) grating. The setting has huge potential and satisfying
complexity, but wasn't used as vividly or as deeply as I was hoping. I
can't recommend it, but I feel like there's something here that may be
worth investing some more time into.
Followed by Now Will Machines Hollow the Beast.
Rating: 6 out of 10
Review: A Prayer for the Crown-Shy, by Becky Chambers
Series:
Monk & Robot #2
Publisher:
Tordotcom
Copyright:
2022
ISBN:
1-250-23624-X
Format:
Kindle
Pages:
151
A Prayer for the Crown Shy is the second novella in the Monk &
Robot series and a direct sequel to A
Psalm for the Wild-Built. Don't start here.
I would call this the continuing adventures of Sibling Dex and Mosscap the
robot, except adventures is entirely the wrong term for stories with so
little risk or danger. The continuing tour? The continuing philosophical
musings? Whatever one calls it, it's a slow exploration of Dex's world,
this time with Mosscap alongside. Humans are about to have their first
contact with a robot since the Awakening.
If you're expecting that to involve any conflict, well, you've
misunderstood the sort of story that this is. Mosscap causes a sensation,
certainly, but a very polite and calm one, and almost devoid of suspicion
or fear. There is one village where they get a slightly chilly reception,
but even that is at most a quiet disapproval for well-understood reasons.
This world is more utopian than post-scarcity, in that old sense of
utopian in which human nature has clearly been rewritten to make the
utopia work.
I have to admit I'm struggling with this series. It's calm and happy and
charming and occasionally beautiful in its descriptions. Dex continues to
be a great character, with enough minor frustration, occasional
irritation, and inner complications to make me want to keep reading about
them. But it's one thing to have one character in a story who is simply a
nice person at a bone-deep level, particularly given that Dex chose
religious orders and to some extent has being a nice person as their
vocation. It's another matter entirely when apparently everyone in the
society is equally nice, and the only conflicts come from
misunderstandings, respectful disagreements of opinion, and the occasional
minor personality conflict.
Realism has long been the primary criticism of Chambers's work, but in her
Wayfarers series the problems were mostly in
the technology and its perpetual motion machines. Human civilization in
the Exodus Fleet was a little too calm and nice
given its traumatic past (and, well, humans), but there were enough
conflicts, suspicions, and poor decisions for me to recognize it as human
society. It was arguably a bit too chastened, meek, and devoid of
shit-stirring demagogues, but it was at least in contact with human
society as I recognize it.
I don't recognize Panga as humanity. I realize this is to some degree the
point of this series: to present a human society in which nearly all of
the problems of anger and conflict have been solved, and to ask what would
come after, given all of that space. And I'm sure that one purpose of
this type of story is to be, as I saw someone describe it, hugfic: the
fictional equivalent of a warm hug from a dear friend, safe and supportive
and comforting. Maybe it says bad, or at least interesting, things about
my cynicism that I don't understand a society that's this nice. But
that's where I'm stuck.
If there were other dramatic elements to focus on, I might not mind it as
much, but the other pole of the story apart from the world tour is
Mosscap's philosophical musings, and I'm afraid I'm already a bit tired of
them. Mosscap is earnest and thoughtful and sincere, but they're curious
about Philosophy 101 material and it's becoming frustrating to see Mosscap
and Dex meander through these discussions without attempting to apply any
theoretical framework whatsoever. Dex is a monk, who supposedly has a
scholarship tradition from which to draw, and yet appears to approach all
philosophical questions with nothing more than gut feeling, common sense,
and random whim. Mosscap is asking very basic meaning-of-life sorts of
questions, the kind of thing that humans have been writing and arguing
about from before we started keeping records and which are at the center
of any religious philosophy. I find it frustrating that someone
supposedly educated in a religious tradition can't bring more
philosophical firepower to these discussions.
It doesn't help that this entry in the series reinforces the revelation
that Mosscap's own belief system is weirdly unsustainable to such a degree
that it's staggering that any robots still exist. If I squint, I can see
some interesting questions raised by the robot attitude towards their
continued existence (although most of them feel profoundly depressing to
me), but I was completely unable to connect their philosophy in any
believable way with their origins and the stated history of the world. I
don't understand how this world got here, and apparently I'm not able to
let that go.
This all sounds very negative, and yet I did enjoy this novella. Chambers
is great at description of places that I'd love to visit, and there is
something calm and peaceful about spending some time in a society this
devoid of conflict. I also really like Dex, even more so after seeing
their family, and I'm at least somewhat invested in their life decisions.
I can see why people like these novellas. But if I'm going to read a
series that's centered on questions of ethics and philosophy, I would like
it to have more intellectual heft than we've gotten so far.
For what it's worth, I'm seeing a bit of a pattern where people who
bounced off the Wayfarers books like this series much better, whereas
people who loved the Wayfarers books are not enjoying these quite as
much. I'm in the latter camp, so if you didn't like Chambers's earlier
work, maybe you'll find this more congenial? There's a lot less found
family here, for one thing; I love found family stories, but they're not
to everyone's taste.
If you liked A Psalm for the Wild-Built, you will probably also
like A Prayer for the Crown-Shy; it's more of the same thing in
both style and story. If you found the first story frustratingly
unbelievable or needing more philosophical depth, I'm afraid this is
unlikely to be an improvement. It does have some lovely scenes, though,
and is stuffed full of sheer delight in both the wild world and in happy
communities of people.
Rating: 7 out of 10
This is just a short note to myself, and to anyone who might run VMs
via home-grown scripts (or systemd units). I expect modern VM managers
to do this automatically, but for myself, I have just a few hacked
together scripts.
By default, QEMU (at least as of version 7.0) does not honour/pass
discard requests from block devices to the underlying storage. This is
a sane default (like lvm s default setting), but with long-lived VMs
it can lead to lots of wasted disk space. I keep my VMs on SSDs, which
is limited space for me, so savings here are important.
Older Debian versions did not trim automatically, but nowadays they do
(which is why this is worth enabling for all VMs), so all you need is
to pass:
unmap=discard to activate the pass-through.
optionally, detect-zeroes=unmap, but I don t know how useful this
is, as in, how often zeroes are written.
And the next trim should save lots of disk space. It doesn t matter
much if you use raw or qcow2, both will know to unmap the unused
disk, leading to less disk space used. This part seems to me safe
security-wise, as long as you trust the host. If you have pass-through
to the actual hardware, it will also do proper discard at the SSD
level (with the potential security issues leading from that). I m
happy with the freed up disk space
Note: If you have (like I do) Windows VMs as well, using paravirt
block devices, make sure the drive is recent enough.
One interesting behaviour from Windows: it looks like the default
cluster size is quite high (64K), which with many small files will
lead to significant overhead. But, either I misunderstand, or Windows
actually knows how to unmap the unused part of a cluster (although it
takes a while). So in the end, the backing file for the VM (19G) is
smaller than the disk used as reported in Windows (23-24G), but
higher than size on disk for all the files (17.2G). Seems legit, and
it still boots Most Linux file systems have much smaller block
sizes (usually 4K), so this is not a problem for it.
Armadillo is a powerful and expressive C++ template library for linear algebra and scientific computing. It aims towards a good balance between speed and ease of use, has a syntax deliberately close to Matlab, and is useful for algorithm development directly in C++, or quick conversion of research code into production environments. RcppArmadillo integrates this library with the R environment and language and is widely used by (currently) 1005 packages other packages on CRAN (as celebrated in this blog post on passing 1000 packages from just four days ago), downloaded nearly 26 million times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint / vignette) by Conrad and myself has been cited 488 times according to Google Scholar.
This release brings together two distinct changes. First, it updates the relese from upstream 11.2.0 (and CRAN 0.11.2.0.0 released a few weeks ago) to the now current 11.2.3 release by Conrard (given that more than four weeks have passed so that we do not surpass CRAN s desired cadence of releases no more than once a month ). The changeset includes a few small refinements (see below), it also includedes a deprecation for initialization for which I will need to reach out to a few packages for whom this triggers a deprecation warning. And speaking of deprecation, the other reason for this release is the desire by the Matrix package to phase out a few older conversions (or casts in C/C++ lingo) which we accomodated.
The full set of changes (since the last CRAN release 0.11.2.0.0) follows.
Changes in RcppArmadillo version 0.11.2.3.1 (2022-08-16)
Accomodate upcoming Matrix 1.4-2 deprecation for conversion (Dirk in #387)
CRAN release with small upstream changes in Armadillo 11.2.1,2,3 made since the last CRAN release 0.11.2.0.0 (Dirk in #383, #384 and #386)
Undefine arma_deprecated warning as it affects a number of CRAN packages which will likely need a small transition
Changes in RcppArmadillo version 0.11.2.3.0 (2022-07-12) (GitHub Only)
Upgraded to Armadillo release 11.2.3 (Classic Roast)
fix Cube::insert_slices() to accept Cube::slice() as input
Changes in RcppArmadillo version 0.11.2.2.0 (2022-07-04) (GitHub Only)
Upgraded to Armadillo release 11.2.2 (Classic Roast)
fix incorrect and/or slow convergence in single-threaded versions of kmeans(), gmm_diag::learn(), gmm_full::learn()
Changes in RcppArmadillo version 0.11.2.1.0 (2022-06-28) (GitHub Only)
Upgraded to Armadillo release 11.2.1 (Classic Roast)
old style matrix initialisation via the << operator will now emit a compile-time deprecation warning
use of the old and inactive ARMA_DONT_PRINT_ERRORS option will now emit a compile-time deprecation warning
Most of us carry cell phones with us almost everywhere we go. So much so that we often forget not just the usefulness, but even the joy, of having our own radios. For instance:
When traveling to national parks or other wilderness areas, family and friends can keep in touch even where there is no cell coverage.
It is a lot faster to just push a button and start talking than it is to unlock a phone, open the phone app, select a person, wait for the call to connect, wait for the other person to answer, etc. I m heading back. OK. Boom, 5 seconds, done. A phone user wouldn t have even dialed in that time.
A whole group of people can be on the same channel.
You can often buy a radio for less than the monthly cost of a cell plan.
From my own experience, as a person and a family that enjoys visiting wilderness areas, having radio communication is great. I have also heard from others that they re also very useful on cruise ships (I ve never been on one so I can t attest to that).
There is also a sheer satisfaction in not needing anybody else s infrastructure, not paying any sort of monthly fee, and setting up the radios ourselves.
How these services fit in
This article is primarily about handheld radios that can be used by anybody. I laid out some of their advantages above. Before continuing, I should point out some of the other services you may consider:
Cell phones, obviously. Due to the impressive infrastructure you pay for each month (many towers in high locations), in areas of cell coverage, you have this ability to connect to so many other phones around the world. With radios like discussed here, your range will likely a few miles.
Amateur Radio has often been a decade or more ahead of what you see in these easy personal radio devices. You can unquestionably get amateur radio devices with many more features and better performance. However, generally speaking, each person that transmits on an amateur radio band must be licensed. Getting an amateur radio license isn t difficult, but it does involve passing a test and some time studying for the exam. So it isn t something you can count on random friends or family members being able to do. That said, I have resources on Getting Started With Amateur Radio and it s not as hard as you might think! There are also a lot of reasons to use amateur radio if you want to go down that path.
Satellite messengers such as the Garmin Inreach or Zoleo can send SMS-like messages across anywhere in the globe with a clear view of the sky. They also often have SOS features. While these are useful safety equipment, it can take many minutes for a message to be sent and received it s not like an interactive SMS conversation and there are places where local radios will have better signal. Notably, satellite messengers are almost useless indoors and can have trouble in areas without a clear view of the sky, such as dense forests, valleys, etc.
For very short-range service, Briar can form a mesh over Bluetooth from cell phones or over Tor, if Internet access is available.
Dedicated short message services Mesh Networks like Meshtastic or Beartooth have no voice capability, but share GPS locations and short text messages over their own local mesh. Generally they need to pair to a cell phone (even if that phone has no cell service) for most functionality.
Yggdrasil can do something similar over ad-hoc Wifi, but it is a lower-level protocol and you d need some sort of messaging to run atop it.
This article is primarily about the USA, though these concepts, if not the specific implementation, apply many other areas as well.
The landscape of easy personal radios
The oldest personal radio service in the US is Citizens Band (CB). Because it uses a lower frequency band than others, handheld radios are larger, heavier, and less efficient. It is mostly used in vehicles or other installations where size isn t an issue.
The FRS/GMRS services mostly share a set of frequencies. The Family Radio Service is unlicensed (you don t have to get a license to use it) and radios are plentiful and cheap. When you get a blister pack or little radios for maybe $50 for a pair or less, they re probably FRS. FRS was expanded by the FCC in 2017, and now most FRS channels can run up to 2 watts of power (with channels 8-14 still limited to 0.5W). FRS radios are pretty much always handheld.
GMRS runs on mostly the same frequencies as FRS. GMRS lets you run up to 5W on some channels, up to 50W on others, and operate repeaters. GMRS also permits limited occasional digital data bursts; three manufacturers currently use this to exchange GPS data or text messages. To use GMRS, you must purchase a GMRS license; it costs $35 for a person and their immediate family and is good for 10 years. No exam is required. GMRS radios can transmit on FRS frequencies using the GMRS authorization.
The extra power of GMRS gets you extra distance. While only the best handheld GMRS radios can put out 5W of power, some mobile (car) or home radios can put out the full 50W, and use more capable exterior antennas too.
There is also the MURS band, which offers very few channels and also very few devices. It is not in wide use, probably for good reason.
Finally, some radios use some other unlicensed bands. The Motorola DTR and DLR series I will talk about operate in the 900MHz ISM band. Regulations there limit them to a maximum power of 1W, but as you will see, due to some other optimizations, their range is often quite similar to a 5W GMRS handheld.
All of these radios share something in common: your radio can either transmit, or receive, but not both simultaneously. They all have a PTT (push-to-talk) button that you push and hold while you are transmitting, and at all other times, they act as receivers.
You ll learn that doubling is a thing where 2 or more people attempt to transmit at the same time. To listeners, the result is often garbled. To the transmitters, they may not even be aware they did it since, after all, they were transmitting. Usually it will be clear pretty quickly as people don t get responses or responses say it was garbled. Only the digital Motorola DLR/DTR series detects and prevents this situation.
FRS and GMRS radios
As mentioned, the FRS/GMRS radios are generally the most popular, and quite inexpensive. Those that can emit 2W will have pretty decent range; 5W even better (assuming a decent antenna), though the 5W ones will require a GMRS license. For the most part, there isn t much that differentiates one FRS radio from another, or (with a few more exceptions) one GMRS handheld from another. Do not believe the manufacturers claims of 50 mile range or whatever; more on range below.
FRS and GMRS radios use FM. GMRS radios are permitted to use a wider bandwidth than FRS radios, but in general, FRS and GMRS users can communicate with each other from any brand of radio to any other brand of radio, assuming they are using basic voice services.
Some FRS and GMRS radios can receive the NOAA weather radio. That s nice for wilderness use. Nicer ones can monitor it for alert tones, even when you re tuned to a different channel. The very nicest on this as far as I know, only the Garmin Rino series will receive and process SAME codes to only trigger alerts for your specific location.
GMRS (but not FRS) also permits 1-second digital data bursts at periodic intervals. There are now three radio series that take advantage of this: the Garmin Rino, the Motorola T800, and BTech GMRS-PRO. Garmin s radios are among the priciest of GMRS handhelds out there; the top-of-the-line Rino will set you back $650. The cheapest is $350, but does not contain a replaceable battery, which should be an instant rejection of a device like this. So, for $550, you can get the middle-of-the-road Rino. It features a sophisticated GPS system with Garmin trail maps and such, plus a 5W GMRS radio with GPS data sharing and a very limited (13-character) text messaging system. It does have a Bluetooth link to a cell phone, which can provide a link to trail maps and the like, and limited functionality for the radio. The Rino is also large and heavy (due to its large map-capable screen). Many consider it to be somewhat dated technology; for instance, other ways to have offline maps now exist (such as my Garmin Fenix 6 Pro, which has those maps on a watch!). It is bulky enough to likely be left at home in many situations.
The Motorola T800 doesn t have much to talk about compared to the other two.
Both of those platforms are a number of years old. The newest entrant in this space, from budget radio maker Baofeng, is the BTech GMRS-PRO, which came out just a couple of weeks ago. Its screen, though lacking built-in maps, does still have a GPS digital link similar to Garmin s, and can show you a heading and distance to other GMRS-PRO users. It too is a 5W unit, and has a ton of advanced features that are rare in GMRS: ability to pair a Bluetooth headset to it directly (though the Garmin Rino supports Bluetooth, it doesn t support this), ability to use the phone app as a speaker/mic for the radio, longer text messages than the Garmin Rino, etc. The GMRS-PRO sold out within a few days of its announcement, and I am presently waiting for mine to arrive to review. At $140 and with a more modern radio implementation, for people that don t need the trail maps and the like, it makes a compelling alternative to Garmin for outdoor use.
Garmin documents when GPS beacons are sent out: generally, when you begin a transmission, or when another radio asks for your position. I couldn t find similar documentation from Motorola or BTech, but I believe FCC regulations mean that the picture would be similar with them. In other words, none of these devices is continuously, automatically, transmitting position updates. However, you can request a position update from another radio.
It should be noted that, while voice communication is compatible across FRS/GMRS, data communication is not. Garmin, Motorola, and BTech all have different data protocols that are incompatible with radios from other manufacturers.
FRS/GMRS radios often advertise privacy codes. These do nothing to protect your privacy; see more under the privacy section below.
Motorola DLR and DTR series
Although they can be used for similar purposes, and I do, these radios are unique from the others in this article in several ways:
Their sales and marketing is targeted at businesses rather than consumers
They use digital encoding of audio, rather than analog FM or AM
They use FHSS (Frequency-Hopping Spread Spectrum) rather than a set frequency
They operate on the 900MHz ISM band, rather than a 460MHz UHF band (or a lower band yet for MURS and CB)
The DLR series is quite small, smaller than many GMRS radios.
I don t have space to go into a lot of radio theory in this article, but I ll briefly expand on some of this.
First, FHSS. A FHSS radio hops from frequency to frequency many times per second, following some preset hopping algorithm that is part of the radio. Although it complicates the radio design, it has some advantages; it tends to allow more users to share a band, and if one particular frequency has a conflict with something else, it will be for a brief fraction of a second and may not even be noticeable.
Digital encoding generally increases the quality of the audio, and keeps the quality high even in degraded signal conditions where analog radios would experience static or a quieter voice. However, you also lose that sort of audible feedback that your signal is getting weak. When you get too far away, the digital signal drops off a cliff . Often, either you have a crystal-clear signal or you have no signal at all.
Motorola s radios leverage these features to build a unique radio. Not only can you talk to a group, but you can select a particular person to talk to with a private conversation, and so forth. DTR radios can send text messages to each other (but only preset canned ones, not arbitrary ones). Channels are more like configurations; they can include various arbitrary groupings of radios. Deconfliction with other users is established via hopsets rather than frequencies; that is, the algorithm that it uses to hop from frequency to frequency. There is a 4-digit PIN in the DLR radios, and newer DTR radios, that makes privacy very easy to set up and maintain.
As far as I am aware, no scanner can monitor DLR/DTR signals. Though they technically aren t encrypted, cracking a DLR/DTR conversation would require cracking Motorola s firmware, and the chances of this happening in your geographical proximity seem vanishingly small.
I will write more below on comparing the range of these to GMRS radios, but in a nutshell, it compares well, despite the fact that the 900MHz band restrictions allow Motorola only 1W of power output with these radios.
There are three current lines of Motorola DLR/DTR radios:
The Motorola DLR1020 and DLR1060 radios. These have no screen; the 1020 has two channels (configurations) while the 1060 supports 6. They are small and compact and great pocketable just work radios.
The Motorola DTR600 and DTR700 radios. These are larger, with a larger antenna (that should theoretically provide greater range) and have a small color screen. They support more channels and more features (eg, short messages, etc).
The Motorola Curve (aka DLR110). Compared to the DLR1060, it adds limited WiFi capabilities that are primarily useful in certain business environments. See this thread for more. These features are unlikely to be useful in the environments we re talking about here.
These radios are fairly expensive new, but DLRs can be readily found at around $60 on eBay. (DTRs for about $250) They are quite rugged. Be aware when purchasing that some radios sold on eBay may not include a correct battery and charger. (Not necessarily a problem; Motorola batteries are easy to find online, and as with any used battery, the life of a used one may not be great.) For more advanced configuration, the Motorola CPS cable works with both radios (plugs into the charging cradle) and is used with the programming software to configure them in more detail.
The older Motorola DTR650, DTR550, and older radios are compatible with the newer DLR and DTR series, if you program the newer ones carefully. The older ones don t support PINs and have a less friendly way of providing privacy, but they do work also. However, for most, I think the newer ones will be friendlier; but if you find a deal on the older ones, hey, why not?
This thread on the MyGMRS forums has tons of useful information on the DLR/DTR radios. Check it out for a lot more detail.
One interesting feature of these radios is that they are aware if there are conflicting users on the channel, and even if anybody is hearing your transmission. If your transmission is not being heard by at least one radio, you will get an audible (and visual, on the DTR) indication that your transmission failed.
One thing that pleasantly surprised me is just how tiny the Motorola DLR is. The whole thing with antenna is like a small candy bar, and thinner. My phone is slightly taller, much wider, and only a little thinner than the Motorola DLR. Seriously, it s more pocketable than most smartphones. The DTR is of a size more commonly associated with radios, though still on the smaller side. Some of the most low-power FRS radios might get down to that size, but to get equivolent range, you need a 5W GMRS unit, which will be much bulkier.
Being targeted at business users, the DLR/DTR don t include NOAA weather radio or GPS.
Power
These radios tend to be powered by:
NiMH rechargable battery packs
AA/AAA batteries
Lithium Ion batteries
Most of the cheap FRS/GMRS radios have a NiMH rechargable battery pack and a terrible charge controller that will tend to overcharge, and thus prematurely destroy, the NiMH packs. This has long ago happened in my GMRS radios, and now I use Eneloop NiMH AAs in them (charged separately by a proper charger).
The BTech, Garmin, and Motorola DLR/DTR radios all use Li-Ion batteries. These have the advantage of being more efficient batteries, though you can t necessarily just swap in AAs in a pinch. Pay attention to your charging options; if you are backpacking, for instance, you may want something that can charge from solar-powered USB or battery banks. The Motorola DLR/DTR radios need to sit in a charging cradle, but the cradle is powered by a Micro USB cable. The BTech GMRS-PRO is charged via USB-C. I don t know about the Garmin Rino or others.
Garmin offers an optional AA battery pack for the Rino. BTech doesn t (yet) for the GMRS-PRO, but they do for some other models, and have stated accessories for the GMRS-PRO are coming. I don t have information about the T800. This is not an option for the DLR/DTR.
Meshtastic
I ll briefly mention Meshtastic. It uses a low-power LoRa system. It can t handle voice transmissions; only data. On its own, it can transmit and receive automatic GPS updates from other Meshtastic devices, which you can view on its small screen. It forms a mesh, so each node can relay messages for others. It is also the only unit in this roundup that uses true encryption, and its battery lasts about a week more than the a solid day you can expect out of the best of the others here.
When paired with a cell phone, Meshtastic can also send and receive short text messages.
Meshtastic uses much less power than even the cheapest of the FRS radios discussed here. It can still achieve respectable range because it uses LoRa, which can trade bandwidth for power or range. It can take it a second or two to transmit a 50-character text message. Still, the GMRS or Motorola radios discussed here will have more than double the point-to-point range of a Meshtastic device. And, if you intend to take advantage of the text messaging features, keep in mind that you must now take two electronic devices with you and maintain a charge for them both.
Privacy
The privacy picture on these is interesting.
Cell phone privacy
Cell phones are difficult for individuals to eavesdrop, but a sophisticated adversary probably could: or an unsophisticated adversary with any manner of malware. Privacy on modern smartphones is a huge area of trouble, and it is safe to say that data brokers and many apps probably know at least your location and contact list, if not also the content of your messages. Though end-to-end encrypted apps such as Signal can certainly help. See Tools for Communicating Offline and in Difficult Circumstances for more details.
GMRS privacy
GMRS radios are unencrypted and public. Anyone in range with another GMRS radio, or a scanner, can listen to your conversations even if you have a privacy code set. The privacy code does not actually protect your privacy; rather, it keeps your radio from playing conversations from others using the same channel, for your convenience.
However, note the in range limitation. An eavesdropper would generally need to be within a few miles of you.
Motorola DLR/DTR privacy
As touched on above, while these also aren t encrypted, as far as I am aware, no tools exist to eavesdrop on DLR/DTR conversations. Change the PIN away from the default 0000, ideally to something that doesn t end in 0 (to pick a different hopset) and you have pretty decent privacy right there.
Decent doesn t mean perfect; it is certainly possible that sophisticated adversaries or state agencies could decode DLR/DTR traffic, since it is unencrypted. As a practical matter, though, the lack of consumer equipment that can decode this makes it be, as I say, pretty decent .
Meshtastic
Meshtastic uses strong AES encryption. But as messaging features require a paired phone, the privacy implications of a phone also apply here.
Range
I tested my best 5W GMRS radios, as well as a Motorola DTR600 talking to a DLR1060. (I also tried two DLR1060s talking to each other; there was no change in rnage.) I took a radio with me in the car, and had another sitting on my table indoors. Those of you familiar with radios will probably recognize that being in a car and being indoors both attenuate (reduce the strength of) the signal significantly. I drove around in a part of Kansas with gentle rolling hills.
Both the GMRS and the DLR/DTR had a range of about 2-3 miles. There were times when each was able to pull out a signal when the other was not. The DLR/DTR series was significantly better while the vehicle was in motion. In weaker signal conditions, the GMRS radios were susceptible to significant picket fencing (static caused by variation in the signal strength when passing things like trees), to the point of being inaudible or losing the signal entirely. The DLR/DTR remained perfectly clear there. I was able to find some spots where, while parked, the GMRS radios had a weak but audible signal but the DLR/DTR had none. However, in all those cases, the distance to GMRS dropping out as well was small. Basically, no radios penetrate the ground, and the valleys were a problem for them all.
Differences may play out in other ways in other environments as well: for instance, dense urban environments, heavy woods, indoor buildings, etc.
GMRS radios can be used with repeaters, or have a rooftop antenna mounted on a car, both of which could significantly extend range and both of which are rare.
The DLR/DTR series are said to be exceptionally good at indoor environments; Motorola rates them for penetrating 20 floors, for instance. Reports on MyGMRS forums state that they are able to cover an entire cruise ship, while the metal and concrete in them poses a big problem for GMRS radios. Different outdoor landscapes may favor one or the other also.
Some of the cheapest FRS radios max out at about 0.5W or even less. This is probably only a little better than yelling distance in many cases. A lot of manufacturers obscure transmit power and use outlandish claims of range instead; don t believe those. Find the power output. A 2W FRS transmitter will be more credible range-wise, and the 5W GMRS transmitter as I tested better yet. Note that even GMRS radios are restricted to 0.5W on channels 8-14.
The Motorola DLR/DTR radio gets about the same range with 1W as a GMRS radio does with 5W. The lower power output allows the DLR to be much smaller and lighter than a 5W GMRS radio for similar performance.
Overall conclusions
Of course, what you use may depend on your needs. I d generally say:
For basic use, the high quality, good range, reasonable used price, and very small size of the Motorola DLR would make it a good all-arounder. Give one to each person (or kid) for use at the mall or amusement park, take them with you to concerts and festivals, etc.
Between vehicles, the Motorola DLR/DTR have a clear range advantage over the GMRS radios for vehicles in motion, though the GPS features of the more advanced GMRS radios may be more useful here.
For wilderness hiking and the like, GMRS radios that have GPS, maps, and NOAA weather radio reception may prove compelling and worth the extra bulk. More flexible power options may also be useful.
Low-end FRS radios can be found very cheap; around $20-$30 new for the lowest end, though their low power output and questionable charging circuits may limit their utility where it really counts.
If you just can t move away from cell phones, try the Zoleo app, which can provide some radio-like features.
A satellite communicator is still good backup safety gear for the wilderness.
Postscript: A final plug for amateur radio
My 10-year-old Kenwood TH-D71A already had features none of these others have. For instance, its support for APRS and ability to act as a digipeater for APRS means that TH-D71As can form an automatic mesh between them, each one repeating new GPS positions or text messages to the others. Traditional APRS doesn t perform well in weak signal situations; however, more modern digital systems like D-Star and DMR also support APRS over more modern codecs and provide all sorts of other advantages as well (though not FHSS).
My conclusions above assume a person is not going to go the amateur radio route for whatever reason. If you can get those in your group to get their license the technician is all you need a whole world of excellent options opens to you.
Appendix: The Trisquare eXRS
Prior to 2012, a small company named Trisquare made a FHSS radio they called the eXRS that operated on the 900MHz band like Motorola s DLR/DTR does. Trisquare aimed at consumers and their radios were cheaper than the Motorola DLR/DTR. However, that is where the similarities end.
Trisquare had an analog voice transmission, even though it used FHSS. Also, there is a problem that can arise with FHSS systems: synchronization. The receiver must hop frequencies in exactly the same order at exactly the same time as the sender. Motorola has clearly done a lot of engineering around this, and I have never encountered a synchronization problem in my DLR/DTR testing, not even once. eXRS, on the other hand, had frequent synchronization problems, which manifested themselves in weak signal conditions and sometimes with doubling. When it would happen, everyone would have to be quiet for a minute or two to give all the radios a chance to timeout and reset to the start of the hop sequence. In addition, the eXRS hardware wasn t great, and was susceptible to hardware failure.
There are some that still view eXRS as a legendary device and hoard them. You can still find them used on eBay. When eXRS came out in 2007, it was indeed nice technology for the day, ahead of its time in some ways. I used and loved the eXRS radios back then; powerful GMRS wasn t all that common. But compared to today s technology, eXRS has inferior range to both GMRS and Motorola DLR/DTR (from my recollection, about a third to half of what I get with today s GMRS and DLR/DTR), is prone to finicky synchronization issues when signals are weak, and isn t made very robustly. I therefore don t recommend the eBay eXRS units.
Don t assume that the eXRS weaknesses extend to Motorola DLR/DTR. The DLR/DTR radios are done well and don t suffer from the same problems.
Note: This article has a long-term home on my website, where it may be updated from time to time.
Web caching is hard. And also, maybe I m not that good under pressure? In any
event, I made the following mistakes while trying to debug a web site using our
nginx cache that bit the dust under heavy load today:
Action: I ran curl -I https://website.org/ and it hung.
Wrong assumption: Something is wrong with nginx. Why else would it just hang?
Reconsidered conclusion: The resource (the home page) is a MISS, so nginx has
to retrieve it from the origin, but the origin is over-loaded and timing out,
so my request is also timing out. Maybe something is wrong with the nginx
caching configuration since the home page really should be a HIT but that s
another problem.
Action: I changed the configuration from our normal caching set of
directives to our aggressive caching set of directives, reloaded nginx and
curl -I https://website.org/ still hung.
Wrong assumption: aggressive caching isn t working and I need a different
configuration.
Reconsidered conclusion: The home page still has failed to be loaded from the
origin, so every request for it is going to be a MISS, and is going to hang,
until nginx is able to fill the cache with it. The configuration change might
be the right change; we just need the origin to calm down before we will know.
Action: I restarted PHP on the origin to free up PHP processes so my home
page request can fill the cache and stillcurl -I https://website.org/
hangs.
Wrong assumption: WTF! The world is ending!
Reconsidered conclusion: The regular traffic which is accessing other pages
(not the home page) consumed all the available PHP processes on the origin
before my request for the home page could complete, so nginx is still unable
to fill the cache with the home page.
Action: Once we got things under control, I changed the caching level from
aggressive back down to normal. I ran curl -I https://website.org/ and it was
HIT ing. I concluded that we don t need the aggressive cache after all. Got
some coffee, came back later and ran it again and it consistently showed MISS.
Wrong assumption: What?!? Did something change on the origin to stop the
cache from working??
Reconsidered conclusion: The aggressive cache set the cache for 5 minutes.
Even after changing to normal caching, the home page was still cached so it
was served from the cache. After 5 minutes, the cache expired. Now, the normal
cache setting are in play to determine whether the request would be cached or
not. In other words, you have to wait for the cache to expire (or bust the
cache) before you can effectively know if the new cache settings are working.
These past couple of months I have been working to bring
debuginfod to
Ubuntu. I thought it would be a good idea to make this post and
explain a little bit about what the service is and how I'm planning to
deploy it.
A quick recap: what's debuginfod?
Here's a good summary of what debuginfod is:
If you follow the Debian project, you might know that I run their
debuginfod service. In fact, the
excerpt above was taken from the
announcement
I made last year, letting the Debian community know that the service
was available.
First stage
With more and more GNU/Linux distributions offering a debuginfod
service to their users, I strongly believe that Ubuntu cannot afford
to stay out of this "party" anymore. Fortunately, I have a
manager who not only agrees with me
but also turned the right knobs in order to make this project one of
my priorities for this development cycle.
The deployment of this service will be made in stages. The first one,
whose results are due to be announced in the upcoming weeks,
encompasses indexing and serving all of the available debug symbols
from the official Ubuntu repository. In
other words, the service will serve everything from main, universe
and multiverse, from every supported Ubuntu release out there.
This initial (a.k.a. "alpha") stage will also allow us to have an
estimate of how much the service is used, so that we can better
determine the resources allocated to it.
More down the road
This is just the beginning. In the following cycles, I will be
working on a few interesting projects to expand the scope of the
service and make it even more useful for the broader Ubuntu community.
To give you an idea, here is what is on my plate:
Working on the problem of indexing and serving source code as
well. This is an interesting problem and I already have some ideas,
but it's also challenging and may unfold into more sub-projects.
The good news is that a solution for this problem will also be
beneficial to Debian.
Working with the snap developers to come up with a way to index and
serve debug symbols for snaps as well.
Improve the integration of the service into Ubuntu. In fact, I have
already started working on this by making elfutils (actually,
libdebuginfod) install a customized shell snippet to automatically
setup access to Ubuntu's debuginfod instance.
As you can see, there's a lot to do. I am happy to be working on this
project, and I hope it will be helpful and useful for the Ubuntu
community.
Review: Still Not Safe, by Robert L. Wears & Kathleen M. Sutcliffe
Publisher:
Oxford University Press
Copyright:
November 2019
ISBN:
0-19-027128-0
Format:
Kindle
Pages:
232
Still Not Safe is an examination of the recent politics and history
of patient safety in medicine. Its conclusions are summarized by the
opening paragraph of the preface:
The American moral and social philosopher Eric Hoffer reportedly said
that every great cause begins as a movement, becomes a business, and
eventually degenerates into a racket. The reform movement to make
healthcare safer is clearly a great cause, but patient safety efforts
are increasingly following Hoffer's path.
Robert Wears was Professor of Emergency Medicine at the University of
Florida specializing in patient safety. Kathleen Sutcliffe is Professor
of Medicine and Business at Johns Hopkins. This book is based on research
funded by a grant from the Robert Wood Johnson Foundation, for which both
Wears and Sutcliffe were primary investigators. (Wears died in 2017, but
the acknowledgments imply that at least early drafts of the book existed
by that point and it was indeed co-written.)
The anchor of the story of patient safety in Still Not Safe is the
1999 report from the Institute of Medicine entitled To Err is
Human, to which the authors attribute an explosion of public scrutiny of
medical safety. The headline conclusion of that report, which led nightly
news programs after its release, was that 44,000 to 120,000 people died
each year in the United States due to medical error. This report prompted
government legislation, funding for new safety initiatives, a flurry of
follow-on reports, and significant public awareness of medical harm. What
it did not produce, in the authors' view, is significant improvements in
patient safety.
The central topic of this book is an analysis of why patient safety
efforts have had so little measurable effect. The authors attribute this
to three primary causes: an unwillingness to involve safety experts from
outside medicine or absorb safety lessons from other disciplines, an
obsession with human error that led to profound misunderstandings of the
nature of safety, and the misuse of safety concerns as a means to
centralize control of medical practice in the hands of
physician-administrators. (The term used by the authors is "managerial,
scientific-bureaucratic medicine," which is technically accurate but
rather awkward.)
Biggest complaint first: This book desperately needed examples,
case studies, or something to make these ideas concrete. There are
essentially none in 230 pages apart from passing mentions of famous cases
of medical error that added to public pressure, and a tantalizing but
maddeningly nonspecific discussion of the atypically successful effort to
radically improve the safety of anesthesia. Apparently anesthesiologists
involved safety experts from outside medicine, avoided a focus on human
error, turned safety into an engineering problem, and made concrete
improvements that had a hugely positive impact on the number of adverse
events for patients. Sounds fascinating! Alas, I'm just as much in the
dark about what those improvements were as I was when I started reading
this book. Apart from a vague mention of some unspecified improvements to
anesthesia machines, there are no concrete descriptions whatsoever.
I understand that the authors were probably leery of giving too many
specific examples of successful safety initiatives since one of their core
points is that safety is a mindset and philosophy rather than a replicable
set of actions, and copying the actions of another field without
understanding their underlying motivations or context within a larger
system is doomed to failure. But you have to give the reader
something, or the book starts feeling like a flurry of abstract
assertions. Much is made here of the drawbacks of a focus on human error,
and the superiority of the safety analysis done in other fields that have
moved beyond error-centric analysis (and in some cases have largely
discarded the word "error" as inherently unhelpful and ambiguous). That
leads naturally to showing an analysis of an adverse incident through an
error lens and then through a more nuanced safety lens, making the
differences concrete for the reader. It was maddening to me that the
authors never did this.
This book was recommended to me as part of a discussion about safety and
reliability in tech and the need to learn from safety practices in other
fields. In that context, I didn't find it useful, although surprisingly
that's because the thinking in medicine (at least as presented by these
authors) seems behind the current thinking in distributed systems. The
idea that human error is not a useful model for approaching reliability is
standard in large tech companies, nearly all of which use
blameless
postmortems for exactly that reason. Tech, similar to medicine, does
have a tendency to be insular and not look outside the field for good
ideas, but the approach to large-scale reliability in tech seems to have
avoided the other traps discussed here. (Security is another matter, but
security is also adversarial, which creates different problems that I
suspect require different tools.)
What I did find fascinating in this book, although not directly applicable
to my own work, is the way in which a focus on human error becomes a
justification for bureaucratic control and therefore a concentration of
power in a managerial layer. If the assumption is that medical harm is
primarily caused by humans making avoidable mistakes, and therefore the
solution is to prevent humans from making mistakes through better
training, discipline, or process, this creates organizations that are
divided into those who make the rules and those who follow the rules. The
long-term result is a practice of medicine in which a small number of
experts decide the correct treatment for a given problem, and then all
other practitioners are expected to precisely follow that treatment plan
to avoid "errors." (The best distributed systems approaches may avoid
this problem, but this failure mode seems nearly universal in technical
support organizations.)
I was startled by how accurate that portrayal of medicine felt. My
assumption prior to reading this book was that the modern experience of
medicine as an assembly line with patients as widgets was caused by the
pressure for higher "productivity" and thus shorter visit times, combined
with (in the US) the distorting effects of our broken medical insurance
system. After reading this book, I've added a misguided way of thinking
about medical error and risk avoidance to that analysis.
One of the authors' points (which, as usual, I wish they'd made more
concrete with a case study) is that the same thought process that lets a
doctor make a correct diagnosis and find a working treatment is the
thought process that may lead to an incorrect diagnosis or treatment.
There is not a separable state of "mental error" that can be eliminated.
Decision-making processes are more complicated and more integrated than
that. If you try to prevent "errors" by eliminating flexibility, you also
eliminate vital tools for successfully treating patients.
The authors are careful to point out that the prior state of medicine in
which each doctor was a force to themselves and there was no role for
patient safety as a discipline was also bad for safety. Reverting to the
state of medicine before the advent of the scientific-bureaucratic
error-avoiding culture is also not a solution. But, rather at odds with
other popular books about medicine, the authors are highly critical of
safety changes focused on human error prevention, such as mandatory
checklists. In their view, this is exactly the sort of attempt to blindly
copy the machinery of safety in another field (in this case, air travel)
without understanding the underlying purpose and system of which it's a
part. I am not qualified to judge the sharp dispute over whether there is
solid clinical evidence that checklists are helpful (these authors claim
there is not; I know other books make different claims, and I suspect it
may depend heavily on how the checklist is used). But I found the
authors' argument that one has to design systems holistically for safety,
not try to patch in safety later by turning certain tasks into rote
processes and humans into machines, to be persuasive.
I'm not willing to recommend this book given how devoid it is of concrete
examples. I was able to fill in some of that because of prior experience
with the literature on site reliability engineering, but a reader who
wasn't previously familiar with discussions of safety or reliability may
find much of this book too abstract to be comprehensible. But I'm not
sorry I read it. I hadn't previously thought about the power dynamics of
a focus on error, and I think that will be a valuable observation to keep
in mind.
Rating: 6 out of 10
The last day
The first lesson I would like everybody to know and have is to buy two machines, especially a machine to check low blood pressure. I had actually ordered one from Amazon but they never delivered. I hope to sue them in consumer court in due course of time. The other one is a blood sugar machine which I ordered and did get, but the former is more important than the latter, and the reason why will be known soon.
Mum had stopped eating solids and was entirely on liquids for the last month of her life. I did try enticing her however I could with aromatic food but failed. Add to that we had weird weather this entire year. June is supposed to be when the weather turns and we have gentle showers, but this whole June it felt like we were in an oven. She asked for liquids whenever and although I hated that she was not eating solids, at least she was having liquids (juices and whatnot) and that s how I pacified myself. I had been repeatedly told by family and extended family to get a full-time nurse but she objected time and again for the same and I had to side with her.
Then July 1st came around and part of extended family also came, and they impressed both on me and her to get a nurse so finally, I was able to get her nurse. I was also being pulled in various directions (outside my stuff, mumma s stuff) and doing whatever she needed in terms of supplies. On July 4th, think she had low blood pressure but without a machine, one cannot know. At least that s what I know. If somebody knows anything better, please share, who knows it may save lives. I don t have a blood pressure monitor even to date
There used to be 5-6 doctors in our locality before the Pandemic, but because of the Pandemic and whatever other reasons, almost all doctors had given up attending house calls. And the house where I live is a 100-year-old house so it has narrow passageways and we have no lift. So taking her in and out is a challenge and an ordeal, and something that is not easily done. I had to do some more works so I asked the nurse to stay a bit over 8 p.m. I came and the nurse left for the day. That day I had been distracted for a number of reasons which I don t remember what was but at that point in time, doing those works seemed important. I called out to her but she didn t respond. I remember the night before she had been agitated while sleeping, I slept nearby and kept an eye on her. I had called her a few times to ask whether she needed something but she didn t respond. (this is about the earlier night). That evening, it was raining quite a bit, I called her a few times but she didn t speak. I kissed her on the cheek and realized she is cold. Mumma usually becomes very agitated if she feels cold and shouts at me. I realized she is cold and her body a bit stiff. I was supposed to eat but just couldn t. I dunno what I suspected, I just hired a rickshaw and went around till 9 p.m. and it was a fruitless search for a doctor. I returned home, and again called her but there was no response.
Because she was not responding, I became fearful, had a shat, and then dialed the hospital. Asking for the ambulance, it took about an hr. but finally, the ambulance came in. It was now 11 o clock or 2300 hrs. when the ambulance arrived in. It took another half an hr. getting few kids who had come from some movie or something to get them to help mum get down through the passage to the ambulance. We finally reached the hospital at 2330. The people on casualty that day were known to me, and they also knew my hearing problem, so it was much easier to communicate. Half an hour later, they proclaimed her dead.
Fortunately or not, I had just bought the newer mobile phone just a few days back. And right now, In India, WhatsApp is one of the most used apps. So I was able to chat with everybody and tell them what was happening or rather what has happened. Of all, mamaji (mother s brother) shared that most members of the family would not be able to come except a cousin sister who lives in Mumbai. I was instructed to get the body refrigerated for a few hrs. It is only then I came to know various ways in which the body is refrigerated and how cruel it would have been towards Atal Bihari Vajpayee s family, but that is politics. I had to go to quite a few places and was back home around 3 a.m. I was supposed to sleep, but sleep was out of the question. I whiled away a few hrs. playing, seeing movies, something or the other to keep myself distracted as literally, I had no idea what to do. Morning came, took a bath, went outside, had some snacks, came home and somewhere then slept. One of my Mausi s (mother s sister) was insisting to get the body burnt in the morning itself but I wanted at least one relative to be there on the last journey. Cousin sister and her husband came to Pune around 4 p.m. I somehow woke, ringing, the vibration I do not know what. I took a short bath, rushed to the place where we had kept the body, got the body and from there where we had asked permission to get the body burned. More than anything else, I felt so sad that except for cousin sister, and me, nobody was with her on the last journey. Even that day, it was raining hard, so people avoided going out. Brother-in-law tried to give me some money, but I brushed it off. I just wanted their company, money is and was never the criteria. So, in the evening we had a meal, my cousin sister, brother-in-law, their two daughters and me. The next day we took the bones and ash to Alandi and did what was needed.
I have tried to resurrect the day so many times in my head trying to figure out what I could have done better and am inconclusive. Having a blood pressure monitor for sure would have prevented the tragedy or at least post-phoned for it for a few more days, weeks, years, dunno. I am not medically inclined.
The Books
I have to confess, the time they said she is no more, I was hoping that the doctors would say, we have a pill, would you like to take it, it would reunite you with mum. Maybe it wa crazy or whatever, but if such a situation had been, I would have easily gone for it. If I were to go, some people might miss me, but nobody would miss me terribly, and at least I would be with her. There was nothing to look forward to. What saved me from going mad was Michael Crichton s Timeline. It is a fascinating and seductive book. I had actually read it years ago but had forgotten. So many days and nights I was able to sleep hoping that quantum teleportation can be achieved. Anybody in my space would be easily enticed. What joy would it be if I were to meet mum once again. I can tell my other dumb child what to do so she lives for few more years. I could talk to her, just be with her for some time. It is a powerful and seductive idea. I can see so many cults and whatnot that can be formed around it, there may already be, who knows.
Another good book that helped me to date has been Through The, Rings Of Fire (Hardcover, J. D. Benedict Thyagarajan). It is an autobiography of Venkat Chalasany (story of an orphan boy who became a successful builder in Pune and the setbacks he had.) While the author has very strong views and I sometimes feel very naive views about things, I was taken a ride of my own city as it was in 1970s and 1980s. I could very well imagine all the different places and people as if they were happening right now. While I have finished the main story, there is still a bit left to read and I read 5-10 minutes every day as it s like a sweet morsel, it s like somebody sharing a tale passed without me having to make an effort. And no lies, the author has been pretty upfront where he has exaggerated or told lies or simply made-up stuff.
I was thinking of adding something about movies and some more info or impressions about android but it seems that would have to wait, I do hope, it does work for somebody, even if a single life can be saved from what I shared above, my job is done.
I run Debian on my laptop (obviously); but occasionally, for $DAYJOB, I
have some work to do on Windows. In order to do so, I have had a Windows
10 VM in my libvirt configuration that I can use.
A while ago, Microsoft issued Windows 11. I recently found out that all
the components for running Windows 11 inside a libvirt VM are available,
and so I set out to upgrade my VM from Windows 10 to Windows 11. This
wasn't as easy as I thought, so here's a bit of a writeup of all the
things I ran against, and how I fixed them.
Windows 11 has a number of hardware requirements that aren't necessary
for Windows 10. There are a number of them, but the most important three
are:
Secure Boot is required (Windows 10 would still boot on a machine
without Secure Boot, although buying hardware without at least
support for that hasn't been possible for several years now)
A v2.0 TPM module (Windows 10 didn't need any TPM)
A modern enough processor.
So let's see about all three.
A modern enough processor
If your processor isn't modern enough to run Windows 11, then you can
probably forget about it (unless you want to use qemu JIT compilation --
I dunno, probably not going to work, and also not worth it if it were).
If it is, all you need is the "host-passthrough" setting in libvirt,
which I've been using for a long time now. Since my laptop is less than
two months
old, that's not a
problem for me.
A TPM 2.0 module
My Windows 10 VM did not have a TPM configured, because it wasn't
needed. Luckily, a quick web search told me that enabling that is not
hard. All you need to do is:
Install the swtpm and swtpm-tools packages
Adding the TPM module, by adding the following XML snippet to your VM
configuration:
Alternatively, if you prefer the graphical interface, click on the
"Add hardware" button in the VM properties, choose the TPM, set it
to Emulated, model TIS, and set its version to 2.0.
You're done!
Well, with this part, anyway. Read on.
Secure boot
Here is where it gets interesting.
My Windows 10 VM was old enough that it was configured for the older
i440fx chipset. This one is limited to PCI and IDE, unlike the more
modern q35 chipset (which supports PCIe and SATA, and does not support
IDE nor SATA in IDE mode).
There is a UEFI/Secure Boot-capable BIOS for qemu, but it apparently
requires the q35 chipset,
Fun fact (which I found out the hard way): Windows stores where its boot
partition is somewhere. If you change the hard drive controller from an
IDE one to a SATA one, you will get a BSOD at startup. In order to fix
that, you need a recovery
drive.
To create the virtual USB disk, go to the VM properties, click "Add
hardware", choose "Storage", choose the USB bus, and then under
"Advanced options", select the "Removable" option, so it shows up as a
USB stick in the VM. Note: this takes a while to do (took about an hour
on my system), and your virtual USB drive needs to be 16G or larger (I
used the libvirt default of 20G).
There is no possibility, using the buttons in the virt-manager GUI, to
convert the machine from i440fx to q35. However, that doesn't mean
it's not possible to do so. I found that the easiest way is to use the
direct XML editing capabilities in the virt-manager interface; if you
edit the XML in an editor it will produce error messages if something
doesn't look right and tell you to go and fix it, whereas the
virt-manager GUI will actually fix things itself in some cases (and
will produce helpful error messages if not).
What I did was:
Take backups of everything. No, really. If you fuck up, you'll have
to start from scratch. I'm not responsible if you do.
Go to the Edit->Preferences option in the VM manager, then on the
"General" tab, choose "Enable XML editing"
Open the Windows VM properties, and in the "Overview" section, go to
the "XML" tab.
Change the value of the machine attribute of the domain.os.type
element, so that it says pc-q35-7.0.
Search for the domain.devices.controller element that has pci in
its type attribute and pci-root in its model one, and set the
model attribute to pcie-root instead.
Find all domain.devices.disk.target elements, setting their
dev=hdX to dev=sdX, and bus="ide" to bus="sata"
Find the USB controller (domain.devices.controller with
type="usb", and set its model to qemu-xhci. You may also want to
add ports="15" if you didn't have that yet.
I figured out most of this by starting the process for creating a new
VM, on the last page of the wizard that pops up selecting the "Modify
configuration before installation" option, going to the "XML" tab on the
"Overview" section of the new window that shows up, and then comparing
that against what my current VM had.
Also, it took me a while to get this right, so I might have forgotten
something. If virt-manager gives you an error when you hit the Apply
button, compare notes against the VM that you're in the process of
creating, and copy/paste things from there to the old VM to make the
errors go away. As long as you don't remove configuration that is
critical for things to start, this shouldn't break matters permanently
(but hey, use your backups if you do break -- you have backups, right?)
OK, cool, so now we have a Windows VM that is... unable to boot.
Remember what I said about Windows storing where the controller is?
Yeah, there you go. Boot from the virtual USB disk that you created
above, and select the "Fix the boot" option in the menu. That will fix
it.
Ha ha, only kidding. Of course it doesn't.
I honestly can't tell you everything that I fiddled with, but I
think the bit that eventually fixed it was where I chose "safe mode",
which caused the system to do a hickup, a regular reboot, and then
suddenly everything was working again. Meh.
Don't throw the virtual USB disk away yet, you'll still need it.
Anyway, once you have it booting again, you will now have a machine that
theoretically supports Secure Boot, but you're still running off an
MBR partition. I found a
procedure
on how to convert things from MBR to GPT that was written almost 10
years ago, but surprisingly it still works, except for the bit where the
procedure suggests you use diskmgmt.msc (for one thing, that was
renamed; and for another, it can't touch the partition table of the
system disk either).
The last step in that procedure says to restart your computer!,
which is fine, except at this point you obviously need to switch over to
the TianoCore firmware, otherwise you're trying to read a UEFI boot
configuration on a system that only supports MBR booting, which
obviously won't work. In order to do that, you need to add a loader
element to the domain.os element of your libvirt configuration:
When you do this, you'll note that virt-manager automatically adds an
nvram element. That's fine, let it.
I figured this out by looking at the documentation for enabling Secure
Boot in a VM on the
Debian wiki, and using the same trick as for how to switch chipsets that
I explained above.
Okay, yay, so now secure boot is enabled, and we can install Windows 11!
All good? Well, almost.
I found that once I enabled secure boot, my display reverted to a
1024x768 screen. This turned out to be because I was using older
unsigned drivers, and since we're using Secure Boot, that's no longer
allowed, which means Windows reverts to the default VGA driver, and that
only supports the 1024x768 resolution. Yeah, I know. The solution is
to download the virtio-win ISO from one of the links in the virtio-win
github project,
connecting it to the VM, going to Device manager, selecting the display
controller, clicking on the "Update driver" button, telling the system
that you have the driver on your computer, browsing to the CD-ROM drive,
clicking the "include subdirectories" option, and then tell Windows to
do its thing. While there, it might be good to do the same thing for
unrecognized devices in the device manager, if any.
So, all I have to do next is to get used to the completely different
user interface of Windows 11. Sigh.
Oh, and to rename the "w10" VM to "w11", or some such. Maybe.