This feed omits posts by rms. Just 'cause.

Some will tell you that Mozilla's worst decision was to accept funding from Google, and that may have been the first domino, but I hold that implementing DRM is what doomed them, as it led to their culture of capitulation. It demonstrated that their decisions were the decisions of a company shipping products, not those of a non-profit devoted to preserving the open web.

Those are different things and are very much in conflict. They picked one. They picked the wrong one.

In light of Mozilla's recent parade of increasingly terrible decisions, there have been cries of "why doesn't someone fork it?" followed by responses of "here are 5 sketchy forks of it that get no development and that nobody uses". And inevitably following that, several people have made comments in the "Mozilla is an advertising company now" thread to the effect that it is now impossible for a non-corporate, open source project to actually implement a web browser, since a full implementation requires implementing DRM systems which you cannot implement without a license that the Content Mafia will not give you.

This is technically true. ("Technically" being the best kind of "true" in some circles.)

Blaming and shaming:

  • It used to be that to watch Netflix (and others) in an open browser required the use of a third party proprietary plugin. That doesn't work any more: now Netflix will only work in a browser that natively implements DRM.

  • That step happened because Mozilla took that license and implented DRM.

  • That happened because: "it's in the W3C spec, we didn't have a choice."

  • How did it get into the spec? Oh, it got into the spec because when the Content Mafia pressured W3C to include it, Mozilla caved. At the end of the day they said, "We approve of this and will implement it". Their mission -- their DUTY -- was to pound their shoe on the god damned table and say: "We do not approve, and will not implement if approved."

    But they went and did it just the same.

"But muh market shares!" See, now we're back to the kitten-meat deli again.

