Red Rozenglass

https://fedi.dreamscape.link/rozenglass

a young man from a far away land.
corposlave ("software engineering consultant" lol).

GNU/Linux (Slackware). Programming (asm, C, sh, Lisp, Lua, Web, JS, etc.). Likes writing documentation, understanding & maintaining systems, archiving, organization. Interested in paper machines, books, visual novels, writing, drawing, anime. EN/AR fluent, TR can order food, JP early learnings.

RƎD.

Website: https://dreamscape.link/
PGP Fingerprint: 0BEB A81D 9E51 F58F 7E40 78B8 CFC8 26D6 A116 A778
Current Account: https://fedi.dreamscape.link/rozenglass
Backup Account: https://mstdn.io/@rozenglass
Dead Account (1): https://anime.website/rozenglass
Dead Account (2): https://letsalllovela.in/rozenglass
OCEAN: O+++C+E-A++N++
MBTI: INFJ
Ψ: RƎD

Public Key

npub1h7c3k380f4nx3kngqyc9lp56dw7phm0lt24uhtpq3fdepjtm3j9q0ssmmd

NIP-05 Address

rozenglass_at_fedi.dreamscape.link@momostr.pink

Profile Code

nprofile1qqstlvgmgnh56engmf5qzvzls6dxh0qmahl4427t4ssg5kuse9acezsprpmhxue69uhhyetvv9ujumt0d4hhxarj9ecxjmntqyf8wumn8ghj7mmxve3ksctfdch8qatzkvutyt

Publishing to

relay.momostr.pink

offchain.pub

relay.snort.social

Author Public Key

npub1h7c3k380f4nx3kngqyc9lp56dw7phm0lt24uhtpq3fdepjtm3j9q0ssmmd

Show more details

Last Notes

2026-03-25 05:32:24 UTC

- reply

> I see. That ties into the “AI”-generated code discourse too: We don’t need to barf code out fast. We need better code applied in necessary points.
Yes, indeed. It is always a trap. You see it everywhere, people thinking that if only they produced more, faster, that their problems will be solved, yet again and again they fail anyway and end up with problems extended or multiplied, and yet the lesson that they take most of the time is "we weren't fast and productive enough, we need more for next time". It does happen, once in a while, that speed might actually be the source of a problem, but it is exceedingly vanishingly rare that it is. But for some reason, it is one of the most popular thought-terminating ideas in modern culture. I guess it is usually easy to measure, and easy to implement, at least in theory, so executives find it a good alternative to them saying "we don't really know what the hell is going on, and we have no idea how to fix it", which is the truthful, and understandable, default mode for humans in almost all our endeavors most of the time. Hiring thousands of remote outsourcing developers for very cheap never grew any company by 100x, and neither will "hiring" thousands of AI agents.
> Aesthetics are important indeed! I’m not the visual type of person, so I want to try paper information management because of persistence and intentionality. But beauty is there for sure, human-made and home-grown!
Yeah, I don't think it was aesthetics (I wasn't creating pieces of fine art there), but it was, like you said, the intentionally. The aesthetics were only a tool to put in more intentionally. Symbolic rituals, of some sorts, that put me into the right mindset.
> This linking part feels really hard. Especially given that my thoughts are extremely unstructured and domain-permeating. Thus resistant against indexing approaches. But I think that keyword indexing might work there!
Most of my linking ends up happening where topics are very closely related, are on my mind, like a residency application linking to the previous attempt at the residency application, or some journal entry linking to some similar event that I remember from an older journal, plus, things like journal entry on birthday linking to the place I keep a gift I got on that day, etc. Emergent associations are more likely to happen due to keyword indexing, or re-visiting long-threads of writings on a specific topic. But all of those features are implemented as links in my system. For example, indexes would be implemented like:
Common Lisp:
1C231124/2
1C240203
1C250311/1
1C250311/2
And an actual link inside an article would be like this:
My random topic[1] to link to, is going to be linked below.
[1] Ref: 1C250311/2
As for threading, I write the following on the exterior of the folded paper:
Previous:
1C231124/2
Next:
1C250311/1
All of those are fundamentally "links", where things like "1C250311/1" are IDs of documents. Fast access to documents by ID is achieved by keeping the documents sorted by ID, thus making rough binary searches easy to do.
> That reminds me of John Locke's Method...
I've seen this before, but I think it only works if all the writings are roughly around the same subject; e.g. a book on algebra, or something. If you have a system that slurps everything in your life, then this kind of index feels really weird, as it would put completely unrelated things next to each other just because they share the same letters. For me, I prefer indexing based on loose association of topics, and a recursive structure to the keywords. So the index may point to other indexes. Instead of having the word "language" in the index point to many documents, I have it instead point to "Index of Language", and similarly I have "Index of Books" and "Index of Anime". Those indexes can be redone as they grow, to restructure them, for example, my Index of Books may get bloated with a disproportionate number of programming books, so I rewrite it instead replacing all the programming books with a link to another index; Index of Programming Books. Of course anything can be linked to and from in a many-to-many relationship, so some programming book may also be linked to by some business-related index or document, etc. The most important thing to me, I found, is to not try to force myself too harshly into pre-made structures, and instead let the garden grow. The key is to not be afraid of throwing things away and rewriting them, once a better shape of the structure starts emerging. The whole process is a bit reminiscent of a Wiki, but with the URLs of pages being forcibly a serial sequence of sortable IDs.
> I have the same effect, just looking at a map once and then trying to not look it up on every crossroad. Helps in exercising memory. So yeah, I get that!
I've been thinking of dabbling in drawing some maps myself, or at least printing them, and slowly marking the landmarks and locations that are important to me over time.
> > remembering the phone number off the top of my head
> Oh, that sounds extremely hard to achieve, ahah
Happened on its own, didn't even try :D
> That’s unfortunate. Being a digital kid, I really like optimizing my workflows. But now that I want to try out the paper life, I might come to the same conclusions.
I know what you mean. Having spent so many years in the digital world, building my own minimal systems, catered to my own needs, it feels a bit like I'm throwing it all away. But then I think that I would probably never have achieved this way of thinking about analogue systems in real life had I not spent so much time thinking about them in the virtual world. Plus, my keyboard typing speed will still be useful when I want to do programming for my work, or markup and typeset stuff I wrote by hand for publishing online or printing. There's a good hybrid world there somewhere, with volition and thought being sourced from the offline simple analogue garden, and execution, efficiency, and reach being the domain of the digital. But it will take tasting both worlds to find the lines and contours.
P.S. You might enjoy trying the power of a handwritten letter given to someone directly. Seems to have orders of magnitude more effect on others than digital communication. Whether a business-related thing, or an appreciation letter to a friend or family member. I've never seen anyone get affected by, or treasure, a digital instant message as they treasure a paper letter held in their hands. No idea how this work, just anecdotal evidence.

