🌱Ian's Digital Garden

Backlinks

• ❓

  how to distinguish dead end links in a zettel?

  • type: question

  ---

  zettelkasten

• ❓

  quality of video call audio vs. landlines?

  • type: question

  ---

  My experience using Google Meet, Zoom, and Discord video calls has been mediocre. Obviously they're going to be worse than in person, which features ~5ms latency, high quality, and an absolutely unreal amount of nines.

  But there's something more fair to compare them to, POTS (Plain Old Telephone Service).

  

  In the most old-school instantiation of POTS, your voice is turned into an electrical signal and then rocks down the cord at 200,000,000m/s, straight to the other party's phone. That's pretty cool. I've read anecdotal reports that they created a much better audio experience than video calls. When I search my memory that seems right. But I'd like some data.

  Dimensions to this Question

  • Aspects of call quality
    • Latency
    • Jitter
    • Sound fidelity
    • Duplex status (see this thread)
    • Misc
      • Such as anti "call-yell" tricks like sidetone
  • Situations
    • Long distance vs. local calls
    • Change over time
      • At some point POTS providers stopped using direct connections and added digital links internally for long distance calls. How did this affect things? Did local calls over a landline continue to use direct connections?
    • Multiple different video call services: Google Meet, Zoom, Discord, etc.
      • Also interested in apps that are pure audio like Mumble
    • Multiple things involved in video call quality. Eg if latency or reliability is bad, which of these is usually the contributor:
      • The internet providers of the participants
      • The video call servers
      • The users' computers and video call clients

  What I've Found so Far

  • Can You See Me Now? A Measurement Study of Zoom, Webex, and Meet
    • arxiv.org/pdf/2109.13113.pdf
    • 2021
    • This part is for the video not audio, but still interesting:

      • In the US, typical streaming lag experienced by users is 20–50 ms for Zoom, 10–70 ms for Webex, and 40–70 ms for Meet. This lag largely reflects the geographic separation of users (e.g., US-east vs. US-west).

  • HN question by me
  • HN thread on the article A Theory of Zoom Fatigue
  • 📝contact me if you have more suggestions!

  Possible Practical Applications

  Obviously the country isn't going to switch back to landlines, but I can still think of some uses for answering the above questions.

  • If poor video call quality is due to varying sources we should do a better job of surfacing which is the problem for particular calls.
    • Right now users often don't know on which end of a two-person call problems are coming from, much less whether the issue is with the video call service or their Internet provider.
      • If the latter they need to know whether it's a latency or bandwidth issue.
  • Google has Project Starline (HN discussion). Should more businesses consider latency optimized video call clients?

• ❓

  What category of software are web browsers and Emacs?

  • type: question

  ---

  • A comparison
    • GCC and Clang are both C implementations.
    • C in turn is a programming language.
    • Having a word for "what C is" is pretty dang useful!
    • Chrome and Safari are both web browser implementations.
    • The web browser in turn is a ???
  • Web browsers dominate the computing world. You're probably using one now. But we don't have a name for the category of software they fall into.
    • Having such a name is important because of weak Sapir-Whorf: language influences our thinking.
    • We have words for specific browsers, Chrome, Safari, and so on, so our thinking is channeled downward to within the browser family.
    • But we don't have a word for the type of thing the web browser itself is.
      • Thus it's hard for our thinking to travel up: to how it fits within the system.
      • Same for sideways: we don't naturally compare browsers to sibling programs in the same category, or imagine new ones.
    • Let's give this category the placeholder name Browser Like Program (BLP) so we have a way to talk about it in the rest of this post.
  • BLP describes user facing programs that provide graphics, handle user input, run applications, store data, do networking, etc.
    • Each tries to provide a complete world within the computer. You rarely or never have to leave.
    • This is close to an operating system, but doesn't imply management of hardware.
  • It's interesting that BLP applies to 💾Emacs as well as browsers.
    • Just as some users never leave web browsers, some lispers never leave Emacs. Especially with 💾Org Mode Emacs can handle practically everything: calendars, contacts, notes, todos, writing, code, email, IRC, etc.
    • For example take this screenshot from www2.lib.uchicago.edu/keith/emacs titled "Figure 2: Emacs as Operating System":
      • 
      • When a program has its own language, package management, games and social apps, it would be good to have a word for it other than "text editor"!
      • There's an old joke about this:
        • "Emacs is a fine operating system in need of a good editor."
        • We can now untangle (and unfunny) it by saying, "No it's not, but it is a BLP that was grown by starting with an editor."
    • With two examples in our new category we can now start using to to compare and contrast.
      • For instance it's interesting to note that that both our examples so far were grown instead of planned.
  • But what name should we actually use? Some possibilities:
    • operating environment
      • en.wikipedia.org/wiki/Operating_environment
      • Accurate but maybe too archaic to be recognized
    • computing environment
      • This is actually used by the book located at the link above about Emacs.
      • A downside is that it doesn't imply personal and interactive. I think the best name would describe systems that are both for individuals (so not things like the Heroku app platform or distributed computing environments), but also broad (so not things like a game store, rather things that you can do all your computing in).
        • However it's still might be the best answer, we can't have everything.
    • application platform
      • Broad again, covering things like the Heroku app platform.
    • desktop environment
      • en.wikipedia.org/wiki/Desktop_environment
      • There are probably two kinds of things that need to be distinguished:
        • BLPs that started as applications
        • BLPs that were built from the start to provide the user-facing half of an operating system.
      • We could define BLP to encompass both of the above. Then desktop environments would be one of the the most common forms of BLP. But they're still only a specific metaphor that not all BLP use, so we can't use desktop environment as the name we're looking for.
    • virtual machine
      • en.wikipedia.org/wiki/Virtual_machine
      • This implies emulation of an actual computer which doesn't fit here.
  • That said, maybe the answer is some combination of
    • These adjectives:
      • personal
      • individual
      • user
      • computing
    • And these nouns:
      • environment
      • system
      • platform
  • For example:
    • personal computing environment
    • user environment
    • etc
  • Postscript
    • Just because someting is a BLP doesn't mean you have to use it that way.
      • E.g. a web browser can be used as just a PDF viewer
      • Same for Emacs and text editing

