zero-st4rs

You might be interested in this related artwork: https://pigsfly.skinnyjames.net/rescue-mission/trolley-probl... which explores the kind of paralysis you are speaking to.

Humans are not machines. The entire point of any technology (including specifications derived from consensus, such as the metric system, democracy, etc) is that it operates deterministically in the service of (as opposed to outside of) actual people with actual needs. This is what makes a tool a tool, and not a human. To me, it all sort of boils down to the shortest path between an intention and it's result. LLM generated code can massively shorten the time between A and B, but not necessarily shorten the path.

The feature that makes LLMs great and interesting is the same feature that makes them hallucinate. This is embedded in the entire idea of coherence being the byproduct of nudging weights in proximity as opposed to being constructed toward an unknown future. I thought it could be cool too, but a deterministic AI (zero temperature, frozen model, or whatever..) would _only_ really serve to be a leaky abstraction over its training sources. Which maybe says more about our access to information and desire to understand it.

I don't think there's a clear cut line (or even value in one!) between LLM output being good or not, but without recognizing that LLM output will always be riffing on prior inputs as opposed to being intentionally constructed toward an unknown future, we've probably lost the plot.

White collar workers will tend to place blame on a poor person's character before their situation. To accommodate a worldview that understands most working conditions, white collar workers would need divorce their economic standing from their sense of implicit value. (ie: I deserve 120k a year because I work really hard. Of course you do, but MOST people do.)

I assume I'll get pushback for saying this, but whatever. The fact of the matter, is that nobody seems interested in taking the risks involved with owning more than "their own private slice of problems"

> The domain of internal constraints is the domain of integrity and creativity, the problem of solving for the best case scenarios and leveraging everything we can leverage to do so

First, the essay itself is positioned as an artwork in a larger set of art releases, it's sort of also speaking to it's own mode of production.

The assertion positions creativity as dependent on constraints as opposed to being unbounded. - which I believe is quite relevant, especially to approaching art (or anything) in 2026.

