The web browser is software that you own and control. Firefox, Chrome, and their various alternatives are mostly open source software that support powerful modifications in the form of browser extensions.

The web does not belong to the companies and brands that publish there. They put a website out there, you download it, and what happens from there is nobody else's business. If there's something you don't like about a website, like the font, visual layout, or a barrage of ads, you can use a browser extension to change the website so that it fits your needs and respects your space.

Let's apply this to YouTube, in the context of the complaints I hear most commonly.

1. The algorithm is trying to push something I'm not interested in Much of the visual real estate in stock YouTube is given to algorithmic discovery of video, and they push it on you constantly. What's worse, it can get the idea for whatever arbitrary reason that you're interested in some particular type of content, and then you're seeing invitations for that constantly, without a clear way to prioritize the channels and topics that you've actually subscribed to.
2. Non-stop barrage of advertisements YouTube shows ads every few minutes and often at the start and end of a video. It's overwhelming, and the companies putting out these ads are not good faith actors. They want to get you addicted, in debt, and miserable. Cutting off their ability to push their content in front of you is critical self-care.
3. YouTube creators tend to waste your time From clickbait video titles to sponsored ad reads and constant reminders to like and subscribe, the average YouTube video is full of anti-patterns that degrade the watching experience in service of the algorithm.

Here's my list of extensions I use, and how each one contributes to a good experience:

Your video player should respect you. That's not too much to ask for. It's a shame that YouTube (and parent company Google) are so disrespectful, but at least for the time being we still live in an era where we control our own web browsers and can modify disrespectful websites to force them to behave.

Take the opportunity. A better world is, in this specific instance, only a few button clicks away.

Writing a runbook takes time. It's rare to write anything down for a script I intend to run one time and discard. In order to get value out of my runbook, I want other people to find it, including my future self. Therefore one of the universal goals of every runbook is discoverability.

Just writing anything down at all can be handy, but I can further increase the value by adding specificity. Exact command invocations, dependency versions, preparatory & cleanup steps, dependencies, and environment setups increase the likelihood that I can reproduce my workflows in the future, or enable another person to succeed in doing so.

Software practices tend to drift over time, as requirements change and trends shift. If practice changes but the runbook doesn't, it becomes a form of tech debt, misleading contributors who aren't aware of the shift and newcomers. My ideal runbook would always be current and reflective of the practice actually used to produce the most recent builds & test results.

The usual practice is to scatter pieces of the runbook in files throughout the software repository, such as:

• targets in a Makefile (or Rakefile, Justfile &c)
• tasks in a language-specific config file like package.json or pyproject.toml
• workflows in a config directory for some CI provider, like .github/workflows, Jenkinsfile, .travis.yml, or many others
• shell scripts¹
• READMEs, HOWTOs, blog posts, and web documentation

Let's analyze these in quadrants:

If the README is among the highest-impact, most discoverable places to document workflows, why don't we put our scripts there? The typical marquee reason is that READMEs are non-executable: they're prose, not code. This makes them suffer in the critical "specificity" criterion for runbook technology. Enter xc, the task runner for your README that works seamlessly with your CI, shell, and editor.

xc² is a task runner similar to Make or npm run, that aims to be more discoverable and approachable

To use it, take all the commands you run to build, debug, test & deploy and document them in your README as code blocks, each under a descriptive header, like "Build". Then run xc build and it'll find that header in your docs and run the code block there.

Crucially, put your CI steps in your README and run them on each merge or release. Quality of life here is good: it supports dependencies between blocks, script arguments and plenty more.

You can also include usage instructions, caveats, deprecation notices, links, and other context right there next to the task's script. And it'll actually look nice, since you have all the info presentation tools normally available in READMEs at your disposal, instead of just spartan code comments.

xc solves a need in the current dev tool space by putting workflows in the most prominent location and keeping them on the "hot path" so that they don't get out of date. It's Free software (MIT license) and migrating has been straightforward. This is a tool I'm glad to have in my working set.

I changed the game's name to “Yondergrove” in this piece in response to concern from a game developer that interested players might find it in their web searches and be prejudiced by this reflection on a single role-play session, a snapshot in time where the game is unfinished and its alpha community is very much still finding itself. If you play a game like Yondergrove, I hope you view it with fresh eyes and a critical mind, and bear always in mind that a roleplaying game is a beautiful dance between the players and the game rules.

