- The release of yarnd 0.15
- Packaging apps for Sandstorm
- SSD performance
- KVM on WSL
- Mitigating smart home spyware for in-store demos
- https://github.com/berthubert/googerteller
- Google's policies around using external code
- The whirlpool currently taking place at Twitter
Also, we discovered an interesting statistic in the call tonight.
100% of technology enthusiasts have at least one Raspberry Pi, but only 25% of technology enthusiasts use them for anything. (it's @taigrr)
Actually, I just had an idea. Would it be feasible to add a configuration option to exclude followed feeds from Discover? That way, we wouldn't have to filter through all the posts we've already read to find new feeds.
Photon supports image rendering with sixels. It's just a feed viewer. It have a database or anything, it just pulls in feeds specified on the command line and displays the items chronologically in a grid view.
It works fine for XKCD. It just looks a lot better in the article view because of the color limitations.
Photon displaying the XKCD RSS feed
Photon's article view on the most recent XKCD
Photon supports image rendering with sixels. It's just a feed viewer. It have a database or anything, it just pulls in feeds specified on the command line and displays the items chronologically in a grid view.
It works fine for XKCD. It just looks a lot better in the article view because the images aren't downscaled very well.
Photon displaying the XKCD RSS feedPhoton's article view on the most recent XKCD
Photon supports image rendering with sixels. It's just a feed viewer. It have a database or anything, it just pulls in feeds specified on the command line and displays the items chronologically in a grid view.
It works alright for XKCD. It looks a lot better in the article view. The images aren't downscaled very well.
Photon displaying the XKCD RSS feedPhoton's article view on the most recent XKCD
I can also see people (read: me) being "trained" over time to not notice the icon because it's a human 99% of the time.
Add this to
trackers.conf. SourceThen, add the following to
teller.conf:
[cloudflare]
balance=1
freq=2000
@tkanos, welcome to the club. https://lab6.com/rss.xml is one of my favorites, but posts are very infrequent.
I'm also a big fan of https://www.prologic.blog/feed.xml, https://codemadness.org/atom_content.xml, and https://jcs.org/rss.
Then, I used Startpage which uses Google results. I switched away from them because they kept thinking I was a robot and making me solve a captcha.
Now, I'm on Brave Search. I don't like their browser much, but I think their search engine is nice. They have their own crawler, which isn't common. The results are usually pretty good, but when I'm trying to do a per-site search I switch to a Whoogle instance.
Marginalia Search is a search engine with their own crawler that prioritizes simple, readable websites.
Kagi is a paid search engine that, apparently, doesn't spy on you. However, all your Web searches are tied to your real identity because you can't pay anonymously.
xz has its own timer. If I remember correctly, it took 7 minutes and 17 seconds on my toaster to compress 1.36 GiB, mostly text, at the highest compression level. I don't think that's all that bad.xz also lets you use multiple threads, which isn't common on these tools. I didn't do it for this test because there is an extremely small size penalty for doing so and I wanted to go all-out.Here's a good blog post that shows the differences with multi-threading. The size difference is negligible, and that test showed no measurable difference in file size between 2 cores and 32 cores. There are diminishing returns in speed, though.
Reddit lets you do something similar. https://www.reddit.com/r/linux+openbsd+serenityos
Also, I'm the line endings for just about everything Gopher are CRLF per RFC 1436. I'd be willing to bet that a lot of hand-written gophermaps use LF.
It's Bitreich's backwards-compatible standard for extensions to the Gopher protocol, including TLS.
main.c, line 31:
#ifdef ENABLE_TLS
#include <tls.h>
#endif /* ENABLE_TLS */
1 1458553185 build/
0.322 469704387 build.tar.Z compress -k build.tar (oh, how far we've come)
0.185 269780511 build.tar.gz gzip -k9 build.tar
0.082 119839762 build.tar.bz2 bzip2 -zk9 build.tar
0.046 67705992 build.tar.xz xz -zk9e build.tar
Ratio File size Filename Command Algorithm
1 1458553185 build/
0.451 658022612 ../node-modules/
0.322 469704387 build.tar.Z compress -k build.tar Lempel–Ziv–Welch (LZW) (oh, how far we've come)
0.185 269780511 build.tar.gz gzip -k9 build.tar Deflate
0.082 119839762 build.tar.bz2 bzip2 -zk9 build.tar Burrows–Wheeler transform
0.046 67705992 build.tar.xz xz -zk9e build.tar Lempel–Ziv–Markov (LZMA)
Ratio File size Filename Command Algorithm
1 1458553185 build/
0.451 658022612 ../node-modules/
0.322 469704387 build.tar.Z compress -k build.tar Lempel–Ziv–Welch (LZW) (oh, how far we've come)
0.185 269780511 build.tar.gz gzip -k9 build.tar Deflate
0.082 119839762 build.tar.bz2 bzip2 -zk9 build.tar Burrows–Wheeler transform
0.046 67705992 build.tar.xz xz -zk9e build.tar Lempel–Ziv–Markov (LZMA)
0.046 is *really* mind-blowing.
Ratio File size Filename Command Algorithm
1 1458553185 build/
0.451 658022612 ../node-modules/
0.322 469704387 build.tar.Z compress -k build.tar Lempel–Ziv–Welch (LZW) (oh, how far we've come)
0.185 269780511 build.tar.gz gzip -k9 build.tar Deflate
0.082 119839762 build.tar.bz2 bzip2 -zk9 build.tar Burrows–Wheeler transform
0.047 68258612 build.tar.br brotli -kZ build.tar Brotli
0.047 67989604 build.tar.zst zstd --ultra -22 build.tar Zstandard
0.046 67705992 build.tar.xz xz -zk9e build.tar Lempel–Ziv–Markov (LZMA)
0.046 is *really* mind-blowing.
Ratio File size Filename Command Algorithm
1 1458553185 build/
0.451 658022612 ../node-modules/
0.322 469704387 build.tar.Z compress -k build.tar Lempel–Ziv–Welch (LZW) (oh, how far we've come)
0.185 269780511 build.tar.gz gzip -k9 build.tar Deflate
0.082 119839762 build.tar.bz2 bzip2 -zk9 build.tar Burrows–Wheeler transform
0.046 67705992 build.tar.xz xz -zk9e build.tar Lempel–Ziv–Markov (LZMA)
0.046 is *really* mind-blowing.
Ratio File size Filename Command Algorithm
1 1458553185 build/
0.451 658022612 ../node-modules/
0.322 469704387 build.tar.Z compress -k build.tar Lempel–Ziv–Welch (LZW) (oh, how far we've come)
0.185 269780511 build.tar.gz gzip -k9 build.tar Deflate
0.082 119839762 build.tar.bz2 bzip2 -zk9 build.tar Burrows–Wheeler transform
0.047 68258612 build.tar.br brotli -kZ build.tar Brotli
0.047 67989604 build.tar.zst zstd --ultra -22 build.tar Zstandard
0.046 67705992 build.tar.xz xz -zk9e build.tar Lempel–Ziv–Markov (LZMA)
0.046 is *really* mind-blowing. I don't need a torrent, we're approaching e-mail attachment file sizes here.
1 1458553185 build/
0.322 469704387 build.tar.Z (oh, how far we've come)
0.185 269780511 build.tar.gz
0.082 119839762 build.tar.bz2
0.046 67705992 build.tar.xz
Ratio File size Filename Command Algorithm
1 1458553185 build/
0.451 658022612 ../node-modules/
0.322 469704387 build.tar.Z compress -k build.tar Lempel–Ziv–Welch (LZW) (oh, how far we've come)
0.185 269780511 build.tar.gz gzip -k9 build.tar Deflate
0.082 119839762 build.tar.bz2 bzip2 -zk9 build.tar Burrows–Wheeler transform
0.047 68258612 build.tar.br brotli -kZ build.tar Brotli
0.046 67705992 build.tar.xz xz -zk9e build.tar Lempel–Ziv–Markov (LZMA)
0.046 is *really* mind-blowing.
node_modules!) So, with browser compatibility data and such, I think it'll still be less than 2GiB.Aggressively compressed with
bzip2 -9, it's only 114.29 MiB. A compression ratio of 0.08. That blows my mind.
/en-US/docs/Web/HTML/Global_attributes is saved with that filename, the Web server is probably going to send the wrong MIME type. Wget solves this with --adjust-extension.Man, you really don't have to do this...
Something that I'd like to have, but isn't required, is mirroring of content (+ page requisites) in frames. (Example) This would involve spanning hosts, but I only need to span hosts for this specific purpose.
It would also be nice if the program could resolve absolute paths to relative paths (
/en-US/docs/Web/HTML/Global_attributes -> ../../Global_attributes) but this isn't required either. I think I'm going to have to have a local Web server running anyway because just about all the links are to directories with an index.html. (i.e the actual file referenced by /en-US/docs/Web/HTML/Global_attributes is /en-US/docs/Web/HTML/Global_attributes/index.html.)
I'm sure I can find something if I look around some more. I can't be the only one that wants to make a static mirror of a dynamic website.
/en-US/docs/Web/CSS/border, and all the filenames are in lowercase, e.g. /en-us/docs/web/css/border.
<tinfoil-hat>I think it's so they can sell more MDN plus subscriptions, making people use their terrible MDN Offline system that uses the local storage of your browser.
At this point, I'm willing to run a local dev server and just save each generated page and its dependencies.
I really only need it to run JavaScript so it can request the browser compatibility JSON. It's https://github.com/mdn/browser-compat-data but the MDN server, annoyingly, transforms it.
Once the BCD data is rendered statically, I should be able to remove the references to the JavaScript.
That will solve another issue I'm having where the JavaScript is constantly trying to download
/api/v1/whoami, which seemingly has no purpose aside from user tracking.
<tinfoil-hat>I think it's so they can sell more MDN plus subscriptions, making people use their terrible MDN Offline system that uses the local storage of your browser.</tinfoil-hat>
At this point, I'm willing to run a local dev server and just save each generated page and its dependencies.
I really only need it to run JavaScript so it can request the browser compatibility JSON. It's https://github.com/mdn/browser-compat-data but the MDN server, annoyingly, transforms it.
Once the BCD is rendered statically, I should be able to remove the references to the JavaScript.
That will solve another issue I'm having where the JavaScript is constantly trying to download
/api/v1/whoami, which seemingly has no purpose aside from user tracking.
<tinfoil-hat>I think it's so they can sell more MDN plus subscriptions, making people use their terrible MDN Offline system that uses the local storage of your browser.</tinfoil-hat>
At this point, I'm willing to run a local dev server and just save each generated page and its dependencies.
I really only need it to run JavaScript so it can request the browser compatibility JSON. It's https://github.com/mdn/browser-compat-data but the MDN server, annoyingly, transforms it.
Once the BCD data is rendered statically, I should be able to remove the references to the JavaScript.
That will solve another issue I'm having where the JavaScript is constantly trying to download
/api/v1/whoami, which seemingly has no purpose aside from user tracking.
At this point, I'm willing to run a local dev server and just save each generated page and its dependencies.
I really only need it to run JavaScript so it can request the browser compatibility JSON. It's https://github.com/mdn/browser-compat-data but the MDN server, annoyingly, transforms it.
Once the BCD data is rendered statically, I should be able to remove the references to the JavaScript.
That will solve another issue I'm having where the JavaScript is constantly trying to download
/api/v1/whoami, which seemingly has no purpose aside from user tracking.
I tried Wpull, but I can't get it to stop crashing on startup and development seems to have stopped.
I'm sure there's a joke to be made about Python here.
I tried Wpull, but I can't get it to stop crashing on startup and development seems to have stopped.
I'm sure there's a joke to be made about Python here.
It's not widely implemented in clients or daemons.
Also, lots of people are against TLS because it's too hard to implement on your own; Gopher daemons would need to depend on an external library.
If you want Gopher encrypted, the best option is to make your Gopher daemon accessible as a Tor hidden service.
Gemini is too simple in the wrong places, e.g. the very limited Markdown-lite. It's also too complicated in the wrong places, e.g. mandatory encryption.
Gopher's continued usage even after being "beaten" by the Web speaks volumes. I don't hate Gemini. Actually, I enjoy exploring Geminispace from time to time. I think it's a fad, though. People aren't going to use it in 30 years.
(Assertions like that, when it comes to technology, never come true. In 30 years, when Gemini takes over, feel free to come back to this twt and make fun of me. It won't be the first time an inferior protocol becomes dominant.)
I also like Gopher more than Gemini. The problem Gemini is trying to solve is better solved by just writing static HTML 4.01 pages.
I haven't used Warpd at all, beyond playing with it initially.
Several countries either censor or have attempted to censor Wikipedia, and Wikiless is a great way to bypass it.
https://en.wikipedia.org/wiki/Censorship_of_Wikipedia
I'm referring to Wikiless being hidden from public view on Codeberg, #digfawa
I was envisioning a Raspberry Pi or something pulling new updates automatically with a Cron job.
I'm referring to Wikiless being hidden from public view on Codeberg, #digfawa
I was envisioning a Raspberry Pi or something pulling new updates automatically with a Cron job.
I generally like that system, but it can get annoying at times. I wish there was a way I could disable the dialog (while still trying https first for unknown domains) on a per-tab basis, letting it fall back to plain HTTP without user input.
On a somewhat related note, I recently discovered a cURL option to specify a default protocol when invoked without a scheme, e.g.
curl mckinley.cc.In
~/.config/curlrc:
proto-default = https
* Wikimedia Legal Enforcement has contacted Codeberg citing quote-on-quote "licensing / trademark infringement issues in the content"
* Codeberg has made the repository private (i.e. it can only be viewed by contributors)
* The author is making changes to the software in order to remove the infringing content*
$ curl https://github.com/zedeus/nitter/wiki/Instances | htmlq 'table:nth-of-type(2) > tbody > tr' | grep '^<tr>$' | wc -l
83
>> document.querySelector("table:nth-of-type(2)").querySelectorAll("tr").length - 1
<- 83
>> document.querySelector("table:nth-of-type(2)").querySelectorAll("tr").length - 1
<- 83
* URIs, URLs, and URNs
* Sketchy SEO companies and Web spam
* Improvements to the search engine
* Goryon debugging
> So it comes down to who you trust [more], your ISP or your VPN provider(s)?
My VPN provider, 100%. I've talked about my ISP in the past.
Besides, I don't *need* to trust them as much as my ISP. Under normal circumstances, this is the important information that your ISP can know about you:
* All of your personal information, down to a home address
* The IP addresses to which you're connecting
* Information leaked by unencrypted traffic (DNS queries, etc.)
As long as the VPN provider doesn't require any personal information, and mine doesn't, you're making it so no single party has all of that information. The IP address cloaking is an added benefit for me.
> You still leak your IP address with that TURN server however.
If your WebRTC implementation isn't broken, the TURN server sees your traffic as coming from the VPN server, just like any thing else you connect to through that tunnel. It's the same story if I open a port and make a direct p2p connection.*
> So it comes down to who you trust [more][more][more][more][more][more][more][more], your ISP or your VPN provider(s)?
My VPN provider, 100%. I've talked about my ISP in the past.
Besides, I don't *need* to trust them as much as my ISP. Under normal circumstances, this is the important information that your ISP can know about you:
* All of your personal information, down to a home address
* The IP addresses to which you're connecting
* Information leaked by unencrypted traffic (DNS queries, etc.)
As long as the VPN provider doesn't require any personal information, and mine doesn't, you're making it so no single party has all of that information. The IP address cloaking is an added benefit for me.
> You still leak your IP address with that TURN server however.
If your WebRTC implementation isn't broken, the TURN server sees your traffic as coming from the VPN server, just like any thing else you connect to through that tunnel. It's the same story if I open a port and make a direct p2p connection.*
> So it comes down to who you trust [more][more=], your ISP or your VPN provider(s)?
My VPN provider, 100%. I've talked about my ISP in the past.
Besides, I don't *need* to trust them as much as my ISP. Under normal circumstances, this is the important information that your ISP can know about you:
* All of your personal information, down to a home address
* The IP addresses to which you're connecting
* Information leaked by unencrypted traffic (DNS queries, etc.)
As long as the VPN provider doesn't require any personal information, and mine doesn't, you're making it so no single party has all of that information. The IP address cloaking is an added benefit for me.
> You still leak your IP address with that TURN server however.
If your WebRTC implementation isn't broken, the TURN server sees your traffic as coming from the VPN server, just like any thing else you connect to through that tunnel. It's the same story if I open a port and make a direct p2p connection.=*
> So it comes down to who you trust [more][more=][more][more=][more][more=][more][more=], your ISP or your VPN provider(s)?
My VPN provider, 100%. I've talked about my ISP in the past.
Besides, I don't *need* to trust them as much as my ISP. Under normal circumstances, this is the important information that your ISP can know about you:
* All of your personal information, down to a home address
* The IP addresses to which you're connecting
* Information leaked by unencrypted traffic (DNS queries, etc.)
As long as the VPN provider doesn't require any personal information, and mine doesn't, you're making it so no single party has all of that information. The IP address cloaking is an added benefit for me.
> You still leak your IP address with that TURN server however.
If your WebRTC implementation isn't broken, the TURN server sees your traffic as coming from the VPN server, just like any thing else you connect to through that tunnel. It's the same story if I open a port and make a direct p2p connection.*
> So it comes down to who you trust \n\n\n\n, your ISP or your VPN provider(s)?
My VPN provider, 100%. I've talked about my ISP in the past.
Besides, I don't *need* to trust them as much as my ISP. Under normal circumstances, this is the important information that your ISP can know about you:
* All of your personal information, down to a home address
* The IP addresses to which you're connecting
* Information leaked by unencrypted traffic (DNS queries, etc.)
As long as the VPN provider doesn't require any personal information, and mine doesn't, you're making it so no single party has all of that information. The IP address cloaking is an added benefit for me.
> You still leak your IP address with that TURN server however.
If your WebRTC implementation isn't broken, the TURN server sees your traffic as coming from the VPN server, just like any thing else you connect to through that tunnel. It's the same story if I open a port and make a direct p2p connection.*
> So it comes down to who you trust \n\n, your ISP or your VPN provider(s)?
My VPN provider, 100%. I've talked about my ISP in the past.
Besides, I don't *need* to trust them as much as my ISP. Under normal circumstances, this is the important information that your ISP can know about you:
* All of your personal information, down to a home address
* The IP addresses to which you're connecting
* Information leaked by unencrypted traffic (DNS queries, etc.)
As long as the VPN provider doesn't require any personal information, and mine doesn't, you're making it so no single party has all of that information. The IP address cloaking is an added benefit for me.
> You still leak your IP address with that TURN server however.
If your WebRTC implementation isn't broken, the TURN server sees your traffic as coming from the VPN server, just like any thing else you connect to through that tunnel. It's the same story if I open a port and make a direct p2p connection.*
> So it comes down to who you trust [more], your ISP or your VPN provider(s)?
My VPN provider, 100%. I've talked about my ISP in the past.
Besides, I don't *need* to trust them as much as my ISP. Under normal circumstances, this is the important information that your ISP can know about you:
* All of your personal information, down to a home address
* The IP addresses to which you're connecting
* Information leaked by unencrypted traffic (DNS queries, etc.)
As long as the VPN provider doesn't require any personal information, and mine doesn't, you're making it so no single party has all of that information. The IP address cloaking is an added benefit for me.
> You still leak your IP address with that TURN server however.
If your WebRTC implementation isn't broken, the TURN server sees your traffic as coming from the VPN server, just like any thing else you connect to through that tunnel. It's the same story if I have a port opened and make a direct p2p connection.*
> So it comes down to who you trust [more]\n[more]\n[more]\n[more]\n, your ISP or your VPN provider(s)?
My VPN provider, 100%. I've talked about my ISP in the past.
Besides, I don't *need* to trust them as much as my ISP. Under normal circumstances, this is the important information that your ISP can know about you:
* All of your personal information, down to a home address
* The IP addresses to which you're connecting
* Information leaked by unencrypted traffic (DNS queries, etc.)
As long as the VPN provider doesn't require any personal information, and mine doesn't, you're making it so no single party has all of that information. The IP address cloaking is an added benefit for me.
> You still leak your IP address with that TURN server however.
If your WebRTC implementation isn't broken, the TURN server sees your traffic as coming from the VPN server, just like any thing else you connect to through that tunnel. It's the same story if I open a port and make a direct p2p connection.*
> So it comes down to who you trust \n\n\n\n\n\n\n\n, your ISP or your VPN provider(s)?
My VPN provider, 100%. I've talked about my ISP in the past.
Besides, I don't *need* to trust them as much as my ISP. Under normal circumstances, this is the important information that your ISP can know about you:
* All of your personal information, down to a home address
* The IP addresses to which you're connecting
* Information leaked by unencrypted traffic (DNS queries, etc.)
As long as the VPN provider doesn't require any personal information, and mine doesn't, you're making it so no single party has all of that information. The IP address cloaking is an added benefit for me.
> You still leak your IP address with that TURN server however.
If your WebRTC implementation isn't broken, the TURN server sees your traffic as coming from the VPN server, just like any thing else you connect to through that tunnel. It's the same story if I open a port and make a direct p2p connection.*
My real IP still didn't leak because my VPN client prevents any other program from using my real network interface.
> the Internet kind of requires IP Addresses to even function in the first place
True, but a VPN can be used to mask your real IP address because all of your network traffic is relayed through another computer with a different IP address.
> p2p protocols like WebRTC require peer addresses to be able to communicate with one another
In principle, yes, but they don't need to be able to communicate directly as long as both clients can communicate with a TURN server. At least, that's how I understand it.