Earlier quoted context omitted.
Yes, I am asking if that particular policy could be changed. A little AI here and there is fine, to each their own, but I would prefer not to read posts that are overwhelmingly so.
It's one thing for us to detect and autokill generated comments on our own site; it's our site and we can set the rules and run software on our own servers to process the comments and handle things in the way we and the community are happy with. It's a big additional leap to for our software to try to reach into others' sites, get through any anti-bot defenses they may be running, try to scrape their content and eval…
Choose DuckDB rather than SQLite
61–65 of 65 posts
Re: Choose DuckDB rather than SQLite
#62Earlier quoted context omitted.
It's one thing for us to detect and autokill generated comments on our own site; it's our site and we can set the rules and run software on our own servers to process the comments and handle things in the way we and the community are happy with. It's a big additional leap to for our software to try to reach into others' sites, get through any anti-bot defenses they may be running, try to scrape their content and eval…
You should talk with dang, as the email I received about this from him, to my eyes, does not agree with your stance here in the long term. I don’t want to get into the interminable blood quantum debate over Llm authorship either, however, I see substack doing something about it, and, as a long time hn reader, it makes me want to spend more time over there than here.
In the meantime, please feel free to flag items that are badly written/unpleasant to read, and email us if something is on the front page that shouldn't be there.
Re: Choose DuckDB rather than SQLite
#63Earlier quoted context omitted.
You should talk with dang, as the email I received about this from him, to my eyes, does not agree with your stance here in the long term. I don’t want to get into the interminable blood quantum debate over Llm authorship either, however, I see substack doing something about it, and, as a long time hn reader, it makes me want to spend more time over there than here.
We're talking about it all the time :) My comment above doesn't contradict the email. I didn't say we're not wanting/planning to do anything about it, just that there's more to it than plugging in Pangram . If Substack is being more proactive about it on their own site, that's great. It would make life easier for all of us if all the major content platforms cleaned up their own sites. We're already proactive about de…
Re: Choose DuckDB rather than SQLite
#64DuckDB is modern but written in C++ and crashes in production more than SQLite, which is old and it doesn’t really crash. you have to build in resilience to use DuckDb.
Wait seriously? That's a dealbreaker if true.
Re: Choose DuckDB rather than SQLite
#65Earlier quoted context omitted.
Let's keep discussion bar high. I've just checked their website, and they state "relying on ClickHouse to power these analytics use cases". That's not OLTP. https://clickhouse.com/comparison/postgresql Fair to say, seeing 1000x w/o any trace of proof won't help me to choose.
You new to the world, right? ClickHouse proven being a beast for analytics, tracing and even some basic metrics storage (VM won of course, but still CH is probably 2nd or 3rd)