In both games, your character arrives at the grand hall as a penniless immigrant. You choose which animal you want as your avatar, each with their own strengths and weaknesses which you can adjust with positive and negative traits to create a well-rounded character or a narrow savant. You wear only your fur and have neither tools nor weapons, nor a coin to your name. But here is where Yondergrove and Hedgerow Hall show their first significant divergence in vision.

Hedgerow Hall puts forth a vision of abundance, in which the titular Hall provides a nurturing haven for immigrants to get them on their feet and on the path to independence. You can always return to the Hall for free meals and water (your character gets lethargic when hungry, but it is not possible to starve) and training in any skill of your choice by the Hall's many NPC tutors. There is a tutor of each animal type, ensuring that you always see a familiar face when you begin playing a character, and the different animals teach different skills, suggesting archetypes of skills that go together and capitalize on the signature strengths of each animal.

Hedgerow Hall's generosity is not unlimited: you cannot ask for more than a few square meals per day, and your skill training is limited by the number of "skill points" you have available. You begin the game with a few dozen of these, and every hour or so of gameplay your points get replenished, whatever activities you chose to partake in during that time. With your initial allotment of skill points, you can choose to immediately become basically proficient in one or two skills of your choice, or you can gain a beginner's level in a handful of skills. If your idea of fun is to create a character who's scrappy and self-sufficient right off the bat, you might seek training in scrounging for food and climbing trees to avoid danger, and this is provided free of charge by the welcoming tutors of the Hall. Of if you desire a mystic's life, you can seek the skills to identify crystals from among rubble that can hold a magical charge, and to power them up with your own mind.

Meanwhile, the vision of Yondergrove is of austerity and consumption. Its central structure is the image of cold neutrality: it offers no free meals except whatever is provided by players as charity, its halls are silent and empty unless players choose to actively loiter around for welcome duty, and it is likely that none of the characters you meet will be the same animal as yourself. The library is stacked high with skill training books, to which you can help yourself. But reading is a destructive act in Yondergrove: any time you read a book it is lost forever, and the library's stacks are finite. Unlike a public library, here there are no returns, and gaining proficiency in a skill requires destroying not just one book but many. Of course, this has been taken to its logical end in the game world: the library is barren of books on useful, popular subjects like scrounging for food, climbing trees, identifying minerals, or charging magical crystals. The books that remain are the unpopular ones: a stack of tomes on sword-fighting is over a hundred books high, because swords are hard to come by in this fantasy world of scarcity.

The only way to learn any skill in the world of Yondergrove is to read skill books. You cannot learn by doing, or by watching another player. The objective of this design, as stated by the game's developers, is to create an in-game economic hierarchy between the new and established player where, if a new character wants to be able to do anything useful like scrounging for food, they must first ply the charity of another player who becomes their benefactor, or agree to pay rent in return for training in the form of consumable books.

Some of these books may have been hoarded into private collections directly from the library: many books in player-run shops carry the iconic "Complete Edition" stamp which comes only from books found in the library or created by an established player with a complete mastery of the skill. Player-created books are made from scarce bark and ink by those with skill in writing and woodland-crafting.

All of the skills necessary to bootstrap an economy, like making books, clothes, weapons or jewelry, are locked up behind counters in player-run shops. Every entry into the game is transactional, with the established properties providing some necessary resources on lease, extracting promises of future payback. Unlike in Hedgerow Hall, there is no subsistence in Yondergrove without debt.

Part of the joy of playing Hedgerow Hall was how each character would adhere to their animal archetype, or rebel against it. Rats were especially good at fighting, and many rat brigands (or body-guards) roamed the woods. Shrews were especially good at foraging and many a shrew's burrow was richly adorned with the fineries they would discover in the woods. Squirrels were able climbers, and it was not uncommon to spot a scurry of squirrels debating and snacking on nuts high up amid a stand of trees. The squirrel who could not climb, the shrew who could not provide for herself, and the weakling badger mystic were uncommon enough to be interesting outliers in their own right.

