Jesus. I guess we’re going to have to start figuring out how to reverse engineer our keyboards so we can install QMK on random built-in laptop keyboards and cheap Logitech membrane keyboards to repair the damage Microsoft has done to them.

This sounds like a fun project, and perhaps quite innovative! I’m excited by it and I hope it goes well!

Thanks! I’m kindof on a weird personal quest to make as many DSLs for accomplishing traditionally GUI-based, point-and-click-adventure sort of use cases as possible. Here is my previous (slightly-less-ambitious) installment in that quest.

If I were in your shoes, I’d probably choose the AGPL. It sounds to me like your library is quite innovative, and might contain some useful features that don’t exist in other similar projects?

Yeah, I’m leaning pretty strongly toward AGPL at this point. I was already leaning that way before making my post, and both aurtzy’s post (and more-so the article they linked to) and your post have clinched it. That “codecomic” thing I linked to earlier, I originally published under GPL, but just now switched it to AGPL. While I hold the copyright on the whole thing is probably the best time to do that. Heh. (Well, second-best, right after “before I published it” would have been, but at least if I change it now, I can ensure that only the very first version doesn’t have the whole Affero-specific provision.)

There is no definitive answer, since the license depends on the copyright system itself for the definition of a derived work.

That’s all fascinating. In my case, I’m writing it in Go which I believe, by default, statically links against libraries and includes other Go code on a source basis rather than via linking. But Go does have a way to do runtime-loadable code. (“Plugins” if you will.) That plugin system is only kindof half-supported, though. (It’s not supported at all on Windows in recent days.)

Anyway, a ramble of my own, but I guess it informs a bit under exactly which theories others’ code could end up being derivative and under which theories others’ code wouldn’t be derivative.

The more leverage you have (features, quality, more mindshare etc.), the more you can use that to push for copyleft.

Yeah, I’m pretty sure there’s nothing out there much like what I’m working on. So I guess the whole “if it does something unlike what anything else out there does”, definitely applies. Once it’s published and the idea that there could exist a DSL for making things like game assets is out there, someone else could implement a different design/implementation of the same basic vision from scratch (even learning a bit from the trail I’m blazing) just to avoid having any copyleft-ish sort of obligations, but of course that’s an investment that companies have declined to undertake many times, opting instead to just blatantly violate the GPL. (Look at the Vizio suit, for instance.) So that’s probably a pretty solid argument for just going AGPL rather than going for anything like LGPL or anything.

Quality: I guess remains to be seen. Lol. Mindshare: well, that rounds to zero at the moment, but a couple of folks have expressed interest.

I do expect I’ll be publishing something soon – probably in the next couple of months. Definitely an “alpha” sort of thing with much room for improvement, but I’ll probably publish it once it reaches a point of being minimally-able-to-provide-some-utility while being something I’m ok with having my name/reputation connected to.

Anyway! Great stuff. Thanks for your answer. It definitely helped!

This is exactly the kind of thing I’m looking for, thanks!

Bookmarked that shit so fuckin’ hard.

Curl.

Hey thank you! I’m glad to hear some interest in it. I’ve definitely got ideas as far as how I’d like to see it improve moving forward (some syntactic sugar, more sophisticated ways of drawing “people”/creatures/skeletons/etc, maybe vector graphics output support – no project is ever really done, you know.) I’m on another project at the moment, but if it got enough interest, I’d probably be inclined to put more work into it.

I don’t have a TTRPG campaign running right now (which is what I wrote it for), so I’m not “eating my own dog food” very much with that particular project. But I would love to do more with it. Only reason I’m not already is because I’ve got so many other projects I want to work on. Heh.

The main project I’m working on lately has been that 3D game assets DSL that I mentioned later in my post. It’s probably quite a bit more ambitious than codecomic (it’s actually Turing complete which definitely adds to the challenge), but I do see a point approaching where it’s feature-complete enough to at least publish an alpha version. It also definitely needs a lot more code comments/documentation before I publish. Probably still months away, but it feels a lot closer than it did last week. Heh.

Anyway, thanks again for the complement!

• Circular financing where all the “AI” players are paying each other making it seem like they’re worth something when they’re not (kinda like circle-jerk-style wash trading in a way.)
• The tech CEOs and government all know that AI’s failing miserably and the bailout is already happening. The government is just casting things that are a bailout as “not a bailout” to try to keep it under wraps. (The “Great Big Beautiful Bill” had measures in it specifically to bail out AI companies.) They’re also propagandaing us hoping the public will support (or at least tolerate) a much more blatant bailout in the near future.
• CoreWeave is a former crypto company that pivoted into building data centers. Many of the other AI players are financially dependent on CoreWeave. Meanwhile CoreWeave is in gar-fucking-gantuine amounts of debt that they will never be able to pay back in a trillion years. It’s very possible CoreWeave could be the first major domino to fall.

