Hacker News Reader

Comment by vunderba | Hacker News Reader

Good article but as a heavy user of Obsidian (and previously Evernote), I would offer some counterpoints:

> After some mental gymnastics weighing if I should continue with Obsidian, I found solace when asking myself "Can I see myself using this in 20 years?". I couldn't. The thought of cyclically migrating notes from one PKMS to another every 5 years, as I had done from Evernote to Notion to Obsidian, made me feel tired.

In point of fact this is actually an argument IN FAVOR of Obsidian. While the editor might be proprietary - the notes themselves are just standard markdown. If somehow all the copies of Obsidian magically disappeared off the earth tomorrow, I could easily switch over to Emacs org mode, VS Code, or literally anything else.

> Obsidian was a great tool for me personally for a long time. But I felt frustrated when I wanted to access my notes on my phone while on-the-go and saw that I had to pay for this feature.

Again, a little bit odd considering that the author is technically savvy enough to write an entire PKMS but didn't seem to consider that you can just check your markdown notes into a git repository and sync with the native android/iOS Obsidian app on a mobile device. All my notes sync up to Gitea hosted on my VPS and it works relatively seamlessly.

I'm glad the author had fun. Personally, I'm very happy with Obsidian and the plugin architecture has made it easy for me to extend it where necessary.

View on HN

> In point of fact this is actually an argument IN FAVOR of Obsidian. While the editor might be proprietary - the notes themselves are just standard markdown. If somehow all the copies of Obsidian magically disappeared off the earth tomorrow, I could easily switch over to Emacs org mode, VS Code, or literally anything else.

100% this. The reason I started using Obsidian in the first place is that it's built on the exact directory structure and file formats that I was already using to manage my writing and notes, and if Obsidian goes away for some reason, that won't change.

Big obsidian fan, but I will say: notes being “just markdown” is not entirely true depending on how you use obsidian. If you are a plug-in heavy user, and those plugins introduce new syntax and lots of JavaScript functionality, you are accumulating a bespoke custom syntax that only works on your copy of obsidian with your set of plugins. Obsidian and those plugins are still free and are a huge benefit, but just something to keep in mind regarding data hygiene and longevity.

True, but the format is still text. In a "catastrophe", you can always just a) ignore these, or b) write custom code to process them (e.g. port the plugin to VSCode or whatever).

Still far better than a proprietary format.

A proprietary format with an export function allows you the same inconvenience of having to write code for processing.

Not true for a variety of reasons:

1. You're relying on the external service to continue providing the export functionality, or else doing regular backups.

2. The format of the exports might be proprietary, so it might be orders of magnitude more difficult to parse.

3. The export might not contain all the data.

4. Even if the export isn't to a proprietary format, it might be to a format that's much harder to parse than Markdown. Markdown is not only a standard, it's fairly readable even without any parsing, as opposed to, say, exporting in HTML. Losing some functionality (often minor, depending on what you use Obsidian for) is better than losing more or all functionality.

1. No, the data is already local, the app is already local, you're not relying on anything.

2. Or it might be orders of magnitude easier to parse vs replicating all the plugins functionality. You're just arbitrarily making the alternative worse

3. That's again something you've made up that's not a generic feature of alternative proprietary format

4. It might also be export to markdown. Again, unless you make up artificial barriers

But you can also do it the other way, for example, anything non-trivial like some large table with in-cell formatting won't be readable in your primitive plain text-based proprietary format, so it will be much worse that the unreadable Excel xml or its binary alternative, but that would still be a much preferable export format since no, you're not going to develop a new spreadsheet parser that some obsidian plugin uses to make sense of it

> it's fairly readable even without any parsing, as opposed to, say, exporting in HTML.

that's true for primitive formatting needs, but in this case there are tools that can convert html to markdown that would easily do that

> 1. No, the data is already local, the app is already local, you're not relying on anything.

