@alcinnz@floss.social
@alcinnz@floss.social avatar

alcinnz

@alcinnz@floss.social

A browser developer posting mostly about how free software projects work, and occasionally about climate change.

Though I do enjoy german board games given an opponent.

Pronouns: he/him

This profile is from a federated server and may be incomplete. Browse more on the original instance.

baldur, to random
@baldur@toot.cafe avatar

We really don’t make enough of the fact that you don’t need JS to make a nice website. Just HTML and CSS

And, whatever most programmers say about them, HTML and CSS are absolutely much more accessible to learn than JS ever has been or will be

alcinnz,
@alcinnz@floss.social avatar

@baldur Its worth emphasizing: These skills don't goes out-of-date! Browserdevs go out of our way to ensure the pages you've written yesterdecade still work!

New optional features have been added, & best practices have solidified since the 1990s... But still!

Having to periodically rewrite outdated code is something webdevs bring upon themselves! Having to keep ontop of the latest frameworks is something webdevs bring upon themselves!

alcinnz, to random
@alcinnz@floss.social avatar

Yesterday I discussed collaboratively editing text, but there's other things you might want to edit!

Implementation notes: I'd keep the data in RAM in its sorted & compressed form, only decompressing it transiently for processing & modifying. Zipping from columnar format into "edit" rows would be most involved step.

For instance we'd want to edit not only individual files but whole directories of them! And the attributes attached to each of its files!

1/?

alcinnz,
@alcinnz@floss.social avatar

This editor framework would use CRDTs to implement features I'd say should be tablestakes like infinite undo, autosave, collaboration, & composing these editors together! Whilst simplifying the data the editor itself needs to output.

I'll hold off on describing an XML CRDT until Ink & Switch has finished writing up what they've just figured out, for me to summarize as part of this hypothetical!

5/5 Fin! Tomorrow: Diffing!

alcinnz,
@alcinnz@floss.social avatar

The catch with building new CRDTs upon these primitives is you need to deal with changes to this "schema", so we'd store any breaking changes in the CRDT. Adding a "Cambrian" wrapper around our AutoMerge implementation which evaluates the appropriate breaking schema changes forwards or backwards. Pretending to the caller like the document's in the version it expects.

Furthermore I'd probably implement a framework for implementing editors (could include the text editor!) upon CRDTs.

4/4.5!

alcinnz,
@alcinnz@floss.social avatar

To implement such a "mapping" CRDT we can define an operation which sets the value at a given key to a given value, possibly to a "tombstone" value to indicate deletions. The problem comes when 2 peers attempt to set the same key to different values!

If we track our understanding of the latest edits our peers are aware of (a "lampart timestamp"), storing that in our edits' metadata, we can establish a causal ordering to these edits. When that fails we can compare peer IDs.

2/?

alcinnz,
@alcinnz@floss.social avatar

This causal sort is also vital for ordering text insertions!

Talking about text... Lists would be implemented basically the same way but with greater freedom regarding which data you can store in each node.

We may want to incorporate counters, by summing all the nudges up/down collaborators have made.

And once we have collections we'd want to store numbers, constant strings, booleans, etc in them. Combine these datatypes and we should be able to define most other CRDTs you might want.

3/4!

alcinnz, to random
@alcinnz@floss.social avatar

Code isn't the only thing which would be included in an the OS for our hardware-Internet Communicator! It'll need images, fonts, audio, voices, etc to communicate with you! Can we self-host much of this development too?

Up to a few thousand pixels, we could have a UI for setting the colour at any given pixel of an image (stored in Arithmetic Core) displayed onscreen. Probably worth sacrificing colour-depth for resolution. Include flood-fill!

1/3?

alcinnz,
@alcinnz@floss.social avatar

As for auditory fonts... I've stated that I'd include a joystick in that form-factor. We could use it to select a parameter (in the Arithmetic Core) to nudge up & down as the voice reads out some text.

Or we could ship eSpeak's, since we'd be shipping their pronunciation rules! These could be edited as text.

For further creative tools... Maybe another metathread? This should be enough to self-host development of the OS.

5/5 Fin! Tomorrow: Collaborative editing!

