Bear Blog Trending Posts

my favourite unconventional animal

hidden (monocyte) — Thu, 30 Apr 2026 15:19:20 +0000

with me writing this in the last days of april i am really consistent when it comes to procrastination with carnival posts. anyhow for this month's bearblog carnival hosted by sage, i present you the wackiest animal of all time: the pumpkin toadlet.

picture of a pumpkin toadlet on a leaf by Ariovaldo Giaretta /CC BY-SA 2.5

why?

i mean it doesn't look all that weird on the outside. it's just a small little frog so why is it wacky? first of all have you seen how small it actually is? like here, look at it compared to a hand.

picture of a pumpkin toadlet compared to a hand by Diogo B. Provete/CC BY-SA 2.5

SEE HOW SMALL THAT IS???? also you might not realise but being this small comes with a lot of sacrifice, mostly in relation to how underdeveloped their inner ears are.

so just how underdeveloped are their ears?

gif of a pumpkin toadlet jumping from Richard Essner of Southern Illinois University Edwardsville

look at this gif of it jumping. it can jump alright but the landing? uhh not so much. it doesn't have the best semicircular canals to know just how it's moving in the air so it just jumps and hopes for the best. which usually means jumping and flopping about. it looks really goofy.

ears are supposed to hear

one critical function of the ear is the ability to hear (wow, astonishing) and with just how small their ears are this ability is also lacking so much so that they can't hear their own species mating calls. they just go off of the visual cues like vocal sac inflation, hand waving and mouth opening.

did i mention, poison?

yeah they are also highly poisonous. that's why they are able to get away with having not fully functioning systems. when we talk about an animal there are 3 major things that it needs to do in order to survive:

eat
move around
mate

in this animal 2 of those 3 major functions are impaired. make of that what you will.

My ideal blog

hidden (futureperfect) — Fri, 01 May 2026 00:09:00 +0000

I wish more blogs were like the old school online journals. People just talking about their day. Not too much detail, not too confident in their opinions, not trying to prove any points, etc.

This certainly is not an attack on anybody. My blog isn’t like that either. For some reason it just feels more natural to write the way you typically see others write on their blogs in the modern era(at least what I normally see on the discovery/trending pages on bear).

That old LiveJournal/Xanga/MySpace blog style of post just felt more personal, though. Less like an op-ed.

Maybe I’m just stuck in a nostalgia trap right now. But I want to start posting more like that.

Tomorrow is Friday. This week has been excruciatingly long. Let’s finish strong and cruise into the weekend!

Bye Spotify, hello MP3s

hidden (minimal) — Fri, 01 May 2026 13:03:00 +0000

I was on and off on different streaming subscriptions like Spotify or Apple Music for a long while. I would eventually cancel my subscriptions for 2 main reasons, price and the algorithm.

In Germany, Spotify premium it's 12.99€ per month. That's not a huge price tag, but it's also not insignificant. I felt ok paying for it when I was regularly listening to music, but often times I just had periods when I would just listen to a couple of hours per month. So the expense just felt a bit unjustified. The non premium version of Spotify is decent for a short listening session, but the ads get really annoying after a while.

The second reason is that somehow I would end up listening to always the same music. I have a small number of artists and albums that I really like and I would put them on rotation. Sometimes I would go on the discovery playlist, but somehow I would always end up quite disappointed by the recommendations! I am sure that that's probably just me, since I heard people really like the algorithm recommendations.

A couple of months ago I decided to do something different. I made a list of all the albums that I would really like to listen on a regular basis, and then ordered them from this used music/movies/books website. Here is a list of what I ordered:

Artist	Album
All Time Low	Nothing Personal
Blink-182	Enema of the State
Daft Punk	Random Access Memories
Eminem	The Marshall Mathers LP 2
Green Day	21st Century Breakdown
Green Day	American Idiot
Imagine Dragons	Night Visions
Linkin Park	Hybrid Theory
Linkin Park	Meteora
Nirvana	Best Of Nirvana
Red Hot Chili Peppers	Californication
Skrillex	Bangarang EP
Sum 41	All Killer No Filler
Sum 41	Chuck
Sum 41	Screaming Bloody Murder
The Beatles	1

As you can see I have a bit of a soft spot for early 2000s punk rock music, with a bit of other things that I listened growing up. For the 16 CDs I ended up spending 61,92€. Here are some pictures of them:

I am planning to do another order soon as soon as I have made my mind on what CDs I would like to add.

I considered using an old mp3 player that I have for playing them, but I decided to just use my phone and the VLC app. The app is not the best, but it's free, open source, not filled with ads and has at least the basics covered (Albums, playlist, random playing). Here is how it looks like:

I want to conclude with some thoughts on this process:

I really loved the search for the albums that I wanted to buy. I spent hours listening on YouTube to songs in order to decided what I liked most. It feels somehow more definitive when you invest some money on a CD versus just opening a streaming app.
The limited number of songs (approx 230 songs / 14h listen time) has not been boring. Actually quite the opposite. Not having the freedom to just skip for something else makes me just appreciate the song more and not have fomo. I often felt like Spotify was a tiktok-like experience.
Not having ads is great. Not having a recurrent fee is also great. Knowing that I now own the music and I don't need an internet connection to play them is just awesome.
Listening to a full album is something that I missed. There is something very relaxing to go from the first till the last song of an album and not just get the greatest hit.
I do still occasionally listen to the non-premium version of Spotify. The I find the desktop experience better and with less ads.
I often put on the radio when I want to listen something completely new. There are many radios which are ad-free (for example, DASDING) and do some small moderation while proposing top pop hits.
I have since the first order bought some other CDs from used stores around my city. The price it's even lower than online, usually ~1€. This makes for a fun and sporadic activity.
The CDs make for a nice decorative item our home, and a conversation starter, especially if it's an album that the guest likes as well.

Crescent - dataframe library in C23 built using safe_c.h and cforge

hidden (hwisnu) — Fri, 01 May 2026 04:25:00 +0000

This article contains a lot of images, if your browser failed to load them, try a different browser. Firefox based browsers looks to have issues loading the images.

Another note: it is a very long article, I was thinking of splitting it but this bearblog account is my documentation medium anyway, so I apologize in advance for readers getting annoyed at the length of this article.

Introduction - Building a Pandas Replacement in modern C23

I've been maintaining a side project called valueHunter ~ a screener for stock markets, used as internal tool for office work. It loads about 970 stocks, runs four screening strategies (undervalued growth, deep value, safe tech, composite), then does about 14 DataFrame analytics operations on the result. Basically a small data pipeline.

The original version was Python with Pandas. It worked fine, but for someone used to work with low level languages, Python dataframe libraries such as Pandas and Polars left me looking for more speed. Added that I'd been wanting to build something finance-related project in modern C23 for a while, so one weekend I thought: "let me just build my own dataframe in C23." After all I've been building quite a lot of my internal tools in C, Zig and Rust. Well, let's just say that weekend (around 4 months ago) turned into a rabbit hole. I ended up with a custom DataFrame library called Crescent, built using my own custom build system (cforge), while implementing safe_c.h standard as the header file, and even though the performance result is kinda expected, but still it surprised me.

The Numbers First

Three libraries, one pipeline, four data sizes. The same code path: load CSV → 4 screening strategies → 14 DataFrame operations. All produce identical output.

Small data (970 rows, 430 KB)

That's ~49x faster than Pandas and ~32x faster than Python/Polars (Python numbers from prior measurement, marked ††).

But fast at 970 rows is expected. What matters is how it scales.

Scaling to 1.9 million rows (866 MB)

Resource breakdown by dataset

Crescent wins at every size. On small data it dominates (10.8x faster than Rust). On large data it still leads ~ 3.3x faster at 1.9M rows, using 505% CPU (up from 107% at small sizes) and 2.6 GB RAM vs Rust's 5.0 GB. Rust burns 300-800% CPU between the smallest and largest data sizes ~ average 2-3x more cores for a slower result.

At 1.9M rows, Crescent uses half the RAM and much less CPU compared to Rust/Polars while running faster.

The question everyone asks: "what about a real-time webapp?" The C binary processes the full pipeline in 12 ms. Rust takes 130 ms. Python takes 400+ ms. For a webapp endpoint called on every page load, 12 ms vs 130 ms is the difference between "instantly" and "noticeable lag."

Wait, Isn't C Supposed to Be Hard?

Yes and No. With the tools available in modern C, it's less hard than it used to be. Here's how Crescent works.

The setup has three layers:

Layer 1: safe_c.h ~ the utility belt

Read more on safe_c.h here safe_c.h is a single-header C library that adds things C should have had from the start:

RAII macros via __attribute__((cleanup)) ~ resources auto-clean when they go out of scope
Type-safe vectors via DEFINE_VECTOR_TYPE(name, type) ~ basically generics for dynamic arrays
Result/Optional types ~ Result<T, Error> monads without the ceremony
StringView, Span, smart pointers ~ stuff you'd recognize from Rust or C++

Here's what it looks like in practice:

// File auto-closes when scope exits
{
    AUTO_FILE(f, "data.csv", "r");
    // use f...
}  // fclose() called automatically

// Vector with typed API
DEFINE_VECTOR_TYPE(Stock, Stock)
StockVector vec;                // vec.data, vec.size, vec.capacity
Stock_vector_init(&vec);
Stock_vector_push(&vec, my_stock);
Stock_vector_free(&vec);        // or let AUTO_TYPED_VECTOR handle it

The AUTO_DataFrame, AUTO_Dsl, AUTO_DFQ_SCOPE macros you'll see later are all built on safe_c.h's CLEANUP mechanism. Without it, every single error path would need manual goto cleanup boilerplate. With it, the code looks almost as clean as Python.

Layer 2: Crescent ~ the DataFrame library

Crescent or libvh_df is the core of this project. It's a pure-C DataFrame library (~10,000 lines of code) that implements:

Columnar storage (f32, f64, i32, i64, str, dictionary-encoded str)
CSV reader (multi-threaded, RFC-4180 compliant, bump-arena allocation ~ zero heap per row)
SIMD aggregations (sum, min, max with AVX2)
GroupBy, aggregate, window rank, rolling windows
Pivot tables, merge/join, melt
Correlation matrix, z-score, binning (cut), describe, value counts
String operations (contains, startswith, endswith, lower, upper)
A chainable DSL for building pipelines

