It looks like this hasn't had any updates since May 2018.
The GitHub page has lots of fairly recent updates:
https://github.com/perkeep/perkeep
Readit Newsramzeus commented on Keep Your Stuff, for Life perkeep.org/... · Posted by u/vincent_s
ramzeus commented on Solar storm risk and EMP attacks chris-said.io/2020/06/18/... · Posted by u/csaid81
This reminds me, I've been toying with the idea of starting a github repository for survival and rebuilding society if a major SHTF scenario occurred. It would be crowdsourced and bake-able into an ebook for offline reading. Anybody interested in it as a "Show HN" post?
Wikipedia is a quite good repository of all sorts of information. You can always clone that at put it on your computer for offline viewing.
ramzeus commented on How and why GraphQL will influence the Sourcehut alpha sourcehut.org/blog/2020-0... · Posted by u/michaelanckaert
> People who talk about auto-generating GraphQL wrappers for Postgres database schemas (not the author of this post, to be clear, but it's common enough) are missing the point entirely. The whole point of GraphQL is to span heterogeneous and independent data sources;
I don't think they are missing a point; rather, they have a completely different point: eschew a backend and use GraphQL on a DB + a frontend that gets all that data. If you're developing rapidly and don't have complex backend logic, I can see why you'd want to do that.
I think the problem with this approach becomes apparent when the database model changes, suddenly the API doesn't match the model anymore or the API needs to change. Both can be difficult problems leading to braking changes in the client(s).
Of course, for some rapid testing and simple personal projects this doesn't matter so much but for most other projects I think this might bite you hard in the future.
ramzeus commented on Exceptions should be Exceptional (2016) mattwarren.org/2016/12/20... · Posted by u/kogir
Go handles it shitty, like the past five decades of computer science and PL design never happened. For imperative languages, exceptions are perfectly fine as a way to encode failure as part of the domain of operations. If you're in functional fantasy land, the correct approach is to use a Maybe monad or, better yet, an Either monad. But Go supports neither of these and that's one of many reasons why it sucks for modern development. In TypeScript you can do better and, for the sake of others who have to maintain your code, you should do better.
My experience with Go have been very positive. Once you get over the initial irritation of the error handling, I think it works perfectly fine. I have never been so productive as I can be when programming in Go. I’m sure there are technically better alternatives, but it has a very good balance between features, speed, standard library and multi platform support.
At least for the backend server tasks I use it for.
My biggest complaint has more to do with the new module system and tooling. The (not so) new Go Language Server is still very buggy and almost unusable in my opinion.
ramzeus commented on The ancient world teemed with birds aeon.co/essays/the-ancien... · Posted by u/autokill
I was living in Chengdu for a year and I remember that I was surprised by the almost total lack of birds. In Hong Kong, where I am at the moment, there are more birds, but seems less than what we have back home in Northern Europe.
ramzeus commented on Formatting floating point numbers zverovich.net/2019/02/11/... · Posted by u/matt_d
As someone from a country which uses commas as a decimal separator (Norway)... Just use a dot. If you're not going to make a _serious_ commitment to actually make your software work well in all the various locales, use a dot. People will understand it regardless.
You're probably going to do something stupid like showing the user a comma-separated list of numbers at some point, which will be needlessly hard to parse for a human when your numbers use a comma as a decimal separator. You (or someone else, or your users if they are technical) will probably at some point make something which tries to parse some output, and that will break if you switch between points and commas arbitrarily. Your users will want to copy a number your software prints and paste it into a calculator or REPL or something, and that probably doesn't work with comma as a decimal separator.
Half-assed "localization" from people who don't know anything about how other countries work is just needlessly annoying to be subjected to.
That's at least my perspective as a Norwegian who experiences a lot of _bad_ localization even though I know English fairly well and configure all my computing devices to use English. The perspective of someone from a country where English is less well known might be different.
<rant>
Examples of horrible localization from clueless American companies or organizations include:
* A lot of software will use your IP address to determine your language. That's annoying when I'm in Norway and want my computers to use English, but it's horrible when abroad. No, Google, I don't want French text just because I'm staying in France for a bit.
* Software will translate error messages, but not provide an error code. All information about error messages online is in English on stackoverflow or whatever. If Debian prints an error message in Norwegian, there's absolutely no information about the error anywhere on the web.
* There was a trend for a while where websites would tick the "localization" checkbox by adding a Google Translate widget, so English websites would automatically translate themselves into completely broken Norwegian automatically. That would've been useless if I didn't know English, and it's even worse considering I already know the source language just as well as Norwegian. Luckily, most websites seem to have stopped doing that.
</rant>
Yeah, I feel your pain, I’m Swedish living in Hong Kong, I don’t want my webpages or programs translated in either Swedish or Chinese, give me English please!
And as for the float parsing part, I have had to fix many bugs through the years where floating point numbers were stringified on a Swedish computer and then read back into float on an English computer, or vise versa. And sometimes a mix of the two where human input is involved. Easy to fix, but still a common problem.
ramzeus commented on Formatting floating point numbers zverovich.net/2019/02/11/... · Posted by u/matt_d
To me the most complicated thing about formatting and parsing floating point numbers is usually if it uses decimal comma or decimal dot. It never seems to be what you expect if using a mix of different language operating systems.