• #push [[31]]
  • Un mantra:
  • Las Jaras, qué jaras?

2023-05-19

• Yesterday I submitted my final output for [[YXM830]]!

  • [[Reclaiming the stacks: how ICT workers can contribute to a transition to ecosocialism]] was the final version.
  • Enjoyed the course and pleased to have gotten final submission submitted. Learned a great deal along the way. Still lots of work needed on the idea of reclaiming the stacks.

• Reading [[Capital is Dead]] (again, didn't finish last time) and loving it. I really like [[McKenzie Wark]]'s writing style in this. I'm finding the argument about there now being an information-based [[Vectoralism]] - something even worse than capitalism - quite compelling, though I know many disagree.

• Used the borrowed orbital sander to sand down garden table and chairs that are a bit weather beaten.

• Friday, 05/19/2023 ** 11:59 Justifying you dislike, aversion, or repulsion is incredibly important. The next time you see something and dislike it, spend five minutes thinking about why... the visceral reaction is real, but it ccomes from somewhere. Find a logical explanation for the distaste, drawing the idea back to either customs you're used to, or principles humans share, or both. You can only talk about what you'd rather have when you understand what you don't want. ** 12:05 Through middle and high school, instead of bringing our calculators to school every day, most students had a calculator ROM app. Users could pirate a TI-84 ROM, run it on this calculator emulator, and have all of the functionality of the original calculator available. ** 15:22 Finally understanding more and more of 100 Rabbits' radicalization principles and why I might want to deviate from them.

• GPU programming is a proprietary mess.
• Window managers are a disorganized mess with largely overlapping APIs that have small (but significant) differences.
• SDL2 is the easiest way to get access to a device framebuffer that you can write pixels to the screen without intermediate complexity.
• SDL2 handles all of the window manager abstraction work for you, from allowing you to open windows with different settings to receiving window manager input events. These are necessary to make any sort of cross-platform software.
• Virtual machines are necessary for making software portable. C is a good idea - a good start - but expecting C compilers to work the same way on every system is a mistake.
• The best way to write cross-platform code would be to standardize a machine language across everything (impossible). The second best way to stay portable is to make a virtual machine that can execute platform-independent code, then distribute software for that machine.
• The third best way is to use the most popular existing virtual machine - the web browser. Users can't discover your work without being able to view examples of it and try it out on the clearweb.
• A fixed size window means no thinking about changes of layout when making the screen size larger or smaller. Building only for a single screen size eliminates lots of considerations and problems.
• Refusing to support modern formats, standards, and software allows you to significantly reduce code bundles and complexity.
• Interoperability - both aesthetically and logically - is beautiful. Unifying on standards is really cool.

Conclusions:

• I'm less interested in minimizing resources and more interested in maximizing creativity than they are. I want modern tools that are easily understood, free, and widely available.
• I want to support larger ecosystems like the language-server protocol, modern font families, and modern image formats so that non-technical people can use my tools in their everyday lives.
• I care just as much about making software beautiful and minimal, but I will always compromise minimality for ecosystem support.
• Supporting multiple screen sizes can be a good decision, but it's not as necessary as the modern web and mobile devices would like you to think. Use fixed screen sizes when possible to simplify tools.
• Portability requires sharing. I need to make sure not only that it's as easy as possible to download and use GUI applications as a part of a normal OS workflow, but also that it's easy to find and share those applications.
• Web app users expect to be able to try and use free tools in the browser, then download them later. Our engine will have to support a web backend in some way.
• Keeping the core of an engine incredibly minimal pays off. All of your software will run instantly everywhere.
• Abstracting away concepts besides files to share between applications is really useful. Text buffers are a great example - they can hold anything UTF-8.

Other thoughts:

• I'll eventually need to make a reactive GUI system to get this all to work right. This will require a compilation step on every platform. Hopefully I'll be able to devise some smooth incremental compilation scheme.
• Ideally someone can just use/download/update their program with a single command passed a URL. That will work for technical users. How do we make non-technical use feel just as seamless (no '!Update' banners from web browsers or silly Adobe notifications)?
• Nailing your website design and web copy is the most important tool for being seen on the internet - more important than any social media use or post. Instagram, Twitter, TikTok, etc... are secondary to a beautiful, impressive, and clear personal website.
• Diagrams and images are vital to your web work. Without them your writing is kind of meaningless. Interactive visualizations are ideal, but barring those, diagrams as pictures are great.