I have an experimental web framework I'm currently working on.

While going through the code to clean up styling before tagging a stable release, I've been debating this specific part in the HTTPS module:

https://github.com/c4punks/CWIST/blob/dev/src/net/http/https.c

Right now, this code just uses a dumb, massive ring buffer to absorb connection bursts, and I'm wondering if I should switch it to a lock-free queue.

There are three main things that make me hesitate:

* State can get pretty tangled and messy in a lock-free queue.

* We have a tiny team and I'm maintaining almost all of this alone. If something breaks with CAS (even if the odds are low, if I mess up the code during refactoring), the blast radius on the dev branch will just be too big.

* I also wonder how often real-world traffic actually warrants lock-free. Plenty of web frameworks handle traffic just fine without this level of extreme optimization.

Considering that I'm still a junior developer and lack experience, is it really worth swapping this out for a lock-free structure, and would it actually make a noticeable difference?

Here's release notes! If you have a password for a station. it's good.

Session hijacker is not fully implemented yet(it's a mode that scraps chat logs via adding a registered user to other stations)

v1.3 (Lovelace) -- named after Ada Lovelace

Chatter joins the live DDial network: station-to-station linking through the MagViz hub, a full MagViz command set for retro dial-in terminals, and a root-cause fix for the scrollback duplication that made relay traffic unreadable.

DDial network integration

• Station (auxiliary) mode: Chatter now links into the DDial network as a full station via the MagViz hub (magviz.ca:2301). Registered on the hub user list and relaying chat bidirectionally with all linked stations in real time.
• User ("hijack") upstream mode (CHATTER_DDIAL_MODE=user): the relay acts as an ordinary DDial account. Includes a per-account file lock so two processes never log in twice, a reconnect cooldown (double-login guard) that also covers abnormal termination, /Q logout on shutdown, and dedup of the upstream's own-line echo. A chat message containing "bye" no longer drops the connection.
• DDial listener (-D bind:port): retro terminals dial in over raw TCP/telnet into a Diversi Dial engine with the MagViz command set — ###password member login, channels 1-999 with ~ dual-channel wire form, colors (/h#RRGGBB), mail, message box, /ig /null /p moderation, paced /300-style output, and more. See docs/DDIAL.md.
• Chat bridging: dial-in chat reaches the Chatter room (as system entries, so nothing loops back) and the upstream link; upstream chat reaches the room and local dial-ins. Link-echo and local handles are suppressed so no one sees a line twice.

DDial command interoperability from the Chatter room

• Read-only DDial commands typed in the room (/s, /s1-/s4, /sm, /i, /h, /ls, /b?, /ver) are forwarded raw to the linked station; the reply returns through the normal relay path and lands in the room history (verified live against the MagViz hub).
• Everything else stays local: protocol commands (/K, /V, /E, ...) can never be injected from chat. Operator-only /ddial raw remains the sole protocol escape hatch.

Scrollback rendering fix

• session_process_pending_sink's non-incremental fallback re-emitted the entire visible history window every time a single message arrived (incremental redraw had been disabled earlier to avoid screen clears). With relay traffic, every message repainted the whole recent history — the duplicate-block scrollback spam reported during DDial testing — and buried the input line.
• The fallback now appends only entries newer than the sink cursor; the cursor is advanced when the sender's own line is rendered immediately, invalidated on hard screen clears and on return from protected modes (BBS/RSS/game), and reset when coming back from a scrolled view. Verified: every message renders exactly once across two SSH sessions, dial-in relay, scrollback navigation, and BBS exit.

DDial link line format and relay

• Linked stations showed our chat as 63Lee Yunjin) msg instead of 63#1[T1:Lee Yunjin) msg: station mode dropped the #slot[T1: prefix whenever the remote never printed our #N(T1:?) status line. Link chat and /P now always carry the speaker's own line number (a Chatter member's chat-link slot, the same one its login was announced with; a dial-in's session slot).
• The relay's own slot is learned only from our status line, so another user's #2[T1:Bob) line can no longer overwrite it.
• The idle keepalive no longer writes a telnet IAC NOP into the stream (remotes rendered it as �� in front of the next line); kernel TCP keepalives are used instead.
• /pm follows the public-chat relay path: a Chatter private message in the room, and the DDial equivalent when the target is on the DDial side (P#slot(handle) msg to a dial-in, link /P<slot> #slot[T1:handle) msg to a user on the linked station). Inbound link /P reaches only its recipient instead of the room history, and our own /P coming back is dropped.
• /reply is relayed to DDial as a plain chat line (@author text), since DDial has no replies.
• /users and /connected count DDial participants: dial-ins, plus everyone behind the Station Link, kept in a hash map keyed by handle. It is filled from station user lists ([SYSOP] 73-.SynerChat #0[T1:AriZona Mae #2<T1:Joe Boo:232 ...), login events and chat lines, rebuilt at start-up from the last 2048 history entries, and a user is removed only when they leave (logout, or dropping out of their station's list).
• History keeps what the link sent; one display-time filter decides what people see, for past and new entries alike and in every view (SSH, scrollback, live broadcast, JSON/web feed): link housekeeping ([SYSOP] station lists, [LINK] login/logout events) is hidden, and relayed DDial chat such as 71#4[T1:MaxMouse) ... is shown as a Chatter message ([id] <MaxMouse> ...).

Usernames with spaces and localized command messages

• /pm, /mail send, /block confirm and /bbs mute take name|args (e.g. /pm Lee Yunjin|hello), matching the BBS comment syntax; single-word names still work without |.
• Help labels, usage lines, the /bbs subcommand help, and the system messages of /pm, /mail, /block, /unblock, /kick, /ban, /banname, /banlist, /getaddr, /poke, /pardon, /getos, /resetpw and /showstatus are available in all eight UI languages.

Crash forensics and BBS hardening

• The SIGSEGV handler now logs the first-fault signal, code, address, fault RIP/RSP, and TID to stderr (journald) before re-raising, because the re-raise used to overwrite the faulting ucontext and erase the real crash location from every core dump.
• BBS post lookup refuses to iterate a post arena whose capacity exceeds SSH_CHATTER_BBS_MAX_POSTS and rejects ids above 2^40 (defense against the wild-pointer crash class seen on 2026-09-23).

Full changelog: v1.2...v1.3

Hi, recently I am developing a personal TODO scheduler app. I was simply refactoring my old codes, and I found this:

#ifndef __TODOX_FORMAT_H__
#define __TODOX_FORMAT_H__

#include <stddef.h>
#include <stdio.h>
#include <time.h>

#define TODOX_TIME_FORMAT "%Y-%m-%d %H:%M:%S %z"
#define TODOX_TIME_COMPAT_FORMAT "%Y-%m-%d %H:%M:%S"

#define TODOX_ALARM_MAX_LEN 1024
#define TODOX_ALARM_TABLE_MAX_ROWS 128
#define TODOX_ALARM_TASK_MAX_LEN 256
#define TODOX_ALARM_COMMENT_MAX_LEN 256

/** @struct todox_format_t
 * @brief  a data format of todolist.
 */
typedef struct __todox_format_t {
    /// unix timestamp
    time_t ts;
    /// a name of a task
    char task[TODOX_ALARM_TASK_MAX_LEN];
    /// a comment section of a task
    char comment[TODOX_ALARM_COMMENT_MAX_LEN];
    /// non-zero when the alarm repeats weekly
    int repeat;
} todox_format_t;

/** @brief converts an ISO 8601 datetime string to time_t.
 * @param[in] ts an ISO 8601 datetime string.
 * @return a unix timestamp, or (time_t)-1 on failure.
 */
time_t iso8601_to_time_t(const char *ts);

#endif

In this case, repeat variable is int variable.

However, some says that using bool is a better convention(and a professor taught me a same thing)

I think that using bool can reduce extra struct padding at some scenarios, but there are still many modern codes that uses int flag to show boolean status.

As a result, I don't sure if I should refactor this, or leave this. If I leave this, I will make it extensible. For a good example, repeat==14 can be extended into 'this repeat flag is only valid within 2 weeks'.

However, if I really gonna refactor this, it has a few implementations:

bool repeat;
int  days_until;

bool repeat;
time_t ts_until;

/// 0(false), 1(true), x > 1(valid days)
int repeat;

Currently repeat is a simple boolean flag. However, I may extend the scheduler in the future to support recurrence policies such as repeating for N days or until a specific date.

Would you still model the current field as bool, or would you intentionally keep it as int to preserve room for future extension? Or is introducing another field or an enum the better design?

Hi, recently I made a TODO application for personal use.

I thought that I used AI coder too frequently, so I wrote many parts of this application's source by myself(most parts except DBus and weekly alarm extension)

The basic structure of this application follows:

CLI->Set Alarm at alarms.txt

                |

              Daemon   --reads a text file when updated, and sleep until the next alarm time(or next alarm setup)

When daemon wakes up:

Send alarm to d-bus->check the next alarm->sleep until the next alarm

I guess this structure is quite simple enough...

But, this error handler part is weird, I don't sure if I did it well or not? At least this is not a traditional way.

typedef struct __todox_error_t {
    enum TODOX_ERROR_LEVEL level;
    int code;
    char *msg;
} todox_error_t;

---

#include <error/error.h>
#include <stdlib.h>
#include <string.h>

todox_error_t TODOX_ERROR(const char *msg, enum TODOX_ERROR_LEVEL level, int code) {
    todox_error_t err;
    err.msg = strdup(msg);
    err.level = level;
    err.code = code;
    return err;
}

void todox_notify(const todox_error_t err) {
    if(err.level == DEBUG && TODOX_DEBUG_PRINT == 0) {
        free(err.msg);
        return;
    }

    switch(err.level) {
        case WARN:
            fprintf(stderr, "[WARN] msg: %s(code: %d)\n", err.msg, err.code);
            break;
        case ERROR:
            fprintf(stderr, "[ERROR] msg: %s(exit code: %d)\n", err.msg, err.code);
            free(err.msg);
            exit(err.code);
        case INFO:
            fprintf(stdout, "[INFO] msg: %s(code: %d)\n", err.msg, err.code);
            break;
        case DEBUG:
            fprintf(stdout, "[DEBUG] msg: %s(code: %d)\n", err.msg, err.code);
            break;
        default:
            fprintf(stdout, "[UNK] msg with unknown loglevel: %s(code: %d)\n", err.msg, err.code);
    }
    free(err.msg);
}

When I was writing this code, I thought that this simple application can simply return a given error code and exit(actually, attaching a bug tracker was planned).

However, its error code is not following linux/unix standard codes..

#define TODOX_WRONG_TIMESTAMP 100
#define TODOX_NO_CONFIG_FILE 110

In my opinion, to debug an application, I need a bug tracker, but this application is written within 1100 lines(and reading a whole source code takes only 10-20 minutes)

I don't sure which method can be a good convention to indicate these sorts of error. Since it is not a system software that sticks to traditional unix commands(it is a todo application!) I am pretty unsure.

Plus, the d-bus part by AI copilot is quite terrible! Currently the application is small, and I am not planning to extend it as a full GUI alarm app yet, it works fine. However, I cannot conclude if I should write a d-bus module here to cleanly manage a notification.

#include <notify/notify.h>
#include <dbus/dbus.h>
#include <syslog.h>
#include <stdlib.h>
#include <stdio.h>

int todox_send_desktop_notification(const char *title, const char *body) {
    DBusError err;
    DBusConnection *conn;
    DBusMessage *msg;
    DBusMessage *reply;
    DBusMessageIter args;
    DBusMessageIter sub;

    dbus_error_init(&err);
    conn = dbus_bus_get(DBUS_BUS_SESSION, &err);

    /* If the session bus address was stripped by sudo or another privilege
     * boundary, derive it from the standard systemd user runtime directory.
     * This keeps the daemon working when launched as a systemd --user service
     * or from an otherwise clean environment.
     */
    if(conn == NULL && getenv("DBUS_SESSION_BUS_ADDRESS") == NULL) {
        const char *runtime = getenv("XDG_RUNTIME_DIR");
        if(runtime != NULL) {
            char addr[512];
            int n = snprintf(addr, sizeof(addr), "unix:path=%s/bus", runtime);
            if(n > 0 && (size_t)n < sizeof(addr)) {
                setenv("DBUS_SESSION_BUS_ADDRESS", addr, 1);
                dbus_error_free(&err);
                dbus_error_init(&err);
                conn = dbus_bus_get(DBUS_BUS_SESSION, &err);
            }
        }
    }

    if(dbus_error_is_set(&err)) {
        syslog(LOG_ERR, "todox: failed to get dbus session bus: %s", err.message);
        dbus_error_free(&err);
    }
    if(conn == NULL) {
        syslog(
            LOG_ERR,
            "todox: dbus connection is null (DBUS_SESSION_BUS_ADDRESS may be missing or invalid)");
        return -1;
    }

    msg = dbus_message_new_method_call("org.freedesktop.Notifications",
                                       "/org/freedesktop/Notifications",
                                       "org.freedesktop.Notifications", "Notify");
    if(msg == NULL) {
        syslog(LOG_ERR, "todox: failed to create dbus Notify message");
        return -1;
    }

    const char *app_name = "todox";
    dbus_uint32_t replaces_id = 0;
    const char *app_icon = "dialog-information";
    const char *summary = title ? title : "todox";
    const char *notification_body = body ? body : "";
    dbus_int32_t expire_timeout = 0;

    dbus_message_iter_init_append(msg, &args);
    dbus_message_iter_append_basic(&args, DBUS_TYPE_STRING, &app_name);
    dbus_message_iter_append_basic(&args, DBUS_TYPE_UINT32, &replaces_id);
    dbus_message_iter_append_basic(&args, DBUS_TYPE_STRING, &app_icon);
    dbus_message_iter_append_basic(&args, DBUS_TYPE_STRING, &summary);
    dbus_message_iter_append_basic(&args, DBUS_TYPE_STRING, &notification_body);

    dbus_message_iter_open_container(&args, DBUS_TYPE_ARRAY, DBUS_TYPE_STRING_AS_STRING, &sub);
    dbus_message_iter_close_container(&args, &sub);

    dbus_message_iter_open_container(&args, DBUS_TYPE_ARRAY, "{sv}", &sub);
    dbus_message_iter_close_container(&args, &sub);

    dbus_message_iter_append_basic(&args, DBUS_TYPE_INT32, &expire_timeout);

    reply = dbus_connection_send_with_reply_and_block(conn, msg, 5000, &err);
    dbus_message_unref(msg);

    if(dbus_error_is_set(&err)) {
        syslog(LOG_ERR, "todox: dbus Notify call failed: %s", err.message);
        dbus_error_free(&err);
        if(reply != NULL) {
            dbus_message_unref(reply);
        }
        return -1;
    }

    if(reply != NULL) {
        dbus_message_unref(reply);
    }
    return 0;
}

A lot of boilerplate codes are scattered, and there are no abstracted functions right there. But it is quite unsure if I should write a bunch of wrappers for this short program..If it was 10000 LOC full-featured application I must write a wrapper. But this is less than 1100 LOC without extra dependencies without Linux/BSD system libraries. If this was 100 LOC toy application I would not hesitate. Even this code is quite small, managing DBus is not a simple work for Unix-like systems. Should I consider?

Thanks, and sorry for my bad English. This post is also written without AI translator..

https://preview.redd.it/ldgc5xmkge6h1.jpg?width=3000&format=pjpg&auto=webp&s=ebf02a1f88f33ee5b37d0e87f709363e019d2519

Ethiopia Keramo Niguse Gemeda

Region: Hayisha village, Keramo Kebele, Ethiopia

Farm owner: Niguse Gemeda

Altitude: 2,380M

Process: Natural

Roast Level: Light

Extraction Method

100ml of water, brikka 2 cups.

Upper pot chilled in a freezer with 120ml of fresh cold water, 3 minutes.

Moka Pot ground(0.2mm-0.3mm), No tamping.

1st Extraction: 40ml.

2nd Chilling: With 50ml cold water. Right back to the stove after pouring cold water into the upper pot.

2nd Extraction: 20ml.

3rd Chilling: With 50ml cold water. After pouring water into an upper pot, empty the upper pot after chilling it for 10 seconds.

3rd Extraction: 20ml.

Taste

A berry of Rubus oldhamii Miq., Magnolia Berry,

Chinese Licorice, A flower of black locust, Mildly boiled pork, Forest soil after a sun shower, Black pepper

Bodiness: Low, Tea-like

Umami: Mid-high, pork-like purity

Bitterness: Mid-low

Sweetness: Mid

Impressions

Juicy, Herbal medicine-like bodiness. (like an orange juice)

Pure umami, resembles a boiled pork or Japanese matcha.

This resembles a forest walk, but it's not earthy.

>A forest walk after a sun shower. A sky is clear, a soil is fragrant.

>Score: 4.0/5.0 (Reason: Not sweet enough. Good umami)

https://github.com/gosuda/ssh-chatter/releases/tag/v0.1

Flagship BBS: chatter.pw

TELNET: 2323

SSH: 22

https://preview.redd.it/qnp86bpeo25h1.png?width=1357&format=png&auto=webp&s=bbb37f05ca77db6fcf97b29f7afe7592e54954d7

https://preview.redd.it/ful5tasmo25h1.png?width=993&format=png&auto=webp&s=82560c35d64cb7d341c45c284572033fe914c2fc

Hi, I made a blog in C.

I made this because I love C.

It follows C17/C23 standards which I love.

It supports HTTP/3 and QUIC.

I picked a color that looks 'weird' but it still looks quite cool tho..

Highlight colors can be customized via this.

I don't want to promote, or make a portfolio from its source, but I am willing to provide if you guys ask me.

Thanks :)

P.S) I am not a good designer but I love this simplicity

title=C4PUNK
subtitle=Lee's Tech Blog: Following 'Birds of Paradise'... brand_footer=🄯 Lee Yunjin
port=443 accent=#a2a389