2026-03-24 20:35:53 UTC

- reply

I've been enjoying "no build" systems in my last few projects; write the build process in the language itself, grow custom features as needed. zero dependencies, all you need is the compiler or runtime of the project's language:
cc build.c -o build && ./build
sbcl --script build.lisp
node build.js
tcc build.ts && node dist/build.js

2026-03-24 03:15:32 UTC

- reply

I haven't dabbled in the math and shorthand stuff, but did switch to analogue for a while, doing a Zettelkasten-like system of my own, using folded A4 paper, with IDs, thread chaining, indexes, linking, etc. A pencil and a ruler plus the paper were all the tools I used. I used it for journaling, writing, keeping lists of books, writing reviews and notes, task management, indexing my collections of psychical objects, and other assorted uses. My verdict is: analogue has definitely been more productive than digital for me. It is slower in every way, so /speed/ is not how it did it. It was more through /focus/, friction making switching away from things more expensive, more accurate estimation and prioritization of tasks, and some kind of psychological effect from the meditative effect of preparing the documents, lining the paper manually, and drawing some flourish and some attempts at calligraphy in the titles; having beauty and care imbued into the work; craftsmanship of sorts. I tried it even on other people, for example helping my wife with a long-term project by dedicating a paper to record her achievements, writing them down very carefully and slowly, with some ornaments around the paper, etc. It had a very visible effect on her excitement and dedication to get to her goals, and she was always coming back to ask me to write down the next thing she's proud of. I don't think this effect would be achieved by writing a bullet list in a plain text file.
The negatives of analogue are overblown usually. Most governments ran on paper machines, but too many salesmen wanted to sell us the "Digital Transformation" the past few decades. Search is not a big issue, because you can have an index, and write keywords in it, backups are not a big issue, because you can scan your documents, copy them, and even OCR them if your writing is acceptably readable, or even manually copy them by hand if the writings are important (every time you manually copy, you have a chance to improve what you wrote; an article re-written from scratch three times is usually of way higher quality than one written once). Hyper-linking does not require a digital tool; you can have IDs and use them as links, and finding the right document can be fast if you have a good ID schema to sort your documents by. Even copy-paste works in analogue if you really want, by... you know, copying with a printer, and then pasting with some glue. Or just link using IDs. I use simple nylon plastic sleeves as folders, give folders IDs too, and link to them from an index page that explains what things are in that folder. Usually the index paper is kept as the first paper in the folder itself, then a link to that index paper is made from a more central index (e.g. index of personal government documents, index of sentimental letters, gifts, and trinkets, etc.). Moving paper around is also easy. Throw it on a scanner, make a copy, put it in your clipboard, and take it with you on a bus ride. If you want to move an original document from your main data store to some other place (e.g. from home to office), you can write that down in a special "move index" file, in which such moves are tracked.
Another thing I noticed with analogue, is that my brain became better at things, making it faster than using a computer. For example, it takes me a few minutes to search online maps to make a trip plan to where I wanted to go, but since I'm using analogue instead of digital (I got rid of my phone completely too, by the way) I had to write the directions down on a paper and take it with me, as I couldn't access them on demand whenever I needed them otherwise. Well, not for long, because my brain suddenly started remembering the roads for next time, whereas I went places dozens of times using digital maps before, and never memorized the roads. Same for phone numbers, I used family members' numbers hundreds of times using a mobile phone, never memorizing them, but without using a digital contacts manager, I had to write them down, and then I find the paper and read it when I needed to call them using landline, and less than half a dozen times later I was just remembering the phone number off the top of my head. Much faster than searching any digital tool :D
After a year or so, I went back to my digital systems to see if the lessons I learned can be helpful there. I ventured forth implementing my (8th, over the past decade) home-grown digital organization system, in Emacs Lisp, focused on a chunked single plain-text log, with internal linking, tag-based indexing, very fast leader-key-based shortcuts to do everything, etc. The results so far, around 3 months in, are not very good. It is much better than any of the seven digital systems that I built before it, and any of the dozen 3rd party digital tools I've tried, but it just doesn't "hit it". There's something really missing in the digital world. The faster the tools are, the easier the shortcuts, the lower the friction, the worse it becomes. The results are measurable reductions in total productivity, even though /it feels/ like I'm faster, and I spend less time organizing and planning, and everything just "emerges" from the system. Yet, I'm measurably less productive. I see I lose a lot more time on distractions, small side tracked tiny tasks that hairball into massive time wastes, more likely to not be productive due to not "feeling it"; i.e. low-energy, lack of excitement about things I want to do, etc.
Now, of course, there are like a million confounding factors in those experiments, so I can't really make any absolute judgments. But I'm starting to build a model that has two distinct approaches to productivity, one focused on improving the tools and workflows, modifying the outside world, and the other on sharpening the mind and mental state, modifying the world within. Doing analogue things in the real world, because it's slow as heck, because it has friction, because it allows your brain many many free cycles to generate random associations in the background, because you see many things at the same time (try spreading 20 related cards / documents on a big desk or the floor, very hard to simulate what happens there on a computer), because it costs so much time and effort, it all pulls your mind together, gives a fine point to your attention, and a sharp edge to your priorities.
Or that's my hypothesis about what happened with me at least. To learn more, lots of information around Zettelkasten is good food for thought, and I recommend the book Paper Machines by Jacques Derrida, which I found very interesting (though I haven't finished the entire book yet).