The contemporary canon of abstract art is informed by movements that started in the 1800s (I'd personally position Manet in front of it) and have been subsequently constrained more and more by the need to "speak" some truth while also manufacturing a branded stylistic identity.

A brushstroke doesn't come from nowhere, it's informed by a decision. That decision is informed by a constraint. The brushstroke is evidence of the constraint, but also the decision made in the face of it. (Does it pretend the constraint doesn't exist? Does it accommodate the constraint? Does it push back and how?)

A banal example of an internal constraint would be "I made a song that was anti-capitalist. Do I put it on spotify and market it to sustain revenues, or would that muffle/negate the artistic voice of the track?" Maybe going out in the street and performing it over a boombox would be a more creative approach to that specific constraint.

The essay uses math and technical domains to describe decision points _for_ creative/ethical solutions without asserting what those solutions should be. Most creative/ethics efforts tend _away_ from these modes, and I'd argue they aren't very creative or ethical at all.

==

Does that answer your question? Sorry if it's not a great answer, I elaborate depending on what you are thinking.

Hi! I'm trying my best okay? Hokusai Pocket might currently be composed of wood and string, but one day he will be a real boy!

It also integrates some helpful libraries, like libuv for cpu intensive tasks and I'm currently working on adding networking/HTTP and builds for android (it already runs on a pinephone).

The thing I think that is cool is that you don't need to compile your apps, you can just run them with the binary.

The motivation came from building desktop applications and working with awesome but cumbersome GUI toolkits like Nuklear.

I built a graphics backend-agnostic GUI library in CRuby called Hokusai, but Hokusai uses FFI, isn't portable, and is hard to distribute. (Need a Ruby interpreter on the target)

I ported the library to MRuby, developed some build tools, and now have a portable binary for different platforms that can run a dynamic desktop application/game that is written in Ruby.

You can try it yourself by downloading the latest release and running an app like: https://github.com/skinnyjames/hokusai_demo_paint

If you notice the paint repository, there is nothing to build, just ruby scripts and assets.

The tool also has commands to build your application for different platforms as standalone binary, but I'm currently working in that space for other reasons.

There are of course constraints to using MRuby vs CRuby, but I hope I speak to how this library addresses those.

Thanks for trying to meet me halfway. I hope I can bridge the gap.

The repository is the codebase for a GUI toolkit. It runs ruby scripts that make use of a custom templating language (like html), and a super class that provides similar component technology you'd likely find in vue or react. (Hokusai::Block).

When the ruby script is run from the binary built from the codebase (hokusai-pocket), it spawns a window with your application. There are releases for x86 linux, windows, and osx - and also arm64 linux. You just write your application, and run it with `hokusai-pocket run:target=app.rb`

The hokusai-pocket binary also include a command for publishing your application as a standalone binary for different platforms, but I'm currently working on that.

So all in all, it is a gui toolkit + runner that you can download for x86 linux, windows, and osx to dynamically run desktop applications.

I mentioned cutting its teeth on a photoshop clone. Here's a screenshot: https://file.skinnyjames.net/demo.gif

8.1. Dos

Use your real name on your profile; and

8.2. Don’ts

Create a false identity on LinkedIn, misrepresent your identity, create a Member profile for anyone other than yourself (a real person), or use or attempt to use another’s account (such as sharing log-in credentials or copying cookies);

But profile pictures are here >

https://www.linkedin.com/help/linkedin/answer/a1377087/profi...

> You can use an illustration, caricature, or other artistic rendering of yourself, but your profile photo must reflect your likeness. We may remove profile photos that don’t comply with our User Agreement and Professional Community Policies, including images that consist solely of the following:

I'm pretty sure even this has been updated to accommodate all the Ghibli AI avatars that people use.

When MySpace came out, the profile was the home page for a lot of people, and the content orbited around that. Coupled with the mass movement to represent oneself faithfully online as in the real world, (maybe for banking, maybe for surveillance), I think social media sort of operates as a trap. On facebook, you are encouraged to upload your real photos of drunken night out, family vacation, or whatever IDs you in life. On LinkedIn this is mandatory, your "avatar" must mirror your physical self. I have a lot to say on this, but I think I'll just leave it at topic vs profile.

This link points to a collection of artworks made from a variety of media which generally employ some kind of constraint or deterministic system in their fabrication.

If anyone is interested in this kind of thing, I'm happy to speak to any of the choices I've made as well as my emotional state in making this collection.

Knowledge is shaped by constraints which inform intention, it doesn't "drive it."

"I want to fly, I intend to fly, I learn how to achieve this by making a plane."

not

"I have plane making knowledge therefore I want and intend to fly"

However, I totally understand that constraints often create a feedback loop where reasoning is reduced to the limitations which confine it.

My Mom has no idea that "her computer" != "windows + hp + etc", and if you were to ask her how to use a computer, she would be intellectually confined to a particular ecosystem.

I argue the same is true for capitalism/dominant culture. If you can't "see" the surface of the thing that is shaping your choices, chances are your capacity for "will" is hindered and constrained.

Going back to this.

> What's yourself without your material possessions and social connections? There is no such thing as yourself without these.

I don't think my very ability to make choices comes from owning stuff and knowing people.

perhaps a being that has the capacity for intention and will?

We shape the world through our choices, generally under the umbrella of deterministic systems. AI is non-deterministic, but instead amplifies the concerns by a few wealthy corporations / individuals.

So is AI effective at generating marketing material or propagating arguably vapid value systems in the face of ecological, cultural, and economic crisis? I'd argue yes. But effective also depends on an intention, and that's not my intention, so it's not as effective for me.

I think we need more "manual" choice, and more agency.

From the discussion here: https://news.ycombinator.com/item?id=43938309, it probably won't stay PPL for much longer. It just needs to be worked out.

Ideally, there should be an automated way builtin to the gem that packages apps.

Currently, I use a tool I wrote called Barista to package an an application with it's dependencies, (part of it was modeled after chef/omnibus). This might not be the best way though, so I'm open to ideas.

I will admit that my choice to use PPL is reactionary to the ecosystems of software development as they are now, which I'm not sure GPLv2 addresses. I personally don't really understand why all information shouldn't be free without conditions. Cooperative ethos is also voluntary, so it also isn't my intention to enforce that.

That being said, I might have to think on it for a bit. Hokusai was originally made with Crystal lang, but now uses a Ruby interpreter, so a considerable portion of any derivative source will be available regardless of using the GPL or not. Could a more permissive license prevent an end-user from re-publishing these sources?

There is also an issue with resource allocation (eg. time). The reason I don't think the GPL works well is that most individuals cannot sustain the effort to fully develop many projects that could supplant competitive ones (a necessary condition for equity imo) because they have to live, and living requires money (time).

The closest model I am able to think of is software that has very cheap licenses for the lifetime of that project (as opposed to monthly subscriptions or licenses that are absurdly expensive). Maybe sponsorships are a better answer to these questions.

All in all, these are probably concerns with how companies and people exploit each other as opposed to how software should be available. Maybe GPL2 or a more permissive license is the way to go?

And you are correct, including colorize does break GPL2, I'm surprised I missed that.

Any lawyers out there? :)

Rake tasks don't have builtins for this iirc.

Since Hokusai uses MRI, one can pull in from that ecosystem of gems.

RubyMotion also appears to support (iOS, Android, OSX) whereas Hokusai intends to support OSX, Linux, and Windows.

Implementation-wise, the framework itself seems different. Looking at the following [RubyMotion app](https://github.com/HipByte/RubyMotionSamples/tree/master/ios...), the logic is spread out over separate files and it doesn't appear to have a templating language.

On the other hand, Hokusai UI components are just a class that inherits from Hokusai::Block, and are self contained blocks that can be stitched together.

Hokusai is more like Vue Single file components in this regard. Hokusai also doesn't make a distinction between a "component" and an "app", they are all just Blocks.

Does that answer your question?

The repo itself has more examples.