alcinnz, to random
@alcinnz@floss.social avatar

Tangentially to current events...

Who's your favorite AI from fiction?

I say HERA (Michaela Swee) from Wolf359 in a heartbeat! You?

Go as obscure or mainstream as you want...

alcinnz, to random
@alcinnz@floss.social avatar

Once again wishing the hypothetical device I've long been describing was real!

An OS & hardware focused specifically on the task of communicating with diverse people! Using existing protocols. Barely any apps!

Just today I introduced an editor framework to it so basically every editor has infinite undo, collaboration, & composability! (I wasn't responding to anything, just how the scheduling worked out...)

This a bit more "from scratch" than I'm capable of though...

alcinnz, to random
@alcinnz@floss.social avatar

I've described enough tooling to make it easy to individually implement software for our string-centric hardware on the device, but building an entire browser & OS as a solo-endeavour is inconceivable... So what tooling do we need to collaborate on it!

In just the past decade Computer Science brought us the concept of CRDTs! Which represents your document as a series of edits, which combine such that no matter in which order these edits you recieved we get the same result!

1/?

alcinnz, (edited ) to random
@alcinnz@floss.social avatar

To ensure this order independence, we must never incur a merge conflict! Instead we'd apply arbitrary yet deterministic priority based on peer IDs. With this peers can merge as frequently or infrequently as they like! Maybe we'd integrate this collaborative editing into the SRTP/XMPP videocalls I've established?

Our established text editor already logs a sequence of editing operations, which we can reformat into a text-CRDT by adding some provenance metadata.

2/3 for today!

alcinnz,
@alcinnz@floss.social avatar

To compress a CRDT's provenance metadata away to practically nothing (following Ink & Switch's AutoMerge's lead, ideally we'd achieve compatibility with it!) arranging the data into columnar form reveals plenty of opportunities! Storing all values in one field across a bunch of edits, as opposed to storing an array of edits.

Depending on what works best for each column we could use run-length, diff, codebook, or Deflate compression. With variable-lengthed ints.

4/4.5 for today!!!

alcinnz,
@alcinnz@floss.social avatar

Now that I've established the basics, we need to address performance issues!

First while writing could be as trivial as appending the edits, that would incur heavy overhead in reading the document in the correct order. However if we keep the document sorted in the correct order then writing to it will remain very efficient (akin to editing an ordinary plaintext file) whilst reading would become trivial!

Second we'd be storing a significant amount of data per byte of text!

3/4 for today!!

alcinnz, (edited )
@alcinnz@floss.social avatar

Stretching a bit beyond plaintext editing I've stated that I'd have devs highlight string literals (serialized in plaintext by surrounding 0 bytes) to denote them. However I'd represent them differently in a CRDT to ensure they get merged correctly. Designed a good CRDT is as much a UX exercise as it is a datamodelling one.

Instead I'd dangle begin/end "annotations" off the insert-character edits for toggling string literals on & off.

5/5 Fin for today! Tomorrow: Other CRDTs!

alcinnz, to random
@alcinnz@floss.social avatar

Workshop in Barcelona: How to Build a Low-tech Website - Low Tech Magazine:
https://solar.lowtechmagazine.com/2024/05/workshop-in-barcelona-how-to-build-a-low-tech-website/

alcinnz, to random
@alcinnz@floss.social avatar

Continuing my study of ELF Utils' commandline tools...

After initialization both I/O & internationalization as well as parsing commandline flags ar configures LibELF to a specified format version, parses/validates the commandline flags some more ensuring additional args remain, pops the archive name as a commandline arg, & branches over the subcommand specified by those flags.

This may output some help text via LibArgP. Or it may...

1/5? for today

alcinnz,
@alcinnz@floss.social avatar

In iterating over sections elfcmp has a bit of logic to avoid being thrown off by relocations. With a fallback branch utilizing hashmaps.

5.1/5.1 Fin for today! Will continue tomorrow!

alcinnz,
@alcinnz@floss.social avatar

After parsing commandline flags & configuring supported ELF version elfclassify iterates over remaining args then maybe stdin lines. For each it carefully opens the ELF file, retrieves ELF kind or E/P/S headers to retrieve various properties with optional logging, performs a bunch of checks on those properties possibly outputting results, & aggregates to output as text or exit code.