2026-03-16 23:50:38 UTC

- reply

I didn't know entire TLDs required TLS before. Apparently, buy having them in browsers' "HSTS Preloading Lists". This is disgusting. And .dev at that, which sounds like a domain you might use for a development environment. But anyway, since clients themselves ship the HSTS lists, that means if you provide plain HTTP it can still be useful to clients that don't use those HSTS preloading lists, and I assume any HTTP-only client will not have such lists. If the goal is more compatibility, then that should still satisfy. Of course clients that use HSTS preloading lists will only connect using TLS. If you want such clients to be able to connect to your mirror without TLS, then getting a secondary domain for the mirror would work, if you so wish.

2026-03-15 22:45:21 UTC

- reply

Oh how I wish we would all go back to that. But nowadays, it is unavoidable, if not for big corpo silos, it's for all the world governments that have now invaded the internet, and use it for all kinds of "services" and "communication".

2026-03-15 22:43:27 UTC

- reply

I think it's probably a good thing that big sites like Facebook or Twitter or such refuse plain text, because if they didn't, "oppressors" may force their populace to only use plain text browsers so they can spy on them, and the oppressed won't do much about it because they don't understand the implications. While the current status-quo makes forcing the use of plain text clients equivalent to blocking all major internet services, which would be more revolting to the populace. Big corpos probably know that, and force TLS as an intentional measure against allowing "enemies" to spy on users, and leave the control in big corpo's hands to give the spying data only to "friends". The use of Cloudflare by half the internet perhaps demonstrates that it is not about privacy, as much as "we only allow the eyes we want to allow".
As for smaller internet sites, personal sites, blogs, or archives of scientific knowledge and such, I'm very much in favor of them accepting plain text connections if the user requested explicitly. Perhaps, a middle ground, to work around the stupid behavior of modern web clients, would be to force TLS on the main site, but then have a mirror of the entire site on a subdomain (notls.mysite.org) that does not force TLS connections. This can even go for big corpo silos, if they wanted, e.g. notls.facebook.com, but then again they probably won't do that, because they would risk losing the monopoly power they hold over that information.

2026-03-15 22:22:58 UTC

- reply

Knowing the public information does not make it less interesting to know what specific information a specific person is interested in. Especially in high-stake political situations. Visited website X.lol, is not as damning as visited 200 pages of the form X.lol/something-that-can-get-you-hanged. And on lower stakes, not having TLS encryption means your ISP (and any listener in the middle, like your company or hospital or school, etc.) can build a psychological profile about you just from watching what you read. And worst of all, they can inject changes into the pages you read without you knowing, from injecting ads, to changing the content to what fits them; TLS also validates that the page was not tampered with by your carrier.
I still don't think that forced TLS *server-side* is a good idea, except for things like login pages, or if you know that the content of your site can get people in trouble if casually inspected by their ISP. I think most of the internet should allow plain text connections if the client wanted that. I do think that web clients for the general public should by default enforce TLS, and only allow removing that by the user's explicit request.