The DSL is the part that makes it usable. Here's a value-quality screen:

AUTO_DFQ_SCOPE(dfs, q, out);
q = dfq_from_frame(base);
dfq_query(q, "per > 0 AND roe > 0.08 AND pbv > 0 AND der < 1.5 AND month > -0.10");
dfq_rank(q, "sector", "per", "sector_per_rank", true);
dfq_sort_asc(q, "per");
dfq_head(q, 20);
dfq_assign_mul_scalar(q, "ROE%",   "roe",   100.0f);
dfq_assign_mul_scalar(q, "Month%", "month", 100.0f);
DFQ_SELECT(q, "code", "stock", "sector", "per", "ROE%", "der", "Month%", "sector_per_rank");
DFQ_END(q, out);

And the equivalent in Pandas:

result = (
    df.query("PER > 0 and `ROE %` > 0.08 and PBV > 0 and DER < 1.5 and Month > -0.10")
    .assign(
        sector_per_rank=lambda x: x.groupby('Sector')['PER'].rank().astype(int),
        **{
            'ROE%': lambda x: x['ROE %'] * 100,
            'Month%': lambda x: x['Month'] * 100,
        }
    )
    .sort_values('PER')
    .head(20)[['Code', 'Stock', 'Sector', 'PER', 'ROE%', 'DER', 'Month%', 'sector_per_rank']]
)

You still need AUTO_DFQ_SCOPE, dfq_from_frame, and DFQ_END around the edges. But the middle reads like Pandas. dfq_assign_mul_scalar replaces the old dfq_assign_scalar(q, "ROE%", "roe", VHDF_BINOP_MUL, 100.0f) ~ same work, none of the enum noise. Top to bottom, it flows like a method chain.

The biggest friction point was arithmetic expressions. Before the current version, computing a momentum score looked like:

dfq_assign_scalar(q, "_w_week",  "week",    VHDF_BINOP_MUL, 0.10f);
dfq_assign_scalar(q, "_w_month", "month",   VHDF_BINOP_MUL, 0.40f);
dfq_assign_scalar(q, "_w_3mo",   "f_3_0mo", VHDF_BINOP_MUL, 0.30f);
dfq_assign_scalar(q, "_w_ytd",   "ytd",     VHDF_BINOP_MUL, 0.20f);
dfq_assign(q, "_t1", "_w_week",  VHDF_BINOP_ADD, "_w_month");
dfq_assign(q, "_t2", "_w_3mo",   VHDF_BINOP_ADD, "_w_ytd");
dfq_assign(q, "momentum_score", "_t1",      VHDF_BINOP_ADD, "_t2");

Seven calls for one formula. That's where I added dfq_assign_expr, a tiny recursive-descent expression parser built into the DSL:

dfq_assign_expr(q, "momentum_score", "week*0.10 + month*0.40 + f_3_0mo*0.30 + ytd*0.20");

One call. The parser handles +, -, *, /, parentheses, and proper precedence. Under the hood it builds the same temporary columns as the manual version, then tears them down automatically. You never see the scaffolding.

Beyond dfq_assign_expr, the DSL now includes purpose-built shortcuts that a typical screener function is now six readable lines:

DataFrame* screen_safe_tech(const DataFrame *base) {
    AUTO_Dsl(q);
    q = dfq_from_frame(base);
    dfq_and_where_str_eq(q, "sector", "Technology");
    dfq_and_where_gt(q, "roe", 0.15f);
    dfq_and_where_gt(q, "npm", 0.10f);
    dfq_and_where_lt(q, "der", 0.80f);
    return vhdf_collect_or_null(q);
}

Line by line, that reads like a Pandas boolean mask.

The Pandas equivalent is:

df[
    (df['Sector'] == 'Technology') & 
    (df['ROE %'] > 0.15) & 
    (df['NPM'] > 0.10) & 
    (df['DER'] < 0.80)
]

Layer 3: cforge ~ the build system

Read more on cforge here cforge is part build tool, part code generator, and part linter. The important part for Crescent is that it removes the repetitive C glue around schemas, dataframe adapters, and reflection.

Three commands handle everything:

`cforge gen-struct <csv> <Name>`

Reads your CSV file, samples ~100 rows, and infers C types for each column by examining actual values:

Integer within i32 range (~±2 billion) → i32; larger → i64; overflow → char*
Float (contains .) → f32
"true"/"false" → bool
Everything else → char*

Type conflicts resolve by widening ~ int -> float -> string. Column names are sanitized: lowercase, non-alphanumeric characters replaced with _, and C keyword collisions get an f_ prefix.

Output: include/<name>_auto.h, containing a typed C struct that matches the CSV plus the small helper macros and vector boilerplate needed to use it.

The implementation template lives in include/csv_to_struct_py.h, but the relevant part for day-to-day work is simple: point it at a CSV and you get a usable C struct instead of writing one by hand.

After generation, gen-struct automatically chains into gen-df-col ~ you don't need to run both commands separately.

`cforge gen-df-col <Name>`

Reads include/<name>_auto.h and emits the dataframe adapter layer:

include/dataframe_col.h
src/dataframe_col.c
include/core.h + src/core.c

This is the code that wires a typed row schema into Crescent's columnar frame representation and CSV ingest path. In practice it means I do not hand-write 50+ column append calls or schema setup code. The implementation template lives in include/gen_df_col_py.h.

`cforge reflect`

Generates the reflection and serialization glue into generated_reflection.c and generated_macros.h. That covers the boring support code around things like cloning, printing, CSV/JSON conversion, field metadata, and typed access helpers. The implementation template lives in include/reflection_generator_py.h.

Auto-generation does the heavy lifting for C. The schema glue, reflection helpers, and CSV integration are generated; the human writes the actual pipeline and application logic. That is a large part of why Crescent is practical to build in C at all.

The Three-Stage Build

cforge build main

This generates a build/dynamic_dev.mk Makefile and runs three stages:

Stage 1 ~ Static Analysis:

gcc -std=c23 -fanalyzer -Wall -Wextra -Wpedantic -Wconversion -Wshadow \
    -Wformat=2 -Wimplicit-fallthrough -D_POSIX_C_SOURCE=202308L

The -fanalyzer flag runs GCC's static analyzer on every compilation unit. Catches null dereferences, use-after-free, buffer overflows, and double-free at compile time. Objects go to build/objs_ana/.

Stage 2 ~ Sanitizer:

gcc -ggdb -fno-omit-frame-pointer -fsanitize=address,undefined

Builds with AddressSanitizer (ASAN) and UndefinedBehaviorSanitizer (UBSAN). After linking, cforge executes the binary with a 5-second timeout. If the sanitizer catches a heap buffer overflow, use-after-free, or integer overflow, the binary crashes with a stack trace pointing to the exact file and line. The release build does not proceed until the sanitizer passes. Objects go to build/objs_san/.

Stage 3 ~ Release:

gcc -O2 -march=native -D_FORTIFY_SOURCE=3 -fstack-protector-strong \
    -fstack-clash-protection -fcf-protection=full \
    -fstrict-flex-arrays=3 -fno-plt -fno-math-errno -fno-trapping-math \
    -fPIE -pie -Wl,-z,relro,-z,now

Full hardened release: buffer overflow detection (FORTIFY_SOURCE=3), stack canaries, stack-clash protection, control-flow integrity (CET shadow stack), hardened linker relocations (-z relro,now), PIE for ASLR. Output: build/main. Objects go to build/objs_rel/.

Note: the Release stage only use -O2, not -O3 as the most aggressive optimization

Incremental compilation is handled by SHA-256 hashing: each .c file gets its hash stored in build/.hash_<path>. On the next run, if a source file's hash hasn't changed, its .o is reused across all three stages. Changing a single file triggers recompilation of only that file ~ typically under 1 second. -MMD -MP generates Make dependency files so header changes propagate correctly.

Why all these hassle, you might ask? Correctness and safety is super important in finance (my main domain), hence I'm applying what's been the standard in libc++ and some more. You can read about libc++ here

Thousands of bugs squashed, 30% drop in baseline segfault rate, out-of-bounds access, UB-triggering precondition violation. All these at 0.3% performance cost at most. It's a no-brainer option, you'd be crazy if you don't use this.

Syntax Comparison: Same Logic, Three Languages

Here's how the same operation looks in each:

Filter + Sort + Head

Pandas:

result = (
    df
    .query("PER > 0 and `ROE %` > 0.08 and PBV > 0 and DER < 1.5 and Month > -0.10")
    .assign(sector_per_rank=lambda x: (
        x.groupby('Sector')['PER']
         .rank()
         .astype(int)
    ))
    .sort_values('PER')
    .head(20)
)

Crescent (C DSL):

AUTO_DFQ_SCOPE(dfs, q, out);
q = dfq_from_frame(base);
dfq_query(q, "per > 0 AND roe > 0.08 AND pbv > 0 AND der < 1.5 AND month > -0.10");
dfq_rank(q, "sector", "per", "sector_per_rank", true);
dfq_sort_asc(q, "per");
dfq_head(q, 20);
dfq_assign_mul_scalar(q, "ROE%",   "roe",   100.0f);
dfq_assign_mul_scalar(q, "Month%", "month", 100.0f);
DFQ_SELECT(q, "code", "stock", "sector", "per", "ROE%", "der", "Month%", "sector_per_rank");
DFQ_END(q, out);

If you want the performance-first form, Crescent also offers typed helpers that skip the string parser (dfq_query) entirely:

dfq_and_where_gt(q, "per", 0.0f);
dfq_and_where_gt(q, "roe", 0.08f);
dfq_and_where_gt(q, "pbv", 0.0f);
dfq_and_where_lt(q, "der", 1.5f);
dfq_and_where_gt(q, "month", -0.10f);

For pure numeric AND filters both paths land on the same fused predicate-execution engine. The typed version avoids parsing, trimming, and token conversion, but on large frames the scan dominates and the gap is small. Use dfq_query(...) when mirroring Pandas .query(...) examples, and dfq_and_where_* / dfq_or_where_* when you want the typed C-native surface.

