2021-01-04

• [[petru]]
  • [[permaculture]]
• [[gamification]]
• [[oliver-sauter]]
  • [[memex]]
  • [[worldbrain]]
• [[s5bug]]
• [[flanbook]]
  • [[worldbrain]] cited yearly value of a [[facebook]] user at 250 USD.
  • [[conaw]] objected: https://twitter.com/Conaw/status/1346061184542199809 pull
  • Closer to 7.5 USD it seems: https://twitter.com/Conaw/status/1346065811497074691 pull
  • Matches https://twitter.com/flancian/status/1335550881933234176 pull
• [[meditations]]
• [[central mid levels escalator]]
• [[aprender de grandes]]
• [[beepb00p]] [[exobrain]]
• [[17:40]] https://twitter.com/flancian/status/1346134251700412423 pull
• [[browser extension]]
• [[pulling]]
• [[dendron]]
• [[solarpunk]]
• [[distdns]]
• [[marko]]
• [[feature requests]]

• TIL you can use dashes for bullets, I've been using asterisks.
• Pushed the [[agora]] browser extension to public repo
  • https://gitlab.com/veracantcode/[[[[agora]]]]-ext
• Tempted to move my private notes into another system, I'm kinda tired of managing two repos. Maybe obsidian can do that bit for me
  • GitJournal only allows me one repo turns out
• Thinking about if I want to start using a feed reader or if fedi is enough
• TIL ¤ is unicode for "generic currency symbol"

• Woke up later than I was meaning to.

• I wish there was a better [[roam-like]] for mobile. I'm using [[GitJournal]] and it's a little too limited.

• My msg on [[fedi]] got a bunch of likes

  • https://freethinkers.lgbt/notice/A2qsRhPmh5lGsDvTNo pull

• A bunch of intellectual types started following me on [[twitter]] recently

• Been talking to my friend Grace about [[dmt]] and the nature of reality. We got stoned on her [[volcano]] the other night and listened to [[Terrance McKenna]] talks on YouTube

• TIL [[git]] comes with examples for [[git hooks]] in .git/hooks for every new repo you initialize

• It doesn't look like [[agora]] currently supports triple-tick format, I'm not sure the proper name for it

• Started using [[hypothes.is]] to comment on nodes in the [[agora]], I'm mostly just writing comments on flancians dailys

• Was just checking out https://beepb00p.xyz/blog-graph.html interesting to see blog as a graph very [[roam-like]]

• checking out [[dendron]] It's a [[vscode]] extension like [[foam]]

  • An actual dendron is so simple in its structure yet so complex in its function. I love that
  • https://upload.wikimedia.org/wikipedia/commons/thumb/b/bc/Neuron_Hand-tuned.svg/2880px-Neuron_Hand-tuned.svg.png pull

• reading about [[ditherpunk]]

  • #go-link https://surma.dev/things/ditherpunk/

• reading about [[ontic structural realism]]

• The [[daily note]] idea is interesting because the bounds of the "note entity" are not set by the content of the note but instead by an external celestial cycle, planets orbiting stars is literally what determines the start and end of my files. That's pretty nuts

• Talking to my friend about some of the frustrations of both [[matrix]] and [[xmpp]]

  • thinking of looking into [[tox]]
  • found https://darkcrystal.pw/
    • being implemented in [[briar]] which seems like a cool app but I don't know anyone using it
    • also looks to be plugged into [[ssb]]
      • Might check out again since it seems like they added some stuff?
  • found [[arbor.chat]]
    • Arbor is an open-source chat collaboration system that thinks a little differently about conversations. Arbor captures more of the context of messages than traditional chat, allowing you and your peers to communicate more clearly with less effort.
    • it looks like pretty early days but still interesting

• turns out the [[matrix]] homeserver was just needing to be restarted. software as a service is so finicky

• found [[simplecss]]

• my friend [[shae]] showed me a video about geometry in higher dimensions

  • https://www.youtube.com/watch?v=dr2sIoD7eeU&feature=share

16:00 various thoughts

what's wrong with posix io

src

• stateful: file descriptors must always be opened before reading or writing them, but this is all tracked internal to the kernel rather than externally; this measn that things can't be done asynchronously

• the posix io model causes the cost of opening a file to scale linearly with the number of requests in userland requesting the opening, even on parallel file systems!