That's not necessarily true. Some apps keep only cached copies of the data and the rest on the cloud. Sometimes the local files are in a binary format that is unreadable without the export functionality, and newer releases of certain apps remove the export functionality.

> 2. Or it might be orders of magnitude easier to parse vs replicating all the plugins functionality. You're just arbitrarily making the alternative worse

Obviously this depends on the exact app.

But I don't think you can credibly claim that a textual format like markdown isn't easier to parse than... well, almost any other format.

> 3. That's again something you've made up that's not a generic feature of alternative proprietary format

I didn't make it up. It depends on the alternative app you're talking about. Some export full data including all metadata, some don't include all metadata, etc.

My point is that if all the data is actually just markdown files on your computer, there is no question of whether you have all the data.

> 4. It might also be export to markdown. Again, unless you make up artificial barriers

Once again, depends on the specific app. I was a long-term user of Evernote, and still have a subscription. I just checked, and it looks like you can export to a format called "enex", or to a single html page, or to pdf. That's awesome! And the chance that you won't be able to use this in another app is next to nothing, since everyone works to be able to import Evernote.

It's still a tradeoff between the extra functionality you get from Evernote, vs. the simplicity of the "export" files you have. In Obsidian, there's no separate export, the files are stored in simple-to-read Markdown. But you get less functionality.

It's a tradeoff. I'm not saying one is better than the other. But pretending there isn't a tradeoff is quite simply wrong.

> But you can also do it the other way, for example, anything non-trivial like some large table with in-cell formatting won't be readable in your primitive plain text-based proprietary format, so it will be much worse that the unreadable Excel xml or its binary alternative, but that would still be a much preferable export format since no, you're not going to develop a new spreadsheet parser that some obsidian plugin uses to make sense of it

Yes. I wouldn't use Obsidian to do anything that would require a spreadsheet. I'd simply use Excel, since it's a billion times better at it.

I'm certainly not against using the right tool for the job, nor am I against proprietary formats in general.

1. It true since the argument about formats. You can limit storage of open format to the cloud as well.

> and newer releases of certain apps remove the export functionality.

Then you'd just use the old release with the export functionality intact. You can also make up stuff like "Obsidian can release an app that deletes/encrypts all local files, retaining only the cloud copy, and start charging for it without having any export functionality"

> But I don't think you can credibly claim that a textual format like markdown isn't easier to parse than... well, almost any other format.

This isn't markdown, but markdown + dozens of extensions, so it's very easy to claim that it's much harder to write custom parsers for dozens of formats rather than use an existing parser for some more elaborate format that doesn't need those extensions.

> the files are stored in simple-to-read Markdown

they aren't, they're stored in an undefined format depending on which extensions you use. Part of it is markdown (which is not simple to read in the non-primitive case of richly formatted docs)

> there's no separate export

That's not a benefit! It means that you can't move outside of the Obsidian ecosystem because there is no well-defined format that you could use another app with! So it's (practically) even worse than Evernote since that one is already widely supported, though theoretically it's the same.

> But pretending there isn't a tradeoff is quite simply wrong.

Yet you've failed to identify it, turns out it all "depends on the specific app"! Fine, compare apps, but the general argument was about text-based proprietary format with a chance of data loss if the ecosystem dies (or a chance of requiring a lot of effort to convert), and a generic proprietary format that can be exported into a text-based format... with the same risks!

I don't really know what we're disagreeing on.

> This isn't markdown, but markdown + dozens of extensions,

Yes, if the way you use Obsidian includes dozens of extensions that each use a proprietary format, then it's similar to just using Evernote in many ways.

If you're mostly using plain markdown with only a few custom formats, then it's still easier.

If today, right now, Obsidian stopped working, I could literally open my Obsidian folder in VSCode and still be able to do 90% of the things that I do in Obsidian.

If today, right now, Evernote stopped working, it would take some effort to find a working version, export the files, convert them to markdown or whatever, etc.

I just don't know how you can claim that Obsidian is more effort to use outside of Obsidian than something proprietary.