2026-02-27 15:17:31 UTC

- reply

if your use-case includes storing all agenda items, tasks, and journal entries, for many people for years to come, then inode exhaustion and space overhead due to mostly-empty allocated file-system pages can be a pain, and of course slower directory access once you have a few tens of thousands of files unless you split them into many directories for balance. perhaps, ical used one file because they expect a person to potentially generate thousands of items per-year, and over a couple of decades. if you want to search all journal entries by some criteria, you will have to open() thousands of files just to look something up, which is much slower than grep'ing through a single file a few megabytes in size.
a multi-file setup makes multi-user work much easier of course, saves a lot of locking and synchronization headaches, since mv/rename() are atomic, and that's very nice.
random fresh thought, not well-explored: what if each user client would have a single file owned by them, so no need for complicated locking and synchronization, and then a shared space exists for many users to communicate where every object is a single file, and every operation is atomic. a user then appends their "inbox" of temporary single-file objects into their homefile in which everything else they own exists. this way, multi-user operations would still be relatively easy, but the final data storage does not have issues with page overhead, inode usage, or slow access and search. i wonder if some system exists that uses something like that already.

2026-02-05 01:41:32 UTC

- reply

what has helped me a lot is to write the name on a little notebook in my pocket, sectioned per-company or context, maybe with some identifying marks, sometimes even during the conversation itself, being open that i'm not good at remembering names, so i write them down to help with that (people seem to actually receive this positively, not awkwardly; they see it as a sign you like them enough to care to remember their name). after writing the names down, and having the fun little conversation about it, i rarely actually need to go back and check the name again later, my brain just remembers a lot better through the act of writing itself. not always though, sometimes i do have to check the notebook to find what the name of a person is.

2026-02-04 23:28:26 UTC

- reply

Fundamentally, I don't use YouTube for the same reason I don't use HackerNews or many other "useful" sites: because there is an infinite amount of useful and good information, enough to completely drown me, and prevent me from getting anything actually done. Any information that I won't use, no matter how curious, is not worth wasting part of my life on. Even information that can be of great use is so numerous that it can spam me into a grinding halt. I'm a very curious person, so places like YouTube can be a massive time-sink. Especially with how slow videos in general are at delivering information. I can get information from reading way faster than I can get them from watching videos, even at x2.5 to x3 playback speed.
Another reason why I don't use YouTube is how much information it can leak about my psychology and interests to a powerful corporation that I don't want to have so much information about me. This is more workable with 3rd party front-ends like yt-dlp and invidious, but YouTube is cracking down on them more and more, and it's becoming a real hassle to watch YouTube without having to sign in "to prove I'm not a robot". The more they tighten, the less I watch YouTube.
When I used to use invidious and such, I would actively block the recommendations section using uBlock Origin's element zapper feature, because I don't want my mind and attention to be steered by the whims of the big corporation, its advertisers, its algorithms, or even the collective of YouTube watchers in case the algorithm was really completely unbiased in its recommendations. I want my mind to give its attention to the things I want to do long-term, not to the things everyone is talking about short term. Thus, the only way for me to see a video is for me to search for a topic specifically, or, for someone I know to give me a link to the video. Slowly, I even stopped using the search, because even that is tainted with the algorithmic preference.
In general, YouTube is slowly going more and more user-hostile, in my perception, and their attempts at milking more and more money are very obvious. This also reflects on the culture of the video producers seeking popularity, as their approach becomes more and more obnoxious and offensive to the intellect. It is sad that YouTube are the sole holders of a massive amount of human knowledge and history produced by millions of people, and that if they go down, most of it would be gone. All more the reason for us to try to "diversify" internet video production away from that single point of failure.
Personally, I do have a few slow YT channels I still subscribe to using RSS feeds, and watch using yt-dlp, but very few and infrequent, and with no risk of run-away rabbit holing. If at some point, watching those videos without using YouTube's web frontend or apps becomes unavoidable, I will stop completely.
I think I would have no qualm about using YouTube for publishing, for additional "exposure", granted I keep my identity and personal information leakage to a minimum. But I would only do it as a secondary "mirror" of my published material elsewhere, because I don't want to push people who want to listen to me to have to use a platform that doesn't respect them or their privacy, and tries constantly to manipulate them. I would guide the viewers to watch my videos on other platforms in every video I publish to YouTube. This doubles also as protection against being censored or kicked out by YouTube in the future, for any reason. Of course, publishing on my own site and server would be the preferred method, all other services would be mirrors, but that would be hundreds of dollars of hosting expenses at least for anything serious, so, using service platforms might be the only feasible option for some.

