🏛 Stoas near [[@agora/2021 01 04]]
📚 Node [[2021-01-04]]
↳ 📓 Resource [[@agora/2021 01 04]]
- worldbrain cited yearly value of a facebook user at 250 USD.
- conaw objected: https://twitter.com/Conaw/status/1346061184542199809
- Closer to 7.5 USD it seems: https://twitter.com/Conaw/status/1346065811497074691
- Matches https://twitter.com/flancian/status/1335550881933234176
- central mid levels escalator
- aprender de grandes
- beepb00p exobrain
- 17:40 https://twitter.com/flancian/status/1346134251700412423
- browser extension
- feature requests
16:00 various thoughts
what's wrong with posix io
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
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
- 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
- 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 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) 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://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
TIL you can use dashes for bullets, I've been using asterisks.
Pushed the agora browser extension to public repo
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.
My msg on fedi got a bunch of likes
A bunch of intellectual types started following me on twitter recently
It doesn't look like agora currently supports triple-tick format, I'm not sure the proper name for it
- An actual dendron is so simple in its structure yet so complex in its function. I love that
reading about 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
- thinking of looking into tox
- found https://darkcrystal.pw/
- 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
my friend shae showed me a video about geometry in higher dimensions