In Yondergrove, squirrels who cannot climb are commonplace because climbing is a fun, useful, and popular skill, so all the climbing books are locked up in private collections. Rabbits who cannot provide for themselves are the norm, because books on scrounging are especially scarce and in-demand. A rat with competent sword-skill and a decent set of arms and armor would have to be deeply indebted to one or more entrenched players who could support all the expenses of such an endeavor. The animals of Yondergrove seemingly have none of the intrinsic dignity we as human players associate with their kind; or, more precisely, they have exactly as much dignity as they are able to purchase by taking on debt.

The overall experience of playing Hedgerow Hall is that you can make your own way in the world by accepting a modest existence, or you can realize grand ambition by cooperating with the community of animals you find around you. You can range wide in exploration and interact infrequently with other animals, you can play a socialite, or anything in-between. The game design choices that made this possible were imposed in the form of a social compact followed by all players and enforced through a combination of role play, moderation, and the narrative design of the game world and interface.

In terms of lore, the game provided an explicit designation for the social compact that it offered players. Why do tutors provide training free of charge? Why do even the cruelest of villains refuse to kill other characters, never even giving it a consideration? Why does the Hall provide square meals every day to the most saintly or most reviled of characters alike, no questions asked? Why do critters foraging for food in the woods never turn up insects, fish, snails or crabs? It's all because of the Green Way, the catch-all excuse to explain the social order, where all immigrants are owed autonomy and all animal life is to be respected.

If Hedgerow Hall is the cozy woodland utopia of the Green Way, Yondergrove is the woodland dystopia without it. Like a vision of childhood fantasy seen through a glass darkly, it depicts the world of Redwall or Watership Down via the stunted politics of austerity and libertarianism, a secluded glen of interconnected animals each playing out the story of their lives as a rentier or an indentured worker.

Yondergrove reminds me in many small ways of the aesthetic and pace of Hedgerow Hall which I dearly miss, and the game is far from finished. I expect that its community will continue to grow and change, and that its many systems and mechanics will be overhauled as they work to find and sustain a dedicated player base for the long term.

I'm excited to see the direction that the Yondergrove team takes the game from here. What they have built has already given me a much deeper appreciation for the particular elements that gave Hedgerow Hall its legendary vibes and its charm. I'm grateful for the opportunity to luxuriate in the memory of my favorite Hedgerow Hall stories of old, and I will return to see how progress is coming.

Guix puts software and data onto computers, following your plan. In that sense, its closest competitors might be Ansible, Chef, or Docker. But it's a more useful and capable technology than any of those because its underlying model is so expressive. It provides a collection of composable building blocks to create and organize systems of any complexity and deploy them to any computer, all using declarative code.

The uniformity and expressiveness of Guix allow you to avoid entire classes of problems with software deployment that we typically use a collection of tools to handle.

Every part of Guix is free software according to the Free Software Definition, and the Guix project as a whole meets the much higher standards of the Free System Distribution Guidelines. Beyond that, the design of Guix is carefully thought-out to help you make practical use of your freedom.

The Guix project is backed by a non-profit foundation and maintained entirely by volunteers. It has no backing from venture capital, no enterprise product, and no advertising. If you want to see it grow and succeed at bringing universal deployment to the whole world, please consider contributing your skills in one of the many areas we need help, or making a donation to the project!

Guix packages look a lot like data, since they mostly consist of URLs and descriptions and so on. But don't be fooled! Packages are code, and building a package runs arbitrary code on your computer. A malicious package can do dastardly things. So don't run packages from people you don't trust unless you've inspected them yourself and gain some understanding of what they're doing.

Guix discovers what packages exist by loading all the Guile code on its guile-load-path and collecting package definitions. That means you can add new packages just by adding files that define them to your Guix load path.

Here's an example using my repository:

  git clone https://github.com/ryanprior/guix-packages.git
  cd guix-packages
  guix environment -L. --ad-hoc countdown -- countdown 10s

To break it down:

  ~/guix-packages$ countdown
  countdown: command not found
  ~/guix-packages$ guix environment -L. --ad-hoc countdown
  ~/guix-packages$ type countdown
  countdown is /gnu/store/w0gy4d14b2byir64jakpsrw3j73n916a-profile/bin/countdown
  ~/guix-packages$ exit
  ~/guix-packages$ type countdown
  bash: type: countdown: not found

