# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 26
# self = https://watcher.sour.is/conv/mfddciq
That FAT12 implementation is very naive and unoptimized. You can see in this video that it takes about 7 seconds to copy a ~10 kB file: https://movq.de/v/fbf2b90ce1/los86-fat12-copy.mp4 🥴 I *kind of* like that, though, because it feels a little bit like an old machine. 😅🤪~
That FAT12 implementation is very naive and unoptimized. You can see in this video that it takes about 7 seconds to copy a ~10 kB file: https://movq.de/v/fbf2b90ce1/los86-fat12-copy.mp4 🥴 I *kind of* like that, though, because it feels a little bit like an old machine. 😅🤪~
That FAT12 implementation is very naive and unoptimized. You can see in this video that it takes about 7 seconds to copy a ~10 kB file: https://movq.de/v/fbf2b90ce1/los86-fat12-copy.mp4 🥴 I *kind of* like that, though, because it feels a little bit like an old machine. 😅🤪~
That FAT12 implementation is very naive and unoptimized. You can see in this video that it takes about 7 seconds to copy a ~10 kB file: https://movq.de/v/fbf2b90ce1/los86-fat12-copy.mp4 🥴 I *kind of* like that, though, because it feels a little bit like an old machine. 😅🤪~
(This issues a lot of BIOS calls, that’s why it’s so slow.)
(This issues a lot of BIOS calls, that’s why it’s so slow.)
(This issues a lot of BIOS calls, that’s why it’s so slow.)
(This issues a lot of BIOS calls, that’s why it’s so slow.)
@movq Ahh (_sorry ignore my previous Twt_); Any way to optimize the no. of BIOS calls? 🤔
@movq Ahh (_sorry ignore my previous Twt_); Any way to optimize the no. of BIOS calls? 🤔
@prologic Lots, I guess. 😅 The kernel keeps almost no state between syscalls, so when you want to read the next byte from a file, it has to do all the work from scratch: Locate the file in the directory and traverse the cluster chain until you’ve reached the next byte. It’s easier to code this way, but obviously much slower. And the userspace program cp could read/write in multiples of 512 – it currently does not do that, intentionally, because if everything is a multiple of 512, you’re less likely to discover bugs. 😅
@prologic Lots, I guess. 😅 The kernel keeps almost no state between syscalls, so when you want to read the next byte from a file, it has to do all the work from scratch: Locate the file in the directory and traverse the cluster chain until you’ve reached the next byte. It’s easier to code this way, but obviously much slower. And the userspace program cp could read/write in multiples of 512 – it currently does not do that, intentionally, because if everything is a multiple of 512, you’re less likely to discover bugs. 😅
@prologic Lots, I guess. 😅 The kernel keeps almost no state between syscalls, so when you want to read the next byte from a file, it has to do all the work from scratch: Locate the file in the directory and traverse the cluster chain until you’ve reached the next byte. It’s easier to code this way, but obviously much slower. And the userspace program cp could read/write in multiples of 512 – it currently does not do that, intentionally, because if everything is a multiple of 512, you’re less likely to discover bugs. 😅
@prologic Lots, I guess. 😅 The kernel keeps almost no state between syscalls, so when you want to read the next byte from a file, it has to do all the work from scratch: Locate the file in the directory and traverse the cluster chain until you’ve reached the next byte. It’s easier to code this way, but obviously much slower. And the userspace program cp could read/write in multiples of 512 – it currently does not do that, intentionally, because if everything is a multiple of 512, you’re less likely to discover bugs. 😅
@movq Ahh so you lack some kind of an open() syscall to hold some state for the open file, i.e: a "file descriptor"? 🤔
@movq Ahh so you lack some kind of an open() syscall to hold some state for the open file, i.e: a "file descriptor"? 🤔
@prologic Something along those lines, yeah. And/or some generic cache for disk sectors.
@prologic Something along those lines, yeah. And/or some generic cache for disk sectors.
@prologic Something along those lines, yeah. And/or some generic cache for disk sectors.
@prologic Something along those lines, yeah. And/or some generic cache for disk sectors.
@movq Yeah I have to admit I don't know nearly enough about how the Linux Kernel works™ much here. I'm quite sure there's a lot under the covers that we just don't really fully appreciate 🤣
@movq Yeah I have to admit I don't know nearly enough about how the Linux Kernel works™ much here. I'm quite sure there's a lot under the covers that we just don't really fully appreciate 🤣
@prologic Indeed, I’ve gained a lot more respect for Linux/BSD and DOS. 😃
@prologic Indeed, I’ve gained a lot more respect for Linux/BSD and DOS. 😃
@prologic Indeed, I’ve gained a lot more respect for Linux/BSD and DOS. 😃
@prologic Indeed, I’ve gained a lot more respect for Linux/BSD and DOS. 😃