Yes, having a solution for this makes sense, but the proposed solutions are just not good. Sometimes one has to admit that not everything can be solved gracefully and just stop, hunting the whale.
Yes, having a solution for this makes sense, but the proposed solutions are just not good. Sometimes one has to admit that not everything can be solved gracefully and just stop, hunting the whale.
How is this "free online edition" distinct from piracy, in that case?
People are making books freely available all the time, even those they sell on other platforms. Nothing wrong with this.
Having a database isn’t mutually exclusive with the core functionality. You can simply not use it.
They have several modifications of Markdown, everyone has. But not everything makes sense to implement in a flavour of Markdown. YAML is for structured data significant better than a freeform-format, especially when you're in the phase of building the foundation of a new feature-family.
The complain is valid, Markdown is for documents, free form, free flow, structured data are a very different use case, and while YAML is better for the job, it's still a different language with different smell.
But Obsidian is a tool for managing knowledge, always has been; it's not just a plain Markdown-editor. All those features which are going beyond simple flavoured text, have always been part of it's Core-Mission, just not materialized yet.
No, horrible job at explaining. What does it mean to turn any set of notes into a powerful database? What does it mean to "turn"? Does it mean that a file will become a database? Or does it mean that a file can be interpreted as a database? And why set of notes? If I have a single note, can I turn that into a database too? Are the records of the database files, or items in a file? What is happening when I type ![[Untitled.base]]? Is the file where I typed that a database now? Or does that text assume that the file named Untitled must be a database?
They do a horrible job at explaining it.
You must be fun at parties. Complaining about everything, but not even bother to read the damn manual... It's explained on the third sentence on that site. Ok, to be fair, there is a big picture between those parts, and you have to follow some links for more details.
> And why set of notes?
Just curious, do you even know Obsidian? Have you ever used it? You read like someone who has no clue about this software, jump right in the middle of the manual, and then complain that you missed the tutorial.
Obsidian is a markdown-editor with knowledge base. Notes are its lifeline, and they have since nearly the beginning the option to put metadata into each note in a special section (in yaml), basically the header of the note. This metadata are now called properties. Bases is a feature building up on this metadata, offering a database-like experience for viewing and editing them in a specialized UI. The database, is the vault, the folder+subfolder containing the notes. Each note is a row in that database.
This is all explained in the documentation, if you just would read it...
Otherwise it is a bit like saying "all monads are functors" when trying to make your reader care for investing time and energy into understanding the concept of monads. The problem there of course is that explaination is circular: without the reader knowing what a monad or a functor is they can't understand the explaination.
A good explaination gives you the technically correct slogan in the beginning (for the advanced readers) and then explains the words and what you can do with such a database and why you should care. Many explainations skip the last step and leave that part as an exercise to the reader.
You can't constantly optimize your communication for the least educated recipient. Obsidian is full of technical, specialized terms. If you don't know a word, research it.
And database as a concept is common knowledge today. Everyone will have the word heard in news at least, most will have a rough understanding of its purpose. And people using obsidian are usually not the most uneducated, there have a certain level of technical expertise. Most will also know and understand the dataview-plugin.
On top of that, you can add other properties to the view, especially one like modified date, which updates every time you modify the file. This is useful for seeing which files you haven't looked at in a while. Old concepts often apply to new ones, but we sometimes forget to check back to make that connection explicit."
Maybe it's a bit harder to understand, as it's a more mushy than the usual relational database.
The analogy would be to Cargo: `cargo fmt` just runs `rustfmt`, but you can also run `rustfmt` separately if you want.
ruff at least seems to be compiled into uv, as the format worked here without a local ruff. This is significant more than just an interface. Whether they are managed and developed as separate tools doesn't matter.
> This is more about providing a simpler experience for users that don't want to think about their formatter as a separate tool.
Then build a separate interface, some script/binary acting as a unified interface, maybe with its separate distribution of all tools. Pushing it into uv is just adding a burden to those who don't want this.
uv and ruff are poor names anyway, this could be used to at least introduce a good name for this everything-python-tool they seem to aim for.