# […lots of warnings]
guix environment: warning: failed to load '(vlang)':
no code for module (vlang)
./vlang.scm:4:0: warning: module name (testing vlang) does not match file name 'vlang.scm'
hint: File `./vlang.scm' should probably start with:

     (define-module (vlang))

guix environment: error: countdown: unknown package

  (define-module (testing countdown)
   ;; snip
  )

If you have a single file that defines a package of interest, you can use the -f flag to refer to the package it evaluates to. But you have to take care that the file actually evaluates to the desired package and doesn't merely define it.

For example, in my guix-packages repository, the countdown.scm file has a structure like this:

  (define-module (testing countdown) …)


  (define-public countdown
    (package
      (name "countdown")
      …))

What's important to note is that the last form of the file is a (define-public) form, which does not have any return value. A file evaluates to the return value of its last form, so while this file defines the countdown package, it evaluates to nothing. So if you run guix build -f countdown.scm it will give you an error message like so:

~/guix-packages/testing$ guix build -f countdown.scm 
guix build: error: #<unspecified>: not something we can build

hint: If you build from a file, make sure the last Scheme expression returns a package value.  `define-public' defines a variable, but returns `#<unspecified>'.  To fix this, add a Scheme
expression at the end of the file that consists only of the package's variable name you defined, as in this example:

     (define-public my-package
       (package
         ...))
     
     my-package

If you edit countdown.scm to put a new line at the end that just says countdown, then Guix will build the package:

  ~/dev/guix-packages/testing$ cat >>countdown.scm

  countdown
  ~/dev/guix-packages/testing$ guix build -f countdown.scm 
  /gnu/store/6x2lmakp59vzdjbjqxha2560g2jrqdyv-countdown-1.0.0

Now the countdown executable is available in the listed directory, and we can start a 10 second countdown like so:

~/dev/guix-packages/testing$ /gnu/store/6x2lmakp59vzdjbjqxha2560g2jrqdyv-countdown-1.0.0/bin/countdown 10s

  ;; …rest of countdown.scm

  (package
    (inherit countdown)
    (inputs `(("countdown" ,countdown))))

  ~/guix-packages/testing$ guix environment -l countdown.scm 
  ~/guix-packages/testing$ type countdown
  countdown is /gnu/store/4gc33v065h1hm0lq42j1fir7gs151j9s-profile/bin/countdown

The currently available methods for testing a Guix package you find on the Internet are fraught with thorns and pitfalls for the unwary. This can give an overall unfriendly feeling to newcomers.

Suppose we were to come upon a clearing in the thicket where some hackers were having a merry potluck, where everybody brought their packages to try and there was a friendly uniform mechanism to try and share these packages?

Such a tool was proposed: Guix Potluck was submitted in 2017 to address this kind of use case. It never got a public release, but there may be lessons there for a hypothetical future tool that could make guides like this one obsolete.

⌘+Space opens the elementary applications menu:

This menu controls all the power settings for the desktop. It's part of a set of elementary components called Switchboard. I'm looking for an option here to turn the screen after 1 minute.

No such option. I dig deeper and try to find out how Switchboard manages power settings and see if that leads me to a workaround.

Every piece of the elementary OS desktop is free software, which means its source code is available for the community to study, change, and re-use. I don't know how the Switchboard power menu works, so I'm going to study the source code to find out.

Finding the source code for power settings

The elementary project has a page on GitHub where I can search for components:

Scrolling down, there's a search box for repositories. I try typing "power" to see what comes up:

This is the repository where the source code for the power settings is stored. I browse a few files in the repository, looking for the key phrase "Turn off display" which is found in the settings menu:

Now I know there's a component called screen_timeout which we manipulate when we touch the control with that label. But what does it actually do to change the power settings when we select a different option?

Understanding the power settings method of action

I search for "screen_timeout" and scan through the results until I see one that says "connect," suggesting that this is where the settings panel connects to another component that takes action to change settings. The name of this component is dpms_helper.

Back to the elementary GitHub organization! Now I'm looking for the dpms helper to dig further.

This repository has the source code for dpms-helper, the tool that I found out Switchboard uses to act on our power settings preferences. How does it work? I search around in its source code and soon find that it's executing another program called xset:

How can we use xset to achieve the desired goal of turning our screen off after a short time-interval? Now that I know what to look for, let's see what the system manual has to say:

I set out to find out how to set short intervals for power management: 1 minute before turning off the screen, and 2 minutes before suspending. The search took me through:

• The applications menu and power settings menu
• The elementary project's GitHub repositories
• Source code for Switchboard and dpms-helper
• The system manual

After researching the method of action, I can answer the original question like so:

# power settings: standby after 2 minutes, never suspend,
# and screen off after 1 minute.

# `xset dpms` takes arguments in seconds, in that order.

standby_seconds=$(((2*60)))
screen_off_seconds=$(((1*60)))

xset dpms $standby_seconds 0 $screen_off_seconds

standby_time=$(gsettings get io.elementary.dpms standby-time | cut -d" " -f2)

suspend_time=$(gsettings get io.elementary.dpms suspend-time | cut -d" " -f2)

off_time=$(gsettings get io.elementary.dpms off-time | cut -d" " -f2)

# power settings: standby after 2 minutes, never suspend,
# and screen off after 1 minute.

# gsettings for these take time in seconds

gsettings set io.elementary.dpms standby-time $(((2*60)))
gsettings set io.elementary.dpms off-time $(((1*60)))

io.elementary.dpms-helper

The elementary OS team puts a ton of love into creating a beautiful, accessible, privacy-respecting desktop. The source code is available for everyone to read, study, share and modify, so the whole community is invited learn more about computers and share the work of improving them.

Three ways you can contribute to elementary

1. Spread the word! Share this article and others you find interesting and helpful. The elementary team writes a great blog.
2. Purchase elementary OS (name your price), apps on AppCenter, and sponsor elementary on GitHub.
3. Contribute your skills to elementary OS development, starting with our guide for developers.

You can also sponsor me on GitHub to get more practical explorations like this one!

Let me start by laying out specifically how I see Svelte marketing itself, and I'll follow-up with how I feel about those claims.

Svelte code looks like JavaScript, CSS, and HTML, but its compilation stage takes that and munges it totally out of recognition into a tangle of reactive JS code. What's running on the client does not resemble what you wrote; yet, where you're looking at it in your editor, it looks just like normal code. Your brain will tend to allow assumptions that would hold for normal JS/CSS/HTML.

So in order to avoid providing an API or framework, Svelte creates a split world where you need to always know which side you're on–is this code that will be interpreted directly, or compiled by Svelte? Your code looks the same on each side but acts totally different.

So whereas Svelte explicitly appeals to people on the principle of familiarity, this greatest strength hides a confusing trap.

Svelte markets itself as having no runtime: unlike React & friends, there is no code that's taking the data structures you create and turning them into a DOM, it's merely a tangle of JS code specific to each component that's doing the rendering directly.

What that means in practice is that you have a different Svelte runtime per component that's generated for you. You start from ground zero each time you find a production glitch of some sort; there's no single standard runtime that provides introspection & helps you mess with your data structure and see how that would render differently, or enables you to edit your code and see live how that changes things.

The way to change the behavior of a running Svelte app is to either A) abandon the logic you were working with when you created the component in the first place, instead working on the logical level of the generated JS code; or B) go back to your editor, make changes, pray, recompile your app, and reload.

While Svelte touts how it adds no extra complexity due to a runtime library, there's still the implicit complexity of understanding each component as it's actually implemented, and you don't get any of the niceties of a runtime to help you deal with that.

I like Preact. It's the exact same API as React, so I benefit from being able to search for "how to do X in react" and get results that work for Preact too. But the runtime is simpler & smaller and it's easy to get started without a bunch of boilerplate and code generators like create-react-app, which are endemic to React tooling.

I like having an API that's not magical or disappearing, which I can use to do my rendering. I like that Preact can be used directly in the browser without any transpilation steps. I like that it plays well with other front-ends which may set event listeners on objects which React would usually clobber.

I am excited by the possibilities for compiled web apps which run on low-memory devices or achieve ultra-high-performance on powerful consumer machines. While I'm dissatisfied with Svelte's approach which mimics and munges standard web technologies, it seems likely to inspire the community to create innovative APIs which will allow us to build reactive high-performing compiled web apps with WebAssembly and Rust or TinyGo, and even with new languages like Crystal.

I also worry that Svelte may inspire a raft of copycat "no-API" front end systems which implement mutually incompatible semantics, each on top of normal-looking JS/CSS/HTML, further increasing the potential for "split world" headaches.