• prescribing metadata doesn't seem all that bad… their point is that files are all kept track of independently but still must maintain the same standards. this cannot adapt to additional metadata information we want to store

  • isn't it fine to just use extra files to denote additional specs? you can use the format of the file to carry that additional information, or manage it in other files as metadata. perhaps another system may want to track extra information… in this case, the separation is not quite ideal, but this does not seem like a significant issue

• semantics: after a write, each read returns the data specified by the previous write until the next write. this means that a write is required to block execution until a read call will produce the result from that write, which is grossly inneficient for async systems - but it provides strong guarantees to those systems, and without this guarantee you'd have to check back to see if the file was updated when monitoring files

  reduces consistency to a single node relaxes stateful requirements of parallel data

  i don't think this article was quite meant for my work - in my world, the POSIX guarantees provided are better than alternatives. they're standards that provide guarantees I do think that certain technologies - synchronous requirements for linting, for example - that I use could be done asynchronously more effectively, but the real solution here is not to serialize out to files at all. programming shouldn't be about the file, it should be about the program!

partial rebuttal of the previous by robb, a plan9 author

src

• microkernels may not be the way to go for consumer software; plan9's kernel is much smaller than the linux kernel or any distributed system. [perhaps a monolithic kernel isn't the best for abstraction, but it offers much more compact functionality and better performance]
• unix as an application program? seems like an emulation layer that's way too difficult to approach
• enabling RPC but leaving it to the user to implement is silly and terrible. having to implement RPC standards for every userland program ruins the consistency of the system and any power necessary to maintain it
• async is not the answer to synchronous inneficiencies. they solve different problems!
• new languages are needed – they say no, but 29 years later i think the answer is an obvious yes – it's the lack of programming language development and higher level features, particularly in systems programming, that has hurt the user of such programs. languages like rust have carried a lot of the systems programming development, though its fixation with the imperfect LLVM
• distributed shared memory diss - i kind of agree
• if you have a good process model, you can ignore all of these process/thread distinctions and substantially simplify the machine. having both is a substantial flaw.

the reddit thread about rewriting unix-like

src

• the user system was designed to protect the system from users rather than protecting users from malicious software, as is more often the case today. there are mitigations - 'hacks' like running each program 'in a container' with an isolated file system and new user, but this is a stopgap measure. proper single user environments should see real implementations; we don't share computers or systems as much as someone computing before the 80s would anticipate
• cool video from leonard pottering – making the user's data independent from the operating system means that you don't have to worry about reinstalling over it.
• config files need better and improved standards
• a standard way of parsing and returning command line inputs! if you standardize that in the kernel, then user programs trivially have to support identical interfaces! [there isn't that much space for creativity on the command line anyways…]
• shifting responsibility to things the user can't modify to guarantee consistency is excellent when done right - that is, when it's clear that there is a solution that will be liked or at least generally accepted. see the amigaos docs and command line standards document
• look into the selinux/apparmor permissions systems, just like what's implemented in android. these properly 'fix' the mermissions we have in mainline linux systems

cool things about languages:

• nim: completely c interoperable; nimscript handles a lot
• zig: lightweight and memory safe
• rust: takes a significant amount of time to learn, a bit bloated, but a powerhouse and a joy to program in – particularly functionally

the obvious one: why is piping plain text in and out the basis for an operating system? did ken thompson hate OO that much? microkernels are just better for software though, right?

learn more about redox; it will be beneficial for the future https://doc.redox-os.org/book/ch01-05-why-redox.html pull Operating Systems https://scattered-thoughts.net/writing/assorted-thoughts-on-zig-and-rust/ zig seems significantly easier to learn than rust while offering similar security, for the most part. it also seems to offer some ml style power, albeit without the syntax

zig compilation is lazy, has very good support for cross-compilation. cool build system that differs from cargo and allows for the creation of arbitrary build systems

zig has much lower cognitive overhead than rust, and seems better for faster development speed, but it doesnt have a good method for uaf escalation, data races, data sharing etc. rust lifetimes are cool and so are traits, but zig might have the facilities to implement them

https://en.wikipedia.org/wiki/Inferno_(operating_system) pull sequel to plan9 - it even runs as a userspace application inside of the plan9 operating system. the fact that it provides an inbuilt virtual os is incredible. try this one out sometime when you want to learn more about os research. on android though? on nintendo ds????

what's wrong with fork? some research:

• https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf
• https://drewdevault.com/2018/01/02/The-case-against-fork.html the OOM killer…….. KnightOS? the spawn model, in which a new process is created and kept in limbo, then you can change its environment, pass it more file descriptors, and so forth until you're ready for the process to actually begin