> If today, right now, Evernote stopped working, it would take some effort to find a working version, export the files, convert them to markdown or whatever, etc.

No, at your accepted level of the loss of functionality that would be trivial.

  - Launch the app you already have, export
  - Launch another app, import. Could be Obsidian. Here is their guide. https://help.obsidian.md/import/evernote
  - Open results in VSCode and ignore the 10% lost in conversion

> I just don't know how you can claim that Obsidian is more effort to use outside of Obsidian than something proprietary.

Because at every step you trivialize one option and complicate the other. While they're generically equivalent. All the same things apply...

> If you're mostly using plain

If you're mostly using plain notes in Evernote, then your conversion to the same plain markdown will be trivial, so using another plain markdown isn't easier

No. You might not be able to load the program to get to the export button. They might paywall it away. Etc.

No, there is no paywall or etc. This is not an imaginary anything goes area, but simple note taking where you have local client with locally synced data which can always export, so this risk doesn't exist

Very much this. I cannot even fully agree with "plug-in heavy" remark: I mean, how heavy must it be, to be considered "plug-in heavy"? I consciously tried to limit plugin usage. But it really gets pretty wild soon. I was relatively lean for maybe the first 6 months, but when some patterns of how I use it become clear enough, it becomes pretty evident how inefficient many super-common situations are and how I can fix them just by installing a plugin.

Fast-forward a year, and all your vault structure implicitly relies on the quirks of Obsidian search behavior, the markdown you write is extremely obsidian-flavored markdown, and you don't even remember how to write LaTeX without LaTeX-Suite shortcuts.

I've been using Obsidian for years now and besides some experiments use zero plugins. What inefficient patterns are you running into?

If you're willing to reimplement them in your own obsidian-like editor anyway, I don't quite see the difference

I wouldn't so I keep to markdown and minimize plugins where aplicable, if I need to run for the hills, I don't expect to lose much

I've thought about this and I think Templater and Dataview are the two plugins I'd miss if Obsidian was sold to a VC tomorrow and enshittified.

And I'm pretty sure both will be forked and modified to run independently of Obsidian within a week of the theoretical enshittification.

Also, Obsidian supports free iCloud sync if you are a Mac and iOS user. I know that's only a subset of users, but a nice option to get Obsidian to sync on the phone if you are in the Apple ecosystem.

Also, they have a cheaper Sync plan now that is $4 per month.

I can't really be bothered that Sync would cost up to 1000 in ten years. If you use Obsidian daily, it had an immensive value and it's cheaper than most services out there.

Syncthing... It can do it too

handles syncing my pictures too

Wasn't the syncthing android app deprecated relatively recently?

It was if you install it from google's app store, but it's still fully functional for now if you install it from F-droid.

I've been using Obtainium to install Android apps from Github releases and automatically update them. It's worked great.

Syncthing's .apk release files can be found here: https://github.com/Catfriend1/syncthing-android/releases

Syncthing-fork (of the android app, not syncthing itself) is a straight improvement.

Yes, I use this and it is pretty solid. I can recommend it

I can second Syncthing. I just use a simple markdown editor with Syncthing on Windows, Android, and a Linux.

Yeah the article was painful to read. $1000 in a decade? Its a decade, who cares. If you make 100k a year its 0.01% of your salary towards something you found worthwhile enough to use for ten years straight

the cheap sync plan is a scam though, it doesn't do enough to be even worth bothering with iirc

To add to your point, the phrasing of "$1K in a decade" seems convoluted to intentionally try to over-emphasize the cost. A much more fair/normal way of phrasing that cost would be $100/year, or $9/month, which is very little for someone who has the time and energy to write their own and gets enough value out of it that they find that worthwhile.

The tradeoff doesn't make sense otherwise. If you're poor, then you wouldn't have the luxury of the available time to write your own PKM - the opportunity cost is huge, it's massively preferential to use an existing free solution that is "good enough" (Obsidian without sync or using your own sync solution, Dendron, Roam, Org). If you're not poor, then $9/month is a rounding error, especially compared to the value provided.

