this post was submitted on 15 Oct 2023
115 points (100.0% liked)
Technology
37735 readers
51 users here now
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You could be right, but I'm not 100% sure of that. From the article:
If they can stick to that, they can avoid going downhill. The main driver for enshittification is big shareholders that want the company to keep growing -- shareholders don't care about stable profitability, they need growth for their ownership stake to increase in value. If Obsidian is profitable now and they're fine with just keeping it that way, they can make it work.
The driver of enshittification is extracting money from your user base and investors alike. Lacking one doesn't stop it.
If I was going to trust obsidian, their code would be fully foss. Since it isn't, there is nothing future proofing my notes in their software. Might as well switch now to something which largely works better and is more feature rich.
Which is relative to personal taste and needs.
I definitely agree that I wish it was fully foss, but i also think it is a far better option than notion, onenote, etc for most people (as long as it meets their needs and preferences) since with obsidian you do actually own your data and you don't need to pay unless you want their sync.
Even if, worst case, Obsidian enshitifies, all the notes are markdown or json (json for config and things that don't work in markdown, but the community and the devs work hard to keep that to a minimum) so you can still access your stuff in any text editor and it will be fairly easy to get the important data migrated into anything else. (I often use vs code to manage my notes, for instance, esp for big find and replace or re-org tasks) Even the non-standard markdown from obsidian and the most popular plugins reads well and could fairly easily be replicated with remarked or other markdown libraries. In this way, i think Obsidians approach is far superior to a tool which uses a database to store its data, since a database would require some effort to use standalone, or some work to migrate it to another tool or some sort of minimal client interface.
By its design, Obsidian could also be replaced by reverse engineering their api. If obsidian takes the dark path, we will probably see a foss community grow from the plugin dev community to replace it and be as compatible with plugins as possible, even if its just the basic text and display components. Tbh, it could totally be a vs code plugin, an emacs mode, [insert any text editor with plugins here]... thats how portable the data is. The obsidian devs know this, and they are intentional about staying this way. A shift in attitude here would be noticed by the community very quickly.
Everything about this discussion is.
OK.
Why bother when I can do it now with the better option rather than in a couple years with several thousand notes?
Also it should be noted that peculiarities about how obsidian works makes transfers non trivial. Individual notes are fine, file structures not as much, but it's minor.
Trilium has a pretty robust export system last I checked. Not rally worried about that, meanwhile I get the massive speed upgrades and stability associated with a database.
Sure it could be reverse engineered... Or just use the software that's already basically there...
You're doing that thing where someone starts going to bat and listing off this that or this other thing to rationalize their own choice or rationalize the choice for others.
I've used obsidian for years. I switched to trilium for reasons I stated above. Unless obsidian goes fully foss, and gets way way more stable, i'll be using the genuinely better choice, thanks though.
I have not explored Trillium enough, but from what I know, it seems to be an excellent choice and worthy of mention and advocacy. I did not say that Trillium was bad.
I'm glad it's a better choice for you! Replying to you doesn't mean I was saying your choice was incorrect for you or others, merely that I wanted to discuss in context of your comment. Apologies if you read that from my response. I do not think I can declare a genuinely better choice. In my opinion, the most important thing with note-taking is whether you keep returning to do it and can easily find past notes.
Ok? I don't recall saying Obsidian was THE choice, nor that your reasons were incorrect, so I don't know why you're casting me in that role. Generally I lean towards self-hosting and foss options for the reasons you describe, but this is an instance where I calculated differently, and I just want to provide context that, compared to other proprietary options, Obsidian is way less a concern. I've personally gone down rabbit holes with foss alternatives because i've been overly concerned about things and ended up not being productive. I've also chosen foss tools before that I thought would be safe or easy to migrate out of, and then ended up having a terrible time anyway when the day came that it became abandonware or a new maintainer took it in a different direction.
Perhaps you are doing that thing where you forget that not everyone can easily use a fully foss option and that not everyone can reliably install a tool from github in the event it isn't available on an app store or via an installer? (I'm certainly guilty of this sometimes myself)
Even for a tool like Trillium, while it wouldn't enshitify the same way a proprietary tool could, it could also just be abandoned, no forks could arise, and someone without a ton of self-hosting/compiling/cli-based install troubleshooting experience would be in just as bad a situation for migrating or going elsewhere. Even right now, Trillium is technically unsupported on macOS, so it's not a great option for some out the gate. (Nor does that make Obsidian automatically better)
I didn't say everyone should necessarily use trilium. I described my rationale pretty plainly. Trilium can be transformed into md files trivially, if it gets abandoned, any users will be fine.
Trilium is literally available as an installer.
Use whatever you want. I'm not really here to describe the entire feature set of trilium for people in a play by play. Go look at the features, give it a try, or don't, im not about to place massive amounts of personally produced information in software I can't fully trust though.
Linking in trillium notes is PITA.
How do you work efficiently? Trillium is much more friction I felt when testing it out.
I agree that trilium could use more worth on linking efficiently. It's no various complements. I don't really have a method I just deal with it, sorry to disappoint.
But what is your workflow then?
Just curious because I can see trillium notes as worthfully when really creating sophisticated notes, like finished documentation.
But for working with small/atomic/draft notes the workflow is just too much friction for me to use it as a tool despite documenting past stuff.
I generally finish thoughts out in sections in a note and if I feel I need a new note I can drop in a link or I can send a section into a new note. I find it actually has cut down on note bloat, my main pain point is quickly writing aliases. If I was a script writer I don't think it would be hard to improve the feel of it tbh.
It's completely markdown which is future-proof and easily portable to other software
Or just... Not waste my time and use the better alternative now which has no risk of enshittifying.
But Trillium is not plain-text Markdown, so you're comparing apples to oranges. They're completely different approaches at their most base level.
Having been through the enshitification of Obsidian, it was important to me and many others to be not beholden to any vendor's file system. Trilium notes require Trilium to be instantly usable. My notes are useful and usable in Obsidian, Logseq, VSCode, and others, because they use plaintext Markdown files.
They are functionally and aesthetically twins. Besides obsidian isn't even actually markdown, it uses its own linking system. Either way this is just a silly assertion to make.
It's the most critical, most basic factor in determining what software to choose. I am specifically using software that works on plain-text Markdown files for many reasons, least of all that I need other software to be able to interact with those files. You can't do that with Trilium.
Secondly, Obsidian does not use its own linking system, it supports both the widely used Wikilinks system and the DaringFireball/CommonMark markdown system.
Come on. At least have knowledge about the software you are trying to criticise.
Lmao. No, I don't agree that file format is the most critical choice, though in that regard a database still has many many benefits. Regardless trilium has interoperability, if you entirely need plaintext files then you do you. I don't really care, nor do I expect that to be anywhere close to a common requirement.
Yes obsidian supports various linking formats, but mainly uses its own. Unless you convert or willingly and intentionally use a more compatible system from the start, something plugins and obsidian itself only somewhat support, you'll probably be using the obsidian specific linking. Why wouldn't you either, it's a good link system.
Ive used obsidian for 4 years before switching to trilium. Feel free to not be an ass and actually say something useful or relevant to the discussion, otherwise cheers.
Local vs web-hosted, or open formats vs closed formats are part of the exact same choice. So I think you probably do agree that it's a critical, basic component of your software decision. 😉
But it doesn't. The only two options are Wikilinks or original Markdown.
The only software that I'm aware of that is in the same camp as Obsidian - plaintext Markdown files and non-outliner - is Zettlr.
K. Md files using wikilinks, which don't actually work in mediawiki. Not a great argument for compatibility off the shelf as some universal thing.
You're describing now a larger scope of requirement than whether a file is .md, and which is met in various ways not solely relevant to whether a file is md.
Feel free to check out zettlr if your strictest requirement is that you use plaintext markdown files the entire time you're writing and simply cannot accept exporting or interacting with a database. Or you just prefer it. Do what you like.
I am not. I am saying data storage format is a basic, critical factor. And it is. And I already know you agree on this, which is why you choose FOSS options with known, open formats.
And both the trilium db and markdown files validate that requirement. So it's not really relevant.
Not relevant to you, but relevant to others who might require local plaintext files, rather than a database.
Which brings us right back to apples and oranges 😘
I don't think you know what apples and oranges means, but if it means you're satisfied with the conversation then happy day.
Use the software that works best for you. If dealing with a database is too much for whatever else you're doing, feel free to use something else.
Obsidian, Zettlr, and Logseq live in the category of local plain-text file-based PKMs.
Trilium lives in the category of local database-based PKMs.
The reason the first category exists is that people wanted to get out of vendor and file lock-in.
Apples and oranges.
Having been through the enshitification of Obsidian, it was important to me and many others to be not beholden to any vendor's file system. Your database requires Trilium to be instantly usable. My notes are useful and usable (and frequently accessed) from Logseq and VSCode.
The two options are simply not comparable, hence apples and oranges.