Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Smaller is better – The rise, fall, and rise of flat file software

wilcosky.com

Post reply on HN
Print view View original

111–120 of 152 posts

Re: Smaller is better – The rise, fall, and rise of flat file software

#111

Post by voltaireodactyl »

drawingthesun wrote: post #63

I like plaintext as I have the option to make edits with various editors in addition to the main application. This can lead to easier search and manipulation. I use Logseq and Noteplan, both store data in plaintext. As a secondary editor to both I use Sublime Text for very fast search and replace, or diagnosing why Logseq might be having issues. I’ve had issues before in other note taking / task apps and when I run i…

Do you use Logseq and NotePlan together, or as separate silos? I’ve been trying to figure out a way to use them in sync, but it doesn’t quite work. NotePlan is pretty good at making org functions possible just in markdown files tho so I keep leaning towards sticking there — but then I remember how powerful org is and I’m back where I started.

Basically, if you have your workflow written up anywhere I’d love to read it.

Re: Smaller is better – The rise, fall, and rise of flat file software

#112

Post by macintux »

Mehdi2277 wrote: post #99
mkleczek wrote: post #77

Earlier quoted context omitted.

This opinion is quite popular nowadays but IMHO it is caused by misunderstanding what a database and database management system is and what it is for. DBMS (and in particular) RDBMS is not a merely persistence medium for an application - DBMS main role is to _share_ data between applications.

I don’t understand this as distinction with file systems. Networked file systems exist and I have a lot of production code that shares data as files in either some networked file/blob system. Often databases even just store a reference to a file path for stuff like images/other large artifacts that are shared from some file system.

Read-only sharing is trivial. Concurrent write accesses, not so much.

Re: Smaller is better – The rise, fall, and rise of flat file software

#113

Post by [deleted] »

latch wrote: post #42
ReactiveJelly wrote: post #34

Earlier quoted context omitted.

If you're running Postgres in Docker, you can just stop the container and tar up the data volume and start it somewhere else (This also works without Docker of course, but Docker makes me feel safer when I do stuff like this)

This procedure is officially documented (1). Since we're talking about copying a folder, I'm not sure why you'd feel safer doing it via an additional layer of abstraction. (1) https://www.postgresql.org/docs/14/backup-file.html

[deleted]

Re: Smaller is better – The rise, fall, and rise of flat file software

#114

Post by Danborg »

WalterGR wrote: post #106
Danborg wrote: post #26

Using flat files only solves half the problem, in order to truly be able to host anywhere, you also need to be able to ditch PHP and server side processing requirements. (Wonder CMS, highlighted in this article, requires PHP with a couple of mods.) That’s why I think static site generators are the more interesting code in this space. I’m a big fan of Gatsby, but there are several other great ones as well. This allows…

> Using flat files only solves half the problem, in order to truly be able to host anywhere While that may be a problem for some, I don't think it's the problem for the purposes of this article and discussion. Different situations have different requirements.

Still, it is a consideration, and it all factors in. Copying your WonderCMS files to another host, great… oops, it doesn’t have PHP mbstring extension, sorry, won’t run. (And if you’re trying to use “free” hosting, you probably don’t have privs to install the missing requirements.)

Re: Smaller is better – The rise, fall, and rise of flat file software

#115

Post by HanClinto »

Xunjin wrote: post #61
RedShift1 wrote: post #18

uncle roger voice just use SQLite haiyaaaaa

I'd love watch a uncle Roger programming-wise reviews.

JomaTech has done a colab or two with him, but I agree -- I feel like Joma could build his own dedicated character of that type.

Re: Smaller is better – The rise, fall, and rise of flat file software

#116

Post by ntnsndr »

GuB-42 wrote: post #30

Maybe it is just a reflection on the state of filesystems vs databases. There is no fundamental difference between a database and a flat file, it is all bytes on a disk/memory in the end. So it is mostly a question of balancing the roles of the hardware, OS, and application software. For example, if the reason you are using a database is that it does a particularly good job at limiting disk IO, then it may not be nec…

I love this point. I had honestly never thought of the question this way before.

Re: Smaller is better – The rise, fall, and rise of flat file software

#118

Post by DarylZero »

DeathArrow wrote: post #53
GuB-42 wrote: post #30

Maybe it is just a reflection on the state of filesystems vs databases. There is no fundamental difference between a database and a flat file, it is all bytes on a disk/memory in the end. So it is mostly a question of balancing the roles of the hardware, OS, and application software. For example, if the reason you are using a database is that it does a particularly good job at limiting disk IO, then it may not be nec…

A database can be relational, it can make some guarantees, it can pass Acid. With a file you are responsible for performance, reliability, integrity and security of the data. Do you believe that you can do a better job than those tens of guys who contributed to a DBMS? Go ahead. Do you not need reliability, integrity, security, performance? Go ahead. So use a file to store data instead of database but know the trade-…

The filesystem provides its own ACID guarantees too. Well, some filesystems.

Re: Smaller is better – The rise, fall, and rise of flat file software

#119

Post by funstuff007 »

OJFord wrote: post #50
GuB-42 wrote: post #30

Maybe it is just a reflection on the state of filesystems vs databases. There is no fundamental difference between a database and a flat file, it is all bytes on a disk/memory in the end. So it is mostly a question of balancing the roles of the hardware, OS, and application software. For example, if the reason you are using a database is that it does a particularly good job at limiting disk IO, then it may not be nec…

For me it's about proprietary vs. readable - unless it's obviously necessary for performance I think I'd still prefer 'flat file' to sqlite, but basically I just want something that isn't an incomprehensible blob, that I can use with other tools etc. Bonus points for some open standard, but some kind of understandable format even if proprietary is miles ahead of proprietary and cryptic. I wish Fusion360 for example h…

> main reason I say I'd still prefer plaintext to db

Is there a non-proprietary somewhat sane way to do version control for spreadsheets (Excel and LibreOffice)?

Re: Smaller is better – The rise, fall, and rise of flat file software

#120

Post by djrobstep »

rrrrrrrrrrrryan wrote: post #49
GuB-42 wrote: post #30

Maybe it is just a reflection on the state of filesystems vs databases. There is no fundamental difference between a database and a flat file, it is all bytes on a disk/memory in the end. So it is mostly a question of balancing the roles of the hardware, OS, and application software. For example, if the reason you are using a database is that it does a particularly good job at limiting disk IO, then it may not be nec…

> There is no fundamental difference between a database and a flat file, it is all bytes on a disk/memory in the end. A database has a whole engine, which I'd argue is a pretty fundamental difference. I think I get what you were trying to say, though: there's no fundamental difference between database tables and flat files, and there's no fundamental difference between a database and a filesystem.

How is a filesystem not a "whole engine"?
Post reply on HN