Polars via Rust:

  let result = base.clone().lazy()
      .filter(
          col("PER").gt(lit(0.0))
              .and(col("ROE %").gt(lit(0.08)))
              .and(col("PBV").gt(lit(0.0)))
              .and(col("DER").lt(lit(1.5)))
              .and(col("Month").gt(lit(-0.10))),
      )
      .with_columns([
          col("PER")
              .rank(
                  RankOptions {
                      method: RankMethod::Ordinal,
                      descending: false,
                  },
                  None,
              )
              .over([col("Sector")])
              .alias("sector_per_rank"),
      ])
      .sort(["PER"], Default::default())
      .limit(20)
      .collect()?;

Filter + Top-K + CSV export

This is the same workflow as the "export top value picks" block in valueHunter.

Pandas:

value_picks = (
    df[df['PER']
        .between(0.01, 15.0) 
        & (df['ROE %'] > 0.08) 
        & (df['DER'] < 1.5)]
    .nsmallest(20, 'PER')
)
value_picks.to_csv('value_picks_pandas.csv', index=False)

Crescent (C DSL):

AUTO_DFQ_SCOPE(dfs14, q14, export14);
q14 = dfq_from_frame(base);
dfq_and_where_between(q14, "per", 0.01f, 15.0f);
dfq_and_where_gt(q14, "roe", 0.08f);
dfq_and_where_lt(q14, "der", 1.5f);
dfq_nsmallest(q14, 20, "per");
DFQ_SELECT(q14, "code", "stock", "sector", "per", "per_rank", "Momentum_Score", "roe", "der");
/* Materialise once; use the frame for both CSV export and display. */
DFQ_END(q14, export14);
if (export14) {
    if (vhdf_frame_to_csv(export14, "value_picks.csv"))
        printf("\n[Export] Wrote %zu value picks to value_picks.csv\n",
               export14->num_rows);
}

Polars via Rust:

let value_picks = base.clone().lazy()
    .filter(
        col("PER").gt_eq(lit(0.01))
            .and(col("PER").lt_eq(lit(15.0)))
            .and(col("ROE %").gt(lit(0.08)))
            .and(col("DER").lt(lit(1.5))),
    )
    .sort(["PER"], Default::default())
    .limit(20)
    .collect()?;

let mut file = std::fs::File::create("value_picks_polars.csv")?;
CsvWriter::new(&mut file).finish(&mut value_picks.clone())?;

The performance story here is the same as the previous example: the typed dfq_and_where_* filters are the faster C-side surface, because they go straight into the deferred/fused numeric predicate path. A dfq_query(...) version would still be valid, but it would pay a small extra parsing cost up front for no gain in the actual filter execution.

Pandas is the shortest. Crescent is explicit but still compact. Rust/Polars is serviceable, but once CSV export enters the picture the chain expands into extra builder and I/O ceremony.

Computed Column

Pandas:

df['Momentum_Score'] = (
    df['Week']*0.10 + 
    df['Month']*0.40 + 
    df['3.0Mo']*0.30 + 
    df['YTD']*0.20
)

Crescent (C DSL):

dfq_assign_expr(q, "momentum_score",
    "week*0.10 + month*0.40 + f_3_0mo*0.30 + ytd*0.20");

Polars via Rust:

.with_columns([(
      col("Week")  * lit(0.10)
    + col("Month") * lit(0.40)
    + col("3.0Mo") * lit(0.30)
    + col("YTD")   * lit(0.20)
).alias("Momentum_Score")])

Pandas and C are one-liners. Rust requires lit() wrapping every scalar and explicit .alias().

GroupBy + Aggregate

Pandas:

df.groupby('Sector')['PER'].mean().rename('avg_per').reset_index()

Crescent (C DSL):

dfq_groupby(q, "sector");
dfq_groupby_mean(q, "per", "avg_per");

Polars via Rust:

.group_by(vec![col("Sector")]).agg([col("PER").mean().alias("avg_per")])

ISIN filter

Pandas:

df[df.Sector.isin(['Finance', 'Technology'])]

Crescent (C DSL):

DFQ_ISIN(q, "sector", "Finance", "Technology");

Polars via Rust:

.filter(col("Sector").eq(lit("Finance")).or(col("Sector").eq(lit("Technology"))))

No native is_in for the C DSL ~ just a variadic macro. Rust/Polars requires chaining .eq().or().eq() for simple membership checks.

The Verdict on Syntax

Ranking each on compactness and clarity:

Pandas is still the clearest and most compact. Fifteen years of refinement shows. But the C DSL has closed a lot of that gap.

Crescent (C23) is now genuinely approachable. dfq_and_where_gt(q, "roe", 0.15f) reads like a Pandas boolean mask; dfq_or_where_gt(...) gives the matching OR form when you need it. dfq_groupby_mean(q, "per", "avg_per") self-documents the operation ~ no enum values to memorize. DFQ_SORT(q, VHDF_DESC("sector_score"), VHDF_DESC("value_score")) reads as clearly as .sort_values(by=['sector_score','value_score'], ascending=False). The VHDF_BINOP_* enums that used to litter every arithmetic call are now hidden behind purpose-built shortcuts.

The remaining gap is the scaffolding: AUTO_DFQ_SCOPE, dfq_from_frame, DFQ_END add ~3 lines per pipeline. And the mutable builder means you can't chain operations like Pandas ~ each is a separate statement. But once you know the RAII scope pattern (about 5 minutes of learning), the DSL reads top-to-bottom like a method chain.

Rust/Polars is the most verbose. Every operation requires ceremony: lit() wrapping every scalar, RankOptions { method: RankMethod::Ordinal, descending: false } for a sort direction, .clone().lazy() and .collect() on every chain, .alias() for every column rename. The type system does catch real bugs at compile time. But the API fights you on simple things. A rank call in C takes four positional arguments. In Rust it's a struct + enum + method chain. You'll need a few hours before it feels natural.

Bottom line: Pandas is the most intuitive. The C DSL is the most surprising ~ it shouldn't be this readable for C, but it is. A Pandas developer can read a Crescent screener and understand every line without explanation. Rust/Polars gets the job done but makes you work for it.

Memory

Pandas uses about 110 MB for the small dataset (970 rows). Crescent uses 2-4 MB. The difference comes down to:

Bump arena allocation ~ the CSV parser allocates one large arena (~128 KB stack buffer + linked slabs for overflow) and doles out memory linearly. No per-field malloc. Freeing is a single arena reset.
Columnar storage ~ float arrays are contiguous float* blocks, not arrays of Python objects with refcounting overhead.
No interpreter ~ no Python object overhead per value (28+ bytes per Python float vs 4 bytes per C float).
No GC ~ deterministic allocation, no collection pauses. The pattern is "allocate arena, process, free arena".

Where the speed comes from

The ~49x speedup (vs Pandas) isn't from one thing. It's a stack of small wins:

Multi-threaded CSV parsing ~ Crescent splits the file into chunks, parses each chunk on a separate thread, then merges. The CSV parser itself is RFC-4180 compliant with quote escaping, arena allocation, and zero heap allocations per field. Pandas parses CSV on a single thread.
Memory locality ~ Columnar storage means all ROE values sit in a contiguous float* array. A filter(roe > 0.15) touches one cache line per 16 values. Row-oriented storage (Python list of tuples) scatters values across memory.
No refcounting ~ Every Python float access increments and decrements a reference count. Over 970 rows × 50 columns × multiple operations, this dominates the profile. Pandas user CPU is 2.48 s for 0.59 s wall time ~ it's saturating over 4 cores with refcounting and GC overhead.

Rust/Polars: The Blazingly Mediocre Part

After seeing Crescent hit 12 ms, I thought: "Okay, but what if we just use Polars from Rust directly? No Python, no GIL, no FFI ~ pure native speed." I rewrote the entire screener in Rust using polars 0.53. Identical output, 55 columns, same data to the last decimal.

Here's the full picture across all data sizes:

Rust/Polars loses at every data size. There is no crossover point where it catches up. The professional, native-compiled, battle-tested DataFrame library loses to a side-project C program on small data (10.8x), medium data (2.2x), and large data (3.3x).

The resource comparison at 1.9M rows:

The numbers are clear: at 970 rows Crescent finishes in 12 ms while Rust/Polars takes 130 ms. At 1.9M rows it's 4.2 s versus 13.81 s. Rust is not the bottleneck here ~ the architecture is.

Crescent stores floats as plain float*: a pointer and a length. No Arrow buffers, no null bitmaps, no offset tables, no buffer metadata. When a filter says roe > 0.15, it generates a tight loop over a contiguous array. The compiler vectorizes it, the prefetcher keeps up, and the result is a stream of indices. CPU usage stays low: 107% at small data, 505% at 1.9M rows.

Polars uses Arrow-backed columns where every access traverses buffer metadata, null bitmaps, and offset tables. For 970 rows, the query optimizer's cost model alone takes more time than the actual filter work. Polars CPU usage hits 301% on small data and 804% at 1.9M rows ~ nearly 3x more cores on average for a slower result. The abstractions are sound in general, but at this scale they add indirection without delivering compensating speed.

What went wrong?

Polars brought a query optimizer, Arrow buffers, and a thread pool to a street fight. For 970 rows, the optimizer's cost model takes more time than the actual filter. For 1.9M rows, Arrow's buffer metadata, null bitmaps, and offset tables add indirection that C's raw float* arrays don't have.

Crescent stores floats as float*. No bitmaps, no metadata, no indirection. Just a pointer and a length. When a filter says roe > 0.15, it generates a loop over a contiguous float array. No null checks, no offset calculation, no buffer traversal. The compiler vectorizes it, the prefetcher keeps up, and the result is a stream of passing indices.

Polars' Arrow-backed columns add indirection at every access. For small data, the overhead is negligible. For medium data, it starts to add up. For large data, the optimizer and parallelism usually compensate ~ but not enough to catch Crescent.

Why no benchmark with larger dataset? Actually it was Polars in Rust that stopped me doing that, since using the 866MB csv file stutters my system heavily, up to the point I need to close down my other apps / browsers...quite embarrassing if you ask me, Crescent in C23 did not have this issue, I can use my system just fine while doing the benches. Now imagine what a 5-10GB file would do to Polars in Rust.