2026-02-04 02:16:57 UTC

- reply

All real languages speak C ABI, so problem solved.

2026-02-02 03:39:10 UTC

- reply

none of those things are things I could not do in my text editor. This comes down to the definition of IDE, which is fuzzy, and defined differently by different people. My personal definition is: IDE understands the language being used on an AST-level at least (vim with a language-server is an "IDE" in my view for example), and provides a set of pre-made tools to act over that AST. While an editor works at the level of text, and provides tools that works over textual content in general. Working at the level of text is very powerful (much more powerful than IDEs in my opinion), and much faster performance-wise. For example, I can, in Emacs, grep for a symbol, record a macro that goes to each result, then does a very complex custom ad-hock transformation specific to my code, and run it over all the results, watching the outcome of each automatic execution, while collecting all the modifications into a patch file, then sending it as an email to my colleagues, and announcing it on an IRC chat channel. All of those things are "textual", and thus can be worked productively together within the same paradigm. An IDE cannot provide such power just by "understanding" the code of the specific language I'm currently working on. Jumping to definition, mass-renaming, replacing calls of a method with its content (i.e. inlining) are some of the easiest things that can be done at the text level.
The real positive for the IDEs usually, is low barrier of entry. The constraint of the pre-made operations acting upon structured ASTs and content, ensures that the user doesn't need to learn much before becoming productive, all while pointing out your mistakes and guiding you with hints and suggestions. The textual editing paradigm is a playground for infinite creativity, and requires a lot of learning. Nothing stops you from shooting your foot off, and ultimate mastery is forever a moving goalpost.

2026-02-01 14:33:27 UTC

- reply

the best editor is your own editor :3
i want to write one, one day, to replace the thousands of lines of customization kludges required to make emacs tolerable for me. but that means having to deal with rtl and arabic rendering, which is pretty complex, and im lazy, but i need that in my editor, and while emacs doesn't get it right in all situations, it works "acceptably" enough.

2026-01-30 22:56:08 UTC

- reply

IDEs are the bandaid that can help you _after_ a codebase becomes full of bugs, slow to code, and drowning in technical debt.

2026-01-29 23:02:22 UTC

- reply

I do the opposite; I leave the wireguard interface in the default namespace, and move the physical device interface to a special "physical" namespace. So, by default, all my applications use my self-hosted VPN. I also have multiple namespaces for multiple VPNs, for example, I only run my torrents through one specific VPN, so I have a script ~/.local/share/bin/rtorrent that runs su -c to first prompt me for password and then run rtorrent proper inside the appropriate namespace. That way, I can never run rtorrent in the wrong namespace by mistake, as the name is overridden. I also do the same for a firefox instance that runs with a different --profile to access my bank and such through the physical network. Having to write the password makes it abundantly clear that I'm now switching to the physical network, and can never happen by mistake.

2026-01-27 14:06:20 UTC

@npub1suu…e5ly you have a pretty site. i spent the past hour reading and exploring it. thank you ^-^

2026-01-25 13:58:30 UTC

- reply

Teddy Hyde - Sex With A Ghost
https://inv.nadeko.net/watch?v=AGKcT5vlRkE
https://youtu.be/AGKcT5vlRkE

2026-01-24 00:29:02 UTC

- reply

A memory of RED. I don't own her, I wouldn't want to, but I own my memory of her. I was but a handful of years old, on a bus of some sorts, going somewhere that doesn't matter. But there I saw her. Her face escapes me by now; too many decades ago. Her silhouette barely recognizable, a shadow in the reflections of my mind, but her RED, hers still glows. She didn't say a word, she didn't do a thing. Only sat there, with her slightly oversized Red coat, so pretty, so elegant, so untouchable, unreachable, something not of our world, doesn't belong to the same plane. Her radiance illuminated that place, that time, and from that point, all time beyond, and all time before. I still have no idea what I encountered that night, or what I saw, I could not fathom it, I could not understand it. But something of her, still lives in me. A lifetime, or a few perhaps, later, and I still feel her presence, I still see her, I still visit her. Nowadays, she mostly watches over islands over the far horizon, from the ruins at the top of the hill, and from time to time, dips her hands in the pure river, that therein flows.

2026-01-23 22:43:36 UTC

- reply

I have some script that uses fetchmail, curl's IMAP support, some awk, grep, and mpv, to play an alarm sound on speakers when I get a mail notification from my company's monitoring systems. I've been thinking of setting that up on some small SoC, maybe ideally with a SIM card for internet access, and thus, have a portable pager, kinda. But I haven't gotten around to doing that yet.

2026-01-17 16:29:04 UTC