Cura’s a fantastic slicer, but kindof a terrible program. They gave up on ARM support a while ago. And their dependency situation is majorly out of control. To the point that Gentoo has literally given up on supporting it and maintaining a working package.

Because fuck you, that’s why.

• Microsoft

Saved you a click.

Here’s my GitLab. None of it’s “active” really. I’m the only contributor to most things I have on GitLab. At least some of the things there, if they started getting attention and interest, I might very likely make them active. But for now, they’re just out there and may or may not receive further updates. Though I’m working on other projects I specifically intend to publish as FOSS in the future.

• Simple-CSS-Shrinker was made for a web-based game I wrote back in the day. I ought to dust that game off and publish it.
• JeSter, the JS tester. A really simple JS unit testing framework that runs in a browser and doesn’t require Node or V8 or anything. Made in service to the same game I mentioned in the previous item.
• pystocking was basically in service of hydrogen_proxy
• hydrogen_proxy is a “scriptable HTTP proxy” written in Python. Definitely intended for privacy kind of applications. But it’s kinda slow. I have in the back of my mind to rewrite it in Go, but it’s not high on my priority list. (I’m honestly mulling the idea of quitting the use of browsers all together if I can wrangle a way to do that that doesn’t involve switching to a bunch of proprietary software. The main browsers are bullshit these days.)
• GoVTT was written because I wanted to play a TTRPG with friends remotely. It’s a web-based virtual tabletop application that you can self-host. I may some day offer hosting for it. (Like, if you want to use it but don’t want to be bothered to go through the hassle of hosting it yourself, maybe I’ll offer to host it for a small fee.) No guarantees, though, except that it’ll always be FOSS and it’ll always be an option to self-host.
• codecomic is a domain-specific language for making simple webcomics or story boards. I made it because I wanted to be able to include webcomics/story boards in my game mastering notes, which are managed with a system that I should also publish as FOSS.

My main side-projects right now that I haven’t published yet are:

• A domain-specific language for building 3d game assets. Roughly speaking, FreeCAD is to OpenSCAD as Blender is to what I’m currently working on building. (It’s in the early stages right now. I intend for it to be able to do modeling, rigging, animations, textures, normals, etc. All in the DSL’s syntax. I’m making progress, but of course that project is ridiculously ambitious. We’ll see where it is in a year.)
• A framework for rapidly prototyping 3d-printable mechanical keyboards. (Also pretty ridiculously ambitious.) The image below is a sneak peak at the first keyboard I’m intending to build with it. Some day.

Mod here.

This post got reported three times by three different individuals.

It’s 100% antithetical to the point of this whole community to post AI-generated images. Except probably to make fun of it, show good examples of it failing miserably, etc. Which isn’t sufficiently the case here. And I kinda think this was posted in a way that kindof comes off as dickish. So:

• Imma remove the post.
• I think maybe it’s a little harsh to ban the poster.
• So we’ll consider this a “first offense.”
• And maybe don’t do it again, m’kay?

Communication with others might be limited without proprietary messenger apps. It could be argued whether Signal counts as proprietary or not, but that’s probably the only option alongside with SMS.

Well, I use Lemmy and lurk Mastadon, but I don’t use Facebook or anything else like that. I use Google Chat on my computer. But honestly not having things that incessantly ding at me in my pocket is as much a feature as a limitation.

Camera quality likely suffers a lot, without proprietary camera drivers.

I did say “proprietary apps”. I’m sure I’m running some proprietary drivers and device firmwares and such. My camera quality is definitely dog shit, though.

Online banking is pretty much impossible without proprietary apps, since (at least here in Europe) every bank I know requires you to use their app for 2FA.

I haven’t had issues doing online banking on a desktop/laptop(/Raspberry Pi) with a browser. My bank’s 2FA just requires access to email. (So far.) I’m in the U.S., though.

Games will be severely limited, since there’s not a lot of non-proprietary apps.

Sure. But there are decent FOSS games like Shattered Pixel Dungeon and Mindustry. Plus I use Lemuroid (emulator suite) a fair amount.

Navigation will be severely limited

Not sure what you mean by this. Like, GPS? Yeah, I don’t use that.

