asaibx

For all those who are requesting ISO8601 dates -- according to the GitHub repo [0] these are already supported:

> Dates: A date can be expressed in a few forms. Human readable dates are supported, like 1665, 03/2222, or 09/11/2001, as well as IO8601 dates, like 2031-11-19T01:35:10Z.

[0]: https://github.com/kochrt/markwhen

Not anymore, unfortunately [0] :(

[0]: https://news.ycombinator.com/item?id=24840310

You beat me to it. :) Yes, blocking ##div.release in uBlock Origin did the trick for me as well.

> Also, I unstarred pretty much everything.

Unfortunately, this seems to be a common theme in all of the discussions I have read so far. It's really an unfortunate outcome for projects that have nothing to do with this, but perhaps a wave of "unstarring" across the site will cause GitHub to reconsider this change.

Like many others it seems (for example here [0], or this issue [1] that amusingly seems to think it's a problem caused deliberately by the VSCode developers), I have been wondering why this recent change has occurred in GitHub's activity feed and whether there was a way to disable it.

The linked thread provides both some insight into the first question (from a GH product manager who explains the dubious case for including unwanted information in the main feed), as well as a number of hacks and workarounds to resolve the second one (using Block element in uBlock Origin with ##div.release as suggested by ozon2 seems to work perfectly).

I would be interested to hear what others here think about the proposed change in direction for the activity feed (i.e., to make it more about "news from your wider network" rather than "notifications you have intentionally signed up for").

[0]: https://github.community/t/release-notifications-from-starre...

[1]: https://github.com/microsoft/vscode/issues/125951

This looks great -- well done! I'd love to be able to use it (the CSS in particular) in a number of different projects where creating such nice readable output is a hassle. However I couldn't find a license mentioned anywhere -- either for the associated repo as a whole [0] or the CSS specifically.

Would it be possible to add a license so it's possible to know whether others can use this in other projects without rewriting the CSS from scratch?

[0]: https://github.com/ashok-khanna/pdf

There's always recutils [0] which uses a plain text database format stored in files called recfiles.

[0] https://labs.tomasino.org/gnu-recutils/

Glad to see a few people have brought up Jamendo already, but I'm really surprised that no one has mentioned ccMixter [0]. This is one of the really early sites to try and address this exact need. They have an enormous back catalog of open-licensed music designed specifically for mixing and reuse, and a still quite active community of dedicated users (though the site design needs a bit of a refresh).

[0] http://ccmixter.org/

My favourite portal for discovering sites like this is something I discovered just recently here on HN: https://wiby.me/

It never fails to amaze me how much amazing stuff is out there online, hidden by a thick layer of top search results, and even more than that, the sheer amount of individual and collective effort that has been put into each of these sites. Someone mentioned the word "niche" and there is certainly some weirdly (or wonderfully) specific content you will find in the Wiby.me index. Lots of sites that haven't been updated since 1998, but still have an enormous and encyclopedic list of everything related to some topic (like the characteristics of different types of tomatoes, or how to build a motorcycle from spare parts or whatever). Some of it may be a little out of date, but a lot of it has been submitted for indexing precisely because of its timelessness or continued usefulness.

Whenever I feel hopeless about the current state of the web, I find this is the perfect antidote!

This is great. Thanks so much for creating this!

There is actually an amazing amount of really good quality content out there, but as everybody on this thread has pointed out already, discoverability is a major issue. I often wonder how one would go about finding a site like the one you made if it hadn't been posted here, though I suppose "aggregator" is actually a decent search keyword that should (in theory) also lead to other good content. Presumably "blog aggregator" wouldn't be a particularly useful search term though.

Beautiful! Reminds me a bit of Hatnote's Listen to Wikipedia [0].

[0]: http://listen.hatnote.com/

The Virginia Tech Tree ID app is quite good, although it only covers North American species.

https://dendro.cnre.vt.edu/dendrology/idit.htm

No need for a physical keyboard -- if you have Hacker's Keyboard installed it comes with a Ctrl key, and Ctrl-Z works as expected.

Just to let you know, I updated to the latest version of Chrome (Android) and it seems to be working fine now.

Sounds like a great idea, but the site just brings up a blank page in both Firefox and Chrome on Android.

Great idea. Love the minimalism! I was going to comment that it might be better (or at least easier to remember) to have short options like -o and -v instead of separate commands like dno and dnview, but then I looked at the code and noticed these are all just a collection of shell aliases stored in the "dn" file. Nicely done!

This might help:

https://github.com/open-dict-data/ipa-dict

As others have commented, love the ambitiousness of this! However, Unicode searches do not seem to work at all -- not just "中文" but also even "français" gives an error. Unicode support is something you definitely want to build in from the very beginning in order to avoid headaches (for you and users) in the future. Even if there is no content in the index, the presence of non-ASCII characters in the search term should not lead to a server error. Suggest you make Unicode the default encoding for everything even if you are not planning on supporting non-English search results for the moment, just to avoid unexpected errors when people search for things like "café" for example.