oh man, this was great! little to no humidity and 63F outside with hills. felt stupid easy which i think being able to breathe easily really was the main reason.
#running
oh man, this was great! little to no humidity and 63F outside with hills. felt stupid easy which i think being able to breathe easily really was the main reason.
#running
oh man, this was great! little to no humidity and 63F outside with hills. felt stupid easy which i think being able to breathe easily really was the main reason.
#running
n7gavoa.
n7gavoa.
o6dsrga, but I can't find the source for it (the raw file). I reset everything, and re-fetched fresh feeds (allegedly including archives). Where is it?
o6dsrga, but I can't find the source for it (the raw file). I reset everything, and re-fetched fresh feeds (allegedly including archives). Where is it?
twtxt.txt I see this line:
2024-09-16T17:37:14+00:00\t(#o6dsrga) @<prologic https://twtxt.net/user/prologic/twtxt.txt>
@<quark https://ferengi.one/twtxt.txt> This is what I get. 🤔
Which is using the right hash. Mine, on the other hand, when I replied to the original, old style message (
Message-Id: <o6dsrga>), looks like this:
2024-09-16T16:42:27+00:00\t(#o) @<prologic https://twtxt.net/user/prologic/twtxt.txt> this was your first twtxt. Cool! :-P
What did you do to make yours work? I simply went to the oldest @prologic's entry on my Maildir, and replied to it (
jenny set the reply-to hash to #o, even though the Message-Id is o6dsrga). Since jenny can't fetch archived twtxts, how could I go to re-fetch everything? And, most importantly, would re-fetching fix the Message-Id:?
twtxt.txt I see this line:
2024-09-16T17:37:14+00:00 (#o6dsrga) @<prologic https://twtxt.net/user/prologic/twtxt.txt>
@<quark https://ferengi.one/twtxt.txt> This is what I get. 🤔
Which is using the right hash. Mine, on the other hand, when I replied to the original, old style message (
Message-Id: <o6dsrga>), looks like this:
2024-09-16T16:42:27+00:00 (#o) @<prologic https://twtxt.net/user/prologic/twtxt.txt> this was your first twtxt. Cool! :-P
What did you do to make yours work? I simply went to the oldest @prologic's entry on my Maildir, and replied to it (
jenny set the reply-to hash to #o, even though the Message-Id is o6dsrga). Since jenny can't fetch archived twtxts, how could I go to re-fetch everything? And, most importantly, would re-fetching fix the Message-Id:?
¿Quien dijo que con las dietas se come menos? ⌘ Read more****
>
Message-Id: <o6dsrga>That’s an older format that was used before jenny version v23.04. It should look like this nowadays:
>
Message-Id: <o6dsrga@twtxt>Changelog entry from back then:
v23.04 2023-04-19
[Changed]
- The format of the "Message-Id" and "In-Reply-To" headers has
changed. They now need an "@twtxt" suffix to be more compliant with
RFC(2)822. This fixes issues when using aerc
(https://aerc-mail.org/) as a frontend instead of mutt.
If you want to retain compatibility with existing files in your
maildir, you must manually add this suffix to these headers. (Or go
ahead and re-sync everything.)
I guess I could have added backwards compatibility to the code. Maybe I’ll fix that later. 🤔
>
Message-Id: <o6dsrga>That’s an older format that was used before jenny version v23.04. It should look like this nowadays:
>
Message-Id: <o6dsrga@twtxt>Changelog entry from back then:
v23.04 2023-04-19
[Changed]
- The format of the "Message-Id" and "In-Reply-To" headers has
changed. They now need an "@twtxt" suffix to be more compliant with
RFC(2)822. This fixes issues when using aerc
(https://aerc-mail.org/) as a frontend instead of mutt.
If you want to retain compatibility with existing files in your
maildir, you must manually add this suffix to these headers. (Or go
ahead and re-sync everything.)
I guess I could have added backwards compatibility to the code. Maybe I’ll fix that later. 🤔
>
Message-Id: <o6dsrga>That’s an older format that was used before jenny version v23.04. It should look like this nowadays:
>
Message-Id: <o6dsrga@twtxt>Changelog entry from back then:
v23.04 2023-04-19
[Changed]
- The format of the "Message-Id" and "In-Reply-To" headers has
changed. They now need an "@twtxt" suffix to be more compliant with
RFC(2)822. This fixes issues when using aerc
(https://aerc-mail.org/) as a frontend instead of mutt.
If you want to retain compatibility with existing files in your
maildir, you must manually add this suffix to these headers. (Or go
ahead and re-sync everything.)
I guess I could have added backwards compatibility to the code. Maybe I’ll fix that later. 🤔
>
Message-Id: <o6dsrga>That’s an older format that was used before jenny version v23.04. It should look like this nowadays:
>
Message-Id: <o6dsrga@twtxt>Changelog entry from back then:
v23.04 2023-04-19
[Changed]
- The format of the "Message-Id" and "In-Reply-To" headers has
changed. They now need an "@twtxt" suffix to be more compliant with
RFC(2)822. This fixes issues when using aerc
(https://aerc-mail.org/) as a frontend instead of mutt.
If you want to retain compatibility with existing files in your
maildir, you must manually add this suffix to these headers. (Or go
ahead and re-sync everything.)
I guess I could have added backwards compatibility to the code. Maybe I’ll fix that later. 🤔
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person.
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions:(#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person.
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
ssh-keygen -Y sign or ssh-keygen -Y verify tools already available? Maybe in combination with @xuu 's idea of generating a random unique ID for your feed, say # id = and signing it with your ED25519 key? 🔑
ssh-keygen -Y sign or ssh-keygen -Y verify tools already available? Maybe in combination with @xuu 's idea of generating a random unique ID for your feed, say # id = and signing it with your ED25519 key? 🔑
# url = changes in your feed?> Whatever gets used, it would be nice to be able to rotate identities. I like @lyse’s idea for that.
# url = changes in your feed?> Whatever gets used, it would be nice to be able to rotate identities. I like @lyse’s idea for that.
1. It minimizes I/O amplification by separating keys and values, allowing for more efficient storage and retrieval.
2. The design leverages the SSD's performance characteristics, utilizing sequential writes and parallel random reads to enhance throughput and reduce latency.
3. WiscKey maintains excellent insert and lookup performance while improving SSD lifespan by reducing the number of erase cycles required.
1. It minimizes I/O amplification by separating keys and values, allowing for more efficient storage and retrieval.
2. The design leverages the SSD's performance characteristics, utilizing sequential writes and parallel random reads to enhance throughput and reduce latency.
3. WiscKey maintains excellent insert and lookup performance while improving SSD lifespan by reducing the number of erase cycles required.
1. Separation of keys from values, with only keys stored in the LSM-tree and values in a separate log file.
2. Utilization of the parallel random-read characteristic of SSD devices to handle unsorted values during range queries.
3. Implementation of unique crash-consistency techniques to manage the value log efficiently.
4. Optimization of performance by removing the LSM-tree log without sacrificing consistency, reducing system-call overhead from small writes.
1. Separation of keys from values, with only keys stored in the LSM-tree and values in a separate log file.
2. Utilization of the parallel random-read characteristic of SSD devices to handle unsorted values during range queries.
3. Implementation of unique crash-consistency techniques to manage the value log efficiently.
4. Optimization of performance by removing the LSM-tree log without sacrificing consistency, reducing system-call overhead from small writes.
- Authors: Lanyue Lu, Thanumalayan Sankaranarayana Pillai, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau
- Conference: 14th USENIX Conference on File and Storage Technologies (FAST '16)
- Key Concept: WiscKey is a key-value store that separates keys from values to minimize I/O amplification, optimizing performance for SSDs.
- Performance: WiscKey outperforms LevelDB and RocksDB in various workloads, achieving up to 111× faster loading and improved random lookup speeds.
- Design Goals: Focus on low write/read amplification, SSD optimization, and support for modern features like range queries.
- Authors: Lanyue Lu, Thanumalayan Sankaranarayana Pillai, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau
- Conference: 14th USENIX Conference on File and Storage Technologies (FAST '16)
- Key Concept: WiscKey is a key-value store that separates keys from values to minimize I/O amplification, optimizing performance for SSDs.
- Performance: WiscKey outperforms LevelDB and RocksDB in various workloads, achieving up to 111× faster loading and improved random lookup speeds.
- Design Goals: Focus on low write/read amplification, SSD optimization, and support for modern features like range queries.
--fetch-context doesn’t go back into archived feeds … 🤦
--fetch-context doesn’t go back into archived feeds … 🤦
--fetch-context doesn’t go back into archived feeds … 🤦
--fetch-context doesn’t go back into archived feeds … 🤦
jenny renders this:
@quark This is what I get. 🤔
@quark This is what I get. 🤔
@quark This is what I get. 🤔
@quark This is what I get. 🤔