Nice wikis
Wikis with multiple authors
Single authors
- romankogan.net/adhd/
- notes.alexkehayias.com
- notes.andymatuschak.org
- gwern.net
- www.shakesville.com/2010/01/feminism-101.html
- doubleloop.net
Wikis with multiple authors
Single authors
PSU internal, GPU "right side up"
PSU internal, GPU "upside down"
PSU external, GPU "right side up"
PSU external, GPU "upside down"
See also the Modivio xCase has a version for every category.
I decided long ago on a 92mm CPU fan, not a 120mm beast straddling the whole motherboard blocking DIMM and M.2 slots and giving the case the experience of a cramped cupboard. I don't like "efficient" when it leads to that. A stationary computer is partly an art piece for me, I want to feel peace and harmony when I look into it!
That's the upside of the classic ATX miditower: the experience of roominess and easy access, and I've seen 1990s pizzaboxes that created the same experience. To do so, the case should leave about 5 centimeters of margin around every component (and between the component and outer panels), allowing cables to go around the components as if they were roads around buildings.
The best modern example I've seen is the HDPLEX H5, but there's surely room for improvement. It holds no candle to the unidentified 90s cases I've seen—I wish I could link to those.
In my mind, "pizzabox" refers to those 90s cases that didn't try to be small-form-factor, just thin. They emphasised easy access. You didn't have the typical trouble with modern SFF (small-form-factor) PCs where you must try to get your hands in under other components to make adjustments in nooks and crannies, nor did you have to remove other components to get them out of the way — you could access any one component in isolation and swap it out in isolation! That's my pizza-box dream.
For another distinguishing trait, you know those roof brackets, whatever they're called, that run across the middle of many modern slimline chassis to help with sturdiness? The thinner the case, the sillier this looks. In a 1990s pizzabox, you didn't have that – you just had full-blown walls, i.e. the pizzabox could be divided into 2-5 separate compartments. They could do this because they didn't put so much of a premium on low volume per se, just thinness.
I'm biased, but I think here's an unexploited market segment. That's particularly true for 1U-thin cases, because there are at least three tricks that become obvious once you permit yourself to be generous with the X and Y dimensions, but I've never seen them in the wild:
Disclaimer: While I haven't understood the use-case of Denote, I'm sure it has one. This is just directed at the reader who is feeling attracted to Denote due to a perception of "simplicity".
Denote is … simple in the wrong way, in my opinion.
Aside: I like the author, but I disagree with his view of when to use Org, just because of a complex codebase. My plaintext has no reason not to be in Org markup!
(Even if all copies of org-mode.el in the world got deleted or something, it would still have no reason not to be in Org markup over any other! I could probably fork markdown-mode to understand Org syntax in a day, and then I'd once again be at least feature-par with markdown files, and so there's no reason to even "preventatively" stick with Markdown today.)
It sounds like to him, Org's complexity feels very present while editing an Org file, but it's not to me. I do not see anything but the text I'm wanting to write.
I was troubled by the introduction of a denote: link type, worrying how they would survive export, but I'm calmed since I read that Denote will also read regular id: links. Phew!
The strict filename structure creates a roadblock for me. I export many of my Org-roam files to a directory of HTML files, and I rely on the Org exporter to automatically resolve id: links and replace them with relative paths. Which means the filename of each org-roam file ends up determining the URL to each of my posts – good thing the filenames don't matter to org-roam! I wouldn't want the Denote format in the URL! With Denote I cannot just use org export as a drop-in solution. Now I must dig into the source code and hack it to work with Denote's limitations.
Now here's why I call it not-simple. I think simple software allows seamless composition with other software, instead of creating roadblocks!
Org-roam v2 is the most natural way I can see to implement a zettelkasten. I've thought so at least since 2015-05-20 (predating org-roam).
Most complaints I've seen have less to do with technical tradeoffs, and more to do with people not knowing what to do when they can do everything. They like Denote because its limitations lead to someone writing a manual explaining one correct usage, and I guess people who have not previously thought much about file-naming schemes perk up at the "hey, that's smart!" file naming scheme, and so they feel compelled to buy into it just to pay respect to beauty, or something.
One complaint about org-roam is potential desync between filename and #+TITLE. I'm not worried about that, because there is no filename, there is only #+TITLE. For the purpose of my homepage, I made a small command that auto-renames a file based on the title.
The org-roam-db is a godsend sometimes. When I customize my export process, I'm able to query the database for all kinds of things, like,
Sure, EmacsQL is janky sometimes. When it acts up or fails to compile, your org-roam system feels big, messy and fragile. But does a SQL dependency mean org-roam is overengineered?
Let me put it this way. Imagine making a zettelkasten system from scratch, a good one. You want the dream, you want it to take over your life, you want it to be useful beyond your wildest expectations. Isn't it immediately obvious that your system is gonna end up having a SQLite database at some point?
So it's great that someone already built it in. If they didn't, you'd have to get around to doing it yourself.
So you also skip the whole process where you eventually realize, "hey, what if we just base all the code around this SQL layer, refactor away the rest, and arrive at a beautifully simple design?!" That's exactly what org-roam is: "a database abstraction layer for Org-mode", quoting the source code.
(OK, the current org-roam codebase is hard to understand/hack, but it's on us to fix!)