(BTW, how's that market share looking these days? Adding DRM really helped you juice those numbers, did it? Nice hockey-stick growth you got there? Good, good.)

If you were unable to watch Netflix in Mozilla out of the box, yes, that would have impacted their market share. You know what else would have happened? Some third party patch would have solved that problem.

When Netscape released the first version of the Mozilla source with no cryptography in it due to US export restrictions, it was approximately 30 minutes before someone outside the US had patched it back in. I'm not exaggerating, it happened that night. This is the sort of software activism at which the open source community excels, even if it is "technically" illegal. ("Technically", again, being the best kind of illegal in some circles.)

Mozilla had a duty to preserve the open web.

Instead they cosplayed as a startup, chasing product dreams of "growth hacking", with Google's ad money as their stand-in for a VC-funding firehose, with absolutely predictable and tragic results.

And those dreams of growth and market penetration failed catastrophically anyway.

(Except for the C-suite, who made out quite well. And Google, who got exactly what they paid for: a decade of antitrust-prosecution insurance. It was never about ad revenue. The on-paper existence of Firefox as a hypothetical competitor kept the Federal wolves at bay, and that's all Google cared about.)


Now hear me out, but What If...? browser development was in the hands of some kind of nonprofit organization?

As I have said many times:

In my humble but correct opinion, Mozilla should be doing two things and two things only:

  1. Building THE reference implementation web browser, and
  2. Being a jugular-snapping attack dog on standards committees.
  3. There is no 3.

Previously, previously, previously, previously, previously, previously, previously, previously, previously, previously.

Posted Sat Jun 22 20:04:04 2024 Tags:
When, years ago, I thought: "I wanna put bands on stage!" I might have predicted that an enormous part of my attention would end up being taken up by plumbing. What I did not predict that when the monkey paw curled, I would spend the rest of my life writing bespoke business systems and accounting software.

Anyway, dataviz questions.

A question that is of keen interest to us is always: how many people are going to show up for this event? One of the ways that I do this is by plotting ticket sales on a graph and fitting a curve to it, and seeing where the right end lands. One attempt is to just fit a polynomial to it. That makes reasonably accurate predictions when we're a week or so away from the show, but if it's a month out and there are only a few sales, the input is too little and too noisy and the output curve is nonsense.

For another attempt, I generated this graph of historical sales over the last several years, omitting obvious outliers. For each event, the X axis is percent of time that event was on sale (whether that was 3 weeks or 3 months) and the Y axis is percent of total sales. Then I averaged them all:

To "predict" from this graph, I just overlay it with this event's sales period and scale vertically until it intersects the date at which we are making the prediction (today). Usually by a week or two out the prediction is... just ok? But not great.

Here's an event that was on sale for 9 weeks. Let's say it's 3 weeks before the event (day 42), so we're predicting based only on sales prior to that day:

A problem with this technique is that sales match this curve based on the length of time that tickets are on sale, but that's not really true: no matter how long a ticket is on sale, most of the sales happen in the last few days. This particular event did half its sales in the last 4 days, and a quarter of its sales in the last 24 hours.

If this event had been on sale for twice as long, it would have sold pretty much the same number of tickets on the same days. But my historical-curve-fitting would have predicted 25% higher total sales! So this technique falls down for any event that doesn't have a "typical" length of time on sale. The hockey stick on the right doesn't get wider just because the X axis is wider.

(BTW, by "date on sale" in the above I actually mean "date of first sale".)

Anyway. How would someone who ever actually taken a statistics class do this?

Posted Fri Jun 21 03:43:12 2024 Tags:
Just a reminder that 72 years ago, Wilhelm Reich began defending Earth from an alien invasion using a battery of surface-to-air orgasmatrons, and 39 years ago, that heroism was immortalized in this song and video by Kate Bush starring Donald Sutherland. RIP.

Posted Thu Jun 20 19:28:02 2024 Tags:
This seems completely normal and cool and not troublesome in any way.

Mozilla has acquired Anonym, a [blah blah blah] raise the bar for the advertising industry [blah blah blah] while delivering effective advertising solutions. [...]

Anonym was founded with two core beliefs: [blah blah blah] and second, that digital advertising is critical for the sustainability of free content, services and experiences. [...]

As we integrate Anonym into the Mozilla family, we are excited about the possibilities this partnership brings. While Anonym will continue to serve its customer base, together, we are poised to lead the industry toward a future where privacy and effective advertising go hand in hand, supporting a free and open internet.

Anonym was founded in 2022 by former Facebook executives Brad Smallwood and Graham Mudd. The company was backed by Griffin Gaming Partners, Norwest Venture Partners, Heracles Capital as well as a number of strategic individual investors.

Now hear me out, but What If...? browser development was in the hands of some kind of nonprofit organization?

Oh wait.

Previously, previously, previously, previously, previously.

Posted Thu Jun 20 18:11:29 2024 Tags:
I was today years old when I discovered that you can stop Safari from pointlessly truncating your URLs, when there is plenty of room to show the whole thing, by removing the "floating spaces" on either side of the URL field:

This had been pissing me off for decades!

Posted Wed Jun 19 18:46:06 2024 Tags:
You may have noticed that youtubedown has been failing on just about all Youtube videos for the past week or so. I think something has changed about how you apply signatures to URLs, but I can't figure it out.

I would like someone else to figure it out, please.

In fact, I would like someone else to take over maintenance of this program. For 17 years, I have been reverse-engineering YouTube's countermeasures pretty much on my own, and I am absolutely weary of it. It brings me no joy.

It's time for someone else to get their hands dirty. Help, help.

Previously, previously.

Posted Wed Jun 19 06:43:01 2024 Tags:
WebCollage feeds random noise into image search engines to create collages, and it has been running continuously on my site since 1999. That's... a lot of image scraping!

These days it's probably not the most interesting web toy, but I'm kind of shocked that it still works. I only give it a little bit of attention maybe every six months, where I tweak URLs and regexps to track the latest obfuscated nonsense that the various search engines spit out.

Over the years of maintenance, WebCollage has given me some unwwanted insights into the "SEO" industry, almost from that vile industry's inception. When the same image keeps showing up repeatedly, it is a strong indicator that some site has managed to poison search results. Back in 1999, the most common technique was for the <meta keywords> tag to contain thousands of random words from a dictionary. Early adopters of this technique were porn and genealogy sites. How we have grown.

The very first version of WebCollage polled only Alta Vista and Yahoo! Six months later, I added Hot Bot. Google didn't show up until 2001, Lycos in 2002, LiveJournal in 2004, Flickr in 2005, Twitter in 2008, Bing and Instagram in 2013, and then Tumblr and Imgur in 2017.

In 2002, I got an actual email from a Google engineer asking me to stop searching them, because it was a significant enough portion of their traffic that it was annoying them.

Previously, previously, previously.

Posted Tue Jun 18 19:49:42 2024 Tags:

Please enjoy jwz mixtape 246.

From this mixtape: Able Machines return at DNA Lounge on Tue Aug 6; Yellacatt was here last Sunday; and [REDACTED] will be here next month, but that isn't public yet.

Posted Sat Jun 15 22:33:42 2024 Tags:
  • Poor Things (2023):
    This movie looked at the weirdest stuff Ken Russell had ever done and said "hold my beer". It's absolutely incredible. Full of relentlessly weird choices in acting, sets and especially cinematography. Why is it suddenly fish-eye! We will never know! And surprisingly filthy! How did this win Academy Awards? This movie is the kind of thing that the Academy hates.

  • The Abominable Dr. Phibes (1971):
    This movie is absolutely amazing. It had been so long since I saw it that I had forgotten it almost entirely. I remembered the murders, the mask, the hapless detectives, but what I forgot was the sets, the dancing, the fashion, the clockwork orchestra, the absolute lunacy! This is a movie made in 1972 and set in the mid-20s, so the look of it is this insane mixture of 60s high fashion and Art Nouveau. Every scene-change comes with a costume change. Every murder comes with a little dance from Phibes and Vulnavia. This movie is an absolute treasure.

  • Dr. Phibes Rises Again (1972):
    This movie is... lesser. It still has amazing sets, and costumes, and the dancing, but it also has an antagonist, and a smidge more plot. And that does not work in its favor. With the first one, you could just let the mood of it wash over you. This one leads you to ask questions like, "But how did he ship the clockwork orchestra to the pyramid?" and if you are asking questions like that, you have fallen out of the trance.

  • Lisa Frankenstein (2024):
    A goth girl and her reanimated corpse boyfriend. This is basically: "What if Edward Scissorhands was actually good?" It's set in the version of the 80s that is what people who weren't alive in the 80s think they 80s must have been like. (And even with that, I am embarrassed to admit that I didn't get the joke in the title until the next day. "Ohhhhhh....")

    In terms of set dressing and fashion, I wonder if people who lived through the 1980s feel about this movie the way that people who lived through the 1920s felt about Dr. Phibes.

  • 30 Coins (2020):
    This show is absolutely wild. There's a small town in Spain, a creepy priest, and some Satanists trying to collect the Judas McGuffins, and you think, ok, standard Catholic pea-soup fare, I know how this is all going to go. And then there are giant babies, spider monsters, mirror people, shoggoths. Every episode has a "what the fuck did I just see" moment. It's fantastic. And that's just like, the first four episodes! The S02 finale was just chef's kiss. I hope there will be a third season.

  • Giri Haji (2019):
    Japanese cop's dead brother was a mobster, and then shows up in London murdering people, so both the cops and the yakuza send him there to bring him back. Ass kicking ensues. It's mostly set in London, but about 1/3 in Japanese. I liked it a lot, despite my aversion to cop fare.

  • Death and Other Details (2024):
    Locked-room murder mystery on a cruise ship. It is fantastic, in the manner of Knives Out.

  • Parallel (2024):
    A neat little the-multiverse-sucks story where the spooky woods are a portal. Low budget but well done.

  • Extraordinary (2023):
    In a world where everyone gets a superpower at around age 18. Except it's usually a really lame, mostly useless power. This is very funny, in that very specific, cringey British TV way.

  • Ghosts (2019):
    A couple inherit a haunted house, and only one of them can see them. Extreme British Cringe. It took a couple episodes for it to grow on me, but it did.

  • Dune 2 (2024):
    Since part 1 wasn't really a movie -- it was the first two acts of a movie -- I was kind of reserving judgement on the whole thing until this came out. Part 2 is better, and as a whole, I guess it holds up pretty well. I enjoyed how they leaned in to the whole Bene Gesserit colonial thing: that the Fremen's religious beliefs had been done to them intentionally. Paul's character was certainly less flat than he was in the book. I still contend that nobody who hadn't read the books would have a god damned idea of what was going on.

  • Stopmotion (2024):
    Stop motion animators have a reputation for being complete weirdos to begin with, but when they try to work out their shit by going full Brothers Quay with roadkill... antics ensue. Anyway, this is creepy.

  • 3 Body Problem (2024):
    I tried to watch the 90 episode Chinese version and only made it to like episode three before I ran entirely out of fucks. When I heard that this version was by the Lost people I thought "Oh god no" but at least since this show only gave them eight episodes to make something of themselves, they showed some restraint. This wasn't entirely awful, but out of the gigantic cast there are only like two people to give a shit about. The Giant Cheesegrater scene was an amazing effect, but it defies any kind of sanity that it was the first tool in the box that someone would reach for.

  • Late Night with the Devil (2024):
    A 70s late-night host invites a possessed girl on for an interview. "What happens next might surprise you." This is pretty great. Even though it's mostly shot faux-documentary style, they don't go all shaky-cam.

  • Fallout (2024):
    Hyper-competent Mary-Sue has to go on a quest to find her missing dad, Kyle McGuffin. I'm led to believe that this was based on a video game. It certainly has video game logic and physics throughout. The sets are gorgeous, several of the characters are interesting, and much scenery is chewed. It bogged down in the middle and could have been shorter by 50%, but it was fun popcorn.

  • Night Shift (2024):
    Spooky goings-on at a mostly-empty motel, chock full of Checkhov's Handguns. It starts off seeming like it will be predictable but it has a good twist and a satisfying ending.

  • Rebel Moon 2, Something Something Subtitle (2024):
    I had some not-entirely-negative things to say about the first one but WOW is this a snore. While the first one at least took a tour of some goofy space-locales, this one had a 30 minute montage of harvesting wheat. Wheat. This was a major plot point. Because when you have FTL, antigravity, resurrection machines, and a Star Destroyer, apparently the Empire can't function without flying to another planet and bullying a village of literally 50 people into harvesting wheat by hand. Sure that scales. That scales.

  • Humane (2024):
    The solution to climate change is paying people to commit suicide. At the worst family dinner party, antics ensue. Between this and Antiviral, I'm starting to think that growing up in the Cronenberg household must have been pretty fucked up.

  • Godzilla Minus One (2023):
    I enjoyed this a lot; like the original, it was mostly about trauma rather than a rampaging lizard, though the lizard scenes were outstanding. My criticisms are: it could easily have been 25% shorter (the last third is mostly crying) and even though the sets, costumes and framing were excellent, every single shot was god damned teal and orange. No other colors exist in this universe. I'm told that the black-and-white edit is better, and that is utterly believable. If you haven't seen this yet, pick that version.

  • The Ministry of Ungentlemanly Warfare (2024):
    This is great. It's basically Inglorious Basterds but funnier and without Tarantino's weird tics. You wanna see a feel-good romp about some Nazis getting fucked up? Oh yeah you do. How does Alan Ritchson just keep getting larger? (Watch Blood Drive!)

  • Ghostbusters, Frozen Empire (2024):
    It's cute and fun. It suffers from having too many characters and the writers wanting each of them to get their solo. A bunch of it doesn't make a lot of sense, but the sets and the spectacle did a good job of making me not think about it too hard. (Watch I Still See You.)

  • Abigail (2024):
    This starts off as a solid heist movie, adventure party having fake names and all, and then when it pivots to some locked-house vampire shit, it really kicks off. Loved it.

  • Baghead (2024):
    Extremely solid ghost story. Reminded me a bit of the also excellent Talk To Me.

  • True Detective, Night Country (2024):
    Jodie Foster investigates some murders in Alaska, which also wants to murder you, and every single person is a piece of shit. This was pretty great -- about as good as S01. (I didn't much like, and barely remember, S02 or S03.)

  • Whiteout (2009):
    After the latest season of True Detective I was in the mood for more stories where the antagonist is the weather. In this, there's a murder in Antarctica, the night before everyone is shipping out before winter-over. I still really like this movie. There are human villains, bad people making bad decisions, but the primary villain is the environment, which vehemently wants you dead, and it is done really well. This is based on a fantastic comic by Greg Rucka and Steve Lieber, which is better, but the movie is still solid.

    Fun fact! When I was 12 or 13 I thought I might grow up to be a comic book illustrator. Problem was, I went to high school with Steve Lieber, and when I saw how good he was at it I thought, "Yeah, this is not a realistic goal, maybe I should be a computer-toucher instead."

    Billy Porter was also in our class, but fortunately I didn't have any musical theatre ambitions for him to inadvertently quash.

  • Civil War (2024):
    Not bad. I had a bad feeling about this when all the press was this sniveling, centrist, both-sides-ism, "but it's not political!" nonsense. But actually -- it's not political. It's a road-trip character study of a handful of war photographers. The war itself is just set dressing.

  • The Fall Guy (2024):
    Oh no, a stunt man has to solve a murder. Ryan Gosling Ryan Goslings all over the place. Dumb fun.

  • New Life (2023):
    The trailer gives too much away, but it opens with: girl gets infected with a weird disease, goes on the run, and now people are trying to murder her. I liked it. Solid ending.

  • Love Lies Bleeding (2024):
    Extremely trashy 80s noir. People who liked Blood Simple also liked.

  • The Primevals (2023):
    Full Moon Features are still making movies (yes, the Subspecies and Puppet Master folks) and this movie has all the quality of writing and acting that you would expect from their 80s fare, which is to say, abysmal. But! It's a mixture of live action and stop animation and I don't mean a bunch of digital stuff, or a bunch of digital stuff trying to look like stop animation, it seems to be the real deal. They were aiming for Harryhausen but landed on Rankin-Bass, but still, it's charming in its own way.

  • Wipeout 2097 Soundtrack: Noclip Documentary (2024):
    If you are a Wipeout obsessive like me, you will enjoy this brief retrospective and interview with Cold Storage.

Previously.

Posted Sat Jun 15 06:02:17 2024 Tags:
Here's another JavaScript text manipulator that I made ages ago: the DNA Lounge Infobox Generator. It is far less crazy than the last one.

When promoters and bands design flyers for their events they sometimes -- more often than you would expect -- forget some salient details, like... the date. Or the venue. Or they write dates like "5/6" leaving you to guess which month and day of the week it's happening.

So we've got a checklist / style guide, but we also have this Infobox Generator to make it simple.

The first version of this was a CGI that ran ImageMagick on the server, but at some point I rewrote it to do all the formatting client-side, using CANVAS, which is a lot easier to use. You select from the menus, things update in realtime, and then you drag the image to your desktop. It has a transparent background with optional baked-in dropshadow.

If anyone knows how to make Menu / Save to Desktop on the image in Safari give it a file name ending in .png instead of saving as "Unknown" with no extension, that would be nice. (Tested solutions only please.)

Also, any time I post about flyers, I can't help but re-post this clip:

Previously, previously, previously.

Posted Fri Jun 14 01:37:26 2024 Tags:
It's as easy as [1], [2], [3]. #bibliographies #citations #bibtex #votemanipulation #paperwriting
Posted Wed Jun 12 19:10:11 2024 Tags:

SwiftNavigation

To celebrate that RealityKit's is coming to MacOS, iOS and iPadOS and is no longer limited to VisionOS, I am releasing SwiftNavigation for RealityKit.

Last year, as I was building a game for VisionPro, I wanted the 3D characters I placed in the world to navigate the world, go from one point to another, avoid obstacles and have those 3D characters avoid each other.

Almost every game engine in the world uses the C++ library RecastNavigation library to do this - Unity, Unreal and Godot all use it.

SwiftNavigation was born: Both a Swift wrapper to the underlying C++ library which leverages extensively Swift's C++ interoperability capabilities and it directly integrates into the RealityKit entity system.

This library is magical, you create a navigation mesh from the world that you capture and then you can query it for paths to navigate from one point to another or you can create a crowd controller that will automatically move your objects.

Until I have the time to write full tutorials, your best bet is to look at the example project that uses it.

Posted Tue Jun 11 15:05:10 2024 Tags:

My grandmother used to make a recipe from an old newspaper clipping. After decades the original clipping started to crumble so she replaced it with a new clipping when the newspaper re-ran the recipe. I struggled but eventually succeeded in making a recipe which matched my childhood memories. Sadly my childhood memories were romanticized and my grandmother’s original recipe didn’t make the pancakes stay floofed after they were done cooling off, but I hope you enjoy this improved version.

These pancakes rise by water under the batter turning into steam, so to keep the pan from getting cooled off by the batter it’s important to cook them in an iron skillet which has been given time to heat all the way through.

3 eggs
70 grams flour
120 grams milk
1 gram nutmeg
1 gram mint oil
Pinch of salt
6 grams powdered sugar
3 grams Lemon juice powder
20 grams Ghee

Preheat the oven with a skillet inside to 400 degrees. Leave it in for 15 more minutes after preheating. Mix together eggs, flour, milk, nutmeg, mint oil, and salt and beat thoroughly. When the oven is heated add ghee to the pan and put it back in to melt (about 2 minutes). After it’s done melting, pour batter on top. Bake for 20 minutes. Thoroughly mix powdered sugar and lemon juice powder and put it in a dusting wand. Sift completely over top.

Thanks for reading Bram’s Thoughts! Subscribe for free to receive new posts and support my work.

Posted Sat Jun 8 20:18:43 2024 Tags:

Back in the day when presumably at least someone was young, the venerable xsetwacom tool was commonly used to configure wacom tablets devices on Xorg [1]. This tool is going dodo in Wayland because, well, a tool that is specific to an X input driver kinda stops working when said X input driver is no longer being used. Such is technology, let's go back to sheep farming.

There's nothing hugely special about xsetwacom, it's effectively identical to the xinput commandline tool except for the CLI that guides you towards the various wacom driver-specific properties and knows the right magic values to set. Like xinput, xsetwacom has one big peculiarity: it is a fire-and-forget tool and nothing is persistent - unplugging the device or logging out would vanish the current value without so much as a "poof" noise [2].

If also somewhat clashes with GNOME (or any DE, really). GNOME configuration works so that GNOME Settings (gnome-control-center) and GNOME Tweaks write the various values to the gsettings. mutter [3] picks up changes to those values and in response toggles the X driver properties (or in Wayland the libinput context). xsetwacom short-cuts that process by writing directly to the driver but properties are "last one wins" so there were plenty of use-cases over the years where changes by xsetwacom were overwritten.

Anyway, there are plenty of use-cases where xsetwacom is actually quite useful, in particular where tablet behaviour needs to be scripted, e.g. switching between pressure curves at the press of a button or key. But xsetwacom cannot work under Wayland because a) the xf86-input-wacom driver is no longer in use, b) only the compositor (i.e. mutter) has access to the libinput context (and some behaviours are now implemented in the compositor anyway) and c) we're constantly trying to think of new ways to make life worse for angry commenters on the internets. So if xsetwacom cannot work, what can we do?

Well, most configurations possible with xsetwacom are actually available in GNOME. So let's make those available to a commandline utility! And voila, I present to you gsetwacom, a commandline utility to toggle the various tablet settings under GNOME:

$ gsetwacom list-devices
devices:
- name: "HUION Huion Tablet_H641P Pen"
  usbid: "256C:0066"
- name: "Wacom Intuos Pro M Pen"
  usbid: "056A:0357"
 
$ gsetwacom tablet "056A:0357" set-left-handed true
$ gsetwacom tablet "056A:0357" set-button-action A keybinding "<Control><Alt>t"
$ gsetwacom tablet "056A:0357" map-to-monitor --connector DP-1
  

Just like xsetwacom was effectively identical to xinput but with a domain-specific CLI, gsetwacom is effectively identical to the gsettings tool but with a domain-specific CLI. gsetwacom is not intended to be a drop-in replacement for xsetwacom, the CLI is very different. That's mostly on purpose because I don't want to have to chase bug-for-bug compatibility for something that is very different after all.

I almost spent more time writing this blog post than on the implementation so it's still a bit rough. Also, (partially) due to how relocatable schemas work error checking is virtually nonexistent - if you want to configure Button 16 on your 2-button tablet device you can do that. Just don't expect 14 new buttons to magically sprout from your tablet. This could all be worked around with e.g. libwacom integration but right now I'm too lazy for that [4]

Oh, and because gsetwacom writes the gsettings configuration it is persistent, GNOME Settings will pick up those values and they'll be re-applied by mutter after unplug. And because mutter-on-Xorg still works, gsetwacom will work the same under Xorg. It'll also work under the GNOME derivatives as long as they use the same gsettings schemas and keys.

Le utilitaire est mort, vive le utilitaire!

[1] The git log claims libwacom was originally written in 2009. By me. That was a surprise...
[2] Though if you have the same speakers as I do you at least get a loud "pop" sound whenever you log in/out and the speaker gets woken up
[3] It used to be gnome-settings-daemon but with mutter now controlling the libinput context this all moved to mutter
[4] Especially because I don't want to write Python bindings for libwacom right now

Posted Thu Jun 6 06:22:00 2024 Tags:

As I’ve mentioned previously if you want eventually consistent version control, meaning whatever order you merge things together has no impact on the final result, you not only need to have a very history aware merging algorithm, you also need canonical ordering of the lines. This cleanly dodges around the biggest issue in version control, which is what should you do when one person merges AXB and AYB as AXYB and another person merges them together as AYXB and then you try to merge both of those together. None of the available options are good, so you have to keep it from ever happening in the first place. Both people need to be shown AXYB as the order of lines in the merge conflict (or the other order as long as it’s consistent) and that way if either of them decided to change it to AYXB then that was a proactive change made afterwards and is not only a winner of the later meta-merge conflict, there isn’t even a conflict at all, it merges cleanly.

This flies in the face of how UX normally works on merge conflicts, which orders the conflicting regions by whether they’re ‘local’ or ‘remote’. How to do order better is an involved subject which I’ve covered thoroughly in older posts and won’t rehash here, but conflict UX I want to talk about more. Since the order of lines and whether they should be included if everything is smashed together blindly is assumed to be handled, that creates a question of how to detect and present conflicts. What’s going to be needed is a way of marking particular lines as conflicts and figuring out what should be marked. There should be some format of special lines similar to the conflict markers people are already familiar with as a way of presenting them to users in files. That format should include a way of saying which of the two sides individual lines came from.

The general idea is to determine ‘which side each line came from’ and if two lines whose ancestry are different are ‘too close together’ then they’re both marked as being in conflict. If successive lines have the same ancestry then if one of them is in conflict it taints the others. The simplest approach is that a single line of code which is present on both sides ends regions of conflict. Arguably it should be more than one line to declare peace, or that empty or whitespace only lines shouldn’t count towards it. I’m going to assume the simplest approach for a proof of concept.

An important case is when Alice adds a line to a function and Bob deletes the entire function. Obviously that should somehow be presented as a conflict but deleted lines are crucial to it. For that reason there needs to be some way of showing deleted lines in the conflict, definitely with proper annotations around them and possibly with the individual deleted lines commented out.

To detect conflicts each line is marked as ‘peaceful’, ‘skip’, ‘Alice won’, ‘Bob won’ or ‘both won‘. Once all lines are marked then the ones which are marked skip are, well, skipped. Other lines which border lines with a different marking which is not peaceful are marked as in conflict. Finally tainting is spread to neighboring lines which have the same state. Deleted lines are only presented to the user if they’re in conflict.

What to do in each case is best presented as a laundry list, so here goes. Each case is final-Alice-Bob.

missing missing missing: skip
missing missing present: Alice
missing present missing: Bob
missing present present: both (this is an unusual case but it can happen)
present missing missing: both (similar to the previous case)
present missing present: Bob
present present missing: Alice
present present present: peaceful

That seems to handle all the edge cases properly and covers the last of the theoretical details I needed to work out.

When a user resolves a conflict and does a commit it should first throw an error if conflict markers weren’t removed, then should assume the user edited the clean merge they would have seen if each line were presented verbatim without checking for conflicts. When doing a diff between the complete weave and the user’s final file version it should probably more heavily weight lines which were present than lines which were deleted but I’m not sure what the best way of doing that is and will probably make a prototype which doesn’t have any such heuristic.

Posted Sat May 25 22:08:52 2024 Tags:

PLA is a great 3D printing material with one major flaw. It’s the stiffest of available materials, not toxic, cheap, and prints easily. The main downside of it is that it melts at an annoyingly low temperature. It would be nice to have some material which is like PLA in all characteristics but has a higher melting temperature. It turns out that such a material exists and it is… PLA.

That last statement requires some explaining. The distinction is whether PLA is annealed or not. Annealing is a process where a material is brought up to a high temperature and then very slowly cooled down, causing it to be more crystalline (or at least lower energy) at the molecular level and thus stronger/tougher/having a higher melting point. PLA the material does this very well but if you apply the process to 3d printed parts they warp because internal stresses within the parts get released. It’s like the objects are made out of frozen rubber bands which were stretched out as the filament was layed down and heating it up allows them to spring shut.

The causes of this problem are that the filament wasn’t made hot enough when it was extruded and wasn’t cooled down slowly enough afterwards. The straightforward way of fixing this would be to do exactly that: make the filament so hot it’s a liquid when it comes out, then cool everything down slowly afterwards. That would require some kind of soluble support material which is solid at those high temperatures, printing everything at 100% fill because it’s a liquid, and keeping the entire 3D printer at those high temperatures. While this approach may work it’s unlikely the printer itself would still be cheap and reliable with all that literally getting cooked while it’s running.

A more practical approach may be to invent a PLA blend which anneals better. If PLA is interleaved with another material which forms a matrix around it, maybe that other material could melt at a much higher temperature, meaning it’s still frozen at the temperature PLA needs to be heated to to get it to anneal, so doing the annealing process post-printing wouldn’t cause the item to warp. The obvious candidate for this is carbon fiber. Maybe you could make carbon fiber PLA with massively more carbon fiber than anything currently available, to the point where the melting point is dramatically increased, then print using that and anneal later by taking the parts back up to the melting point of PLA but not the melting point of the combined material. Whether carbon fiber specifically or anything in general can get PLA to behave that way I don’t know, and obviously a brass nozzle couldn’t handle that material, but maybe some experimentation could result in a new type of filament which could make very high quality parts quickly and easily.

Thanks for reading Bram’s Thoughts! Subscribe for free to receive new posts and support my work.

Posted Thu May 9 16:27:28 2024 Tags:

TLDR: Thanks to José Exposito, libwacom 2.12 will support all [1] Huion and Gaomon devices when running on a 6.10 kernel.

libwacom, now almost 13 years old, is a C library that provides a bunch of static information about graphics tablets that is not otherwise available by looking at the kernel device. Basically, it's a set of APIs in the form of libwacom_get_num_buttons and so on. This is used by various components to be more precise about initializing devices, even though libwacom itself has no effect on whether the device works. It's only a library for historical reasons [2], if I were to rewrite it today, I'd probably ship libwacom as a set of static json or XML files with a specific schema.

Here are a few examples on how this information is used: libinput uses libwacom to query information about tablet tools.The kernel event node always supports tilt but the individual tool that is currently in proximity may not. libinput can get the tool ID from the kernel, query libwacom and then initialize the tool struct correctly so the compositor and Wayland clients will get the right information. GNOME Settings uses libwacom's information to e.g. detect if a tablet is built-in or an external display (to show you the "Map to Monitor" button or not, if builtin), GNOME's mutter uses the SVGs provided by libwacom to show you an OSD where you can assign keystrokes to the buttons. All these features require that the tablet is supported by libwacom.

Huion and Gamon devices [3] were not well supported by libwacom because they re-use USB ids, i.e. different tablets from seemingly different manufacturers have the same vendor and product ID. This is understandable, the 16-bit product id only allows for 65535 different devices and if you're a company that thinks about more than just the current quarterly earnings you realise that if you release a few devices every year (let's say 5-7), you may run out of product IDs in about 10000 years. Need to think ahead! So between the 140 Huion and Gaomon devices we now have in libwacom I only counted 4 different USB ids. Nine years ago we added name matching too to work around this (i.e. the vid/pid/name combo must match) but, lo and behold, we may run out of unique strings before the heat death of the universe so device names are re-used too! [4] Since we had no other information available to userspace this meant that if you plugged in e.g. a Gaomon M106 and it was detected as S620 and given wrong button numbers, a wrong SVG, etc.