In many cities public transport requires you to use their app for tickets

Yeah, no idea. I haven’t used public transit to speak of.

Also, I don’t use Android Auto. Or my work’s 2FA provider’s proprietary app, but I have a YubiKey for that. I don’t have any cloud backup to Google Drive or anything. Yeah, you’re not wrong that there’s a lot you can’t do on a phone under the restrictions I’ve placed on my phone, but I’d rather deal with those things than the enshittification I’d get with proprietary apps.

Yet another reason not to watch slop.

Everything you’re saying is good and valid points. And yes, the future may be bleak for Linux like the present is for Android.

But at the same time, I’m tapping out this very comment on a rooted phone with an unlockable bootloader without any of the Google apps and in fact running zero proprietary apps.

I think the option to use Linux the unenshittified way in which it was always intended to be used will be there for the foreseeable future the way it, quite frankly, still is for Android despite Google’s best efforts at killing open mobile computing.

So, I’m not a recent convert to Linux. I’ve been using it pretty much exclusively for over 20 years now. And almost entirely Gentoo and Arch.

And I’ll tell you… the Gentoo community is hard core. The sort of hard core that will not tolerate any enshittification. They’ll make sure Gentoo stays pure.

And I’m not just talking about “free from corporate influence”. If Gentoo announced that moving forward, only SystemD would be supported as an init system (and I don’t think that’s likely any time soon), a big part of the community would fork Gentoo and declare they could take OpenRC (or runit or whatever) away when they could pry it from their cold dead hands.

No matter what enshittified Linux distros come to exist in the future, that lifeline of purists will always provide a way to buck enshittification. And that’s a lifeline that the Windows and Mac ecosystems don’t have.

So, while I have little doubt that enshittified Linux distros will exist (indeed already do exist – after all what is Android but enshittified Linux?), I think opting out of said enshittification will continue to be an option for the foreseeable future.

Two caveats:

• I do think the likelihood is that the opting-out-of-enshittification option will largely skew toward a more technical/hacker/power-user sort of user base.
• Some things that aren’t exactly “Linux” (or within the Linux ecosystem) may well enshittify in ways that negatively impact Linux users. For instance, I’d imagine web standards will get more and more captured by corporate interests. WEI will probably return as a web standard. That sort of thing. And while that’s not so much about Linux, it will affect Linux users.

Java, Postgres mostly but also LDAP and random in-house-written RESTful services, almost 20 years.

