To protect yourself from disinformation and fake news you should determine whether the speaker is an authority on the subject. That's what a lot of digital literacy guides say. But it's wrong on two fronts. First, a lot of authorities are wrong, or worse, deceitful. And second, a lot of non-authorities are right. So how do you decide? The answer is to never trust just one source. That's how newspapers do it, or at least, are supposed to do it. As Harold Jarche argues in this post, it's better to rely on a network of voices on a given subject. The question is, how can you know the network is reliable? My response is to refer to the semantic condition for networks: diversity, autonomy, openness, interactivity. A network based on webs, not stars.
I previously have written about the importance and the right to clear access of sidewalks and how in this rush to be “environmentally responsible” we seem to be promoting private vehicle ownership as long as it is electric vehicles. The fact that any Climate Emergency Action Plan (CEAP) should probably always address the most vulnerable sidewalk user is lost in the haste to make the electric vehicle car owner happy. Those EV owner folks already have had up to $8,000 in grants given because they could afford to buy that kind of car, and research is already showing that men are the predominate owners of these vehicles, as they are still too expensive for most women, who have lower incomes. But that’s not part of this equitable dialogue.
Despite the fact that everyone can charge these vehicles at faster electric stations located elsewhere, the City of Vancouver has decided that residents can now legally charge their vehicles in front of their homes, dangling cords across front lawn areas, tucking them under plastic conduits on the sidewalk, and into their vehicle. The charge allowed is only the Level 1 trickle, which takes forever, and which means that vehicles will be charging overnight and weekends. A one hour charge at Level 1 allows you to drive three to six kilometers. Turtle time.
Sounds fine right?
It is surprising that in a city that is valuing “sustainability” in transportation to forget that the most vulnerable road users need unfettered access to the sidewalks. In Vancouver many of those same people from an equity perspective walk, roll or use transit because they cannot afford a vehicle, let alone an electric vehicle.
In the report the City of Vancouver is basing their recommendations on the voluntary program run by the City of Seattle that allows level one charging if a five foot by four foot platform ramp that covers the entire width of the sidewalk is provided to tuck the cord through. (City staff is proposing a 1.2 meter long platform). There’s no report on how the Seattle program is going, and the City of Vancouver staff has no records on charging cord complaints here because they don’t collect data that way.
There were no visual presentations or samples from city staff to show how the cord conduits would look on city sidewalks. There were no photos of current EV cord installations. Staff did not know how many streets had sidewalks, and how many had curbs in the areas that would be allowed to have electrical cord access on city sidewalks. There was some confusion from staff whether the Persons with Disabilities Advisory Committee had considered the report. It turned out they had seen it, but not really given an official response.
In questioning the Seniors Advisory Committee had not seen the report at all.
The report was also not signed off by the Planning Department who definitely would have had community feedback on electrical conduits placed upon neighbourhood sidewalks.
We need to be grateful to the two speakers who registered to speak to this item, Leonard Schein and Richard Campbell . They pretty much identified the research and data that should have been done before this item went to Council.
Mr. Schein pointed out that he had been walking across the city during the pandemic and wondered why the City was not looking at the installation of a cord conduit under the sidewalk, which was done as a test pilot by the city. While city staff pooh poohed this approach due to high cost, Mr Schein (who as a prominent business owner knows a lot about this kind of thing) explained that the cost would be a few hundred dollars, and had even worked out all the metrics which he presented to Council.
He drew upon his experience in Europe and living in Saskatoon with snaking block heater cord across city sidewalks. Mr. Schein pointed out that keeping sidewalks unfettered by cords was probably pretty desirable, and asked what had happened to the City’s pilot on trenching the cords under sidewalks. That pilot with up to fifteen “test” participants was never reported back to Council or results mentioned .
Richard Campbell quite correctly noted that the Persons with Disabilities Advisory Committee of Council were volunteers on a committee, not the disability experts with specific training to evaluate the impacts of cord conduits on public sidewalks. He pointed out that it was time for the City to hire the experts needed to do these assessments, and passing that responsibility off to a volunteer committee “was not helpful”. The Canadian Institute for the Blind (CNIB) had clearly indicated that the placement of this infrastructure on sidewalks was not acceptable; why was Council helping out vehicle owners privileged enough to own still expensive electric vehicles? Where was the equity in not considering use of sidewalks by people who don’t own electric vehicles?
Despite all the holes in this report this Council was not to be deterred and even entertained a motion to allow electric vehicles to charge across sidewalks without a $5.00 permit fee. That idea failed, but the entire Council (minus Pete Fry who was absent on City business) unanimously approved the report. Council saw this as a golden opportunity to cut red tape, calling electric vehicle owners “beleaguered” and that putting encumbrances on sidewalks were “part of a mix of approaches”.
It appears this endeavour is one for mostly single family neighbourhoods to enjoy. Council congratulated itself on fast tracking the initiative and noted that it was low-cost, and had no implications to staffing levels at the City of Vancouver. And now Vancouver has the dubious distinction of being one of the first cities in Canada to openly allow the placement of electrical cords in plastic conduits over city owned sidewalks.
If you own an electric vehicle it was a very good day. If you use sidewalks and are older, disabled, or sight impaired, not so much.
My big project this week was this Video introduction to Datasette and sqlite-utils. I recorded the video a few weeks ago in advance of FOSDEM, but this week I put together the annotated version. I'm really happy with it, and I've added it to the datasette.io homepage as a starting point for helping people understand the project.
Annotating the video
I'm not a huge watcher of video tutorials - I'm impatient and find myself watching them at double speed and still complaining that a text version would be more efficient. So when I publish my own videos I like to accompany them with a useful text version.
The format I've settled on - for this video and for others like Personal Data Warehouses: Reclaiming Your Data - is to use screenshots from the video accompanied by notes, links and code samples. Ideally you can read the text version without watching the video at all, but if you do watch the video the text version can provide extended annotations.
I created this one on macOS using the combination of QuickTime Player and Preview. If you hit Command+C while watching a video in QuickTime Player a PNG snapshot gets copied to your clipboard. Switch to Preview with Command+Tab and hit Command+N to create a new untitled document there containing the image.
I ran through the video creating snapshots of each interesting moment in this way, leaving 40+ open Preview documents called "Untitled", "Untitled 2" and so on.
When I reached the end of the video I switched back to Preview and used Command+S to save each open document in turn, creating a folder full of images with names like "Untitled 2.png". These were in the correct order.
I used the Finder "Rename 40 items..." right-click menu option to remove the Untitled prefix.
I constructed an Observable notebook which accepts a list of filenames (copied and pasted directly from the Finder) and turns them into a sequence of those HTML templates.
Having built out the HTML framework for the page, the last step was to go through and add the annotations. I did that by editing the HTML directly.
It turns out there are two rival standards for this. TMS - Tile Map Service - is a tile specification developed by the Open Source Geospatial Foundation. It's used by the MBTiles specification which is why datasette-tiles was using it.
Google Maps and OpenStreetMap do things slightly differently - counting Y from the top of the map instead of the bottom. This has become the de facto standard for web mapping. Tom MacWright has published a useful explainer of the diffference between the two.
I made myself a couple of diagrams to ensure I completely understood how the two tile systems work:
datasette-tiles 0.6 ships a breaking change that switches the default serving mechanism to the OpenStreetMap system - so /-/tiles/db/z/x/y.png now serves tiles using that coordinate system.
If you want the TMS mechanism, you can use the new /-/tiles-tms/db/z/x/y.png endpoint instead.
Lukas mentioned there were three groups in his conversation, one using specialised tools, one group using no digital tools, and one group using more general tools (“like Roam, Notion or Airtable“). I’m definitely one of the latter.
After reading Rick’s posting a year ago I parked it for a while, but when I adopted Obsidian for note taking, after a while I also started using it for some light weight CRM notes. Unlike Rick I haven’t added any process or automation, but I did start creating CRM notes so that something like it might become possible over time.
What I started with is making notes about people I encounter.
LinkedIn has one glaring hole in its functionality and that is allowing me to add something about the context of when I met someone. After using LinkedIn for 16 years I now sometimes come across a LinkedIn contact and then don’t remember how or why we connected. LinkedIn by now does show when you connected, allowing me to browse through someone’s CV to see what that person did when we connected and try to remember the context of that connection. Xing, mostly used in German speaking countries, had this from the start including a field for a few notes on when / how you met someone. That has proved valuable. [UPDATE In the comments Aad points out such a feature has been present at some point. Online search suggests it was introduced in 2013/4 with LinkedIn Contacts, and became a premium-only feature from 2017. By 2013 I had some 2k contacts, 8 years worth of interaction, where such contextual info was missing, and I use the free version, so the general point stands, even if factually not correct since 2013]
Back when I used a wiki on my laptop for notes, I also kept CRM style notes in it, especially 2004-2008. The useful bit was that I could link to a person’s page in the various notes I made about meetings, events etc. That ‘backlinking’ overview in itself was a great way of adding contextual info.
With Obsidian and the use of simple text files in markdown I have that back, and actually in a better way than in that wiki of old. Because those text files can be approached by a wide variety of software tools, not just Obsidian.
I’m not attempting to be complete in these CRM notes, I grow them the same way as I grow the other type of notes: when I encounter someone new I make note of it. Especially when I don’t know someone yet, or don’t have a strong connection to someone I make those notes. Not so much of people that I’m already connected to like colleagues. I’ve started a few new projects in the past few months, which is always a moment when you encounter a lot of new people in a new context. So those I’ve made notes for, as it helps understand a new client organisation, relevant stakeholders and context. For now backlinking in meeting and project notes is the way for adding a record of interaction.
Maybe in a year or so I can start doing more pro-active things with those notes, like Rick has built into his routines. Another element to me is potentially leaving LinkedIn behind at some point in the future, or at least be somewhat prepared when LinkedIn goes away, as all these platforms do.
Do you have some personal CRM-type routines or automation?
Handshakes and conversations is what I’m interested in, not marketing instruments. Image Handshake by Elisha Project, license CC BY SA
I wanted to move some photos from my camera’s USB card to my new Macbook (M1, Big Sur). I connected a USB card reader to one of the Mac’s ports using an adapter. Finder did not see the card. Odd, because when I then removed the card, it gave the usual warning about not pulling out disks before unmounting them first. Using Diks Utility I found out that the Mac does indeed see the card reader and card, it just doesn’t show them in Finder. The likely reason is that card has no name. On my previous laptop the machine would simply list the card as ‘NONAME’, but apparantly not on this machine.
Right clicking on the card in Disk Utility and selecting ‘rename’ allows you to set a name. After that, throw out the card from the machine, remove it from the card reader and then put it back in. Et voila, the card is listed in Finder with its new name.
Apple Watch owners have the ability to export their tracked data and do whatever they like with it. Since it’s Valentine’s Day, I thought it might be fun to show two ways to read heart rate data from these exports.
Why two ways? Well, I’ve owned an Apple Watch off-and-on ever since the first generation device, and when Apple says you can export all your data, they mean all. The apple_health_export.zip archive is generated by going to the “Health” iOS app, tapping your avatar in the upper left, then scrolling down and tapping the export button:
(NOTE: I suggest saving it to and then downloading it from iCloud vs using local AirDrop to your system.)
This compressed file is a deceivingly ~58 MB in size. Opening it up results in a directory tree of nearly 3 GB of consumed drive space O_o. That tree has the following structure:
Note that newer records of this type are not empty tags.
While dealing with gigabyte+ XML files are not nearly as untenable as they used to be in R, building a parsed XML tree in memory for all of those records will take up a non-insignificant amount of RAM (we’ll see how much below). Since I want to start playing with this data more often I decided to try two approaches: one that processes the XML in streaming “chunks” and one that does it the way you’re likely used to (if you’re unfortunate enough to have to work with XML regularly).
Streaming Beats
We’ll start with the streaming approach, which means using the venerable {XML} package, which has xmlEventParse() which is an event-driven or SAX (Simple API for XML) style parser which process XML without building the tree but rather identifies tokens in the stream of characters and passes them to handlers which can make sense of them in context. Since we’re going old-school, we’ll also use {data.table} to get a tidy dataset to work with.
We’re going to be finding heart rate records and storing the data from them into a list, so we’ll need to make room for them and use indexed-based value assignments to avoid making thousands of copies with append(). To figure out how much room we’ll need I’m going to “cheat” a bit and use ripgrep to count how many HKQuantityTypeIdentifierHeartRate records exist and use that result to reserve list space:
There are just under 790K records buried in that file. The xmlEventParse() function has a handlers parameter which takes a list named functions for various events. The event we care about is the one where we start processing an XML element, which is unsurprisingly called startElement. In it, we’ll only process HKQuantityTypeIdentifierHeartRate records and further only care about data since 2019:
invisible(xmlEventParse(
file = "~/Data/apple_health_export/export.xml",
handlers = list(
# process at element start
startElement = function(name, attrs) {
# only care about the heart rate recs
if ((name == "Record") && (attrs["type"] == "HKQuantityTypeIdentifierHeartRate")) {
# only care about records >= the year 2019
if (substr(attrs["endDate"], 1, 4) >= 2019) {
# if we find them, add them to the list (note the <<-)
records[idx] <<- list(as.list(unname(attrs[c("endDate", "value")]))) # not using names reduces memory
idx <<- idx + 1
}
}
}
)
))
At this point we have a list of all those records and have taken the R session memory from 131 MiB to 629 MiB (so, we’re eating about ~500 MiB of RAM with that call), and it took around 34 painful seconds to process the XML file.
Now, we’ll use {data.table} to tidy it up:
records <- records[lengths(records) != 0] # get rid of any list elements we didn't use
records <- rbindlist(records, use.names = FALSE) # make a data frame
setattr(records, 'names', c("ts", "rate"))
records[, c("ts", "rate") := list(
as.POSIXct(ts, format = "%Y-%m-%d %H:%M:%S %z"),
as.integer(rate)
)]
## ts rate
## 1: 2019-02-12 15:19:54 69
## 2: 2019-02-12 15:26:11 90
## 3: 2019-02-12 15:31:33 92
## 4: 2019-02-12 15:34:24 89
## 5: 2019-02-12 15:57:33 120
## ---
## 734526: 2021-02-13 10:17:08 118
## 734527: 2021-02-13 10:26:50 124
## 734528: 2021-02-13 10:22:56 110
## 734529: 2021-02-13 10:34:56 98
## 734530: 2021-02-13 10:39:34 99
That took around 4.5 seconds, and when the R garbage collector kicks in we’re now consuming ~695 MiB, so not much more than the previous step.
So, ~38s for the ingestion & conversion, and a maximum of ~695 MiB in play at any time during the R session. Let’s see how the new/modern way (i.e. {xml2}) compares.
Modern
Unless I missed something in the {xml2} index page, there is no equivalent streaming processor, so we have to read the entire document into active RAM:
library(xml2)
library(tidyverse)
records <- xml2::read_xml("~/Data/apple_health_export/export.xml")
This operation takes 15.7s and the R session now consumes ~5.8 GiB of RAM. That is a “G”, as in gigabyte.
Now, we’ll find all the records that we care about (as above). We’ll do this via a modest XPath selector:
xml_find_all(
records,
xpath = "
.//Record[
@type = 'HKQuantityTypeIdentifierHeartRate' and
(starts-with(@endDate, '2019') or
starts-with(@endDate, '2020') or
starts-with(@endDate, '2021'))
]"
) -> records
That operation took around ~6.5s and we’re still consuming around 6.23 GiB of RAM.
That took around 10.4s and, after garbage collection happens, we’re back to a much more reasonable ~890 MiB of consumed RAM after a workflow maximum of over 6 GiB, taking a total of ~32.6 seconds.
FIN
If/when memory is tight, it’s nice to have some alternatives besides “get a bigger box”, and this is one approach (there are others) for performing this type of XML surgery in R.
What about a system that automatically changes wording in communications to eliminate your co-workers’ unhelpful quirks? This is just one of the interesting ideas in my Wall Street Journal article about how A.I. can help with workplace communications. An excerpt from this article reads as follows:
The colleague who always sounds angry because she writes in all caps, with no greetings or friendly asides? The colleague translator warms her up by converting her messages to sentence case and adding in a few words like “Hope you’re having a great day.” Got a junior assistant who floods you with so much background information and flattery that you can’t figure out what he’s trying to say? The colleague translator parses his emails and gives you the bullet-point, actionable version.
This is something to keep half an eye on. "Kalaksi is a new way of social network. It adds social features on top of standard RSS feeds. Create 'planets' to act as different timelines, aggregate content from several sources, and publish it all to the web via RSS." I created an account (aka a 'planet) which you can view on the site here.
You might notice the primary navigation tab is driving people to StackOverflow for discussions.
Embracing the existing communities (or native platforms members use) is both an incredibly smart and often an incredibly difficult decision to make.
It means you’re ceding control to a platform over which you can’t moderate and manage activity. Sure, you can participate and reply, but you can’t collect any data, easily escalate issues and plenty more.
Which is why so few organisations take a similar approach. They want control.
It might be psychologically hard to give up this control and simply link to a tag on StackOverflow, Reddit, or even a Twitter hashtag. But it’s far harder to persuade people to participate in your platform, when they’re so comfortable and familiar with participating in another.
You have to forge new habits, offer something members can’t get anywhere else, and force members to jump through additional hoops each time they want to connect.
But it’s worth considering the benefits of this approach.
StackOverflow probably has the best platform experience today. It’s a platform most technical audiences are very familiar with. Snowflake saves itself the trouble of hosting (and managing) the majority of discussions by directing people to another platform already filled with vibrant discussions.
Instead of competing with the existing ecosystem, Snowflake embraces it and adds value with distinct groups (which members can put themselves forward to run), user groups/events, documentation, ideas, and features StackOverflow can’t provide.
If there is already a place where members have discussions about the topic, it’s typically a good idea to embrace it rather than compete against it.
Sitting at the breakfast table writing what will become a blog post on drop in audio.
Yes, it’s a new reMarkable “paper” tablet. I’m using it in the hopes of better deep reading and writing.
Except for a quick microblog to post a picture of it!
Looking forward to reading about your experiences. I bought a Boox Nova 2 last summer for the same reasons, to better read and write. While I am very pleased with the e-ink device and enjoy the reading (including magazines) and writing I do on it, I haven’t had much benefit from it yet in terms of a significantly higher volume / deeper form of reading, as my habits around it are still lacking.
The Voyager 5200 UC is a one-of-a-kind headset. It mounts on your ear and you quickly forget you are wearing it. It picks up your voice, and only your voice, under any circumstances. Screaming kids, city traffic, a roaring truck, in a roadster with the top down, on a bicycle, it always delivers, for six hours straight. Then you put it into its charging case and it juices up twice before you need to get to a power outlet.
My Voyager has been doing this for years, without failure.
But recently, a few friends have bought one and they quickly ran into trouble. Indoors, without any noise, it works a treat. But taken outside its performance quickly falls off to the point where you can no longer be understood on a phone call. Turning it off and on sometimes cures the problem, but often it does not. The issue seems to be triggered by going out of mute when surrounded by noise. We don't know. My Voyager works, theirs don't. Same firmware, same iPhone.
Poly, please fix this. The Voyager 5200 is one-of-a-kind. We need it.
Roland Tanglao 猪肉面@rtanglao
Yesterday I cleared off the snow & enjoyed another fab coffee & doughnut outside Lucky's. Amazingly enough I wasn't… twitter.com/i/web/status/1…
Cineplex theatres could become a part of the COVID-19 vaccine rollout in Canada. In an interview with the Toronto Star, Cineplex CEO Ellis Jacob said the theatre chain had reached out to multiple provincial health agencies to offer up Cineplex locations for vaccine distribution.
In Ontario, talks involved Premier Doug Ford, Jacob told the Star. Further, Jacob noted that health agencies were “receptive” to the idea but hadn’t made any decisions yet.
The offer follows Cineplex’s significant fourth-quarter loss of $230.4 million. The company reported quarterly results Thursday — the quarter ended on December 31st. Cineplex had to close most of its locations throughout the last year due to the pandemic. Some sites have opened in a few regions (as of Friday, only about 15 percent of Cineplex’s 161 theatres were open, a company representative told the Star).
However, officials are still figuring out vaccination sites and balancing vaccine availability, provincial approvals and selecting locations that make sense logistically. Cineplex isn’t the only company seeking to open vaccination distribution locations — Shoppers Drug Mart and other pharmacies sought approval to become vaccination centres as well.
The Star notes that limited vaccine supply has hampered rollout plans so far. But once distribution picks up, Jacob says Cineplex theatres in small markets could help. According to Jacob, theatres accommodate people “all the time” and are familiar locations to residents.
It’s worth noting that aiding the vaccine distribution process is likely in Cineplex’s best interest. The Star explained that Canada is falling behind in vaccine rollout compared to the U.S. If that continues, theatres may be able to open in some major U.S. markets, which would, in turn, encourage Hollywood to release some significantly anticipated movies, such as Marvel’s Black Widow.
If that happens before Canadian cinemas can re-open, it could put them at a disadvantage. Jacob told investors on a recent financial call that “as long as the gap between the U.S. and Canada is not too significant,” Cineplex would be in a “great position” once it re-opened.
One of my enduring personal aspirations is to immerse my life in a universe of self-built, self-hosted tools, at least as far as software tools are concerned. In the lore of self-hosted software tools, perhaps no story figures more heroically than the history of UNIX, the operating system architecture on which most of the Internet and most of the smartphone revolution was built.
The human side of UNIX’s origin story is legendary on its own. Ken Thompson, the original instigator of the project, basically crafted a subtle lie to the Bell Labs management to get a machine on which he could write the operating system, and wrote the first version of UNIX in three weeks, apparently while his wife was away on vacation. It was originally written for the PDP-7, in a moderate amount of assembly, and iterated upon a few times in the following years to get to the ur-UNIX as we know it – the version written in C published in a paper I included in my list of notable papers about computing last year.
I spent this morning reading that original UNIX paper from Ritchie and Thompson titled The UNIX Time-Sharing System. The whole paper is well-written and articulate with details about the state of the art of computing of the era showing through beautifully, but I was struck by the conclusion of the paper, where the authors cite why they think UNIX was so well-received. Of course, at the time of publication, neither of them anticipated the forthcoming explosion of computing that would be fueled by UNIX-based systems, but their account of their success holds up nonetheless:
Perhaps paradoxically, the success of UNIX is largely due to the fact that it was not designed to meet any pre-defined objectives. […] Our goals throughout the effort, when articulated at all, have always concerned themselves with building a comfortable relationship with the machine and with exploring ideas and inventions in operating systems. We have not been faced with the need to satisfy someone else’s requirements, and for this freedom we are grateful.
Unlike most systems of the vintage that were commissioned by large companies for commercial uses, UNIX was created out of programmers' desires for a better tool and workspace for programmers like them. And “paradoxically,” as the authors note, this approach resulted in a system that succeeded nearly universally.
To conclude the paper, the authors lay out three specific reasons that contributed to the success of UNIX. Reading over them, I thought they held a lot of value as timeless principles for building great tools of all kinds, so I wanted to enumerate and comment on them here in relation to some of my own principles.
In the order of their presentation, the three are:
1. Design for makers
UNIX was an operating system designed for programming.
First, since we are programmers, we naturally designed the system to make it easy to write, test, and run programs. The most important expression of our desire for programming convenience was that the system was arranged for interactive use, even though the original version only supported one user.
An operating system is a kind of tool that is the workspace for all your other work. It defines the outer limits of what you can do within it. A batch system for computer use, where a programmer would submit jobs to be run and get answers later, was the norm at the conception of UNIX, but the developers went against this trend for a (now ubiquitous) interactive design.
This insight is tied closely to the fact that the inventors of UNIX weren’t developing a product to meet requirements, as a tool to accomplish a single task. They were building a tool they actually wanted to use, and tried to build “a comfortable relationship with the machine” as they noted in the paper.
It turns out that changing the relationship between the maker and the tool, a purely qualitative change, has a dramatic impact on the kind of work you can do with it, and how productive you’ll be using it.
2. Embrace constraints
Unlike the commercial efforts of the day backed by deep corporate pockets, the UNIX inventors couldn’t spring for expensive top-tier machines.
Second there have always been fairly severe size constraints on the system and its software. Given the partiality antagonistic desires for reasonable efficiency and expressive power, the size constraint has encouraged not only economy but a certain elegance of design.
Here, I think the authors articulate a non-obvious benefit of design constraints. They contend not only that it led to more efficient design, as you’d assume, but also that it led to better, more elegant design of the system. Elegant design makes it easier to change or add components over time as the tool needs to be adapted for broader use cases. Constraints are helpful in the pursuit of more elegant design because they make you think twice about your design decisions, because every tradeoff is more consequential. As an obvious bonus, a tool that works well because it was created under constraints will work even better without those same constraints.
3. Self-host and self-modify
Perhaps most important to me of all three, UNIX quickly became a tool for developing later versions of UNIX.
Third, nearly from the start, the system was able to, and did, maintain itself. […] Since all source programs were always available and easily modified on-line, we were willing to revise and rewrite the system and its software when new ideas were invented, discovered, or suggested by others.
Self-hosting – using a tool to build another instance of itself – is interesting from a technical perspective. But the more important benefit that Thompson and Ritchie point out here is that self-hosting made self-modification easier. You could be using the system, find something that didn’t quite work right, and because the source code was right on the system, you could simply add or modify it as you needed. It’s not just that this was possible, but that this was right there, so available, that people were “willing to revise the system” as convenient.
This is so clearly the best way to build a tool that can grow around the way you use it, over time, around your specific workflows. The UNIX environment, a tool remarkably well-suited to the software development task, didn’t emerge from nothingness in its final form. Its initial version was bare, but moldable. And the first users added utilities and modified its behavior to work the way they needed, because modification was easily available.
I think these principles apply universally not just to software projects, but to the process of building all kinds of tools, from online community platforms to note-taking methodologies to hand tools.
This is the way to build tools. Under the right conservative constraints that inspire elegant design; designed for creative power, not for a task; and under constant, active use that leads to the tool taking shape around the silhouette of the workflows it needs to serve.
I’ve been eyeing this neat little gadget and wondering if I should get one.
Not sure if it’s Gear Acquisition Syndrome or just a desperate need to stop sitting at a traditional computer for 12 hours a day and have something that I can enjoy and fiddle with as a standalone, tactile device.
This looks incredibly useful. Run "python -m trustme" and it will create three files for you: server.pem, server.key and a client.pem client certificate, providing a certificate for "localhost" (or another host you spefict) using a fake certificate authority. Looks like it should be the easiest way to test TLS locally.
Litestream is a really exciting new piece of technology by Ben Johnson, who previously built BoltDB, the key-value store written in Go that is used by etcd. It adds replication to SQLite by running a process that converts the SQLite WAL log into a stream that can be saved to another folder or pushed to S3. The S3 option is particularly exciting - Ben estimates that keeping a full point-in-time recovery log of a high write SQLite database should cost in the order of a few dollars a month. I think this could greatly expand the set of use-cases for which SQLite is sensible choice.
I'm going to take Daniel Goldsmith's excellent post Praxis and the Indieweb as a point of departure for this post. Like Goldsmith, I am a fan of the Indieweb, or at least, the concept of the Indieweb. And I've been involved, at least around the periphery, in its development for many years.
In what follows I will not only talk about the Indieweb, I'll also talk about some of my own projects. I want to be clear at the outset that when I talk about my own projects, the intent is to offer an example of some alternative points of view. I have no doubt that there are numerous other such examples.
What is the Indieweb?
Before jumping in, though, I want to take a moment to ask, what is the Indieweb? Part of it is about ownership: as the Indieweb web site says, "When you post something on the web, it should belong to you, not a corporation." And part of it is about control: "You can post anything you want, in any format you want, with no one monitoring you."
In practice, though, there's a lot of slippage around those ideals. Nobody owns their entire website; the servers it runs on, the domain name, the software it uses, the protocols it follows, even the content it publishes - all of these may be owned by someone else, and through some combination of payment and licensing we make use of these things, adding just enough of ourselves to make it 'our own'.
And nobody does anything online without being monitored (indeed, there wouldn't be any point; it is after all a communications medium). There is at once the all-seeing eye of Google, law enforcement and security agencies, our service providers watching traffic, various copyright and monitoring services, and finally, our own readers, of which we hope to have at least a few.
Given this, there is I think a spirit of what counts as the Indieweb, which may be characterized as do-it-yourself. And this do-it-yourself spirit, I think, is very much in a tension with other values and ideals. Because while we can do it ourselves, I don't think most people really want to, and certainly almost nobody has the time. That's why we end up in places like Twitter and Facebook.
And it is the Indieweb's characterization of these websites as silos that points to a fourth major aspect of the Indieweb: inter-connectivity. At least a part of the Indieweb proposes that anybody should be able to communicate with anybody, without being subject to subscription barriers, algorithms, advertising and content placement, technical limitations, and terms of service.
Who is it For?
This leads us to the first of Goldsmith's criticisms: "the movement as it is currently structured can never move into widespread acceptance, that it is both target blind and exclusionary."
One would think that the Indieweb is targeted toward people who want to own their own website and content, to control that site, to build it according to their own needs and ideas, and to be able to participate in an open network of similar sites. Something like that.
But the Indieweb is target blind, says Goldsmith, in the sense that it seems to be aimed toward people who don't really want to leave existing social networks, and want specifically to emulate the function of the social networks without being limited by, say, their moderation policies.
There are two ways this is the case. One is the design of the Indieweb itself, which is centered around types of posts, all of which are basically copies of the types of posts on traditional social network sites. The other is in the concept of POSSE - Publish Own Site, Syndicate Elsewhere.The idea is that you create content on your site and then broadcast it into traditional social media sites - whereupon, writes Goldsmith, your rights of ownership end.
Ironically, I think that both of these elements were designed in an effort to make the Indieweb more popular and accessible to a wider audience, since it emulates form factors users already understand, and it doesn't require a complete break from traditional social networking sites. But there are differences between these being features of the Indieweb, and these being part of the core design.
The Indieweb has been designed for a specific type of user, one who wants to build and run their own social networking website in such a way that it is interoperable with existing social networking sites (and maybe, with other Indieweb social networking sites). That's why it focuses on posts, and that's why it is based on POSSE.
Posts
Don't get me wrong. I love posts. I've written 33,692 of them, most short, some long like this one. I've worked with various types of posts over the years and settled into a few basic types: links, articles, comments, announcements.
But my work has differed from Indieweb on two fronts. First, in my own software, there's no limit or standard definition of a post you must follow. One of my types, 'link', is illustrative of that. Back at the beginning of blogging, a post used to be about something, usually an article of some sort written by someone else. So the post would include data about this article: who wrote it, what it's URL was, what website it was on, maybe a short description. This is the post as bookmark example, and I've never strayed from that, and have always called this a 'link post'.
The link post is not even in Indieweb's canonical list of post types. Instead, at the beginning of blogging, another model was adopted by the (then) startup blog companies, and these were more in the model of personal diary entries. So there would be no URL other than the post's own URL, and no website other than the one it was on. This model became the Blogger model and the WordPress model and was carried over into things like Twitter and Facebook and the rest.
This model also carried over into things like interoperability standards. Although RSS was originally designed for bookmarks, building on Netscape's bookmarks feature, it was eventually transformed into a model for self-syndication, and only ever used to describe one's own work. That's why the 'pieces of a post' section on the Indieweb web site never goes beyond basic self-centered features like URL, contents, date, etc.
All of this is OK. There's no requirement that people create link posts just because I've created more than 30,000 of them. There's no requirement that websites be outward-looking, like mine, rather than inward-looking, like most others. But these should be options, rather than The Way It Is Done.
That's why, in my own software, gRSShopper, I've designed posts so that people can create whatever post type they want, and add whatever properties they want, and have this structure propagate into the post metadata (like RSS and JSON). And that decision will have a significant impact, as we'll see later on.
Screen shot from gRSShopper
On the second front, I have never felt limited to posts. In fact, I have always been frustrated by the standard ontology of the technorati. On gRSShopper I have a large and open-ended ontology that includes publications, presentations, events, media, courses, projects, whatever (see the illustration). You can make any data type, populate it with any fields you want, and link different types of entities with each other however you want in a graph (to be clear, though: it's not a graph database; it's list an open-ended set of linked data types).
What Is the Web?
Now I've heard the objection many times: if you let people defined data types however they want, then their sites will be incompatible with each other. If you want everybody to be able to communicate with everybody, they have to use the same fields in the same way.
My response is: that's false, because I've been doing it differently for decades, and people can still communicate with me (and I with them). It becomes an issue only if you're thinking of the Indieweb (and the web in general) as a broadcast medium, where you want your thoughts and ideas and posts to propagate as far as possible and to as many different platforms as possible. Then you need global standardization.
But I've never thought of that as the design prin ciple for the web, and I've never thought of that as a core principle of the Indieweb, or of the web generally.
Broadcasting came late to the web, and didn't really appear until the web was commercialized in the late 90s. Before then, it was genuinely a communications medium, characterized by person-to-person or smallish group communications. The idea of blasting a message to everyone on the web, or even everyone on a single network, was thought of as selfish and excessive, and to be reserved only for the unusual and important.
The commercial web brought with it context collapse, in which everybody is talking to everybody. This is what creates the need for filters and algorithms and moderation and all the things we said above that the Indieweb is trying to avoid. But when everybody talks to everybody, these are unavoidable. They have to be managed somehow, and sometimes it feels like most Indieweb projects are exercises in different ways of doing this.
My own view of the Indieweb (and again, not everyone has to share this view; it's OK) is that it's a space for conversation rather than syndication. Of sure, we still use syndication technologies, but we're not locked into the broadcast model, we can design our own syndication formats, use our own classes and entities, and be able to focus in ways that a broadcast medium cannot.
A system based on webs, in other words, and not on stars.
Web (left) vs Stars (right)
I've written about this before. But at that moment in history - 2006ish - the prevailing sentiment seemed to be that a power law distribution of influence was normal, that there would be outsized voices in the blogosphere, and that the specifications should be designed to make this possible. Fifteen years later and the same model - the same people, even - continue to prevail. And that's what gives us this social network model of the Indieweb.
Who is the Indieweb
To this point we have been addressing the criticism that the Indieweb is target blind. We now turn to the criticism that it is exclusionary, or as Goldsmith describes it, "one of the most glaring problems of the indieweb movement: the 'Single Point of Aaron'."
The Aaron in this case is Aaron Parecki. Most Indieweb technologies, Goldsmith writes, are Parecki technologies. "Webmentions.io, for instance, that’s an Aaron Parecki site. Aperture, the microsub reader... that’s also Aaron’s. The Microsub specification is written by Aaron, much as the Webmention spec was.... (and) is one of the authors of the Oauth." Some of the core figures also include Tantek Çelik , formerly of Technorati, who created microformats, and Ryan Barrett, who worked for Google.
Goldsmith characterizes the Indieweb crowd as "with a few notable exceptions, the indieweb is almost entirely white, male and north american." That may be, but I think it's too broad a characterization to be useful. My observation is that in one way or another they all come from what I have called 'the Nexus' - that is, the Berkeley - Stanford - Harvard - MIT Nexus. The same place Google comes from, that Facebook comes from, and that a certain view of the world comes from.
As I mentioned above, it's a view of the world that sees broadcasting, power laws and stars as normal and inevitable. Even more, it's a view that entrenches the idea of winners and losers, views the commodification and often the commercialization of community and media as inevitable, that views all of this as being inherently individual-based, libertarian, and 'free' in a very special and privileged sense of free.
It's also a perspective rooted in what has been called the meritocracy, the view that people get the wealth and recognition they merit, a view that those who make the tools make the rules, and that the people who are 'elite' are such because they deserve to be. And those people are, overwhelmingly, themselves. It has nothing to do with being male, North American or white, though for various reasons that's where privilege has accumulated in the past.
And though there is in fact a world-wide community of people working on this stuff, they view themselves as the (natural-born) leaders and inventors. They are nothing of the kind, of course.
First Generation
In recognition of something like this, Goldsmith takes aim and the Indieweb's characterization of 'first generation' Indiewebbers. Here it is:
Capable of building a CMS, custom blogging software, understands SSL, git, SSH, APIs, domain registrars, DNS, nameservers, communicating over IRC, and editing wikis, and is comfortable running a server to host their own content, and knows at least one basic web-based programming language. Comfortable with lengthy documentation.
Goldsmith notes, "I can do much, but not all, of the above, and I can do a fair number of things not on that list. I can still barely function in the Indieweb as it is presently formulated." I can do all of the things on the list and can also barely function on the Indieweb. And Goldsmith is quite right when he writes,
There is a complete dearth of simple, essential programs/tutorials/guides to accomplishing the basic tasks of the Indieweb. The movement is built around what was once called “dogfooding”, but is now Eat What You Cook, creating the tools to make it work yourself, and using it. In this, it shares some features with FLOSS generally, the cult of the individual programmer.
The very existence of a term such as 'dogfooding' in core Indieweb documentation should serve as a red flag for anyone looking for an open and welcoming environment.
There are scarcely any examples of moving past self-sufficiency, providing scraps from the table for people to use. There should, at a minimum, be clear and established routes to achieving the goals of the indieweb ideal, presented in as clear and unambiguous format as possible, in a wide range of programming languages. Currently, that simply does not exist.
Quite right.
As it stands, the Generations diagram is wholly exclusionary. While it allows for people of less facility in computers to play a role in the movement, eventually, it affords little or no understanding of who those people will be. In short, it doesn’t describe people in the “real world” (what on earth is Softalicious?) nor does it encompass people of lesser means.
These are not the values of a movement that looks outward. It is what we would expect from a movement that centers its own members as the stars, with no real need to consider the needs and interests of a wider community (a community that, for all intents and purposes, barely exists when viewed from the centre).
Rather than being focused on the technical prowess of a 'founding' generation, it should be focused on (shall we say) a road map of widely available applications and services that everyone can use without requiring a degree in computer science or eschatology.
What does that look like? Well, I tried to provide an example last week with Remote Comments. It would be a way of enabling people to very easily add a comment to a document without worrying about all the trappings of WebMentions and the rest; these would work behind the surface and be a part of whatever blogging or writing application they're using.
Exclusionary
The Indieweb is based on owning your own domain name and owning and managing your own web server. As Goldsmith notes, none of these is free, and in fact, they create a significant barrier to participation. "If a movement has at its core a significant barrier to entry, then it is always exclusionary. While we’ve already seen that the movement has barriers at ability and personality, it is also true that, as of 2021, there is a significant barrier in terms of monetary resources."
One of the things I really appreciate about Reclaim is that it costs significantly less than similar services running on, say, Amazon Web Services. Yet at the same time, I recognize that even this cost is a barrier to many people around the world, and that "If your liberation movement has an entry fee, then its just another country club." And there does appear to be an expectation in Indieweb that to be a player you're going to have to pay the significant up-front costs.
And that's the other thing I appreciate about Reclaim: they've made efforts to find ways to have other people pay for those costs. The Domain of One's Own program, for example, typically rolls out in such a way that the educational institution provides the hosting and peripheral costs, allowing individuals to freely develop their own online environments. That's how the first websites (back in the Golden Days of Personal Websites of the 80s and 90s) were made possible. No individual was setting up a web server; it was all enabled through institutions.
In more recent years, institutions have retreated from this role and handed it over to the commercial sector. Many of these commercial sector providers are spin-offs from the original institutional hosting program (or, as in the case of Facebook and Google, things done with institutional hosting). It's hard to see how anything like a genuine Indieweb can develop while the infrastructure remains almost entirely in commercial hands.
Of course, access to the internet itself, much less a space for one's own domain, is not evenly distributed. It's a free perk for those fortunate enough to be able to pay tuition fees, but for the large majority of the population, the only domain they can afford is a free (and easy-to-use) Facebook or Twitter address. With asymmetric bandwidth making it much harder to upload than download, people cannot easily host their own servers (and it's not exactly like internet providers, who also market broadcast content, want to make that any easier).
That said, if we really wanted a broadly inclusive Indieweb, we'd be talking not about how to set up large complicated servers, or offering additional platforms to sign up for and pay for, but rather we'd be talking about how to make self-hosting more accessible and available to individuals.
To me, right now, the only game in town seems to be self-hosted containers running pre-configured platforms accessing cheap (or free!) cloud storage space. I think this should be considered an essential social service. I think this is where people should be able to store their data - not just their 'posts' but all their data - their health and education records (maybe like Opal), their voting and policy preferences, their virtual environments and in-game characters, etc.
A Roadmap?
What would a roadmap look like?
I think we have to return to what we think the Indieweb is. The original goals were ownership, control, do-it-yourself, and inter-connectivity. These have morphed into some sort of amalgam of code camps and self-authored software. But I think that if we revisit these in the spirit of social and community benefit, we can envision something more encompassing.
An Indieweb is a...
- way for people to store and manage their own data (where 'data' means any digital creation or record, including metadata)
- a way for people to share data with each other without being required to give up their rights or ownership over that data,
- a way for data management and sharing to be independent of the particular platform they are using,
- a way for people to create common resources and services around that data, or in other words, to create interdependent communities,
- and an environment that is broadly egalitarian, based on the principles of a web rather than on mass and centralization, based on interaction rather than broadcasting.
I think that in addition to these basic descriptions of an Indieweb, there ought to be some desiderata describing what sort of technology meets this description.
For example (and I don't mean this list to be exhaustive):
- data specifications should be open, not only in the sense that anyone can use them, but also in the sense that people can add to them, adapt them, or choose which parts to use. Specifications, in other words, should be protocols, not standards.
- tools should be in the first instance simple and easy to use. Something should notbe counted as being 'a part of the Indieweb' if it requires special skills to operate. They should be cross-platform and (as Goldsmith says) supported in multiple programming languages.
- the tools should also be lightweight. Obviously this is a moving target, but they should ideally be able to run on a computer available to everybody - it should be possible to make them work (say) with a Raspberry Pi and a TV.
- the parts that depend on cloud services should be accessible to everyone, not just a subclass of people (like university students or company employees), and these parts should be (ideally) free or incredibly inexpensive, and generally regarded as essential infrastructure
- you shouldn't have to pay for it. You should be able to run the whole thing off your own computer if you want, without having to pay hosting costs to some online service, and you should be able to do so with a minimum of installation and configuration
I know that my own work is a long way from this. But it at least points me in a direction where there might be something worthwhile at the other end.
I think we have to return to what we think the Indieweb is. The original goals were ownership, control, do-it-yourself, and inter-connectivity. These have morphed into some sort of amalgam of code camps and self-authored software. But I think that if we revisit these in the spirit of social and community benefit, we can envision something more encompassing.
This is an excellent post analyzing the weaknesses of the Indieweb as it is currently constituted. You may have already seen my response. Daniel Goldsmith makes the point that the Indieweb is target-blind, exclusionary, and "has at its core a significant barrier to entry." I can't disagree. It instantiates a certain point of view of the world (the same one that informs existing social networks), it is complicated and difficult to follow, and it doesn't take into account the broader ideal of what an Indieweb should be.
While both a modem and a router help your devices connect to the internet, they have separate (and complementary) functions. A modem is a box that connects your home network to your internet service provider, or ISP. A router is a box that lets all of your wired and wireless devices use that internet connection at once and allows them to talk to one another directly. Often, your internet service provider will give you a device typically referred to as a gateway, a single box that serves as both modem and router, but these are still different technologies. You need the features of both a modem and a router, integrated or not, in order to have an internet connection for all of the devices in your home.
One of the biggest issues that I’ve had while biking during the pandemic is whether or not to wear a mask. In particular during cold weather, fogging of glasses has been a huge issue for me. The best solution that I’ve found so far is to use a disposable mask with a strip of first aid tape across the nose.
Here is me after a 35 minute commute in about -8°C weather. No fogging.
However, this solution is less than ideal since repeated use of the first aid tape caused skin irritation. There were some positive reviews of a high end mask from Oakley, the MSK3, so I decided to check it out. Note: $74 in Canada.
Here is a user video review showing unboxing, etc, so I won’t bother going through all the details.
His conclusion is that it does a pretty good job of preventing fogging.
However, my experience was quite different, and I imagine it is because I have a relative low nose. Here is me after a ride under more or less the same conditions.
Lots of fogging, just in case you couldn’t tell.
However, as the video above makes clear, it does work for some people.
I have a couple of small notes about the mask. It comes with two filters, one disposable, and the other reusable. They almost look the same; you have to look at the labels on the bag, and also the reusable one has two strips of velcro on the sides.
The other thing is that the replacement filters are also not cheap but I did notice that they were very similar in shape to KN95 masks that are readily available for about $1 each. I’ll be trimming one down to see if it fits.
I will note that the KN 95 mask is quite a bit thicker than the filters supplied by Oakley, and the Oakley mask package has lots of lawyereaze to assert that they make no guarantees about the protective properties of the mask.
“Best site”? Let me guess, 25km outside of town, at the bottom of an open pit mine, so the business guys don’t have to lay an eye on it. “In a statement to CBC Toronto, BIA executive director Kelly McKenna said her organizati“n is helping search for the best location for a supervised consumption site in Barrie and isn't delaying or opposing such a site. “
A Barrie, Ont., mother whose son died from consuming tainted drugs says she was disgusted to discover the city's business leaders are paying $28,000 to a lobbying firm to have a proposed supervised consumption site moved away from the downtown area.
That anger deepened after watching video of the Downtown Barrie Business Improvement Area's chair — a former mayor of the city — calling drug users not "productive, contributing" citizens.
Christine Nayler said her son, Ryan, was actively seeking treatment when he died on Nov. 29, 2020, just days before his 35th birthday.
Ryan was open about the fact he was using crack cocaine to deal with his bipolar disorder, she said, and would have used a supervised consumption site to check the safety of his supply had there been one in Barrie. It could have saved his life, Nayler said.
Instead, a police officer knocked on her door at 4 a.m. to break the news she'd been fearing for years — Ryan had died at his home after using drugs that were likely laced with fentanyl, a powerful opioid. (The family is still waiting for a coroner's report to confirm exactly what happened.)
"It's the most devastating feeling," she said.
"It's so hard to talk about this and relive it over and over again, but I'm doing it in hopes that we can get supports and so that no other mother, no other family, has to have someone knock on their door."
The Simcoe-Muskoka District Health Unit's (SMDHU) most recent data suggests there is a need for a supervised consumption site in the city, located about 100 kilometres north of Toronto. There were 47 suspected overdose deaths in the first nine months of 2020 alone, while the city's central north area, which includes downtown, has seen overdose rates eight times higher than the rest of Ontario.
Nayler says she's on a mission to see a site open in Barrie.
But while she has her church outreach community, the BIA has thousands of dollars to spend on a contract for what it calls "communications support" with Sussex Strategy Group, one of the country's largest lobbying firms.
Individual business owners or business groups opposing social services in their community is nothing new in Canada, but the decision to spend money on an outside company raises questions about who is swaying the debate around a serious public health issue. Nayler says she believes the entire process should be led by health officials, and questions why the BIA has a say in the site selection at all.
"This is not their mandate," she said.
Message in the meeting footage
In a statement to CBC Toronto, BIA executive director Kelly McKenna said her organization is helping search for the best location for a supervised consumption site in Barrie and isn't delaying or opposing such a site.
The BIA "understands the impact the opioid crisis is having on our city," McKenna said.
"We have seen the data and we know our members witness related issues firsthand daily. The opioid issue affects those with addictions as well as our community's first responders, business owners, and residents."
However, video from a September 2020 BIA meeting suggests the organization, chaired by former Barrie mayor Rob Hamilton, may be more focused on business issues and the city's image than health outcomes. There was no discussion, for example, of the potential harm of moving a supervised consumption site further from the core.
At one point, Hamilton cuts off a colleague to say drug users are not "productive, contributing" citizens before urging his colleagues to be forceful in their efforts to move them to a place where "they're not in your face."
WATCH | BIA chair's comments on people who use drugs in Barrie:
Rob Hamilton, Barrie's former mayor, shared these opinions during a September, 2020, meeting of the business improvement association. 1:57
McKenna refused to comment on Hamilton's remarks and said the chair asked that all communications go through her.
At that meeting, six of the seven BIA members present voted to oppose a supervised consumption site within one kilometre of the downtown area the group represents.
Barrie Mayor Jeff Lehman didn't comment directly on Hamilton's remarks but said city council represents everyone, "whether they have an addiction or not."
Lehman said the city should follow the guidance of public health officials — the same way it has during the COVID-19 pandemic.
"I believe that in the case of the SCS issue, we should listen less to lobbying firms but continue to make decisions based on science," he said.
Sarah Tilley, a harm reduction co-ordinator with the Gilbert Centre, a local organization that helps those affected by HIV and the area's LGBTQ community, says there's a real downside to views like Hamilton's.
"When people feel like they're not citizens or they're not treated as community, they're not going to care about their surroundings as much," she said.
Supporting those people instead, she said, would be the better path to ensuring a safe environment with profitable businesses.
Supervised consumption sites haven't eliminated all community concerns in cities where they've opened, such as Toronto and Vancouver, but public health data suggests they have saved lives. Toronto Public Health data, for example, shows its front-line staff have administered the opioid antidote naloxone more than 800 times since August of 2017.
But even with the sites, the opioid crisis rages on. Toronto paramedics responded to 34 fatal opioid overdose calls in December 2020, marking a grim new record for the city.
BIA seeks outside help
Last December, the BIA reached a deal with Sussex after the firm recommended in a proposal it undertake a "concerted effort" to push the SMDHU to a site of the BIA's choosing.
Sussex's proposal (initially for $69,500 worth of work) notes the BIA "has been careful in its public positioning not to oppose the idea of safe injection sites" and "by proposing alternative sites within/close to the BIA it can argue credibly that it is willing to "accept" sites within the business area, just not those that are currently proposed."
That messaging is still happening.
McKenna warned city councillors last week in an email that two downtown locations the SMDHU is considering would have a "negative impact" on the community and the city's reputation.
"The Downtown Barrie BIA cannot support the two currently proposed locations and believes there are alternative options that can meet the needs of those with addictions and still protect our city's safe, vibrant downtown core," McKenna wrote to councillors.
A newly launched part of the BIA's website allows members of the public to email "key decision-makers" with a form letter that uses nearly the exact same language.
Sussex said in an email it couldn't discuss specifics of its work with the BIA, but the website uses the same proprietary technology — VOX — that Sussex touts as one of its proprietary tools in its initial proposal to run the aforementioned email form and keep a record of supporters the BIA can contact again in the future.
The company wouldn't say if it's been involved in other debates over supervised consumption sites.
Health unit forging ahead
The SMDHU, which is leading the search for a site, said it's aware of the BIA's work with an outside company, and notes the BIA recently accepted a position on the site selection committee.
Early this year, that committee widened its search for a potential third site, but said it would only look until the end of February.
However, the SMDHU was clear on the need of having a site downtown, where data shows there's the highest concentration of drug use and overdoses.
"The literature identifies that an SCS is ideally located where open drug use is already occurring," the health unit said in an email.
It said any site would offer clients a clean and safe place to use drugs under the care of nursing staff and harm reduction workers, while wraparound services would also be available.
However, Barrie city council, which has close ties to the BIA (two councillors are members), has already deferred approval of a supervised consumption site once.
Christine Nayler remains frustrated with the BIA's involvement and is concerned it will lead to a worse result than if health officials had led the planning.
The BIA, she said, got involved "late in the game, and it's creating delays that are going to cost people their lives."
Once the SMDHU finds its next site, city council will have another debate.
Handshakes and conversations is what I’m interested in, not marketing instruments. Image Handshake by Elisha Project, license CC BY SA
Expand for EKG code
Boris Mann (blog.bmannconsulting.com)
amye @amye
Roland Tanglao 猪肉面 @rtanglao
EastArchive on Twitter.
East German Studies Archive at Reading University (EastArchive)
on Wednesday, February 10th, 2021 10:29am
mrjamesob on Twitter.
