Dotfiles being hidden is a UNIXv2 mistake (2012)

Re:Dotfiles being hidden is a UNIXv2 mistake (2012) by codedokode on Thursday August 11, 2022 @04:44PM (#32431486)

Why add just a monstrous database engine that will spend time reading and parsing database schema, parsing SQL queries, building execution plans to read several settings? Let's go further and use Elasticsearch (startup time about 1 minute) for this.

[ Parent | on HN ]

Re:Dotfiles being hidden is a UNIXv2 mistake (2012) by chasil on Friday August 12, 2022 @12:53PM (#32441134)

By these rules, we probably shouldn't link to the C library either.

  # ll /lib64/libc-2.17.so /lib64/libsqlite3.so.0.8.6
  -rwxr-xr-x. 1 root root 2156664 May 18 20:27 /lib64/libc-2.17.so
  -rwxr-xr-x. 1 root root  753272 Jan 27  2020 /lib64/libsqlite3.so.0.8.6

[ Parent | on HN ]

Re:Dotfiles being hidden is a UNIXv2 mistake (2012) by snikolaev on Monday August 15, 2022 @02:03AM (#32466354)

Or Manticore Search (startup time 2 seconds) :)

Manticore vs Elasticsearch startup time benchmark - https://manticoresearch.com/blog/manticore-alternative-to-el...

[ Parent | on HN ]

Re:Dotfiles being hidden is a UNIXv2 mistake (2012) by NavinF on Thursday August 11, 2022 @06:10PM (#32432423)

SQLite has identical performance vs parsing ad hoc text files assuming you're reading from flash not RAM. It's also a lot faster if you're loading a few settings from a larger file.

[ Parent | on HN ]

Re:Dotfiles being hidden is a UNIXv2 mistake (2012) by codedokode on Saturday August 13, 2022 @04:53AM (#32448059)

SQLite is inefficient. For example: it parses table definitions and SQL queries, builds execution plans at runtime, although this could be done at compile time.

[ Parent | on HN ]

Re:Dotfiles being hidden is a UNIXv2 mistake (2012) by NavinF on Saturday August 13, 2022 @05:59AM (#32448366)

Like I said it makes no difference when your SSD takes 40us to respond to a read. Maybe you have an exceptionally slow CPU?

[ Parent | on HN ]