gejose

The author literally spells out why this isn't always the case:

> Yes to start out it’s 95% booleans. But then you want a rollout. And then you want some targeting rules. And then you want non booleans… maybe some json. Oo wouldn’t it be nice if the json could conform to a schema… and then eventually you are like damn I really want to change these without deploying. Or you want to read the same flag from multiple services.

> They're packing lots of signal into fewer words

This has not been my experience. I see it generating walls of text with very little SNR.

Just noticed that the foreign language shown in that screenshot is malayalam[1], a language spoken in a southern state of India.

[1]https://en.wikipedia.org/wiki/Malayalam

Will definitely consider this after I clean things up. Note that it's completely vibe coded though.

Came to the same conclusion too – I appreciate that it exists, but the UI felt really complicated and disorganized.

I really like that this exists, but I found the menus and UI to be rather non-intuitive. My main use case was to sync reading progress between my Kobo and my iPhone. I was able to do this using KOReader on the Kobo & the Readest app[1] on iPhone (also open source).

Ultimately I decided to get rid of KOReader because it felt a bit laggy. The gestures (eg: swiping up on the left side to increase frontlight brightness) didn't work well either.

I eneded up writing my own software to sync progress from Kobo to a KOReader Sync server[2] which my Readest app also connects to (love that unlike the Kindle, the Kobo is quite an open system). You can even set it up so you can SSH into it[3].

[1] https://github.com/readest/readest [2] https://github.com/koreader/koreader-sync-server [3] https://www.mobileread.com/forums/showthread.php?t=254214

ATS = Applicant Tracking System. It's software to help you manage your hiring pipeline as a whole.

100%

Hey kepano, really love the work you're doing!

Here are some feature I wish existed in Obsidian without any plugins:

* Dataview [1] (this is now solved with Bases, so I really appreciate that)

* Folder Note [2] (I, and I assume many others come from Notion, and I wish this were a thing)

* Recent files [3]

* A built in calendar [4]

* Link embeds [5] (or something to store previews for pasted links)

* Waypoint [6], or something to create a table of contents

These are just things I wish existed, but whether or not these are 'basic' can be debated. Ultimately I do wish there were a robust permission system for plugins so that personal functionality gaps can be plugged, but without compromising safety.

References: [1] https://blacksmithgu.github.io/obsidian-dataview/ [2] https://github.com/xpgo/obsidian-folder-note-plugin [3] https://github.com/tgrosinger/recent-files-obsidian [4] https://github.com/liamcain/obsidian-calendar-plugin [5] https://github.com/Seraphli/obsidian-link-embed [6] https://github.com/IdreesInc/Waypoint

Love Obsidian but I've previously commented about the security model for plugins here: https://news.ycombinator.com/item?id=45308131. TLDR: your entire vault (and possibly filesystem) is exposed to every single plugin you install.

I really do think Obsidian needs 2 things to have any reasonable security:

1. It needs to be a lot more batteries-included. A user shouldn't need a plugin for basic functionality.

2. It needs a granular permission system, where each plugin should have to declare and prompt you to allow or reject specific permissions, just like on iOS and Android. The system should enforce that a plugin cannot bypass this.

Github has 84.92% uptime in the last 90 days according to https://mrshu.github.io/github-statuses

I don't know how this is even remotely close to acceptable.

What do you find to be better about it over LocalSend? (The website seems to be down)

Been using this on all my devices (macos, iPhone, iPad, android, windows) and love it!

> Everything is a callback returning a promise in some weird resolution chain

Care to provide some examples of this? This hasn't been my experience, in general.

⬆ Huge upvote for this find as I've been looking for a way to do this recently.

I tried the yabai + skhd recently, but I didn't like that I had to disable System Integrity Protection.

There's always a comment like this in most discussions about javascript.

This sounds like an engineering quality problem rather than a tooling problem.

Well structured redux (or mobx or zustand for that matter) can be highly maintainable & performant, in comparison to a codebase with poorly thought out useState calls littered everywhere and deep levels of prop drilling.

Redux Toolkit has been a nice batteries-included way to use redux for a while now https://redux-toolkit.js.org/

But the popularity of Redux especially in the earlier days of react means there are quite a lot of redux codebases around, and by now many of them are legacy.

I believe Gary Marcus is quite well known for terrible AI predictions. He's not in any way an expert in the field. Some of his predictions from 2022 [1]

> In 2029, AI will not be able to watch a movie and tell you accurately what is going on (what I called the comprehension challenge in The New Yorker, in 2014). Who are the characters? What are their conflicts and motivations? etc.

> In 2029, AI will not be able to read a novel and reliably answer questions about plot, character, conflicts, motivations, etc. Key will be going beyond the literal text, as Davis and I explain in Rebooting AI.

> In 2029, AI will not be able to work as a competent cook in an arbitrary kitchen (extending Steve Wozniak’s cup of coffee benchmark).

> In 2029, AI will not be able to reliably construct bug-free code of more than 10,000 lines from natural language specification or by interactions with a non-expert user. [Gluing together code from existing libraries doesn’t count.]

> In 2029, AI will not be able to take arbitrary proofs from the mathematical literature written in natural language and convert them into a symbolic form suitable for symbolic verification.

Many of these have already been achieved, and it's only early 2026.

[1]https://garymarcus.substack.com/p/dear-elon-musk-here-are-fi...

> Everything about this is ridiculous, and it's all Anthropic's fault. Anthropic shouldn't have an all-you-can-eat plan for $200 when their pay-as-you-go plan would cost more than $1,000+ for comparable usage

Hard disagree. Companies can and do subsidize products to gather market share. It's just a loss leader [1]. The big money for them is likely satisfied software engineers pushing their employers to pay for more Anthropic products in an enterprise setting.

[1] https://en.wikipedia.org/wiki/Loss_leader

I used to run into this quite a bit until I added an explicit instruction in CLAUDE.md to the effect of:

> Be thoughtful when using `useEffect`. Read docs at https://react.dev/learn/you-might-not-need-an-effect to understand if you really need an effect

> on a site I personally maintain (~100 DAU, so not huge, but also not nothing)

This is what the parent said.

> some simple code for your personal website

This is your (reductive) characterization of their work. That's fine, but please keep in mind that that's your inference, not what the parent said.

> a semi-random word generator

Calling tools like Claude Code a "semi-random word generator" is certainly a choice, and I suspect it won't age well.

> lot of magic to make it trivial to start and they don’t scale to real projects

Ruby on Rails is probably a great counter example here though.

> just need to be good enough and fast as fuck

Hard disagree. There are very few scenarios where I'd pick speed (quantity) over intelligence (quality) for anything remotely to do with building systems.

> But you're comparing the LLMs to humans

Didn't the parent comment compare Sonnet vs Codex with GPT5?

Shameless self plug, but my workout tracking app[1] uses a sync engine and it has drastically simplified the complexities of things like retry logic, intermittent connectivity loss, ability to work offline etc.

Luckily this is a use case where conflict resolution is pretty straightforward (only you can update your workout data, and Last Write Wins)

[1] https://apps.apple.com/us/app/titan-workout-tracker/id644949...

Specific permissions declared in a manifest much like browser extensions could be a good first step.

Perhaps, but I think what you might put onto Obsidian (personal thoughts, journal entries etc) can be more sensitive than code.

This is one way to look at it, but ignores the fact that most users use third party community plugins.

Obsidian has a truly terrible security model for plugins. As I realized while building my own, Obsidian plugins have full, unrestricted access to all files in the vault.

Obsidian could've instead opted to be more 'batteries-included', at the cost of more development effort, but instead leaves this to the community, which in turn increases the attack surface significantly.

Or it could have a browser extension like manifest that declares all permissions used by the plugin, where attempting to access a permission that's not granted gets blocked.

Both of these approaches would've led to more real security to end users than "we have few third party dependencies".

This was also my experience when I last tried around 4 months ago. I ran into a lot of bugs and often found myself opening sites in safari instead.

I hope it's improved now.