• The objects we store in the Postgres database are very “hierarchical” in nature, with one top-level object and lots of child/grandchild/great-grandchild objects. (We asked for a Mongo database but the infra team at the time said "make do with Postgres.)
• As I mentioned, some of that hierarchy is in LDAP or RESTful services, not in Postgres, so we needed something capable of dealing with multiple storage backends that would stitch the objects together as necessary. So the “ORM” needed to have backends for multiple backend systems.
• We knew clients would need a vast number of different queries. So we made a RESTful endpoint that gave the full power of the ORM to (authorized) clients. If they needed different data, we’d be like “change your query like this” and they didn’t have to wait on us.
• Early in the project, we consciously designed an extensible JSON representation of our hierarchical objects. That is what’s returned from the aforementioned RESTful endpoint.
• However, we also created a “shortcuts” system to allow us to “balance” how much of the logic lived on the server vs in the client. (It can mix and match. Like “apply this shortcut, but also filter this way and paginate” or whatever.)
• We made the API of the ORM such that it could both be used to query from the database/LDAP/RESTful systems, or be used as a client SDK for the aforementioned RESTful query endpoint that the application exposed.
• It’s both “more than an ORM” (querying from non-database sort of backends) and not fully an ORM (read only, doesn’t handle schema evolution.) But it’s fair to say it’s more “an ORM” than “not an ORM”.
• The implementation of the Postgres backend part of it is heavily inspired by Django’s ORM.

We couldn’t have pressed Hibernate into this use case. It doesn’t really deal with hierarchical data and sure as hell doesn’t know how to query from LDAP. I don’t know that anything existed at the time (nor am I sure anything exists now) that would fulfill our use case.

And the alternative to what we built was a massive, unmaintainable DAO with ridiculous numbers of individual queries in it that would have to be modified or added to endlessly every time someone needed to filter a bit differently or whatever.

This was a developed-in-house e-commerce web application at a major e-retailer. So fortunately that monstrosity of a cookie-handling mess was only ever used by one company.

You know what, though? Talking about this reminds me of another story about the same e-commerce application.

After a customer placed an order on this e-commerce site, the company’s fraud department had to evaluate the order to make sure it wasn’t fraudulently placed. (As in, with a credit card not owned or authorized for use by the purchaser.) Once that was done, the order had to be communicated to a worker at the warehouse so they could pack the right items into a box, put on a shipping label, and set the box aside to be picked up by the UPS truck which would come once a day near the end of the day.

The application used by the fraud department and the application that displayed new orders to warehouse workers was one and the same application. Whether a user had fraud-evaluating powers or pack-items-in-boxes powers just depended on what permissions their particular user had. (That may have been decided by LDAP groups. I don’t remember for sure.)

Meanwhile, the e-commerce site offered gift cards for sale online. The gift card would be shipped to the customer. And there was a box where you could write a message associated with the gift card. So, for instance, someone could buy a gift card to be sent to their nephew’s address or whatever and include a little note like “Happy Birthday. Don’t spend it all at once.” or whatever. And the fraud/pick-and-pack application would display all details of the order including any messages associated with the gift cards.

Well, I found a stored cross-site scripting vulnerability where if you put <script>...</script> tags with some JavaScript in the gift card message box and completed the order, the JavaScript would execute any time someone viewed the details page for the order in the fraud/pick-and-pack application. And of course, the JavaScript could do within that application just about anything the user could do with their given permissions.

The main danger was that a malicious actor with sufficient knowledge of how our fraud application worked could place an order fraudulently with someone else’s credit card and include in the order a gift card with a malicious JavaScript payload in the message box, and then that malicious JavaScript could automatically mark the order “a-ok, no fraud here” when a fraud department worker loaded the order details page, letting the order be fulfilled without any actual fraud review.

The fix was pretty simple. Just stick a <c:out>...</c:out> in the appropriate place in the fraud/pick-and-pack application code. But it was an interesting example of a vulnerability in a not-customer-facing application that could none-the-less be exploited by any public customer/user without any particular special access.

If you’re interested in one more interesting story about the same e-commerce application, see this comment I made a while ago.

Never roll your own ORM

I’ve done this. Probably 10 years ago. Even today, I maintain the same application that has the ORM in it that I designed. If I could go back in time and do something else, I’d do the same thing again. Honest to god. For my use case, I feel it was warranted. It was risky, but it worked out surprisingly well.

Java webapp. Customer facing. E-commerce application, so in PCI scope and dealt with credit card info and such.

There was one specific cookie that stored some site-wide preference for the customer. (Why not just put that preference in the database associated with the user? Because that would make too much sense is why.)

But the way they encoded the data to go into the cookie? Take the data, use the Java serialization framework (which is like Python’s “Pickle” or Go’s “Gob”) to turn that into a string. But that string has binary data in it and raw binary data is kindof weird to put in a cookie, so you base64 encode the result. (The base64 encoding was the only sane step in the whole process.) Then you do the reverse when you receive the cookie back from the browser. (And no, there was no signature check or anything.)

The thing about the Java serialization framework, though is that decoding back into Java objects runs arbitrary object constructors and such. As in, arbitrary code execution. And there’s no checking in the deserialization part of the Java serialization framework until your code tries to cast the object to whatever type you’re expecting. And by that point, the arbitrary code execution has already happened. In short, this left a gaping vulnerability that could easily have been used to extremely ill effect, like a payment information breach or some such.

So all a malicious user had to do to run arbitrary code on our application server was serialize something, base64 encode it, and then send it to our servers as a cookie value. (Insert nail biting here.)

When we found out that there was a severe vulnerability, I got the task of closing the hole. But the existing cookies had to continue to be honored. The boss wasn’t ok with just not honoring the old cookies and developing a new cookie format that didn’t involve the Java serialization framework.

So I went and learned enough about the internal workings of how the Java serialization framework turned a Java value into a binary blob to write custom code that worked for only the subset of the Java serialization format that we absolutely needed for this use case and no more. And my custom code did not allow for arbitrary code execution. It was weird and gross and I made sure to leave a great big comment talking about why we’d do such a thing. But it closed the vulnerability while still honoring all the existing cookies, making it so that customers didn’t lose the preference they’d set. I was proud of it, even though it was weird and gross.

The value that was serialized to put into the cookie? A single Java int. Not a big POJO of any sort. Just a single solitary integer. They could just as well have “serialized” it using base-10 rather than using the Java serialization framework plus base64.

And every day a Butlerian Jihad gets a little more tempting.