To add to your last point - 10 years is a very long time frame. Any recurring cost grows to eye-watering levels if the time interval is huge enough. In 10 years, a lot can happen in the space and you are not locked in with obsidian - if the next better thing comes along in 3 years, you can easily migrate.

Even setting up your own couchdb + livesync should be a small task if one can consider to 'write a whole app' to replace obsidian

edit note, if you want to build something :) please expand livesync or a new plugin to allow easily sharing of self hosted obsidian notes :) All the ones I tried use some 3rd party hosting which I don't like even if its encrypted.

iCloud sync is too unreliable and opaque for me.

It has been reliable for me with Obsidian. I still prefer Obsidian Sync because it has good integrated version history and shared vaults.

Also agree with the sibling poster - I like subscribing to support them on a regular basis (and of course Catalyst).

Obsidian Sync is great (it helps that I got in on early-bird pricing...but it really is reliable).

In addition, the Git plugin, coupled with Working Copy on my iPhone and iPad, also work extremely well, with a bit of added overhead. Though iCloud works reasonably well for just about everything else, I haven't used it for syncing Obsidian data.

Yes I found it wasn't reliable. Perhaps it has improved, but Obsidian Sync has been excellent. I'm happy to support the developer as I'd like Obsidian to stick around.

> Again, a little bit odd considering that the author is technically savvy enough to write an entire PKMS but didn't seem to consider that you can just check your markdown notes into a git repository and sync with the native android/iOS Obsidian app on a mobile device.

Even simpler, I have mine in a Dropbox folder. Felt very strange for _this_ to be the straw that broke the camel's back for the author.

Nonetheless, very glad for them that they enjoyed and learned from the experience of building a replacement!

Yeah, syncing text files across devices is a problem that has little to do with obsidian or whichever editor/renderer one uses. As long as one keeps things relatively simple with plugin-related syntax flavours, editors are interchangeable.

Yeah, I have my obsidian vault in Dropbox and synced to my phone and back with Dropsync on android. The obsidian mobile app Just Works™ with this. It was a one time setup. Of course there's no fancy conflict resolution going on, but it's unlikely I'm editing in two places at once so it's not needed.

Even simpler, just pay for the feature

Yeah agreed - does anyone really care for $4/month?

Fun fact: Dropbox doesn’t support emoji in file names ( or at least, didn’t last time I checked. )

Deal breaker for me - adding iconography to file and folder names can be a natural, zesty enterprise.

And here I am still coming to terms with using spaces in filenames.

I'm willing to pass on this one, IStillPascalCaseMyFolders (And camelCaseMyFiles.txt)

Still doesn't. I recently moved my vault to Dropbox and had to rename a bunch of filenames

> Again, a little bit odd considering that the *author is technically savvy enough to write an entire PKMS*

I’m pretty sure author just wanted to build PKMS. These types of “oooh, will it be there in 20 years” are standard OCD/procrastination.

> The thought of cyclically migrating notes from one PKMS to another every 5 years, as I had done from Evernote to Notion to Obsidian, made me feel tired.

I had a very similar thought process about 15 years ago, and went on a quest to write my own notes system - after trying out a lot of ideas and giving up, I washed up in emacs and gave org-mode a try. It's actually good enough, and I can grep through my notes easiy, and sync them with git.

I think of the sync paid tier as analogous to a patreon membership, combined with paying someone a tiny amount to manage my data for me. The fact that it's all markdown makes me confident I could take my files and go play elsewhere at any time, but I enjoy knowing my money helps keep Obsidian going.

