Notices by wizzwizz4 (wizzwizz4@fosstodon.org)

@alcinnz 3/3 surely?

@alcinnz @alilly I'd be interested to see your take on Prolog. There have been several hardware implementations of it, over the years, but I suspect you'll come up with something new.

I'd also appreciate your take on miniKanren, the other language family in https://aphyr.com/posts/354-unifying-the-technical-interview.

@alilly @alcinnz That said, if you're willing to go really eccentric, the minimum you need is a LISP model of the CPU (including the instructions you want to support), a proof system, and a basic constructive compiler. Then, if you want more optimised machine code for something high-level, you can prove the equivalence of the two algorithms (up to the extent your LISP is supposed to preserve lower-level semantics).

@alilly @alcinnz I don't think it's possible to start with a small language, not unless you're willing to drop down to "and my high-level language spits out machine code". That's cheating, to me: it significantly reduces the approachability.

A big selling point of C is that it's "portable assembly" – except it doesn't achieve that. I'd like to have something that's as powerful as assembly, without all the footguns. Where you can have sum types, and define how those map to machine semantics…

@alilly @alcinnz Personally, I'm interested in a programming language that lets me experiment with various operating system designs in an "every prototype is usable" way.

Where lvalues are first-class objects, so e.g. I can say:

rax = Rax(7);
if f() then *rax = 14;
syscall(rax, &something);

and rax remains unclobbered while the lvalue is in scope.

I would usually use this language to bootstrap up to something higher-level, although it'd be nice to be able to write applications in it, too.

@alilly Existing languages aren't suitable. You know it, I know it. If we want to do OS dev (which I do), we need something better.

(Happy to collaborate if you don't want to make a new language on your own.)

@alilly To my knowledge, FreePascal has all the same footguns as GCC C, except viral Undefined Behaviour. (The optimisation philosophy is quite different: it doesn't seem to transform code into "equivalent code" in the same way, but often produces smaller binaries despite that.)

You could write your own language, and use that to write your operating system.

@alilly If you have the money to spend, I'd recommend it. Who's going to pay those starving artists, if not less-starving artists?

@Jain @mudkip You're half-right. This model probably can be run as generative AI (by providing noise as input, and calling it repeatedly in a particular way), but this application of it isn't, so it's not properly classified as "generative AI".

But "generative AI" isn't a useful term, so I don't really care about policing it. I shall instead police the policing of it! (Because that's what we all need: meta-policing.)

@tetrislife That protocol seems really really complicated, and its documentation misrepresents HTTP. I think it needs more work before serious adoption. However, it's a good start, and the hard work (identifying the real-world requirements) seems to have been done.

@apsmith @jasongorman Do you have a reference for that? I'd be interested in reading about the mathematics, but I can't really bring myself to slog through the breathless press releases again.

@Angle @lightspill Whatever we can abstract from these in a comprehensible way (e.g. most theming, default file associations, consistent key combinations), we should. Where there are already standards (e.g. CSS <system-color>), we should support them, and ideally use them "natively" unless they're somehow wrong-headed (e.g. screen reader APIs implemented over dbus-based RPC).

It's a lot of work, but it's far from unachievable.

@Angle @lightspill We should start with one DE for each paradigm: windowed mouse, tiling keyboard, and single-tasking touchscreen. "Windowed mouse" should be based on Windows 9x (which does, of course, have keyboard combinations), "tiling keyboard" should be based on a good tiling wm (something dmenu-based like dwm or i3, but ideally with mouse support), and "single-tasking touchscreen" should be GNOME 4x-esque but actually good.

@jonny I would say that ActivityStreams's Move action is within the spirit of Cool URIs Don't Change.

However, I've just re-read the original article (https://www.w3.org/Provider/Style/URI), and… hm. This is not nuanced enough. The rest of Tim BL's 1998 style guide is outdated, wrong, or overly-simplistic, but my sentimental attachment to this particular article was preventing me from seeing its flaws.

Do you know of a better canonical reference for how URIs should work?

@vertigo Are you looking for:

https://sites.cc.gatech.edu/gvu/people/Phd/Ian/swing-doc/doc/springs_struts.html

? If so, the source code for this library is available. Per https://kidneybone.com/c2/wiki/SpringsAndStruts, anything from JDK 1.4 will do (and I expect earlier versions to have simpler code).

@vertigo Wow, that's particularly bad! I got something with the query:

springs and struts "layout engine" iOS

This query will inevitably stop working, so my results:

https://whackylabs.com/swift/layout/2022/11/27/intro-simple-layout-engine/
https://doi.org/10.1007/978-1-4302-4600-8_2
https://theswiftdev.com/ios-auto-layout-tutorial-programmatically/
https://en.wikipedia.org/wiki/Layout_engine
https://news.ycombinator.com/item?id=19025361

I also found https://limpet.net/mbrubeck/2014/08/08/toy-layout-engine-1.html, which is neat (cc @alcinnz) but completely unrelated to the topic at hand.

@jonny I don't know providers, but unsubscribe is the RFC 2369 List-Unsubscribe header. If you can get anything capable of high email volumes, where you can set headers, you should be able to do this semi-manually to bide time until you can get a good system in place.

So, having someone vaguely-technical (really, they just need impeccable BCC hygiene and the ability to set headers when forwarding emails) be the designated Mailing List Operator might suffice.

@alcinnz It's almost like it's a good programme.

@alcinnz You must really like this bit: you've quoted it before.

@alilly One potential problem with this naming scheme, versus the popular non-standard approaches, is that it loses versioning information. But we shouldn't be using filenames for that: that's why we have version control. So make sure you have a .git folder in your boot directory, and commit every time you replace the kernel.