11–20 of 75 posts
Earlier quoted context omitted.
That is really cool project, but I can't give this to non technical people
Non technical people aren't the ones who use LibGen though, right? There are things like PDFDrive that has found some popularity in my country.
Will not support linux or Mac.
If it's not open source, how can one trust it in such a sensitive question as accessing libgen? If it is open source, then the support may eventually materialize.
However, the repo has no license, and therefore is not free and open source. Technically that code is still proprietary. How much someone writing a libgen app would care if you forked their proprietary app is left as an exercise for the reader.
No commits in over a year, and developer has announced the next release will be the "final version".
Earlier quoted context omitted.
Non technical people aren't the ones who use LibGen though, right? There are things like PDFDrive that has found some popularity in my country.
Sure they do. College students become highly technical when it’s paying for textbooks vs beer.
Earlier quoted context omitted.
That is really cool project, but I can't give this to non technical people
Non technical people aren't the ones who use LibGen though, right? There are things like PDFDrive that has found some popularity in my country.
Title is wrong, the updated configuration ( https://wiki.mhut.org/_media/software:libgen_desktop_mirrors... ) is using ipfs.com and cloudflare-ipfs.com, so it's still being fetched over HTTP(S), not IPFS.
Even when you have a local IPFS node (which is not common), the "last meter" delivery is still done using HTTP too, via a local gateway
Title is wrong, the updated configuration ( https://wiki.mhut.org/_media/software:libgen_desktop_mirrors... ) is using ipfs.com and cloudflare-ipfs.com, so it's still being fetched over HTTP(S), not IPFS.
This is an interesting point. In my experience, it's very common for HTTP(S) to be used for the "last mile" for content that originates from IPFS. Generally this is done via public or dedicated IPFS gateways. Even when you have a local IPFS node (which is not common), the "last meter" delivery is still done using HTTP too, via a local gateway
Indeed, it seems very common, but that doesn't make my original point less true.
> the "last meter" delivery is still done using HTTP too, via a local gateway
Yeah, that seems common too, but less "wrong" to call it "IPFS support" in that case, in my opinion.
Running your own IPFS gateway at least makes the content actually fetched from the network (internet) via IPFS while using ipfs.com/cloudflare-ipfs.com is not any different than just using a CDN (except usually you have to pay for CDNs, IPFS gateways seems to be free (for now)).
Earlier quoted context omitted.
This is an interesting point. In my experience, it's very common for HTTP(S) to be used for the "last mile" for content that originates from IPFS. Generally this is done via public or dedicated IPFS gateways. Even when you have a local IPFS node (which is not common), the "last meter" delivery is still done using HTTP too, via a local gateway
> it's very common for HTTP(S) to be used for the "last mile" for content that originates from IPFS Indeed, it seems very common, but that doesn't make my original point less true. > the "last meter" delivery is still done using HTTP too, via a local gateway Yeah, that seems common too, but less "wrong" to call it "IPFS support" in that case, in my opinion. Running your own IPFS gateway at least makes the content act…
The ´Books' tool [1] has been doing the same for a long time as well, can be used anywhere where Bash runs and - given its shell-based nature - is eminently hackable. It comes with a CLI (named 'books'), TUI ('nbook' and 'nfiction') and GUI ('xbook' and 'xfiction') and supports both IPFS, Bittorrent as well as direct download. It can search on all fields. Source: I wrote this about 6 years ago and maintain it every n…
That is really cool project, but I can't give this to non technical people