After initializing internationalization & parsing commandline flags ensuring 2 args remain elfcmp ...

4/5?

alcinnz,
@alcinnz@floss.social avatar

Primarily ar performs "extractions" ("list" & "print" are variations), involving opening the archive & populating a hashmap, fstat()s the file, iterates over ELF entries, possibly atomically overwrites the file with extracted symbol table, & cleans up. For each entry it handles filepaths specially, extracts it into a new ELF symboltable, and/or checks for presence in the hashmap, & possibly formats human output with lots of options.

Has a small supporting arlib support library.

3/5?

alcinnz,
@alcinnz@floss.social avatar

For Insert operations ar opens the ELF file, initializes some memory including a symboltable, for oper_qappend operations populates a hashmap ( LibC's search.h one), iterates over the ELF file, followed by extensive validation & cleaning up! For each ELF header (skipping filepaths for performance's sake) initializes a new archive entry for it, considers whether its present in the hashmap, & prepends the entry into a linkedlist.

Deletion works similarly (unconditional hashmap).

2/5?

alcinnz,
@alcinnz@floss.social avatar

... elfcmp configures supported ELF version, carefully opens the 2 given ELF files, retrieves their E headers checking equality on it, retrieves S header numbers to compare if they're equal, then P headers, S header index, various properties of all non-empty sections branching upon each's type, & the count of those sections. After which it gather E & P header properties, allocates regions possibly populating/sorting it, iterates over all P headers to compare them, & cleans up.

5/5.5!

alcinnz, to random
@alcinnz@floss.social avatar

Seeing all the encouragement to try "Linux" & the common pushbacks against it...

If you insist your existing apps should run on "Linux"... I'm impressed by how imperfectly well we've achieved this! Its significantly easier said then done.

To me its very much akin to saying "Don't blame people for driving when our infrastructure is built for cars". There too I'd say we shouldn't be driving.

alcinnz, to random
@alcinnz@floss.social avatar

ELF files can be queried from the commandline, so I'm starting studying thse tools!

After init'ing i18n & parsing commandline flags addr2line parses addresses from stdin or remaining commandline args. For each (if valid) it might parse trailing text, iterates over DWARF modules list is available to find the specified one, iterates over the module's ELF SCN headers to build a relocations table to locate given address & offset it. With possible postprocessing based on additional parsing.

1/?

alcinnz,
@alcinnz@floss.social avatar

Otherwise with some validation it binary searches the address in a DWARF lookuptable to retrieve the containing module, checks additional lookuptables including some tree traversals to find & output which function & sourcefile the address is in to output, similar for the symbol name & type amongst other things to display as the reader desires.

addr2line leans heavily on the DWARF format to supply these details! Which is is implemented as separate libraries in the same repo.

2/2 Fin today!

janriemer, (edited ) to microsoft

So here's the thing with 's new feature:
It's not about Microsoft now suddenly spying on you. They can probably already do that if they want in a much easier way without you knowing.

So please be more realistic!

The far more severe concern in the age of work is when person A shares their screen and person B having Recall enabled, thereby "recalling" the other person's screen without person A knowing.

So it is a privacy concern between people!

alcinnz,
@alcinnz@floss.social avatar

@faassen @janriemer Opt out, and only available on a specific laptop.

Terrible (yet, for Microsoft today, inevitable) idea, but the sky hasn't fallen just yet.

Now just hoping this AI bubble pops before Recall's shipped on more machines...

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • JUstTest
  • kavyap
  • DreamBathrooms
  • thenastyranch
  • magazineikmin
  • tacticalgear
  • khanakhh
  • Youngstown
  • mdbf
  • slotface
  • rosin
  • everett
  • ngwrru68w68
  • Durango
  • megavids
  • InstantRegret
  • cubers
  • GTA5RPClips
  • cisconetworking
  • ethstaker
  • osvaldo12
  • modclub
  • normalnudes
  • provamag3
  • tester
  • anitta
  • Leos
  • lostlight
  • All magazines
    •