@npub1ysc…ffqw I added the following CSS code to my #snac instance:details:not([open]) > :not(summary) { display: none; } 
This removes all HTML elements that are hidden inside closed elements. When the details element is opened, its children are rendered normally. This does not change anything visibly on the page, but it makes the snac page much faster on my older devices. Plus, I use vim-like navigation plugins that allow clicking links by pressing shortcuts, and the 5 such browser extensions I tested all struggle for a few seconds, completely blocking the browser, while their JS code frantically searches for all clickable elements, not to mention that they show hints for elements that are hidden, making the experience very confusing. Additionally, when I search the page for something I just saw, all detail elements expand, and make the page a mess. With this change, the hidden texts inside <details> elements are not searchable, and thus, the browser does not expand all of them needlessly. In general, this change has been very good in my experience. Additionally, I added name=snac-note attributes to the <details> element of all "Reply..." sections, and name=snac-top-controls to the top control elements. Only one of the <details> elements that share the same name is allowed to be open at any time, and thus, if I open the "Reply..." drawer on one post, and then open it on a second post, the first one would automatically close itself. This helped me with the "All <details> unfolding due to search" issue before, but setting display: none using CSS seems to be a better solution for this problem. Still, I think I'm liking the "only one open at a time" rule, but not sure if it's worth the patch. The CSS change I proposed at the top may be somehow annoying in one case I can think of: someone has their settings set to start with all posts folded closed, and wants to search all folded entries for a specific term (like their own name, or something). In this case, their search would come empty, because all content is not actually added to the DOM. Anyway, if you think either of those changes is worth adding to snac, feel free to. I think I can strongly recommend the first CSS change, as it fits with snac's aim to be fast and light-weight. </details></details></details></details>

2025-12-04 05:26:23 UTC

- reply

ba[dataloss] an^@ [dataloss]pilled. Do you basically use one base wine prefix and then COW stuff on top? Does it work acceptably? I use squashfs and unionfs for build machines, and I was thinking of doing that to wine prefixes, but haven't gotten around to that yet.

2025-10-25 08:17:07 UTC

- reply

i find them more discoverable than gui. but my mind is weird; i read or something. given a complex piece of software like ffmpeg or qemu and a comparable gui, i take the cli any time over getting lost in mazes of menus and submenus and popups and tabs and dropdowns. i'd rather search one big linear page and read. as for non techies trying to use basic cli, i just tell them to "tab tab".
i suspect many people think cli are less discoverable due to three factors:
1. they undervalue time, and overvalue effort. if something takes 5 minutes of their time, but they don't have to think, they "feel" that it's easier, over something that can take 10 seconds but involves mental load.
2. they value time-to-done more than they value mastery and flexibility. e.g. i want to optimize my video, i don't want to understand what a codex is or what options are available and what settings are good for what situations.
3. they compare different things built for different purposes. e.g. ffmpeg with a gui with one big button "Optimize My Video". those are not the same thing. i can write a simple ffmpeg optimization shell script, and it would be a one-click thing just like the gui. but the point of ffmpeg is the massive flexibility and power it provides.
i think cli tools tendency towards flexibility and mastery in exchange of effort is not inherit to cli, it's just a culture thing. i wrote a cli application before at work for non-technical people, and no one ever complained about usability or discoverability; they just click it, it opens a terminal and tells them in one line exactly what files to put in what folders, they do that, click it again, it runs, retries on error, reports success or failure, and reason for failure. no options, no settings, no walls of text, no way to misuse it. but this is usually not what "cli people" want from cli tools, and cli tools tend to target cli people.

2025-05-26 15:18:37 UTC

- reply

It's not about hiding things, it's about server load. The latest wave of AI scrappers trying to feed the ever hungry data munchers are extremely hostile, they hit hard, don't respect rules, and there are so many of them because everyone is racing to the "AI" bottom right now. This is why site admins are protecting their sites with proof of work. It's not that they don't want the scrappers to see it, it's that they want the scrappers to not bring the site down while getting the data.
Getting the data from email subscriptions, or by downloading a wiki as a package is what we want the scrappers to do, instead of hitting the servers at hundreds of requests per second re-reading the same pages again and again dozens of times, endlessly, to stay "up to date". Proof of work is to make them "pay for it", so the scrappers will slow down if they support JS, thus reducing server load, or stop completely if they don't, thus having to use the efficient methods to get their hands on the public data.
This is a terrible situation, tragedy of the commons of some sorts, especially for the poor users, figuratively, and literally, as older hardware will struggle with getting to pages, especially if admins crank up the difficulty of the challenge. Most of the time you don't need the challenge to be hard, you just need it to offset the pressure on your server to keep the load reasonable. But the good answer really is to make sure your site is not slow as heck. The sickness of the web started before the AI floods; serving some HTML shouldn't have been this horribly wasteful, but on most sites, it is.

2025-05-20 10:07:47 UTC

- reply

I think scrcpy[1] provides that too, since Android 12.
[1]: https://github.com/Genymobile/scrcpy

2025-05-20 10:05:34 UTC

- reply