Not really.. This problem runs far deeper than most are willing to see. First, Obsidian is using a personalized flavour of markdown, and seconds, for many heavy features it's leaning strongly on plugins which are prone to break or even die. Obsidian has a vibrant plugin-community, which also seems to die really fast. This becomes even more critical by plugins dying from changes in Obsidian itself. So while Obsidian is in theory a nice open app, it's longevity-aspect is really awful. I already had many features and plugins dying in the last years, and who know how much more will break in the next 20 years. Simply switching to another text-editor will not do, because they won't offer the missing features. So at best, you are just not losing your data, but you still won't have the tooling to use them.

Someone creating their own system, where they have full control over everything, even if they will have to sacrifice some benefit in the short run, just makes sense in a bigger picture.

Plugins aren't required to use Obsidian. I have just a few, none of which make consequential modifications to my files. I've never had a need to use anything like Dataview, for instance.

To me, the "dialects" of Markdown have never made any difference in using it, even between applications. I think the only non-standard (for whatever "standard" means in Markdown) markup I use in Obsidian is "%%" to indicate comments. That's certainly something easy enough to search for should it be necessary in a text editor.

But you do have full control, if you want it. Nothing stops you from altering plugins or making your own.

The plugins sit in a local directory. Very easy to modify.

> Nothing stops you from altering plugins or making your own.

You still have no control over obsidian itself. Any change can and will break plugins. So you either settle with one version for the next decade, or you have to maintain them. This is just the normal dependency-hell that every project has, where you have to compromise with external dependency and their whims. Just that neither plugins nor obsidian (to some degree) are the level of professional software-projects in that regard.

And let's not talk about changing Obsidian on fundamental levels. You have even less control on how it works on everything which is not accessible by plugins.

Genuinely curious, which plugins do you mean for example when you say that many heavy features are leaning on them?