I often do benches in both quiet and noisy system, in my use case the noisy test is more relevant since I'm using my machine not only for writing programs, but also monitoring the stock markets, entering algorithm trades, running several data scraping bots. Here's what I wrote in my cgrep article:

So, do you close your other apps when you're running a program? Or do you keep other apps running? Exactly my point! Too many benchmarks do not consider the durability of a program, I think controlled noisy bench should be the normal.

Is Rust/Polars ever faster?

At no data size tested (430 KB to 866 MB) did Rust/Polars beat Crescent. The gap narrows at 10 MB (2.2x) but widens again at larger sizes (3.3x at 1.9M rows) as Crescent's multi-threaded operations scale with data.

Under the Hood: Why Crescent's engine is faster

Let's do a deep dive into Crescent's design, you'll see why putting time into application architecture is super worth it. Crescent wins because the execution engine is tuned for a very specific shape of workload: dense numeric columns, repeated fixed-schema pipelines, low-cardinality categorical strings, and a DSL that carries row selections around as index views instead of copying whole frames after every step.

Polars is solving a broader problem. It supports Arrow semantics, null bitmaps, chunked arrays, lazy planning, type coercion, streaming execution, and a much more general optimizer surface. Crescent solves a narrower problem and exploits that narrowness aggressively.

How the Crescent engine does it:

1. The DSL is view-first, not frame-first

dfq_from_frame() does not clone the input frame. It starts with:

source = frame
view = NULL meaning "full-range sentinel"
view_n = frame->num_rows

Most pipeline steps operate on an index view, not on copied columns. A filter is usually just shrinking a size_t row-index vector.

The key mechanism is deferred predicate fusion:

dfq_and_where_gt() / dfq_and_where_lt() end up in dfq_filter()
dfq_filter() does not execute immediately; it appends a PendingPred into dsl->pending_preds
dfq_flush_pending() executes the entire AND chain in one fused pass

So this:

dfq_and_where_gt(q, "per", 0.0f);
dfq_and_where_gt(q, "roe", 0.08f);
dfq_and_where_lt(q, "der", 1.5f);

does not run three full dataframe filters. It compiles into one tight kernel over the active row set. Each worker gets a pointer to the source frame, the current view, a slice of rows, the full PendingPred[] array, and a local output buffer of passing indices. fused_filter_worker() evaluates all predicates for each row before deciding whether to push that row index. The engine only allocates the final surviving row-index vector once.

This is a very different cost model from "evaluate expression node A, materialize, then B, materialize, then C."

2. Projection stays shallow for as long as possible

Older dataframe libraries often lose performance by turning metadata operations into data copies. Crescent avoids that in the fast path: vhdf_select_columns() aliases columns instead of copying them. vhdf_drop_columns() aliases the kept columns. vhdf_rename_columns() aliases the same backing storage with a different column name.

The implementation uses refcounted column aliasing through vhdf_column_alias(), shared_from, and ref_count. In practice, select, drop, and rename are mostly metadata edits plus a reference-count bump.

The DSL's projection pushdown keeps that advantage alive. dfq_select() can project the source first and only apply the row view afterward through dfq_project_source_view(). If the final report only prints 6 columns, Crescent tries hard not to drag 55 columns through the last materialization step.