Never heard of it, seems interesting, and relatively minimal, which I like. Thanks for the hint.
The reason I rolled my own RSS reader is because I already had a feed system I wrote, so just tuck another plugin into it. My feed client takes many "loaders" as plugins, and uses those to generate the feeds. I have RSS and Atom, but also various hand-written website-specific HTML parsing thingies for some software, some security advisory "feeds", and other things where I want to check a place regularly. Basically any string of shell commands that generates the expected tab-separated files, works. Helps me a lot with staying on top of news related to packages I maintain in some Linux distros, and security announcements for clients I do consulting for, etc.
I could have hacked on some existing feed software, but I would have probably wasted way more time getting into their code-base and whatnot; my core feed checker is 70 lines of shell, and my reader client is another 70 lines.

2025-05-20 09:36:38 UTC

- reply

I wrote some shell scripts that use curl to get the RSS feeds of all the channels I care about, transform them using xslt-proc, storing them into new plain-text files in per-channel folders, then loop over them, listing them, with a prompt. I can see the titles of Youtube videos form all channels I subscribed to, then type the number of the one I want to watch, or just press enter to open the latest video, and it will play it in mpv with some yt-dlp options to choose a reasonable resolution, moving that entry to an old text file. If it's a big video, like a podcast or a talk or something, I have another option to download the video locally first, then I can watch it offline with mpv whenever time permits.

2025-05-11 00:54:50 UTC

- reply

Thank you for the advice, but Opal is usually chill, she was our admin on fedi for a long while, and I know her for almost a decade by now. She's frustrated, and coming up on hard times IRL afaik. It's not "histrionic manipulative" behavior, it's just stress and pressure, and genuine frustration with humankind.

2025-05-10 22:19:30 UTC

- reply

Opening it in mupdf, scrolling the first 500 pages, then going to the end of the document, it takes 50MiB of resident memory, and each extra mupdf instance seems to take 30MiB of additional memory (so 20MiB is shared between the instances, could be the PDF file, memory mapped, which is almost 20MiB, or could be some memory mappings of some shared libraries, not sure). The experience is very snappy (but my machine is relatively stronk).

2025-05-10 22:08:35 UTC

- reply

I see. Apologies then, I sounded pretentious as hell.

2025-05-10 10:44:26 UTC

- reply

> I think this would be a much appreciated patch
Oh, I don't see it among my current patches[1]. I guess like @npub1mhv…8s5z said, it already exists upstream by now. I think I got confused.
> except I guess it is javəscript based, isn't it?
No need for JavaScript to lazy load images on most modern browsers[2].
[1]: https://dreamscape.link/vault/public/debug/snac2/
[2]: https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Lazy_loading#images_and_iframes

2025-05-10 08:53:48 UTC

- reply

not sure what eye readers are, glasses?

2025-05-10 08:50:51 UTC

- reply

I get pretty heavy timelines, and run on a 1vCPU / 512MiB VPS, and it never takes more than a second to load. My current timeline has 210 posts in it, and took 700ms to load. If there aren't new posts, reloads can be as fast as 300ms for the same number of posts.
One thing I modified in my instance, but was never upstreamed iirc, is that I load media and images lazily. Since I proxy all media through the instance, it used to grind to a halt with lots of images and videos on a page, loading all at the same time, but now, it's very snappy and usable.

2025-05-10 06:29:47 UTC

- reply

I get that a lot, but this is what I've been staring at, day and night, work or leisure, for more than a decade. It brings me calm and serenity, and rests my eyes from witnessing the chaos of this world. To me, it is home :3

2025-05-10 05:53:20 UTC

- reply

I assumed the foundational use of strings in xs and xs*json would have been to keep the JSON in memory as strings without actually parsing it until needed, on demand, just for accessed fields. That's what I'm usually used to in performant C JSON libraries. But like I said, I didn't look into xs in depth before speaking. Prompted by your post I did some micro-benchmarks, and yup, you're right, whatever xs and xs*json are doing seems to be some three-times slower than Python when loading and reading some doubles from a snac JSON file repeatedly (the file for your post specifically). :)
See screenshot of code and results, apologies for the crammed code / color theme.
https://fedi.dreamscape.link/rozenglass/s/94c32a8bc0cfcbadef0899b1019770b9.png
https://fedi.dreamscape.link/rozenglass/s/dc0ad320aa53cf34c770587a2ce323c4.c
https://fedi.dreamscape.link/rozenglass/s/b284a28710cce90d9d9be3a7f4cabc8e.py

2025-05-10 03:22:11 UTC

- reply

snac deals with a lot of JSON strings, all data is stored in JSON files on disk, sent as JSON over network, etc. Handling the data as loosely typed strings most of the time is likely cheaper than marshaling everything into well-typed "objects" and then serializing them back again on I/O. I haven't delved much into the implementation of xs myself, but I used it when I wrote a few patches for snac, and it was acceptable to use. I've been using snac for a few months, and it's much better on resources than any other major AP software I've seen, so I don't have complaints about the performance of parsing doubles :)
I still see snac as "worse-is-better" software, which I don't like much, but at least it's simple enough to start doing meaningful patches within a couple of hours of diving into it, and definitely cheaper for me than having to write a whole AP server from scratch, which I was tempted to do before.

