Showing 499 to 502

Thin/slimline/"pizza box" gaming chassis

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.

What distinguishes a pizzabox?

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:

  • Water cooling: 1U gives just enough headroom (44mm) for a radiator plus slim fans.
    • (And it'd easily look fantastic)
  • The FlexATX PSU can be quiet if you cool it with a slim 80-120mm fan in front of the PSU – you simply remove the builtin 40mm fan and perforate extra air grilles in the PSU enclosure.
  • Even if you don't watercool, It would be easy in a 44mm headroom to perfectly plan the airflow and thus force regular chassis airflow right through the CPU and GPU heatsinks on its way out. (As an illustrative example, you could file down an Artic Passive AM4 heatsink to fit.) Thus, you don't need any fans hugging the heatsink diretly, the fans can be elsewhere in the chassis, and as a consequence the chassis can permit heatsinks of reasonable mass.
    • Imagine a three-compartment pizzabox: along one edge sits three 120mm+ slim fans… one for the PSU compartment, one for the entire CPU compartment, one for the GPU compartment.
    • As an aside, it seems to me the small-form-factor market would be interested if someone made a mini-ITX motherboard with a boxed CPU heatsink that perfectly fits the motherboard in question, using all the free volume over its 170x170mm area (and for non-pizzaboxes, inviting an 170mm fan on top of it all)!

What links here

  • Things I (don't) care about
Created (3 years ago)

2023-Feb-26

Org-roam causes less complications than Denote🔗

#emacs

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.

SQL is good🔗

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,

  • I can add a backlinks section (discovering the backlinks requires a DB query!)
  • when there's a link somewhere to an external resource, and I happen to have a note about that resource, then transform that link into a link to the note (requires a DB query!)
  • give a CSS class to links based on the tags of the target note (requires a DB query!)

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!)

What links here

Created (3 years ago)
Showing 499 to 502