• 📝

  icon key

  <body elided>

• 📝

  old stuff and WIP

  <body elided>

• 📝

  purely functional data structures notes

  <body elided>

• ⚛️

  Pan* - or the universal converter pattern

  • type: atomic note

  ---

  • Background

    • 💾

      Pandoc

      • author: 👤John MacFarlane
      • released: 2006
      • source: github.com/jgm/pandoc
      • type: software
      • url: pandoc.org
      • wikipedia: en.wikipedia.org/wiki/Pandoc

      ---

      a universal document converter

  • Practical motivation
    • When I was writing a lot of Haskell I regularly found myself wanting to generate Elm, PureScript, or TypeScript types from my Haskell types.
    • Two things could cause this:
      • I had a Haskell server with a client in another language
      • I had a Haskell reference implemention of an algorithm, toy language, etc. and wanted to start on followup implementations in other languages
    • Conceptually this is straightforward. Everyday Haskell types tend to be a subset of what Elm/PureScript/TypeScript support (going the other way is harder since Haskell doesn't have row polymorphism).
    • And there a lot of Haskell-types-to-X projects so I could usually find one that worked. But each time I found myself digging through the internet trying to find one that was the right fit for my current project I found myself thinking, "This situation is lot like Pandoc's for documents. Why not Pantype, Pandoc for types?"
      • Pantype would reduce work for users, since you'd only have to learn one API.
      • Pantype would reduce work for implementers, since the amount of conversions goes from quadratic to linear.
        • A second question: why not Pandoc for everything?
  • Pandoc details
    • Pandoc has a single core type that everything converts to or from: hackage.haskell.org/package/pandoc-types-1.23.0.1/docs/Text-Pandoc-Definition.html#t:Pandoc
    • The input and output formats supported are listed on the homepage: pandoc.org
      • Most are bidirectional. Some like CSV can only be input. Others like AsciiDoc and PowerPoint can only be output.
    • On lossiness: pandoc.org/MANUAL.html

      • Pandoc has a modular design: it consists of a set of readers, which parse text in a given format and produce a native representation of the document (an abstract syntax tree or AST), and a set of writers, which convert this native representation into a target format. Thus, adding an input or output format requires only adding a reader or writer. Users can also run custom pandoc filters to modify the intermediate AST.
        
        Because pandoc’s intermediate representation of a document is less expressive than many of the formats it converts between, one should not expect perfect conversions between every format and every other. Pandoc attempts to preserve the structural elements of a document, but not formatting details such as margin size. And some document elements, such as complex tables, may not fit into pandoc’s simple document model. While conversions from pandoc’s Markdown to all formats aspire to be perfect, conversions from formats more expressive than pandoc’s Markdown can be expected to be lossy.

    • These seem like pattens that could be useful in other circumstances, not just for documents.
  • Comparison with other design patterns
    • frame your program as a compiler (upcoming)
      • Similar to Pandoc-for-X, but more constrained. Compilers don't throw away inconvenient expressions when moving from a particular syntax to an IR, or from IR to machine code.
    • language-server-protocol for X
      • Also a successful example of going from having to write a quadratic number of programs to a linear one, but less useful to communicate intent since this is for protocols not data.
  • Note on the page name
    • I considered the following distinction
      • Pan* for converters that can be lossy both when generating IR and when generating output
      • universal converter for any type of multiway converter
    • However it seems like a universal converter necessitates possible lossiness at each step, so I think they're the same.
      • Technically it doesn't at the Input -> IR step though, you'd just end up with a gargantuan IR. So maybe this distinction was good?
  • Other universal converter projects
    • imagemagick.org
    • ffmpeg.org
    • calibre-ebook.com
  • question: is there a better name for this? And are there any other particularly interesting universal converter projects I should know about?