2025-05-10 03:05:05 UTC

- reply

*free headpats from random internet passerby* ^-^

2025-05-10 02:30:59 UTC

- reply

> incredibly dismissive.
to not say anything, leaving you shouting into the void alone, would have been even more dismissive. so, baby steps. people need to be able to say i wish you a good day, before they could say i will sacrifice everything i could to save you.
> i wish i could feel bad for using you as an example and attacking you, but no, i don't.
hey, no worries, i'm not clueless, i know the risks of being "shallow positive" when someone is having a bad time, but the conversation has to start somewhere. i've been on the receiving end of shallow positive my entire life too, from people on the other side of the planet, who obviously cannot help, considering my overwhelming war circumstances. so your sentiments are not radical or shocking to me, they feel familiar.
> this nearsightedness in everyone is the exact pain point i've had in life for way too long now. it's easier for everyone to look the other way and leave me to figure it out all by myself. it's easier for people (like how you're doing) to say superficially well-meaninged bullshit.
it's not that people don't realize they're doing it, it's that they don't think they can afford giving anything more, to what is fundamentally an "online stranger", even if they had a shallow para-social relationship with them for years. people prioritize by circles of closeness, their family, their close friends, you almost never see people supporting someone they don't consider "close", unless they're tricked into it by some righteous tribal-belonging signaling nonsense.
the only people who will reliably stand by you in hardship, are ones you cultivate friendships with, over time, with reciprocity and gentle care. and even then, half of those will betray you anyway, in all kinds of unexpected circumstances.
but you've been through a lot;
you already know all of that.
> how about hoping my life gets better?
i really hope it does, opal. i offered before, and i offer again: i can perhaps help with discussing your situation in more detail, privately if you wish, lending you some brain-cycles, talk concrete strategy and tactics, or possibly providing minor online resources (hosting, etc.) or other forms of assistance, if it might help you stabilize your situation (portfolio for job hunting, discussing / proofreading your CV, or job application approaches, etc.). or, at the very least, i can perhaps offer a listening ear, if you need it.
i will not save you, opal, you will.
i can only try to help a little.

2025-05-09 21:53:40 UTC

- reply

The scope hasn't been "HTTP library" for more than 25 years. I assume it's "overarching" for the same reason why most big "evolved" software are; things just got piled up over time, as the shared infrastructure makes adding new things to the same application faster than building new "do one thing and do it well" tools.
cURL started as an HTTP client in 1996, it was called httpget at the time, and then it got FTP support in 1997, changing the scope of the library to something like "transfer data to and from any URL", hence it was renamed the same year to urlget. In 1998 it was renamed to cURL because too many projects were called urlget. From there onward, more protocols were added because the scope of the library became "Any protocol with a URL". SMTP support was added in 2010, in the same borg spirit :)
By now cURL has some 30 protocols or so.
It's been a long time of course, and that's all I could piece from the changelogs. I wonder if @npub1cm0…enqe would kindly chime in more on whether there was any discussions of splitting cURL into separate per-protocol applications, advantages of the current design, or more on the philosophy behind this architecture.

2025-05-09 21:33:31 UTC

- reply

I hope your day gets better, friend *headpats*
https://fedi.dreamscape.link/rozenglass/s/9127a0ba7ac3be2c101f14e4a7b33b44.jpg

2025-05-09 11:01:23 UTC

- reply

Calm your cocks (chickens), calm your tits (birds[1]).
[1]: https://en.wikipedia.org/wiki/Tit_(bird)

2025-05-09 10:52:35 UTC

- reply

I don't have much experience with Rust, but I used the 2018 edition to write some freestanding nostdlib code, mostly marked "unsafe" all over, and linked to some hand-written assembly libraries. I used rustc without cargo through a Makefile, to output object files that I linked later with other C and assembly object files. It wasn't particularly too painful or hard as far as I remember, and rustc allows compiling to assembly as a target, and the assembly output wasn't horrendous. Despite not having access to its standard library, you still get some niceties like slices, sum types (i.e. exhaustive "match" with Option<> types, etc.).
I still prefer C personally; I don't enjoy rust's syntax, its politics, authoritarian spirit, or its turbulent and web-madness-infected ecosystem. But it's not too bad if you freely permit yourself to hold it "wrong".

2025-03-15 00:08:21 UTC

- reply

Had they been more cooperative and social, they would probably be on the main social networks, because their desire for cohesion would override their privacy / security / freedom / seclusion natures; getting along above all else.

2025-03-06 19:54:42 UTC

- reply

maybe I'm brain damaged, but both polish notation, a la lisp, and reverse polish notation, forth, feel more natural to me than the C-like functions, and lord god help the OOP style of I'm going to put the first argument before a period, then the rest of the args in parens after (arg1.myfunc(arg2, arg3)), which is the most mind boggling convoluted solution to the problem of "I want to group some functions by the data types they act upon".