I could see the dataview plugin as an example (even though I don't use that one personally) but most other plugins seem like they just add more convenient ways to do something that would be still pretty simple to do manually. (Templates for example).

> Genuinely curious, which plugins do you mean for example when you say that many heavy features are leaning on them?

Depends on what you are doing. But the whole task & project-management-corner is constantly moving. Everything which modified the editor and preview was also regular breaking in the last years. For example, there were some plugins adding banners at the top of documents, or background-images or some icons. Or plugins modifying the yaml-area. They were all breaking multiple times when Obsidian was switching to the new live-preview-editor, then on changing frontmatter to properties, and on some other occasion IIRC. Usually after some months a new plugin appears, or someone forks the old one and fixes it. But as a user, it's pretty annoying to constantly have something breaking outside your control and getting stripped of features you want/need for various reasons.

Obsidian is useful, but far from being stable long-term yet. It's still very young.

> I could see the dataview plugin as an example

Yes, dataview was also very unstable the first 2 years or so, switching code and concepts, breaking old code along the line. It seems to be stable now, as the focus is on datacore.

> but most other plugins seem like they just add more convenient ways to do something that would be still pretty simple to do manually. (Templates for example).

Does it matter what a plugin is doing? If it breaks, it's a loss, whether it's crucial or just annoying.

Don’t use plug ins

then you lose a large amount of functionality and value. That's the point they were making.

You may lost a large amount of functionality and value. If you never become dependent on plugins, as is true of some Obsidian users, you lose nothing. Obsidian has considerable functionality and value right out of the box, at least as much as many other Markdown editors, and costs nothing.

Concerning, maybe. Definitely not surprising. One’s technical ability to do something has, if anything, a negative correlation with their ability to value and manage their own time. The author’s justification is absolutely ridiculous, hands down. I simply pray that they’re never in charge of deploying another human’s time effectively.

Yeah, I don't even do that. I just copy the files over if/when I want to. (Do people really not know how to use a basic filesystem to copy files these days?)

But mostly I don't. My work notes are on my work laptop and my personal notes are on my PC. I might copy them onto a mobile device if I'm traveling, but I might not bother. Mobile devices don't have the good keyboard and large screen to really be useful for stuff like that. But I have copied them over before just in case I wanted to find something in them.

There is also LogSeq which is open-source and very similar to Obsidian. I use it with Syncthing to sync notes across devices. I would rather see more effort put there, to improve table management, for example...

I'm migrating what's in Evernote to Gmail because the "upgrade to premium" popups are too tricky and the value of Evernote just isn't worth the subscription unless you're relying heavily on it, which I can't because of the popups.

Totally agree, I personally have obsidian set up on multiple devices, and they all automatically sync to my local Synology NAS.

Thanks for the feedback! Agreed Git can be used to sync your notes. Its a great solution for those comfortable putting their notes into a Git repo like Github. I wasn't comfortable with that however.

Currently vetting a way to sync my database files with my markdown files on my laptop, so it functions similar to Obsidian. I enjoy Vim too much to work constrained to Directus' markdown editor!

It's not just git. You have the plugins available for S3, couchdb, FTP, MongoDB, cloud drives, rsync, syncthing, and probably every other storage/protocol in the world. And they're all available for free in obsidian.

Common ways to sync Obsidian are through cloud tools (Google Drive, OneDrive, etc.), SyncThing Fork or Git.

I'd recommend you to look into SyncThing Fork or a similar tool if you never want your notes to leave your own server.

I wrote about ways to sync Obsidian here: https://bryanhogan.com/blog/how-to-sync-obsidian

If you need multiplayer sync, I've been working on a plugin that makes Obsidian real-time multiplayer (like google docs) called Relay [0]. A lot of our users use it in combination with SyncThing to keep it entirely free for up to 3 users (we also offer a paid plan with attachment storage and more seats).

[0] https://relay.md

Git is decentralised. You can sync between laptop and phone directly, no third party server required.

To be clear, GitHub is centralized, but Git is not. You can sync between laptop and phone directly with Git -- no third party server required.

How do you use git on a phone? I haven't found an easy way to pull to my phone and open Obsidian files.

No one said anything about GitHub… git is perfectly fine for this use case and 100% private.

What about git makes you uncomfortable?

I saw that you didn’t want to use a 3rd party provider, but why not stick a git repo on your VPS (which you are trusting with your data today) and use that to coordinate syncs between your client devices?

Made a comment in the thread explaining this https://news.ycombinator.com/item?id=44023090

I expect my PKMS to evolve and wouldn't rule out a self-hosted Git server if I find it's a better option long term.

> wouldn't rule out a self-hosted Git server

I don't think you really get it. Git is distributed. There's no need for "a git server". You already have a machine on which you host the SQL database, you can just use that as yet another git remote.

Thanks for the reply. I do agree with sibling comment from tasuki that I think you’re missing the simpler solution of plain git repos to solve “owning your own data in a future-proof manner”.

If you’re not trying to coordinate work among multiple people, and aren’t trying to enforce a single source of truth with code, you don’t _need_ “git server” software. You just need a git repository (folder & file structure) in a location that you consider to be your source of truth.

I’m not trying to convince you to change it now, especially if you’re happy with what you have, but I would suggest reading some (or all) of https://git-scm.com/book/en/v2

I think the first ~4 subsections of chapter 4 cover what I & tasuki were suggesting could be sufficient for you. If you’re the type of engineer to read through the code of your data storage layer, I think you’d find Chapter 10 (Git Internals) interesting, because it can demystify git. I enjoyed the whole book.

As with any engineering project, I see lots of questions about your choices, and I applaud you for sticking around. I would make very different decisions than you, based on your stated priorities, but that’s okay.

You only really need SSH access on a box to use it as a git remote - no server needed.

I learnt this quite late and was not obvious to me so hope it's helpful for you too.

The odd part here is why take it to 100%+ when you can just build a plugin on Obsidian rather than re-building the whole thing? Seems a bit extreme.

In 20 years will that plugin work? I doubt it.

You can’t even compile stuff from 20 years ago without some extensive archeological efforts. I doubt this is your largest problem by then.

???

I have dozens of projects from 20 years ago that I can compile today.

With respect, I doubt it. Have you tried pulling out a 20 year old tarball and compiling it, without modification, on a modern distro?

I recently unearthed something that I thought was 20 years old when someone asked me about it. I checked and it was only 14 years old based on mtime (thought I suspect I started the project nearly 20 years ago). Another project I unearthed for a different reason was only 13 years old by mtime (again, it was started before that). I must concede that I haven't actually recently compiled and used anything that was untouched for 20 years.

I should note that the first program I wrote that was actually used for a purpose (it calculates energy based on an internal stopwatch and then typing in values from a volt and ammeter, for a science project in 1992) still works in qb64 today.

The second program I wrote that was actually used for a purpose assumes a parallel-port printer on DOS that uses a fairly old version of PCL, and was written in 16-bit C, so probably won't work today.

A lot of these things can be made to work. That isn't being contested. But if you take a random piece of code of the internet from 20 years ago, it very likely won't compile out of the box on a modern system.

For example, I just took the oldest version of openssl I could find with a quick search (2015, so only 10 years old), and it fails to compile on my Mac. It detects macOS/darwin, and then proceeds to compile for 32-bit Intel, which obviously doesn't work. OpenSSL has fallbacks for straight C implementation to support platforms that haven't been customized, but their build scripts assume that macOS = Intel.

Ok sure, changing the whole freaking CPU architecture will bork a build script. So to prove a point I just downloaded v2.6.11 of the Linux kernel (released in 2005), unpacked (this time on Ubuntu 24.04 on real Intel), and did a `make menuconfig && make`. Of course I don't expect a 20 year old kernel to run on modern hardware, but could I compile it? No, I could not: modern GCC forces PIC by default, which parts of the Linux kernel do not support. I was able to fix that by editing the makefile to pass `-fno-pic` in CFLAGS. Then I get hit with another error due to "multiple definitions" of functions that are declared slightly differently. Turns out old GCC didn't warn about this, but modern GCC handles these declarations differently. This is after pages upon pages of warnings, btw, with only a few source files compiled so far.

I gave up. This is what is meant by archeology required: for anything nontrivial you often have to build the environment in which the code was originally compiled in order to get it to compile again.

I have lots of stuff that's 20 years old that still builds ... C, Perl, shell scripts ...

A shell script is something very different from a markdown editing app with plugins, file synchronisation, multi-platform support, and many more moving parts. And even a 20 year old shell script is probably going to fare pretty poorly.

Do you remember what the most common processor was in 2005? A Pentium 4, or a Celeron maybe. That was when 64 bit operating systems just became a thing. I’d really like to see you getting a version of, say. OpenSSL from 2005 to compile on modern hardware…

"A shell script is something very different"

So what? Maybe read the thread that you're responding to.

"And even a 20 year old shell script is probably going to fare pretty poorly."

You can't just say "my sweeping assertion is probably right". I have shell scripts that are more than 20 years old that still run. And I have C89 programs that still compile and run.

"I’d really like to see you getting a version of, say. OpenSSL from 2005 to compile on modern hardware…"

This is a ridiculous disingenuous strawman. I can't get my FORTRAN II programs that I wrote in 1965 to run, but that has nothing to do with the original claim that I responded to, which was a sweeping generalization that a SINGLE counterexample refutes.

Over and out.

This is why I didn't like Obsidian, half the plugins I tried didn't work despite them being in the top 20 downloaded ones. Meanwhile I'll use like 15 year old emacs plugins that haven't been updated in like 5 years and they'll work fine (I think org-diary or something along those lines was what I tried).

In 20 years you might be dead.

Directus is not eternal either. They are OSS, but you can't support it yourself forever. For a such a long run this looks like a controversial choice for me.

your ai will straight up write you the plugin if it hadnt already done that seamlessly when you requested it render your file.

Some people just enjoy the process, and you'll always learn something new

GitHub is not git

Just use Joplin, it’s open source and syncing to many cloud providers you already probably have is free.

Reply on news.ycombinator.com