A while ago José got himself a tablet and started contributing to DIGIMEND (and upstreaming a bunch of things). At some point we realised that the kernel actually had the information we needed: the firmware version string from the tablet which conveniently gave us the tablet model too. With this kernel patch scheduled for 6.10 this is now exported as the uniq property (HID_UNIQ in the uevent) and that means it's available to userspace. After a bit of rework in libwacom we can now match on the trifecta of vid/pid/uniq or the quadrella of vid/pid/name/uniq. So hooray, for the first time we can actually detect Huion and Gaomon devices correctly.

The second thing Jose did was to extract all model names from the .deb packages Huion and Gaomon provide and auto-generate all libwacom descriptions for all supported devices. Which meant, in one pull request we added around 130 devices. Nice!

As said above, this requires the future kernel 6.10 but you can apply the patches to your current kernel if you want. If you do have one of the newly added devices, please verify the .tablet file for your device and let us know so we can remove the "this is autogenerated" warnings and fix any issues with the file. Some of the new files may now take precedence over the old hand-added ones so over time we'll likely have to merge them. But meanwhile, for a brief moment in time, things may actually work.

[1] fsvo of all but should be all current and past ones provided they were supported by Huions driver
[2] anecdote: in 2011 Jason Gerecke from Wacom and I sat down to and decided on a generic tablet handling library independent of the xf86-input-wacom driver. libwacom was supposed to be that library but it never turned into more than a static description library, libinput is now what our original libwacom idea was.
[3] and XP Pen and UCLogic but we don't yet have a fix for those at the time of writing
[4] names like "HUION PenTablet Pen"...

Posted Thu May 9 00:01:00 2024 Tags: