@Nunya Bidness not sure if y’all these are on the Circle B
View quoted note →
nym
nym@primal.net
npub1hn4z...htl5
#Icomeinpeace 
The slow death of TuxFamily
TuxFamily is a French free-software-hosting service that has been in operation since 1999. It is a non-profit that accepts "any project released under a free license", whether that is a software license or a free-content license, such as CC-BY-SA. It is also, unfortunately, slowly dying due to hardware failures and lack of interest. For example, the site's download servers are currently offline with no plan to restore them.
originally posted at 
LWN.net
The slow death of TuxFamily
TuxFamily is a French free-software-hosting service that has been in operation since 1999. It i [...]
Stacker News
The slow death of TuxFamily \ stacker news
TuxFamily is a French free-software-hosting service that has been in operation since 1999. It is a non-profit that accepts "any project released un...
The Great Unpermissioning
It starts with a click: “Do you agree to our terms and conditions?”
You scroll, you click, you comply. A harmless act, right? But what if every click was a surrender? What if every "yes" was another link in the chain binding you to a life where freedom requires approval?
This is the age of permission. Every aspect of your life is mediated by gatekeepers. Governments demand forms, corporations demand clicks, and algorithms demand obedience. You’re free, of course, as long as you play by the rules. But who writes the rules? Who decides what’s allowed? Who owns your life?
originally posted at 
The Great Unpermissioning
Reclaiming Freedom in an Age of Digital Serfdom
Stacker News
The Great Unpermissioning \ stacker news
It starts with a click: “Do you agree to our terms and conditions?” You scroll, you click, you comply. A harmless act, right? But what if every...
Good evening, Nostriches.
RSYNC: 6 vulnerabilities
Two independent groups of researchers have identified a total of 6 vulnerabilities in rsync. In the most severe CVE, an attacker only requires anonymous read access to a rsync server, such as a public mirror, to execute arbitrary code on the machine the server is running on.
originally posted at 
oss-security - RSYNC: 6 vulnerabilities
Stacker News
RSYNC: 6 vulnerabilities \ stacker news
Two independent groups of researchers have identified a total of 6 vulnerabilities in rsync. In the most severe CVE, an attacker only requires anon...
The future of gig economy runs on relays
The employment trends in the gig economy are clear. More and more people take on some form of freelance or temporary work often on top of their full time job. In fact, according to recent estimates, approximately 1.57 billion people, or nearly half (46.4%) of the global workforce, engage in gig work. As gig platforms continue to expand across borders and sectors, this number is projected to keep rising.
In the UK, the gig economy is particularly popular, with many workers supplementing their income with side gigs. According to a recent survey, almost half (48%) of UK gig workers have full-time jobs on top of their side gigs, while 71.5% use gig work to supplement their income rather than provide their sole earnings. The top gig occupation in the UK is online administrative work, with 39% of gig workers offering virtual assistance, data entry, clerical services, or similar computer-based tasks. Sounds like a great way to earn some sats, doesn't it?
Despite the growth and popularity of the gig economy, traditional platforms like LinkedIn have reached their peak and become increasingly plagued by spam from aggressive recruiters and profiles of people with increasingly unverifiable experience. Meanwhile all the centralised platforms like Fiverr and Upwork take a significant cut from freelancers' pay, leaving many workers feeling undervalued and overworked. It's no wonder that many are looking for alternative solutions that prioritize fairness, transparency, trust and compensation paid in money that will last!
Here comes Nostr, a decentralized, censorship-resistant protocol that's laying foundations for the future of the gig work. With its censorship-resistant, peer-to-peer approach, Nostr is poised to revolutionize the way we work and connect with each other. In this article, I'll explore why Nostr is an exciting development for the gig economy, what it means for the future of work and what platforms are already available.
What makes Nostr different? It’s built on principles of decentralization, freedom, trust and Bitcoin as its native currency. Forget walled gardens; with Nostr, your identity is your own. Nobody’s mining your data, and no shadowy algorithms are deciding who sees your posts or what posts you should see. It's a perfect setup for a job marketplace where companies post jobs and freelancers get them done. All paid with Bitcoin with no middleman to take your money
And it’s not just theory. Real solutions are already built, transforming how professionals connect, collaborate, and commit their skills, time and creativity. All open-source and Bitcoin/Nostr-centric.
originally posted at 
The future of gig economy runs on relays
How Nostr will remove the parasitic middleman.
Stacker News
The future of gig economy runs on relays \ stacker news
The employment trends in the gig economy are clear. More and more people take on some form of freelance or temporary work often on top of their ful...
Challenges to funding open source
I’ve had the good fortune to get paid to write open source as part of my job several times. For more than 15 years, I’ve also done a lot of open source development in my free time as a volunteer. Along the way, there’s been a fairly constant refrain that it’d be better if more open source maintainers were paid to maintain their projects. And I’ve seen a lot of ideas for how that could happen. While some of these ideas were successful, many more were not. I’m writing this post to explain three reasons that I’ve seen open source funding concepts fail. These aren’t the only reasons, but they’re reasons that I think are often ignored in the discourse.
This is not a normative piece, I’m not expressing an opinion on if anything here is good or bad. This is entirely descriptive of the things I have seen.
**You can’t articulate what it is people are funding**
Specifically, you can’t articulate how the world with funding would be different than the world without it. For many maintainers, the ideal form of open source funding is something like: instead of working on my project in my spare time, I get paid to do it and I can do it during the work day instead of stealing time from my other hobbies and personal obligations. Unfortunately, if you’re asking someone for money, this doesn’t tell them anything they’re getting for their money.
The underlying premise here is that if you can maintain your project without stealing time from other activities that the project will be more sustainable. This is a better premise, but still falls short, because sustainability is not about anything being different, it’s in fact about things being able to stay the same more predictably. Rationally, this sort of risk mitigation may make sense to invest in, but practically its a very difficult to assess risk (What are the odds that the existing maintainers will stop doing so as volunteers? Who knows! Many open source projects go years, if not decades, with exclusively volunteer maintainers). This explains why we see so little of the open-source funding that does occur is justified in this way.
If you are an open-source maintainer, be prepared to articulate: what will be different from the status quo if you have more time and money to work on your project. Is there a major feature that needs dedicated design and implementation time? A queue of bugs that need to be triaged and fixed? All of these are concrete things that can motivate people to support an open source project.
**Many open source maintainers do not want to be paid**
Or more accurately, they don’t want the expectations that come with taking money. If you’ve accepted money, that generally comes with some expectations (see the previous section). However, for many open source maintainers, having no expectations is the point.
For many folks, open source is enjoyable to work on precisely because you can reject features that offend your sensibilities, even if many users want them. You can take as long as you want until you find a design you like, you don’t have to ship something “good enough”. You can walk away for months if you’re bored, frustrated, or just don’t feel like working on the project.
There’s nothing wrong with this mode of maintainership (indeed, in my experience, having this approach makes my own open-source work more sustainable, even if it is entirely nights and weekends). But if this is why you love open-source, it is going to be challenging to find a way to take money for it without compromising some of what makes it enjoyable for you.
**Time and money are not interchangeable**
For open-source developers with a full time job, money does not translate into significantly more time for their project, unless the money is at the level of replacing a full time salary. It can offset some costs in life, and may be very appreciated. But the largest time obligation most people have is their day job, and for folks with full time jobs, a fraction of their salary doesn’t buy them extra hours in a week.
This means that for many open-source developers, small sums of money do not substantially increase their capacity to maintain their project. It doesn’t give them additional time to implement features, fix bugs, or triage issues. This means that to have an impact, open-source maintainers often need to find salary-replacement level funding for their open-source work.
This combines poorly with another simple observation: many open-source projects, including critical ones, do not make particular sense to fund at a full time level. A library for a stable compression format, for example, does not make sense to staff for 40 hours a week, that much time cannot be used efficiently. Of course, even if the format is stable there’s more than 0 hours a week of work! There’s porting to new platforms, updating for yet another backwards incompatible change in a dependency or CI platform, triaging bug reports, performance improvements, etc.
Perhaps some projects are so critical that as a society that we should fund them as a full-time endeavor even though the scope doesn’t justify it. However, one risk this carries is that developers who find themselves in such a position will need to be on guard against the temptations that more time provides, such as backwards incompatible changes for limited value and adding features of marginal value but with substantial new attack surface.
As an open-source maintainer, ask yourself how your life situation allows you to channel money effectively into work on your project, and what the scope of your project reasonably justifies in terms of hours spent on it.
originally posted at 
Challenges to funding open source · Alex Gaynor
Stacker News
Challenges to funding open source \ stacker news
I’ve had the good fortune to get paid to write open source as part of my job several times. For more than 15 years, I’ve also done a lot of ope...
Viewing images
How hard would it be to display the contents of an image file on the screen? You just load the image pixels somehow, perhaps using a readily available library, and then display those pixels on the screen. Easy, right? Well, not quite, as it turns out.
I may have some experience with this, because I made an image viewer that displays images in the terminal emulator. But why do such a thing, there are countless image viewers already available, including those that work with terminal emulators, why write yet another one? That’s an excellent question! As always2, the answer is because no other viewer was good enough for me.
For example, catimg uses stb_image to load images. While stb_image is an outstanding library that can be integrated very quickly, it doesn’t really excel in the number of image formats it supports. There’s the baseline of JPEG, PNG, GIF, plus a few other more or less obscure formats.
Another example is viu, which again is limited to the well-known baseline of three “web” formats, with the modern addition of WebP. Following the dependency graph of the program shows that the image loading library it uses should support more formats, but ultimately I’m interested in what the executable I have on my system can do, not what some readme says.
The overall situation is that there is widespread expectation and support for viewing PNG files (1996), JPEG files (1992) and GIF files (1987). So… what happened? Did image compression research fizzle out in the XXI century? Of course not. There’s JPEG XL (2022), AVIF (2019), HEIC (2017),3 WebP (2010). The question now is, why is there no wide support for these image codecs in software?4 Because nobody uses them. And why is nobody using them?5 Because there’s no software support.
So maybe these new formats just aren’t worth it, maybe they don’t add enough value to be supported? Fortunately, that’s easy to answer with the following image. Which of the quality + size combinations do you prefer?
But that’s not all. There is a variety of image formats that are arguably intended for more specialized use. And these formats are old, too. Ericsson Texture Compression (ETC) was developed in 2005, while Block Compression (BC) and OpenEXR date back to 1999. BC is supported by all desktop GPUs, and virtually all games use it. ETC is supported by all mobile GPUs. So why is it nearly impossible to find an image viewer for them?
And speaking of texture compression, I also have an ETC/BC codec which is limited in speed by how fast the PNG files can be decoded. There are some interesting observations if you look into it. For example, PNG has two different checksums to calculate, one at the zlib data stream level, and the second at the PNG data level. Another one is that zlib is slooow. The best you can do is replace zlib with zlib-ng, which provides some much-needed speed improvements. Yet how much better would it be to replace the zlib (deflate) compression in PNG files with a more modern compression algorithm, such as Zstd or LZ4? The PNG format even supports this directly with a “compression type” field in the header, but there’s only one value it can be set to. And it’s not going to change, because then you’d have to update every single program that can load a PNG file to support it. Which is hopeless.
originally posted at 
wolf@nereid.pl
Viewing images
I want to view a picture of a funny cat I found on the web. How hard can it be?
Stacker News
Viewing images \ stacker news
How hard would it be to display the contents of an image file on the screen? You just load the image pixels somehow, perhaps using a readily availa...
What's involved in getting a "modern" terminal setup?
Hello! Recently I ran a terminal survey and I asked people what frustrated them. One person commented:
> There are so many pieces to having a modern terminal experience. I wish it all came out of the box.
My immediate reaction was “oh, getting a modern terminal experience isn’t that hard, you just need to….”, but the more I thought about it, the longer the “you just need to…” list got, and I kept thinking about more and more caveats.
So I thought I would write down some notes about what it means to me personally to have a “modern” terminal experience and what I think can make it hard for people to get there.
---
## what is a “modern terminal experience”?
Here are a few things that are important to me, with which part of the system is responsible for them:
- **multiline support for copy and paste**: if you paste 3 commands in your shell, it should not immediatly run them all! That’s scary! (shell, terminal emulator)
- **infinite shell history**: if I run a command in my shell, it should be saved forever, not deleted after 500 history entries or whatever. Also I want commands to be saved to the history immediately when I run them, not only when I exit the shell session (shell)
- **a useful prompt**: I can’t live without having my current directory and current git branch in my prompt (shell)
- **24-bit colour**: this is important to me because I find it MUCH easier to theme neovim with 24-bit colour support than in a terminal with only 256 colours (terminal emulator)
- **clipboard integration** between vim and my operating system so that when I copy in Firefox, I can just press p in vim to paste (text editor, maybe the OS/terminal emulator too)
- **good autocomplete**: for example commands like git should have command-specific autocomplete (shell)
- **having colours in ls** (shell config)
- **a terminal theme I like**: I spend a lot of time in my terminal, I want it to look nice and I want its theme to match my terminal editor’s theme. (terminal emulator, text editor)
- **automatic terminal fixing**: If a programs prints out some weird escape codes that mess up my terminal, I want that to automatically get reset so that my terminal doesn’t get messed up (shell)
- **keybindings**: I want Ctrl+left arrow to work (shell or application)
- **being able to use the scroll wheel** in programs like less: (terminal emulator and applications)
There are a million other terminal conveniences out there and different people value different things, but those are the ones that I would be really unhappy without.
---
## how I achieve a “modern experience”
My basic approach is:
1. use the fish shell. Mostly don’t configure it, except to:
- set the EDITOR environment variable to my favourite terminal editor
- alias `ls` to `ls --color=auto`
2. use any terminal emulator with 24-bit colour support. In the past I’ve used GNOME Terminal, Terminator, and iTerm, but I’m not picky about this. I don’t really configure it other than to choose a font.
3. use neovim, with a configuration that I’ve been very slowly building over the last 9 years or so (the last time I deleted my vim config and started from scratch was 9 years ago)
4. use the base16 framework to theme everything
---
## some “out of the box” options for a “modern” experience
What if you want a nice experience, but don’t want to spend a lot of time on configuration? Figuring out how to configure vim in a way that I was satisfied with really did take me like ten years, which is a long time!
My best ideas for how to get a reasonable terminal experience with minimal config are:
- **shell**: either fish or zsh with oh-my-zsh
- **terminal emulator**: almost anything with 24-bit colour support, for example all of these are popular:
- linux: GNOME Terminal, Konsole, Terminator, xfce4-terminal
- mac: iTerm (Terminal.app doesn’t have 256-colour support)
- cross-platform: kitty, alacritty, wezterm, or ghostty
- **shell config**:
- set the EDITOR environment variable to your favourite terminal text editor
- maybe alias `ls` to `ls --color=auto`
- **text editor**: this is a tough one, maybe micro or helix? I haven’t used either of them seriously but they both seem like very cool projects and I think it’s amazing that you can just use all the usual GUI editor commands (Ctrl-C to copy, Ctrl-V to paste, Ctrl-A to select all) in micro and they do what you’d expect. I would probably try switching to helix except that retraining my vim muscle memory seems way too hard. Also helix doesn’t have a GUI or plugin system yet.
Personally I wouldn’t use xterm, rxvt, or Terminal.app as a terminal emulator, because I’ve found in the past that they’re missing core features (like 24-bit colour in Terminal.app’s case) that make the terminal harder to use for me.
I don’t want to pretend that getting a “modern” terminal experience is easier than it is though – I think there are two issues that make it hard. Let’s talk about them!
---
## issue 1 with getting to a “modern” experience: the shell
bash and zsh are by far the two most popular shells, and neither of them provide a default experience that I would be happy using out of the box, for example:
- you need to customize your prompt
- they don’t come with git completions by default, you have to set them up
- by default, bash only stores 500 (!) lines of history and (at least on Mac OS) zsh is only configured to store 2000 lines, which is still not a lot
- I find bash’s tab completion very frustrating, if there’s more than one match then you can’t tab through them
And even though I love fish, the fact that it isn’t POSIX does make it hard for a lot of folks to make the switch.
Of course it’s totally possible to learn how to customize your prompt in bash or whatever, and it doesn’t even need to be that complicated (in bash I’d probably start with something like `export PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '`, or maybe use starship). But each of these “not complicated” things really does add up and it’s especially tough if you need to keep your config in sync across several systems.
An extremely popular solution to getting a “modern” shell experience is oh-my-zsh. It seems like a great project and I know a lot of people use it very happily, but I’ve struggled with configuration systems like that in the past – it looks like right now the base oh-my-zsh adds about 3000 lines of config, and often I find that having an extra configuration system makes it harder to debug what’s happening when things go wrong. I personally have a tendency to use the system to add a lot of extra plugins, make my system slow, get frustrated that it’s slow, and then delete it completely and write a new config from scratch.
---
## issue 2 with getting to a “modern” experience: the text editor
In the terminal survey I ran recently, the most popular terminal text editors by far were vim, emacs, and nano.
I think the main options for terminal text editors are:
- use vim or emacs and configure it to your liking, you can probably have any feature you want if you put in the work
- use nano and accept that you’re going to have a pretty limited experience (for example I don’t think you can select text with the mouse and then “cut” it in nano)
- use micro or helix which seem to offer a pretty good out-of-the-box experience, potentially occasionally run into issues with using a less mainstream text editor
- just avoid using a terminal text editor as much as possible, maybe use VSCode, use VSCode’s terminal for all your terminal needs, and mostly never edit files in the terminal
---
## issue 3: individual applications
The last issue is that sometimes individual programs that I use are kind of annoying. For example on my Mac OS machine, `/usr/bin/sqlite3` doesn’t support the Ctrl+Left Arrow keyboard shortcut. Fixing this to get a reasonable terminal experience in SQLite was a little complicated, I had to:
- realize why this is happening (Mac OS won’t ship GNU tools, and “Ctrl-Left arrow” support comes from GNU readline)
- find a workaround (install sqlite from homebrew, which does have readline support)
- adjust my environment (put Homebrew’s sqlite3 in my PATH)
I find that debugging application-specific issues like this is really not easy and often it doesn’t feel “worth it” – often I’ll end up just dealing with various minor inconveniences because I don’t want to spend hours investigating them. The only reason I was even able to figure this one out at all is that I’ve been spending a huge amount of time thinking about the terminal recently.
A big part of having a “modern” experience using terminal programs is just using newer terminal programs, for example I can’t be bothered to learn a keyboard shortcut to sort the columns in `top`, but in `htop` I can just click on a column heading with my mouse to sort it. So I use htop instead! But discovering new more “modern” command line tools isn’t easy (though I made a list here), finding ones that I actually like using in practice takes time, and if you’re SSHed into another machine, they won’t always be there.
---
## everything affects everything else
Something I find tricky about configuring my terminal to make everything “nice” is that changing one seemingly small thing about my workflow can really affect everything else. For example right now I don’t use tmux. But if I needed to use tmux again (for example because I was doing a lot of work SSHed into another machine), I’d need to think about a few things, like:
- if I wanted tmux’s copy to synchronize with my system clipboard over SSH, I’d need to make sure that my terminal emulator has OSC 52 support
- if I wanted to use iTerm’s tmux integration (which makes tmux tabs into iTerm tabs), I’d need to change how I configure colours – right now I set them with a shell script that I run when my shell starts, but that means the colours get lost when restoring a tmux session.
and probably more things I haven’t thought of. “Using tmux means that I have to change how I manage my colours” sounds unlikely, but that really did happen to me and I decided “well, I don’t want to change how I manage colours right now, so I guess I’m not using that feature!”.
It’s also hard to remember which features I’m relying on – for example maybe my current terminal does have OSC 52 support and because copying from tmux over SSH has always Just Worked I don’t even realize that that’s something I need, and then it mysteriously stops working when I switch terminals.
---
## change things slowly
Personally even though I think my setup is not that complicated, it’s taken me 20 years to get to this point! Because terminal config changes are so likely to have unexpected and hard-to-understand consequences, I’ve found that if I change a lot of terminal configuration all at once it makes it much harder to understand what went wrong if there’s a problem, which can be really disorienting.
So I usually prefer to make pretty small changes, and accept that changes can might take me a REALLY long time to get used to. For example I switched from using `ls` to `eza` a year or two ago and while I like it (because `eza -l` prints human-readable file sizes by default) I’m still not quite sure about it. But also sometimes it’s worth it to make a big change, like I made the switch to fish (from bash) 10 years ago and I’m very happy I did.
---
## getting a “modern” terminal is not that easy
Trying to explain how “easy” it is to configure your terminal really just made me think that it’s kind of hard and that I still sometimes get confused.
I’ve found that there’s never one perfect way to configure things in the terminal that will be compatible with every single other thing. I just need to try stuff, figure out some kind of locally stable state that works for me, and accept that if I start using a new tool it might disrupt the system and I might need to rethink things.
originally posted at 
Julia Evans
What's involved in getting a "modern" terminal setup?
What's involved in getting a "modern" terminal setup?
Stacker News
What's involved in getting a "modern" terminal setup? \ stacker news
Hello! Recently I ran a terminal survey and I asked people what frustrated them. One person commented: There are so many pieces to having a modern ...
Distro.Moe - Find Me a Linux Distro
Discover a new distribution with a single click
originally posted at 
Find Me a Distro
Stacker News
Distro.Moe - Find Me a Linux Distro \ stacker news
Discover a new distribution with a single click [1 comment]
Distro.Moe - Find Me a Linux Distro
Linux Live Kit is a set of shell scripts which allows you to create your own Live Linux from an already installed Linux distribution. The Live system you create will be bootable from CD-ROM or USB Flash Drive.
1. **Install your favourite distro to disk partition, or into a folder on your existing system.**
- Debian is recommended but not required.
2. **Make sure that squashfs and either aufs or overlayfs kernel modules are supported by your kernel.**
- Chances are your distribution supports them automatically.
3. **Remove all unnecessary files, to make your Live Linux system as small as possible (this step is optional).**
- It is recommended to remove udev's persistent net rules and other settings of your distro, which may prevent it from functioning correctly on different hardware.
4. **Download Linux Live Kit from GitHub and put it in /tmp.**
- Read files in `./DOC/` to learn how it works (this step is optional).
- Edit `.config` file if you need to modify some variables.
5. **Finally log in as root and run the `./build` script.**
- Your Live Kit ISO image will be created in `/tmp`.
6. **To make bootable USB, unpack the generated TAR archive (also from `/tmp`) to your USB device and run `bootinst.sh` from the boot sub-directory.**
originally posted at
Find Me a Distro
Stacker News
Distro.Moe - Find Me a Linux Distro \ stacker news
Discover a new distribution with a single click [1 comment]
I Quit! The Tsunami of Burnout Few See
By now, we all know the name of the game is narrative control: we no longer face problems directly and attempt to solve them at their source, we play-act "solutions" that leave the actual problems unrecognized, undiagnosed and unaddressed, on the idea that if cover them up long enough they'll magically go away.
The core narrative control is straightforward: 1) everything's great, and 2) if it's not great, it's going to be great. Whatever's broken is going to get fixed, AI is wunnerful, and so on.
All of these narratives are what I call Happy Stories in the Village of Happy People, a make-believe staging of plucky entrepreneurs minting fortunes, new leadership, technology making our lives better in every way, nonstop binge-worthy entertainment, and look at me, I'm in a selfie-worthy mis en scene that looks natural but was carefully staged to make me look like a winner in the winner-take-most game we're all playing, whether we're aware of it or not.
Meanwhile, off-stage in the real world, people are walking off their jobs: I quit! They're not giving notice, they're just quitting: not coming back from lunch, or resigning without notice.
We collect statistics in the Village of Happy People, but not about real life. We collect stats on GDP "growth," the number of people with jobs, corporate profits, and so on. We don't bother collecting data on why people quit, or why people burn out, or what conditions eventually break them.
Burnout isn't well-studied or understood. It didn't even have a name when I first burned out in the 1980s. It's an amorphous topic because it covers such a wide range of human conditions and experiences.
It's a topic that's implicitly avoided in the Village of Happy People, where the narrative control Happy Story is: it's your problem, not the system's problem, and here's a bunch of psycho-babble "weird tricks" to keep yourself glued together as the unrelenting pressure erodes your resilience until there's none left.
Prisoners of war learn many valuable lessons about the human condition. One is that everyone has a breaking point, everyone cracks. There are no god-like humans; everyone breaks at some point. This process isn't within our control; we can't will ourselves not to crack. We can try, but it's beyond our control. This process isn't predictable. The Strong Leader everyone reckons is unbreakable might crack first, and the milquetoast ordinary person might last the longest.
Those who haven't burned out / been broken have no way to understand the experience. They want to help, and suggest listening to soothing music, or taking a vacation to "recharge." They can't understand that to the person in the final stages of burnout, music is a distraction, and they have no more energy for a vacation than they have for work. Even planning a vacation is beyond their grasp, much less grinding through travel. They're too drained to enjoy anything that's proposed as "rejuvenating."
We're trained to tell ourselves we can do it, that sustained super-human effort is within everyone's reach, "just do it." This is the core cheerleader narrative of the Village of Happy People: we can all overcome any obstacle if we just try harder. That the end-game of trying harder is collapse is taboo.
But we're game until we too collapse. We're mystified by our insomnia, our sudden outbursts, our lapses of focus, and as the circle tightens we jettison whatever we no longer have the energy to sustain, which ironically is everything that sustained us.
We reserve whatever dregs of energy we have for work, and since work isn't sustaining us in any way other than financial, the circle tightens until there's no energy left for anything. So we quit, not because we want to per se, but because continuing is no longer an option, and quitting is a last-ditch effort at self-preservation.
Thanks to the Happy Stories endlessly repeated in the Village of Happy People, we can't believe what's happening to us. We think, this can't be happening to me, I'm resourceful, a problem-solver, a go-getter, I have will power, so why am I banging my head against a wall in frustration? Why can't I find the energy to have friends over?
All these experiences are viewed through the lens of the mental health industry which is blind to the systemic nature of stress and pressure, and so the "fixes" are medications to tamp down what's diagnosed not as burnout but as depression or anxiety, in other words, the symptoms, not the cause.
And so we wonder what's happening to us, as the experience is novel and nobody else seems to be experiencing it. Nobody seems willing to tell the truth, that it's all play-acting: that employers "really care about our employees, you're family," when the reality is we're all interchangeable cogs in the machine that focuses solely on keeping us glued together to do the work.
Why people crack and quit is largely unexplored territory. In my everyday life, three people I don't know quit suddenly. I know about it because their leaving left their workplaces in turmoil, as there are no ready replacements. One person was working two jobs to afford to live in an expensive locale, and the long commute and long hours of her main job became too much. So the other tech is burning out trying to cover her customer base.
In another case, rude / unpleasant customers might have been the last straw, along with a host of other issues. In the moment, the final trigger could be any number of things, but the real issue is the total weight of stress generated by multiple, reinforcing sources of internal and external pressure.
There's a widespread belief that people will take whatever jobs are available when the economy slumps into recession. This presumes people are still able to work. Consider this chart of disability. Few seem interested in exploring this dramatic increase. If anyone mentions it, it's attributed to the pandemic. But is that the sole causal factor?
We're experiencing stagflation, and it may well just be getting started. If history is any guide, costs can continue to rise for quite some time as the purchasing power of wages erodes and asset bubbles deflate. As noted in a previous post, depending on financial fentanyl to keep everything glued together is risky, because we can't tell if the dose is fatal until it's too late.
A significant percentage of the data presented in my posts tells a story that is taboo in the Village of Happy People: everyday life is much harder now, and getting harder. Life was much easier, less overwhelming, more stable and more prosperous in decades past. Wages went farther--a lot farther. I have documented this in dozens of posts.
My Social Security wage records go back 54 years, to 1970, the summer in high school I picked pineapple for Dole. Being a data hound, I laboriously entered the inflation rate as calculated by the Bureau of Labor Statistics (which many see as grossly understating actual inflation) to state each year's earnings in current dollars.
Of my top eight annual earnings, two were from the 1970s, two were from the 1980s, three from the 1990s and only one in the 21st century. Please note that the nominal value of my labor has increased with time / inflation; what we're measuring here is the purchasing power / value of my wages over time.
That the purchasing power of my wages in the 1970s as an apprentice carpenter exceeded almost all the rest of my decades of labor should ring alarm bells. But this too is taboo in the Village of Happy People: of course life is better now because "progress is unstoppable." But is it "progress" if our wages have lost value for 45 years? If precarity on multiple levels is now the norm? If the burdens of shadow work are pushing us over the tipping point?
This is systemic, it's not unique to me. Everyone working in the 70s earned more when measured in purchasing power rather than nominal dollars, and the prosperity of the 80s and 90s was widespread. In the 21st century, not so much: it's a winner-take-most scramble that most of us lose, while the winners get to pull the levers of the narrative control machinery to gush how everything's great, and it's going to get better.
I've burned out twice, once in my early 30s and again in my mid-60s. Overwork, insane commutes (2,400 miles each way), caregiving for an elderly parent, the 7-days-a-week pressures of running a complex business which leaks into one's home life despite every effort to silo it, and so on. I wrote a book about my experiences, Burnout, Reckoning and Renewal, in the hopes that it might help others simply knowing others were sharing their experiences.
What's taboo is to say that the source is the system we inhabit, not our personal inability to manifest god-like powers. The system works fine for the winners who twirl the dials on the narrative control machinery, and they're appalled when they suffer some mild inconvenience when the peasantry doing all the work for them break down and quit.
A tsunami of burnout and quitting, both quiet and loud, is on the horizon, but it's taboo to recognize it or mention it. That the system is broken because it breaks us is the taboo that is frantically enforced at all levels of narrative control.
That's the problem with deploying play-acting as "solutions:" play-acting doesn't actually fix the problems at the source, it simply lets the problems run to failure. The dishes at the banquet of consequences are being served cold because the staff quit: as Johnny Paycheck put it, Take This Job And Shove It.
The peasants don't control the narrative control machinery, and so we ask: cui bono, to whose benefit is the machinery working? The New Nobility, perhaps?
originally posted at 
I Quit! The Tsunami of Burnout Few See
That's the problem with deploying play-acting as "solutions:" play-acting doesn't actually fix the problems at the source, it simply lets th...
Stacker News
I Quit! The Tsunami of Burnout Few See \ stacker news
By now, we all know the name of the game is narrative control: we no longer face problems directly and attempt to solve them at their source, we pl...