This is one of the biggest reasons the valueHunter pipelines (Crescent's project implementation) stay fast.

3. Materialization is index-gather, and it is parallel

Eventually some operations do need a real frame. When that happens, Crescent materializes through vhdf_frame_take_indices().

It avoids row-by-row append loops. Instead it works in two phases: allocate destination columns up front at the exact required row count, then gather selected rows into those columns. The gather parallelizes across columns when the problem size is large enough.

For numeric columns on x86, the gather path uses AVX2 helpers where available. For large outputs, Crescent spreads the gather work over multiple threads. For string columns it gathers pointers, not heap-allocated string objects. The destination frame retains the source StringArena, so the gather does not duplicate string payloads.

This makes "filter -> collect" much cheaper than a generic deep-copy materializer.

4. Top-k avoids full sort whenever the query only needs top-k

This is a big one in finance workloads.

If the pipeline asks for:

dfq_nsmallest(q, 20, "per");

Crescent does not sort the full active dataset unless it has to. dfq_nsmallest() goes through dfq_topk():

build (value, original_idx) pairs
do multi-threaded pair extraction for large views
run vhdf_select_topk() to partition/select the best k
sort only those k pairs for final presentation

So the cost is closer to O(n) selection plus O(k log k) final ordering, not O(n log n) full sort.

This is the right trade for screener-style outputs where the user wants "best 20 by PER", not "fully sorted 1.9 million row frame."

5. String handling is designed around pointer identity and dictionary codes

Crescent keeps string overhead low by treating them as interned pointers rather than general heap objects.

During CSV ingest, strings go into a StringArena. Two things happen: repeated equal strings often collapse to the same pointer, and string lifetime becomes arena lifetime instead of per-cell lifetime. This lets several operations use pointer identity as a fast-path before falling back to strcmp.

After ingest, vhdf_frame_auto_dict_encode() can convert low-cardinality string columns from VHDF_COL_STR to VHDF_COL_DICT_STR:

one u32 *codes array per column
one const char **dict array of unique values

From there sector == "Technology" becomes integer-code comparison. isin over categorical columns becomes code-set membership. Group keys become much cheaper to hash and compare.

For valueHunter, columns like sector, industry, and mc_class are exactly the shape where this pays off.

6. CSV ingestion is built for fixed-schema throughput, not generic row objects

The CSV path is one of Crescent's least glamorous but most important wins.

The engine does several things that matter: pread()-based chunking instead of a mutex-serialized read() loop, pre-planned chunk boundaries before worker execution, quote-free fast path with edge-only boundary scanning, SIMD helpers for record boundary detection and comma splitting, 2 MiB-aligned worker buffers, one StringArena per worker reused across chunks, and row-count hints pushed into the schema adapter so columns can reserve near-final capacity immediately.

The field-adapter path means the parser writes directly into dataframe columns. There is no intermediate struct Row, no boxed scalar representation, and no "parse into temporary rows, then convert rows into columns" phase.

This is a major reason Crescent wins both wall time and RSS on the large CSV runs.

7. The numeric representation is deliberately narrow

Most of the stock-screener numeric columns are stored as f32, not f64.

So: half the bandwidth, twice as many values per cache line, lower gather/scatter cost, and lower RSS pressure through the whole pipeline.

I made this choice because the domain allows it. For this workload, single-precision is enough. Crescent takes the win instead of paying for double precision everywhere "just in case."

This compounds with the other choices: contiguous float *, no Python object headers, no refcounts, no validity bitmap checks in the dense fast path, and fewer bytes touched per row during filter, rank, sort, and top-k.

8. SIMD is used where the loops are actually hot

There is more SIMD in Crescent than the earlier summary makes obvious.

I did not try to vectorize everything. I targeted the loops that show up over and over in dataframe workloads:

numeric reductions
numeric filters
element-wise arithmetic
correlation
gather/materialization
CSV structural scanning

On x86, the implementation uses runtime dispatch with __builtin_cpu_supports(...) and function-level __attribute__((target(...))) specializations. That means the same binary can:

run AVX2 kernels when the CPU has AVX2
use AVX2+FMA for correlation
use AVX-512 for parts of the CSV scanner when available
fall back to scalar code everywhere else

So the fast path is opportunistic, not mandatory.

Reductions

The obvious starting point is reductions:

vhdf_sum_f32_avx2()
vhdf_min_f32_avx2()
vhdf_max_f32_avx2()
vhdf_sum_i32_avx2()
vhdf_min_i32_avx2()
vhdf_max_i32_avx2()

These work directly on contiguous typed arrays:

8 f32 lanes at a time with __m256
8 i32 lanes at a time with __m256i

For i32 sum, Crescent widens to i64 immediately with _mm256_cvtepi32_epi64(), so the SIMD accumulator does not overflow on long scans. That detail matters. It is the difference between a benchmark kernel and something I can use in a real dataframe engine.

Filters

The SIMD filter path is more important than the reduction path.

The kernels:

filter_f32_avx2()
filter_f64_avx2()
filter_i32_avx2()

do not build a boolean mask array and compact it later. They:

load a vector of values
compare against a broadcast threshold
turn the compare result into a bitmask with movemask
walk the set bits with ctz
write passing row indices directly into the output index buffer

That matches Crescent's engine design perfectly. The natural output of a filter in Crescent is not another column or another bitmap. It is a compact row-index list that the DSL can carry forward as the active view.

So the SIMD path is doing two useful things at once:

faster comparisons per iteration
no extra pass to convert booleans into row indices

Element-wise arithmetic

The same pattern shows up in the arithmetic helpers:

vhdf_scalar_op_f32_avx2()
vhdf_binary_op_f32_avx2()
vhdf_clip_f32_avx2()
vhdf_diff1_f32_avx2()

These are the kernels behind operations like:

multiply a column by a scalar
add or subtract two columns
compute first differences
clip values into a range

Because the numeric columns are plain float * arrays, the loop is just "load eight floats, apply the op, store eight floats." There is no per-element dispatch and no object layer in the middle.

Correlation uses FMA

The correlation path is one of the more technical SIMD kernels.

Crescent has a dense f32 fast path:

has_nan_f32_avx2() first checks whether either input contains NaNs
if not, vhdf_col_corr_f32_fma() computes Pearson correlation with AVX2+FMA

The implementation is split deliberately:

the means are accumulated with widened f64 sums
covariance and variance are accumulated with _mm256_fmadd_ps

So the hot inner loop gets fused multiply-add while the mean computation keeps better numerical behavior than naive f32 accumulation.

That is not a general-purpose linear algebra engine. It is a targeted statistics kernel for the dataframe operations I actually run.

Gather is vectorized too

One easy thing to miss is that Crescent also vectorizes part of materialization.

When a filtered frame finally has to become a real dense frame, vhdf_frame_take_indices() uses:

gather_f32_avx2()
gather_f64_avx2()

under the hood for numeric columns, via _mm256_i32gather_ps() and _mm256_i32gather_pd().

So Crescent is not only fast at contiguous scans. It also accelerates the next bottleneck that usually appears after filtering gets cheap: gathering selected rows back into dense columns.

The CSV parser uses SIMD too

Some of the CSV speedup is from multithreading and arenas, but not all of it. The parser also uses AVX2 and AVX-512 for structural scanning:

vhdf_mem_has_byte_*() checks whether a chunk contains quotes or delimiters
vhdf_find_next_newline_*() finds newlines quickly
vhdf_csv_record_len_structural_*() finds record boundaries while respecting quoted newlines
vhdf_csv_split_fields_noquote_*() finds comma positions in quote-free rows

These kernels scan 32 or 64 bytes at a time, build masks, then use bit scans to locate the interesting byte positions.

That is exactly the kind of work SIMD is good at:

delimiter detection
quote detection
structural scanning before the parser drops into scalar cleanup logic

So when Crescent wins on CSV load time, it is not just "threads plus arenas." It is also using vector instructions to reduce the byte-scanning cost before field conversion even starts.

Why SIMD pays off here

SIMD only helps if the surrounding engine lets it stay close to the real bottleneck.

Crescent's layout makes that possible:

dense homogeneous arrays
low per-element metadata cost
no validity bitmap in the common dense path
row-index outputs from filters instead of heavyweight intermediate objects
fewer abstraction layers between the DSL call and the hot loop

That means the vector kernels are doing actual data work instead of spending half their time navigating metadata.

9. Threading is conservative on small data and aggressive on large data

One reason Crescent does so well at 970 rows is that it avoids acting like a distributed systems project for a toy dataset.

Examples:

dfq_flush_pending() stays single-threaded below 4096 active rows
gather materialization only goes multi-threaded when num_columns * num_rows crosses a threshold
sort parallelism is only enabled for large enough views
dfq_from_frame() scales the compute thread count from the in-memory frame size instead of blindly using all cores

So Crescent avoids paying thread-pool and scheduling overhead when the data is tiny, but it still fans out once the frame is large enough for the extra coordination to amortize. This design choice is often forgotten, amateurish mindset would instead do "put the pedal to the metal" mentality ~ meaning using every single cores available in a system.

This is exactly how my cgrep managed to beat ripgrep using much less resources (especially RAM). You can read about cgrep here.

This explains a lot of why the 970-row case is absurdly fast while the 1.9M-row case still scales.

10. This benchmark fits Crescent's fast path unusually well

This is also where I need to be honest.

Crescent wins here because this benchmark sits right in its sweet spot: dense numeric columns, a fixed schema, the same pipeline run repeatedly, mostly non-null data, low-cardinality categorical strings, and top-k outputs rather than arbitrary joins or nested types.

Polars is built for a broader world. It handles nested types, heavy null propagation, ad-hoc expressions, Parquet-first analytics, and large multi-way joins over heterogeneous sources. For those workloads, its abstractions pay for themselves. This workload is not one of them.

This workload is a stock screener with known columns and repeated filters. Crescent is optimized for exactly that.

The gap exists because Crescent's engine simply is more efficient: fewer layers, fewer transient allocations, fewer bytes moved, fewer metadata checks in hot loops, and fewer full-frame materializations. Rust itself is not the bottleneck. The design architecture is..this connects to the early section of what I said about it is worth it to take time to think about program's design.

The benchmark I did was run multiple times (~ not less than 30x) and they always paint the same picture. By running it multiple times, that means the programs were run in a warm cache condition. Here I want to point out Polars' data structure / cache locality / memory management left a lot of things to be desired. The evidence were clear: massive page faults and I/O operations even after running the same program with the same data multiple times one after the other.

Crescent on the other hand, on the second run I/O ops got down to mostly zero comparatively very low page faults ~ implies proper cache locality which in turn implies proper data structure and memory management. Crescent's flat arrays and bump-arena allocator walk fewer pages. Polars' chunked buffers and metadata-heavy columns keep the kernel busy even when the data is already in RAM.

That is the real performance story.

Note: above is a warm-run of the benchmark, note how Crescent is very clean with zero I/O ops and much less Page Faults compared to Polars-Rust, which have loads of I/O ops and Page Faults even on a warm cache.

Note on the benchmarks using hyperfine and zoop below, I needed to close all other apps coz Polars would run super slow and the elapsed time would become around 19-20 seconds, compare that to Crescent which has no problem with other apps running. This "embarrassingly parallel" situation is something I often encounter when running Rust programs (ripgrep, polars, when compiling Rust programs) where they burn through lots (if not all) of available cores in order to be "Fast". Blazingly mediocre indeed!

DX on building Crescent

cforge, safe_c.h, and Crescent together make C feel closer to Python than I expected. But "closer" does not mean "the same." The workflow is different, and understanding where it shines and where it fights you matters if you're thinking about doing something similar.

What feels like Python

Auto-generation eliminates the boring parts. I never write struct serialization, CSV adapters, or reflection boilerplate. cforge gen-struct and cforge reflect generate thousands of lines of C I would have otherwise typed by hand. The schema changes, I re-run one command, and the code updates.

Incremental builds are fast. cforge build main hashes every source file with SHA-256. Changing one file triggers recompilation of exactly that file across all three stages ~ typically under one second. The sanitizer stage runs automatically, so I find use-after-free bugs within seconds of introducing them, not in production.

RAII macros remove the cleanup tax. In plain C, every error path needs goto cleanup with a carefully ordered set of frees. With safe_c.h, I declare AUTO_DataFrame(df) and the cleanup happens when the variable goes out of scope. The DSL pipelines read top-to-bottom without visual noise from memory management.

What does not feel like Python

No REPL. In Python I filter a column, look at the head, tweak the filter, repeat. In C I edit the pipeline, run cforge build main, execute, check output, repeat. The loop is tighter than you'd think ~ under a second for incremental builds ~ but it is still a loop, not a conversation. For exploratory data analysis, Python wins.

Error messages are rougher. Pandas tells you KeyError: 'ColumnName'. C tells you your program segfaulted. AddressSanitizer gives you a stack trace pointing to the exact line, which is better than raw C, but it is still not a friendly traceback.

Segfaults happen during development. That is the reality of C. The sanitizer catches most of them before release, but you still spend time in GDB occasionally. The trade is explicit: you pay attention to memory in exchange for deterministic performance and no GC pauses.

The build pipeline as a safety net

The three-stage build is not ceremony ~ it is a net:

Static analyzer catches null dereferences and buffer overflows at compile time.
Sanitizer catches heap overflows and use-after-free at runtime during the test execution.
Release builds with hardening flags once the first two pass.

I have caught bugs in stage 1 or 2 that would have been silent data corruption in Python. The cost is a few seconds of build time. The benefit is confidence that the binary is solid before it ever touches real data.

Would I do it again?

For a known pipeline that runs on a schedule ~ a daily stock screener, a report generator, an ETL job with fixed queries ~ absolutely. You write the pipeline, validate it against the Python reference once, and then the C binary runs in 12 ms instead of 590 ms. For a webapp backend, that is the difference between "please wait" and "instant response."

For exploratory data analysis ~ trying different filters, looking at distributions, prototyping models ~ I would still reach for Pandas or Polars. The REPL workflow is too valuable to give up.

Will I continue using this custom tools combo? Yes. The only thing that could pull me away is a stable Zig 1.0 release. I have reduced Zig usage because of breaking changes in the pre-1.0 ecosystem, but a stable release could change that. Until then, cforge + safe_c.h is my stack for performance and correctness-critical work.

Comments section here

If you enjoyed this post, click the little up arrow chevron on the bottom left of the page to help it rank in Bear's Discovery feed and if you got any questions or anything, please use the comments section.

you should be joymaxxing your projects

hidden (tala) — Wed, 29 Apr 2026 13:42:00 +0000

When I'm working on a passion project (or anything, really), I tend to be obsessively serious in ways that stress me out. Something I initially wanted to do becomes a thing I have to do. I've subconsciously cultivated this behavior, as I only ever notice it late: tired, tense, wondering why something I chose to do feels like something I owe, in a sense.

I'm not always caught up on social media jargon, but I'm interested in the —maxxing suffix I've seen circulating online. I liked the shamelessness of it, the idea you can just decide to maximize something (good), as aggressively and deliberately as you want. Joymaxxing, specifically: making happiness non-negotiable, not a reward for finishing a task but a condition maintained throughout the process. It's why my current goal, when working on something, is prioritizing fun.

The older I get, the more I feel permission to play. In practice, this looks different for everyone: working from a cafe instead of my desk, reading something adjacent to the project just for the pleasure of it, and following interesting tangents. All of these things alters the texture of the work in unexpectedly nice ways, because it reminds me that I'm a human being doing the thing, not a machine producing it.

The shift isn't from serious to unserious. I still passionately care about my projects as I always do. However, I stopped treating "enjoyment" as a threat to "quality," like if I was having too much fun, I'll generate something mediocre or straight up horrendous. Looking back at it, perhaps the work I'm most proud of, is the work I've enjoyed doing the most.

A year on an e-reader

hidden (wombat) — Wed, 29 Apr 2026 18:54:00 +0000

E-readers are something of a niche technology. Hardly anybody has an e-reader in public, especially compared to the number of people with a smartphone in hand. Despite that, I took the plunge last year and got an Android e-reader — the Meebook M6.

It’s been nothing short of awesome. I wanted to yap about my reading setup, because cool tech is cool, plus a bit about how I approach reading as a hobby.

Why an e-reader?

I read primarily for fun and enjoyment. If I bought a physical copy of every book I wanted to read, my apartment would overflow with books. Libraries perform an absolutely vital service, but not every library book is in as good a condition as I’d like. Some books are way too bulky to carry on the go. Others are printed in teeny tiny font sizes (what is this, a book for ants?).

For several years, I read e-books on my phone, alongside the occasional library book. To this day, I only purchase physical copies for books with sentimental value (or, rarely, can’t find online). Reading on my phone was… alright. Good enough for me to assume that e-readers were largely redundant. After all, many of us read (or skim?) colossal volumes of text on screens every day. Hell, you’re most likely doing it right now.

That changed when I was walking around a bougie bookstore that happened to have an e-reader section. I wasn’t (and still am not) convinced that the displays looked anything like real paper, but I was blown away by how comfortable they were to read on. I hadn’t even known I'd been settling for less. That same day, I was back home looking for reviews on budget options to try out myself.

Hardware

I eventually settled on the Meebook M6 for a few reasons. I wanted something that would fit in my pocket, so a screen larger than 7 inches wouldn’t do. At the same time, I wasn’t a fan of the phone-shaped form factor, like that of the Hisense Hi Reader and Boox Palma. I knew from experience that I disliked reading with a bigger font on a narrow screen.

So that left the 6 inch, regular Kindle-shaped options, though I didn’t exactly want a Kindle because of the bullshit Amazon had been pulling. Luckily for me, the Meebook M6 just so happened to be on sale on Taobao for under 100 USD — it had decent reviews, so I gave it a shot.

It is a lovely little Android device. Its royal blue bottom bezel and flush screen are immediately pleasing to the eye. It is basic hardware-wise, but there are a couple of neat features.

It has warm and cool front lights that can be adjusted independently with sliders. The warm light is particularly nice for reading in bed. There are three presets: “Day”, “Night”, and “Bed”. I use “Day” most often, which is most suited to reading in weird indoor lighting (rather than daylight).

The refresh rate is also adjustable with four presets: from the regular “regal mode” with a slow refresh rate and no ghosting, to the “A2 topspeed mode” with the fastest refresh rate but heavy ghosting. The former is most suited for reading, and is what I use 95% of the time. The latter option is much appreciated when I’m using apps not optimized for the display, especially when scrolling.

Software

I was not as enthused with the default software experience. I disliked the default launcher and the default reader app was off when rendering English text. The great thing about Android is that it took me about five seconds to ditch them for a new launcher and a new reader.

KOReader rocks!

I’m a bit anal about customizing my reading experience; KOReader has every feature I could ever wish for. It was a match made in heaven. The vast style tweaks options really satisfy that urge to have everything look exactly as I want it. I keep a handful of these enabled all the time — shoutout to spacing between paragraphs.

I was also impressed at how great KOReader is for reading PDFs. The reflow feature works amazingly for many, but not all, PDFs. If it doesn’t, KOReader can automatically scroll to different parts of the screen depending on the reading direction. For example, for a two-column PDF, it can automatically start at the top left, go down until you hit the bottom left, then go up to the top right. Much, much easier than manually zooming in and scrolling.

All the features can be overwhelming, to be fair. Fortunately, the documentation is pretty robust. And things look good out of the box, even if you don’t mess with anything!

Reading fonts

The English fonts that I rotate between are mostly from this GitHub repo containing fonts tweaked for e-reading. Here’s a live showcase for how each font would look in action. Pretty cool!

My current default is their version of Charter. For informational non-fiction, I sometimes switch to a sans-serif font like Atkinson Hyperlegible Next or Jost. For (Traditional) Chinese, I use Chiron Sung HK, an aesthetically pleasing serif font.

This is how I've gotten things to look:

Where to get e-books

I sideload most of my books as EPUBs, and occasionally PDFs. This means I need my books DRM-free — which most e-books being sold are not. Apart from the obvious solution¹, here are a few (100% legit!) suggestions for where to get e-books you actually own:

Project Gutenberg is well-known for hosting a huge collection of public domain works. However, their earlier titles tend to be inconsistent in quality.
My go-to for older English works is Standard Ebooks. Despite their smaller collection, each book is meticulously proofread and beautifully formatted to elevate your reading experience. Seriously, they look gorgeous.
Kobo and eBooks.com are online storefronts with decently sized DRM-free catalogs. (The most popular fiction titles are those published by Tor, like Brandon Sanderson’s novels.)
Here is an extensive list of publishers that offer DRM-free books directly.
If you happen to have institutional access through a university or library, certain publishers allow DRM-free downloads. I find this especially handy for academic publications or textbooks. I recently downloaded several books from Oxford University Press this way.

What I’ve learned

Sometimes, I get comments when I’m reading in public. People have told me, with a touch of regret, that they could never get through a whole book, or that the last time they picked up a book was in sixth grade. It might surprise them that I have struggled with keeping up a reading habit, too.

I don’t know how common this is, but I will confess that I got this device with the expectation that I would annihilate my entire backlog. A misguided approach, of course. The more pressure I put on myself to read, the less appealing and more overwhelming it felt. This was despite the fact that picking up a book was more easy and effort-free than ever. The sole barrier was my mind.

If you’re anything like me, it’s easy to hype something up in your head — even highly enjoyable and rewarding things — and end up demotivating yourself. I still find myself having to adjust my mindset to get over these hurdles. Some of this includes:

Learning how to forgive myself for not being consistent day-to-day. Sometimes, consistency can look more like week-to-week, or month-to-month. Even then, it’s okay to fall off or take a break. I can come back anytime.
In a similar vein, letting myself put books on hold or drop them — whether I’m overwhelmed, exhausted, or just don’t enjoy them. I can pick them back up whenever I want to.
Approaching books with wonder and curiosity, rather than focusing on getting through as many as possible. Learning new stuff and gaining new perspectives is fun and awesome.
Being mindful of when a passage I’m reading is impacting me, and really feeling that wave of emotion. I find this heightens the experience and pushes me to get more into it.

Much of the above applies to other hobbies as well. While it’s easier said than done, maintaining intrinsic motivation is essential for hobbies, which are so vital to a meaningful life. Most importantly, have fun!

Previous | Next

Reply via email

It surprised me that depending on the jurisdiction, removing DRM from e-books you have purchased for personal use might be in a legal gray area. Personally, I find it difficult to argue against on moral grounds (compared to piracy).↩

reddit now forces you to use their app on mobile

hidden (pseudosingleton) — Fri, 01 May 2026 02:02:00 +0000

One of my personal rules for social media is that I only use the web version of sites. The web version is better for privacy, far less addictive, and makes my phone less bloated.

In the last few days, Reddit added a great new feature to the the mobile web version of their site.

Now, when you try to browse their site on your phone, you will encounter the below paywall-esque popup after scrolling a bit.

You cannot dismiss the popup. You must download the app or request a desktop version of the site.

I guess finally a good enough nudge to finally quit Reddit completely.

No love lost¹ ¯\_(ツ)_/¯

Okay, some love lost. Reddit contains many of the remaining forums on the internet, so it sucks those won't be reachable anymore.↩

rejecting convenience

hidden (rnotte) — Wed, 29 Apr 2026 21:11:24 +0000

as i grew through my adult years, one thought has been running through my head over and over again:

"how much have humans been sacrificing in the name of 'convenience'?"

that word... the word "convenience" has become my least favorite word in the english language. i can't stand it. so many things that are bad for humans' social lives, health, and well-being, are consistently used because they're "convenient". why bother going to the brick-and-mortar store? amazon is more "convenient". why bother cooking a nice meal for yourself? doordash and uber eats are more "convenient". why go out and socialize with people? facebook is more "convenient". why use a digital camera, camcorder, or polaroid? your smartphone is more "convenient". why bother going to the theater or concerts? netflix and spotify are more "convenient". why bother making art? asking an AI to generate it for you is more "convenient".

well, i say nuts to that. from now on, i'm going to make my life as inconvenient as possible. i'm going to go to the store and buy stuff in person. i'm going to make my own food with my own hands. i'm going to socialize with people face-to-face. i'm going to use a true camera instead of my phone's camera. i'm going to buy blu-rays, DVDs, and CDs instead of streaming. i'm going to take my time when creating, watching, playing, and reading a work of art.

i don't want to sound high-and-mighty with this. you're not a bad person for using streaming services. but not only are these "convenient" systems costing more money, they're costing humans' social lives and life skills, the most important things that make us human. so, in the interest of keeping my humanity, i'm going to live my life the inconvenient way.

and if you can, i invite you to join me in rejecting convenience.

Your Instagram account is scheduled for deletion

hidden (stitching) — Wed, 29 Apr 2026 20:57:00 +0000

Yesterday, I deleted one of my Instagram accounts. I had two, actually. The first one was used when I was in high school and college, and that was where I followed classmates and friends. The only photos I uploaded there were more personal - a graduation photo, some more artsy pictures that were taken when I traveled, that kind of thing. I hadn’t checked that account in months, so I decided to just pull the plug on it. The second account was mostly used for things involving my hobbies or for following local businesses, and that was the one that was harder to let go of.

I tried to think about why that was, and I listed out some reasons.

I follow along with what local businesses are doing. For example, what special events is the yarn store or bookstore putting on for the community this month? Has a coffee shop or food truck changed its seasonal menu?
I follow a lot of crafters, and seeing other peoples’ projects can inspire me and introduce me to new patterns, designers, and crafting techniques. I occasionally like and comment on these things and sometimes I’ll post pictures to show off my work, too.
Every Tuesday, the local bookstore’s account will post new releases to their story. I get introduced to interesting books that I can add to my TBR (to be read) list.
I watch reels (funny things and recipes, mostly) and share them with friends or save the recipes to try later. I’ve found some great recipes this way!

I didn’t really… interact with other people on Instagram in a meaningful way, though. To ease my reluctance to deactivate my account, I revisited each point and thought about what I could do to still achieve these things outside of an Instagram account.

I can go onto individual businesses’ websites and sign up for email newsletters to stay updated on their events. Most local businesses I have in mind already have websites set up.
I’m already subscribed to a few crafting subreddits. I can browse through those or share my projects there, and I can still get inspiration from those pages.
New books are released every Tuesday. I checked my local bookstore’s website and they have a page for new releases. I can just bookmark that page and check it manually rather than viewing the bookstore’s Instagram story every Tuesday.
I don’t need to view short-form video content, especially as I know how bad it is for our brains and our attention spans. I don’t need funny reels to laugh and I don’t need recipe reels to cook. I own several cookbooks and (of course) I follow some cooking and baking subreddits if I really want to go looking for inspiration.

Making this list and writing it out really helped me to realize that there is nothing unique or exclusive that I can only get from Instagram. Afterwards, I went ahead to the settings page of my second account and “scheduled my account’s deletion” — because Meta doesn’t allow you to delete your account immediately. It schedules it out by one month, probably in the hopes that you’ll change your mind before that month is up.

I feel good, though! This means that since the start of 2026, I’ve deleted my Facebook and Instagram accounts. I’m not totally trying to step away from all websites, but I do want to leave most social medias that aren’t benefitting me in any way. I think Reddit will be harder to stay away from, and I am working to minimize the time spent on that site, at least. I think I’m off to a good start!

独立博客，难在不够独立

hidden (sol) — Wed, 29 Apr 2026 07:00:00 +0000

经常能听到一种声音，说在当下的互联网环境里，坚持写独立博客是一件极难的事情。这种「难」往往被指向几个维度：技术维护的琐碎、内容的持续产出、流量的匮乏以及社交反馈的缺失。

但在我看来，如果一个人觉得独立博客难，很大程度上是因为他还没有实现真正的「独立」。

我们得承认，在这个世界上并没有什么事情是绝对简单的。但「难」与「难」之间存在本质的区别。如果你依附于某家公司，或者身处某个自媒体矩阵之中，那种「难」是具体的、有压迫感的。

你需要考虑更新频次，需要维持内容的垂直度，需要精准地捕捉算法的喜好，因为那是你的 KPI，是你获取生存资源的筹码。在那样的语境下，「难」是常态，因为你的意志必须服从于某种商业逻辑或平台规则。

可是，当你选择「独立博客」这个载体时，你已经从上述的所有枷锁中抽身而出了。既然已经「独立」了，这种「难」的感触究竟是从哪里来的？

很多时候，这种压力是自己强加给自己的。

独立博客不应该仅仅是技术手段上的自主，即拥有一台服务器、一个域名和一套自己挑选的主题。它更应该是一个人独立意志的具现化。如果你的博客内容、更新节奏甚至遣词造句的风格，依然在随着他人的意志或外界的评价而不断摇摆，那么这依然称不上是独立博客。它只是一个被你搬到了私人领地上的「朋友圈」或者「营销号」。

有些人觉得难，是因为他们太看重「读者」了。他们预设了一个庞大的观众群体，总觉得自己写出来的东西必须得给别人带去点什么，或者必须得到某种肯定和回馈。其实这未免有些太高看自己了。在信息过载的今天，并没有多少人会时刻盯着你的思考。

我们要看清一件事情的主次。独立博客首先是用来记录和呈现自我的工具。它是一个树洞，也是一座实验室，它是为了满足我们自身表达和梳理思维的欲望。如果我们能把「记录自己」放在「谋求肯定」之前，那些所谓的坚持不下去的「难」瞬间就会消散。

因为为你自己做事是不需要「坚持」的，只有为别人做事才需要。

从这个角度出发，独立博客难不难，其实取决于一个人人格内核的完整度。凡事如果能做到向内求，事情就会变得顺理成章。独立博客这种极其私人的产物，理应完全为自己考量。它不应该为了凑够某个字数而堆砌文字，也不应该为了迎合某种流行话题而强行发声。

当一个人不再向外寻求认同，不再被那种「必须产出精品」的虚荣心所绑架时，博客就不再是一项任务，而是一种生活方式。

所以，如果你依然在为如何运营好一个独立博客而感到痛苦，或许可以停下来审视一下：你是在为谁而写？你所追求的独立，究竟是代码层面的独立，还是精神层面的独立？

当你真正做到精神上的独立，不再为他人的独立意志而改变自己的表达时，你会发现，在这个自由的自留地里，根本不存在「难」这种说法。剩下的只有表达的快感，和与自己对话的宁静。

Who knows that you blog?

hidden (forkingmad) — Tue, 28 Apr 2026 17:28:00 +0000

Question for the audience: Do you tell people you blog?

I was reflecting on this recently, after I inadvertently mentioned to a colleague that I had blogged about a topic a few days earlier. That, of course, started the questioning from them: Oh, what's it called? What do you write about? Can I see it?

I reluctantly recited the web address. I have no idea if they did/will look. But then I wondered: Why was I so restrained to promote my blog to a real-life-person-type.

Public is Public

I totally accept that everything I say online is Public. I often remind people that what they are saying on the socials could haunt them in the future. Nothing is really private on the internet.

My test for what I recount online is simple:

Would I stand in the middle of a town-square, and proclaim this to anyone who stops to listen?

If the answer is No, then I would not write it online.

Nothing to hide

I've therefore nothing to hide in what I have said. I stand by it all.

So why do I not tell people that I blog?

I'm not sure I have the answer! I am not ashamed. I just feel that this is my little outlet, that requires no discussion with my friends or family! My other-half knows I blog but has never once asked what I blog about, or what the address is!

I appreciate some people like to be anonymous when blogging. That's their choice. I am an open book. You can ask me anything and I will reply honestly, as long as it conforms to my town-square rule.

Back to you: Do you tell people you blog?

Here are a few other blog posts responding to my question. Shout if you want your own added.

"People who don't use AI will be left behind"

hidden (migrainebrain) — Tue, 28 Apr 2026 17:33:00 +0000

"People who don't use AI will be left behind", they say. I can't emphasize enough how much I hate it when I hear/read shit like that because I'm pretty sure, in fact, that what will happen is the exact opposite.

People who rely on AI are the ones who will be left behind. They'll forget how to think, how to write, how to do a simple reliable search, how to tell fact from fiction... they'll forget how to fucking LEARN. I think that's the part that makes me the saddest. What a beautiful thing it is just to learn stuff.

If you believe chat GPT can do better than you, why would you just let it? Why wouldn't you aim to be better, to learn how to be or do something that AI would never?

Reply to this post.

or don't.

It's time we stopped calling them tweets

hidden (guinevak) — Tue, 28 Apr 2026 16:22:00 +0000

I know a lot of people are still mourning the breakup of their toxic relationships with the Hellpit Formerly Known As Twitter, but it's time to move on.

And in token of that, I vote we start calling X posts something more appropriate, like, say, Xcretions.

The balance between privacy and oversharing

hidden (networkpuppy) — Wed, 29 Apr 2026 21:55:00 +0000

I care a lot about privacy. I always advocate for services that don't collect or sell data. I use VPNs, ad blockers, and am usually careful about sharing too much stuff about me online. This blog goes against that third point, and most of what I write is directly related to myself.

Unfortunately, I love talking about things (and myself). The stuff that I post on this blog could dox me or allow people who were interested to build a profile of me. I think about it often when I see the sorts of stuff that other people post on Bear, and in my head I know that 95% of the time it's probably not a big deal to be a little more specific about your personal life.

This results in a dilemma where I have some super cool and interesting (I think) topics but don't want to share them because it's personally identifiable information. I have my age in my Discord about me, I have my timezone and I have a link to this blog too. Those are things that would make it very easy for people to find out more about me—without me even knowing who they are.

I don't want to be saying that you should never speak about yourself online ever, use a fake name, email, birthday, address, job, etc. However, I'm also saying I think it's probably a bad idea to go around posting pictures of your house, or sharing your daily commute, or videos of your car with the license plate unblurred.

Since the rise of Facebook and its push for using real names and identities online, some people see it as weird to use a pseudonym in place of their legal name. In the past year or so, governments around the world have been increasingly pushing for the removal of digital privacy, and the linking of personal profiles and internet accounts. I don't like this at all, and I feel that people have the right to be anonymous online, no matter who they may be. Any information about themselves that someone chooses to reveal should be the only things you can learn about a person.

Privacy is a human right, and companies shouldn't have the ability to strip you of that right for their own monetary gain. The things I post about on my blog are the things I choose to share, and not things that I have to share. Sure, they may give information about myself away, but I have the ability to remove posts, and more simply, to not write about things that could lead to that.

Reply by email

This post was last updated 1 day, 4 hours ago.

You Won't Be Left Behind if You Don't Use AI

hidden (heychat) — Thu, 30 Apr 2026 16:46:00 +0000

Every time I see "people who don't use AI will be left behind," I roll my eyes. When migraine brain's post came up on the trending Bearblog posts I gave out a little "huzzah!" because I love seeing the contrarian views.

You know what I also heard that about constantly 10 years ago? Smart homes. I'm not a person who has monitored economics over my decades of life, but I've been interested in technology and how people use it since I was a kid. These passive observations have become patterns over time, and it turns out lots of people have done research and written papers on what I've seen. I'll take some cues from them to help you see what I'm seeing.

We're currently in the "Gold Rush" phase of AI, a 5- to 10-year window where companies are blindly seeking "AI skills" without a clear definition of what that means. Companies are blindly adopting AI products without considering the user workflow or whether it makes sense. Futurists are making wild statements about the future of AI based on how they'd ilke it to progress. If you're not using an LLM to draft your emails or build your slide decks, the rhetoric suggests you're making yourself obsolete.

If you just look back into recent history you'll see several different possible endings depending on how people choose to use the technology: the most transformative technologies become invisible, moving from revolution to lifestyle choices. The reactions we're seeing are in perfect alignment with the Technology Adoption Life Cycle. We are seeing the same patterns we saw with the dawn of the personal computer, word processing, and the internet.

In the 1990s there was a persistent fear that if you didn't learn to "code" or couldn't talk about all aspects of a LAN, you would become unemployable. For several years, webmasters were the highest paid people in the office because they possessed specialized skills in this new world. As the technology matured, it leveled out. Today being "good at the internet" isn't a job skill, it's a baseline utility, and you don't need to know anything about how it technically works to use it. There are millions of successful professionals who don't even use the internet in their jobs. The technology didn't replace or dictate the future of the workforce like initially predicted.

The "Smart Home" is the best metaphor I can think of when it comes to AI. A decade ago, tech enthusiasts predicted that every home would be a fully automated hub of Internet of Things (IoT) devices, and those who didn't adapt would live in "dumb," inefficient homes. Today, our dumb houses are functioning perfectly well. In fact, I think today there are so many ads all over smart home devices that people are grateful they never adopted the "smart home" approach. I don't think AI will be any different. It enhances if you choose to use it, but you're not at a loss if you don't. Smart home adoption is a niche now. After the initial decade of frantic adoption and panic, AI will likely settle into the background as a tool for those who want it, while leaving the core of human work (judgment, empathy, physical presence) largely untouched.

We are also seeing this "evening out" with social media and smart watches. There was a period where "digital presence" was advertised as "mandatory" for any professional brand, yet we are seeing a trend of executives and creatives going out of their way to avoid the attention economy. While smart watches offer health insights, they haven't made analog watches obsolete. These technologies transitioned from being "the only path forward" to being "another option if that's what you prefer."

We'll likely continue to see AI-first hiring for a decade, which will be frustrating for people who prefer not to use it. However, the hype will reach its peak and plateau, and "AI specialist" roles will likely be folded back into general roles. The "human in the loop" will remain the most valuable asset because while AI can simulate "what," it struggles with "why."

You won't be left behind by a machine. You'll be living in a world where the machine is another appliance to use to some goal or end. Some people will swear by it but others will find it completely unnecessary and live/work/play fine without it.

Can You Reverse Brain Rot?

hidden (untangled) — Tue, 28 Apr 2026 00:15:00 +0000

I’ve been following Cal Newport for some time (known for his book Deep Work and Digital Minimalism). I’ve come to look forward to his weekly podcasts on attention, focus, and life without social media.

Today, he dropped a podcast titled “How Do I Build Cognitive Fitness?” (Alternatively, his YouTube video with the same content was titled “How Do I Reverse Brain Rot?”, so I’m curious which one got more clicks).

In it, he outlines five ways that we can improve our cognitive fitness and challenges us to be more intentional with our time. If you want to give it a listen he covers it in the first half of this episode.

Here are the five things he suggested, and my thoughts on each one.

Read every day.

He suggests that the more time you spend reading, the more you’re rewiring your brain. It gives you practice in “aiming your minds eye at a desired internal target,” such as a thought or idea. He recommends starting with books you’re excited to read, not books you feel you “should” read. Fun books, trashy books, romance books, they all count. Start with 15-20 pages a day. Read at lunch and before bed. After you’re doing that regularly, increase to 30-50 pages a day. As that gets easier, make 1 out of 3 books “hard” or more challenging.

I feel good about reading every day, though I can definitely improve on the number of pages. I’m likely still in the first category, reading 10-20 pages a day. Not quite to 50 pages a day. Though I do think I’m reading more challenging stuff sometimes. I’m currently reading Dune Messiah I’m definitely slowing down to digest the passages.

Don’t avoid writing.

Cal states that many people are writing less than ever before due to generative AI, and that “to improve your cognitive fitness you should seek out as many opportunities to write as possible.” He goes on to say that "we feel naturally resistant to it because of how many moving pieces there are in our brains.” Writing is hard and we feel strain when we write, but it provides us with more “cognitive strength”. He recommends studying technique while you read, writing in a journal/newsletter/blog (ahem), and acclimating yourself to getting over the first 10 minutes of writing as they are the hardest to work through.

Why do you think I’m here? Ha! I’m trying to get better at constructing my thoughts into sentences and paragraphs. And yeah, it’s hard. But I figure the more I do it, the easier it will start to feel. I’m also trying to write by hand more, but I need to find better opportunities to write when I’m not getting interrupted.

Go on thinking walks.

Cal suggests that we take walks several times a week without our phone (and if we do bring our phones we should make them very inaccessible, like at the bottom of our bag). “Practice turning your attention inwards to make sense of some information.” Brainstorming or day dreaming counts here. Reflection is “where you develop your sense of self” and our best ideas come from it. He recommends journaling your insights after your walk, that it will help you clarify internal thinking.

I might have to take on this one. I’m not good at getting out of the house (I work remotely), and I need to be better about it. The weather is warming up though, which will make it easier. Plus it’ll get me away from my desk more often. Something semi-related is that our brains come up with some of our best ideas while we’re in the shower, and I think the two are related.

Plug in your phone.

Cal recommends keeping your phone plugged in and not with you when you’re at home. “Spend hours in your house each day without your phone as your constant companion.” This will give you lots of practice doing things without that constant short term motivation to pick up the phone. Put your ringer on and let people know to call you. Make the phone “less desirable by taking off any apps that makes money from your engagement” - social media apps, for example.

Oooh this one is good. I can do this right now. I have a charger in the other room and can put my phone there. This would be a really good one to practice. I still need an alternative for having my phone next to my bed - I still use it as my alarm because last summer our phones woke us at midnight for a tornado warning that sent us grabbing the kids and flying to the basement. Maybe I can plug it in further away from the bed and still hear weather alerts. I’ll need to explore this further.

Learn a hard skill.

Cal’s last idea is to master a skill that requires you to focus and get better, but also gets you a clear reward. Take up tennis, playing the guitar, learning to knit, etc. He goes on to say that when you learn a hard skill, it “builds up a sense of discipline and helps train your long term motivation system that when we focus on something hard, over time we get meaningful rewards.” When you practice focusing, it becomes easier to sustain concentration. BUT, you need to do this on a regular schedule, not whenever you feel like it.

This is a great one. I’ll have to think about what I’d want to learn! The hard part for me will be sticking with it. I have a terrible habit of picking up new projects every couple of weeks and I need to get on top of that. I need to find something that will sustain me for at least a season or so.

Overall, some really good tips from Cal Newport. I really do think these could help someone step back and assess their cognitive fitness. I know I’ll be implementing some of these ideas.

Which of these 5 do you see yourself implementing? Which is the easiest? The most difficult? I’d love to hear your thoughts on this.

Reply via email

first posts are how selves get made

hidden (risse) — Tue, 28 Apr 2026 00:09:00 +0000

i made a choice to introduce myself as risse

it's a small thing but your name is the first step of an introduction
and i like how you can pronounce it at least five different ways,
plus it's not on my birth certificate, so i don't have to correct people when they say it wrong

i put a lot of weight into introductions
i have this fear that on first pass, people read traits into me that i gotta uphold from then on
so i put a lot of thought into who i'll come off as
and i rewrite first posts over and over
because whether i capitalize my letters says something about the self i can offer them, and once i've committed i'll be stuck for a while

i don't know though. it's not high school anymore, i don't need to daydream of a body to escape into
i should have fun with the identities i act out even if there's nothing truer underneath

so hello !! i'm risse :) it's nice to meet you

Spread Hope

hidden (absurdpirate) — Thu, 30 Apr 2026 18:42:55 +0000

It's getting dark out there. Fascism is wanting to rear its ugly head, people are getting propagandized to hate each other, we're more stressed and neurotic than ever, shit is getting more expensive, and people are struggling to make ends meet. Instead of despair, I ask you to be a beacon of light in the dark. I want you to help spread hope.

Hope is found in the smallest of actions. It's found in when we help others without asking. It's when we open an ear and lend a hand. It's feeding and giving to people who have far less than you. It's being a friend. It's volunteering when and where you can. It's helping the sick, the elderly, the young, the frightened.

I do not say this like it is easy. It's far easier to ignore everything and turn a blind eye to the suffering, but you cannot hide from it forever. So what will you do? Succumb, or embrace your fellow sufferers?

Previous |

Reply via email: me@absurdpirate.com

as of writing this...

I have applied to become a court appointed special advocate for children. I've been putting it off due to time constraints, but I'm in a spot now where I can dedicate the time. Going to a funeral for my wife's grandfather this weekend, we weren't particularly close for a plethora of reasons, so we're mostly showing up to support my MIL.

The New Kid on the Block

hidden (jedda) — Tue, 28 Apr 2026 16:43:14 +0000

There’s something unsettling about being the new kid on the block, even as an adult.

It’s not super obvious, at least not like back then when you were a literal child. No one is pointing or whispering. There’s no cafeteria to navigate or classroom to choose a seat in. The feeling of being in those scenarios show up always, just in a different kind of way. It’s the hesitation before saying something out loud, the extra time spent double (and triple) checking something that would normally feel simple, and the awareness that everyone else seems to know what they’re doing.

I started somewhere new three weeks ago.

In the grand scheme of things, three weeks isn’t a long time. I get that. If anyone else said that to me, I’d tell them to give themselves more grace, to take their time, to settle in. As always, in my head, it sounds different. It’s more like: it’s already week three. You should have a better handle on things by now.

I really don’t though. Not fully.

There are still gaps here and there. I have moments where I’m trying to piece things together in real time, trying to understand not just what I’m supposed to do, but how everything fits, who to go to, and what hasn’t been said out loud but is somehow expected to be known.

Sometimes things are handed off without much context, or reference something that hasn’t clicked yet. Not in a bad way, but just in a way that assumed I’ve already connected all of the dots that I didn’t even know existed. So I nod, and figure it all out somehow.

I get it. I’m not supposed to know everything yet. That would be unreasonable (maybe?). But there’s still that perfectionist part of me that expects it anyway. Or at least expects me to anticipate it, to figure out how to read between the lines and keep up with things I haven’t been introduced to yet. Which, when I say out loud, doesn’t even make much sense. I don’t know how to read people’s minds. I don’t even think I’ve met everyone I’m supposed to meet yet. I still feel behind though.

I know that a lot of this comes from the version of myself I’m used to being. She’s the one who is steady, capable and already a few steps ahead. There’s a rhythm to that version of me, and right now, I’m all over the place. At this moment, I feel slightly disjointed, a little uncomfortable, full of questions that don’t have immediate answers I can get to just yet.

Just like with my making and breaking routines, I’m attempting to sit with it without rushing to just fix it. I’m trying to let myself be new without treating it like a problem. I understand that three weeks is still the beginning, even if it doesn’t feel like it.

I'm trying to be the new kid on the block that isn't just catching up as quickly as possible (my stress level would probably be lower). I'm hoping to learn to find my place while still figuring things out at the same time.

...and if you happen to read this, and you’re in that world of mine right now, no, you didn’t just read this.

I am as confident as can be.

Comments

If you'd like to comment, please send me an email, or sign my Guestbook.

Reply by email

Forget about the numbers

hidden (robert) — Mon, 27 Apr 2026 17:28:00 +0000

I don't check my Bear stats very often. When I do, it's always the same: ups and downs, ups and downs...

The spikes occur when a post is trending. When it's gone, the numbers go back down into the peaceful valley.

I say peaceful because that's how I feel. I like that it goes up and down. It shows that it's not so much about my blog as a whole, but rather that some posts simply happen to attract more people at certain times.

Some might say that's what statistics are for, learning what works, coming up with a winning formula. That might work for a product, but it's a recipe for disaster when it comes to a personal blog.

Blogging according to a winning formula is a great way to lose. You'll lose interest, and so will your readers.

Forget about the numbers. Remember to be yourself.