(ℹ) Join us now at the IRC channel | ䷉ Find the plain text version at this address.
| Techrights-sec | gemini://gemini.techrights.org/feed/ | Feb 15 07:37 |
|---|---|---|
| schestowitz__ | excellent, will pass on to callum !! | Feb 15 07:38 |
| *rianne has quit (Quit: Konversation terminated!) | Feb 15 07:48 | |
| *rianne_ (~rianne@host81-154-169-167.range81-154.btcentralplus.com) has joined #boycottnovell | Feb 15 07:48 | |
| schestowitz__ | some people told me they're reading now from gemini first, can it be made to update more regularly, e.g. every 3 hours for latest articles to be added? | Feb 15 08:04 |
| Techrights-sec | g/feed/ | Feb 15 08:18 |
| Techrights-sec | # m h dom mon dow command | Feb 15 08:18 |
| Techrights-sec | 06 */3 * * * /home/gemini/bin/gemini-cron-updater.sh | Feb 15 08:18 |
| Techrights-sec | Is that too often now? | Feb 15 08:18 |
| Techrights-sec | See the few lines above :) | Feb 15 08:18 |
| schestowitz__ | checking the site... :-) | Feb 15 08:18 |
| schestowitz__ | I have just checked runtime duration for /home/gemini/bin/gemini-cron-updater.sh and it is under 50 seconds | Feb 15 08:20 |
| Techrights-sec | See the few lines above :) | Feb 15 08:21 |
| Techrights-sec | That only updates every third hour, next time will be at 1200 UTC | Feb 15 08:21 |
| Techrights-sec | THe change went in after 0900 UTC | Feb 15 08:21 |
| Techrights-sec | Hmm. That is long anyway. The slow part though is fetching the | Feb 15 08:22 |
| Techrights-sec | RSS feed. That takes many 10s of seconds. | Feb 15 08:22 |
| schestowitz__ | I am asking and checking also because I want to link to gemini:// in social control media, for the latest posts :-) | Feb 15 08:22 |
| Techrights-sec | It can be run more often but then I would have it a little more narrowed in | Feb 15 08:26 |
| Techrights-sec | scope first. | Feb 15 08:26 |
| Techrights-sec | But as mentioned the slow part is waiting for the response to the | Feb 15 08:26 |
| Techrights-sec | HTTP request in fetching the RSS feed... | Feb 15 08:26 |
| Techrights-sec | Something is not quite right there on the server side. | Feb 15 08:26 |
| schestowitz__ | response speed? RSS was always a tad slow and more so when the client is 'thin' because daily links mean a large large xml download | Feb 15 08:27 |
| Techrights-sec | $ time wget -q -S -O /dev/null http://techrights.org/feed/ | Feb 15 08:29 |
| Techrights-sec | HTTP/1.1 200 OK | Feb 15 08:29 |
| Techrights-sec | Date: Mon, 15 Feb 2021 08:28:14 GMT | Feb 15 08:29 |
| Techrights-sec | Server: Apache/2.4.6 (CentOS) | Feb 15 08:29 |
| Techrights-sec | X-Powered-By: PHP/5.4.16 | Feb 15 08:29 |
| Techrights-sec | Vary: Cookie | Feb 15 08:29 |
| Techrights-sec | X-Pingback: http://techrights.org/xmlrpc.php | Feb 15 08:29 |
| Techrights-sec | Last-Modified: Mon, 15 Feb 2021 07:51:48 GMT | Feb 15 08:29 |
| Techrights-sec | ETag: "8fad75f5a8c43b67f8b185864a38d32b" | Feb 15 08:29 |
| Techrights-sec | Connection: close | Feb 15 08:30 |
| Techrights-sec | Transfer-Encoding: chunked | Feb 15 08:30 |
| Techrights-sec | Content-Type: text/xml; charset=UTF-8 | Feb 15 08:30 |
| Techrights-sec | real 0m2.561s | Feb 15 08:30 |
| Techrights-sec | user 0m0.000s | Feb 15 08:30 |
| Techrights-sec | sys 0m0.022s | Feb 15 08:30 |
| Techrights-sec | Hmm its faster at the moment, but can be quite slow. | Feb 15 08:30 |
| Techrights-sec | Each article in the feed is fetched as well, regardless. There's not | Feb 15 08:30 |
| Techrights-sec | a resonable way to avoid some refetching. | Feb 15 08:30 |
| schestowitz__ | I think it's o(n) over time, as the feed does not increase in size, only the capsule does, and afaik the thing that will scale less nicely is building index for bulletin and irc, though not a noticeable slowdown until we have lots of days. Same issue for ipfs BTW. | Feb 15 08:30 |
| Techrights-sec | Once the data is on the local file system, processing goes very quickly even on the RPi. The wait is the multiple HTTP requests | Feb 15 08:32 |
| Techrights-sec | done in serial. | Feb 15 08:32 |
| Techrights-sec | Since the target is a single server and TR at that it would not be useful | Feb 15 08:32 |
| Techrights-sec | to parallelize it. | Feb 15 08:32 |
| Techrights-sec | 2019 is 75M as Gemini. Shall I add it to the RPi? | Feb 15 10:45 |
| Techrights-sec | 1200 UTC in about 2 hours, time to check the cron output then | Feb 15 10:45 |
| schestowitz__ | I ran it manually before we did exercise and the output seemed OK all in all. I wanted to link to gemini:// along with http://, as I shall probably do from now on 50% of the time (helps raise awareness, at least) | Feb 15 10:45 |
| -TechrightsBN/#boycottnovell-Could not resolve host: ,; Unknown error ( status 0 @ http://, ) | Feb 15 10:45 | |
| Techrights-sec | I've added the scripts to Git on TR now | Feb 15 10:58 |
| schestowitz__ | excellent, adds a rollback mechanism | Feb 15 10:58 |
| Techrights-sec | 2019 is 75M as Gemini. Shall I add it to the RPi? | Feb 15 11:01 |
| schestowitz__ | yes, I don't see why not :-) | Feb 15 11:01 |
| Techrights-sec | added and the inventory updated | Feb 15 11:03 |
| Techrights-sec | 2019 is in place | Feb 15 11:05 |
| Techrights-sec | I'll add the other years then? | Feb 15 11:05 |
| Techrights-sec | Probably one per day, as it takes about 7 to 8 hours with throttling to | Feb 15 11:05 |
| Techrights-sec | fetch and extract the URLs. Then the parsing takes a few minutes after | Feb 15 11:05 |
| Techrights-sec | that. | Feb 15 11:05 |
| schestowitz__ | It's a one-time thing and each year will be 'fatter' than prior ones as over time we become more efficient and produce more | Feb 15 11:05 |
| Techrights-sec | As long as the cron scripts function, the growth forward will be automatic. | Feb 15 11:07 |
| Techrights-sec | The adding of the archives has to be done manually though. | Feb 15 11:07 |
| Techrights-sec | There is a slight risk of a link not getting made Dec 31 after 2100 UTC, but I am not sure yet. | Feb 15 11:07 |
| Techrights-sec | From 0000 on Jan 1 each year it should be good though. | Feb 15 11:07 |
| schestowitz__ | Assuming the "master" copy of the DB and WWW, we don't need to worry about imperfections. Due to gopher/gemini limitations, regardless, the conversions are inherently lossy. | Feb 15 11:08 |
| schestowitz__ | *is the DB | Feb 15 11:08 |
| Techrights-sec | The reason being that if an article is added after the last indexing, the | Feb 15 11:10 |
| Techrights-sec | of the year, the next year does not automatically go and reindex the previous | Feb 15 11:10 |
| Techrights-sec | year, even though it was a few minutes prior. | Feb 15 11:10 |
| Techrights-sec | I'm just worried about major changes to the CMS layout / structure | Feb 15 11:10 |
| schestowitz__ | Unlikely to happen any time soon. That's the reason I insist on LTS and don't go for fancy/shiny crap without proper justification. Some that go for "latest" doom their own sites. Also, bulletins and other stuff depend on consistency in the CMS. | Feb 15 11:11 |
| Techrights-sec | $ ls -1 | sort -t . -k2,2r -k1,1 | Feb 15 11:11 |
| Techrights-sec | gemini-scripts-README.txt | Feb 15 11:11 |
| Techrights-sec | gemini-bulletin-irc-update.sh | Feb 15 11:11 |
| Techrights-sec | gemini-cron-updater.sh | Feb 15 11:11 |
| Techrights-sec | gemini-main-index-template.sh | Feb 15 11:11 |
| Techrights-sec | gemini-fetch-urls-from-rss.pl | Feb 15 11:11 |
| Techrights-sec | gemini-fetch-web-page.pl | Feb 15 11:11 |
| Techrights-sec | gemini-inventory.pl | Feb 15 11:11 |
| Techrights-sec | gemini-parse-html-to-gemini.pl | Feb 15 11:12 |
| Techrights-sec | That a lot. Though most are very simple. | Feb 15 11:12 |
| schestowitz__ | I made a full pi (/home) backup this past weekend. | Feb 15 11:12 |
| Techrights-sec | ok good | Feb 15 11:54 |
| Techrights-sec | The microSD cards wear out eventually | Feb 15 11:54 |
| schestowitz__ | That is the scenario I prepare for... | Feb 15 11:55 |
| schestowitz__ | Right now there's one IP that either DDOSes the gemini capsule or indexes it | Feb 15 11:57 |
| schestowitz__ | gemini@raspberrypi:~ $ grep radia.bortzmeyer.org log.txt | wc | Feb 15 11:59 |
| schestowitz__ | 31515 189086 2930850 | Feb 15 11:59 |
| Techrights-sec | BTW the update at noon seemed to go ok. The "feed" link got updated as | Feb 15 12:16 |
| Techrights-sec | part of that, all automatically. | Feb 15 12:16 |
| schestowitz__ | I was about to do a video about subs | Feb 15 12:17 |
| Techrights-sec | turning-sites-into-capsules.webm has no video after some minutes, | Feb 15 12:44 |
| Techrights-sec | the audio continues | Feb 15 12:44 |
| schestowitz__ | will try to reproduce here | Feb 15 12:45 |
| schestowitz__ | works on locally | Feb 15 12:50 |
| schestowitz__ | will msd sumcheck wrt server | Feb 15 12:50 |
| schestowitz__ | mds | Feb 15 12:50 |
| Techrights-sec | in VLC there is no video after a short while into the video | Feb 15 12:51 |
| schestowitz__ | maybe it got corrupted during download rather than upload? | Feb 15 12:51 |
| schestowitz__ | I just did a 20-min video about subscription | Feb 15 12:52 |
| schestowitz__ | checksum ok | Feb 15 12:52 |
| Techrights-sec | $ sha256sum turning-sites-into-capsules.webm | Feb 15 12:53 |
| Techrights-sec | 7d53d77870401bf1e971bc7c3743d605e18e7b64548eb93f6f923365d305ce2b turning-sites-into-capsules.webm | Feb 15 12:53 |
| schestowitz__ | $ sha256sum turning-sites-into-capsules.webm | Feb 15 12:53 |
| schestowitz__ | 7d53d77870401bf1e971bc7c3743d605e18e7b64548eb93f6f923365d305ce2b turning-sites-into-capsules.webm | Feb 15 12:53 |
| schestowitz__ | I get the same | Feb 15 12:53 |
| schestowitz__ | I open the file in Parole | Feb 15 12:54 |
| Techrights-sec | The server has the same checksum | Feb 15 12:54 |
| schestowitz__ | https://twitter.com/jamesabernard/status/1361285000646127616 | Feb 15 13:47 |
| -TechrightsBN/#boycottnovell-@jamesabernard: @schestowitz Must be doing something right! | Feb 15 13:47 | |
| schestowitz__ | https://twitter.com/jasonsnitker/status/1361131811640905728 | Feb 15 13:47 |
| -TechrightsBN/#boycottnovell-@jasonsnitker: <3 from Debian! https://t.co/25ChJctPAt | Feb 15 13:47 | |
| -TechrightsBN/#boycottnovell-@schestowitz: "Debian sends all of our love and a giant “Thank you” to the upstream and downstream creators and maintainers, host… https://t.co/LapStCCbyY | Feb 15 13:47 | |
| schestowitz__ | https://www.bortzmeyer.org/ seems like a legit domain, but 100,000+ hits in a few hours is odd. Maybe some research being done. It takes up about 100KB/sec, so tolerable given our capacity/throughput. | Feb 15 13:51 |
| -TechrightsBN/#boycottnovell-www.bortzmeyer.org | Blog Stéphane Bortzmeyer: Accueil | Feb 15 13:51 | |
| schestowitz__ | it seems to be rate-limited or paces, about a dozen connections every 10 seconds, with pauses in between | Feb 15 13:53 |
| schestowitz__ | My session got around after "The server has the same checksum" | Feb 15 16:14 |
| Techrights-sec | I'm not familiar with SB | Feb 15 16:15 |
| Techrights-sec | or his background, though he is apparently famous | Feb 15 16:15 |
| Techrights-sec | (still looking at traffic shaping for Linux) | Feb 15 16:15 |
| schestowitz__ | Did I miss something after "The server has the same checksum"? | Feb 15 16:15 |
| Techrights-sec | Probably not. | Feb 15 16:25 |
| Techrights-sec | ' | Feb 15 16:25 |
| Techrights-sec | BTW what bandwidth do you wish to limit the RPi to? | Feb 15 16:25 |
| schestowitz__ | I am relieved to know I lost nothing during the hang-up (those happened more lately), knowing it's not ideal comms tool but a good bridge that let's me redact things is needed. The buffers can be wiped without notice and it's not easy to find what was missed in any log files, maybe some pipes down the system (i/o). Regarding pi b/w, I see no reason for it to use more than 100kb (800mbit) per second as we have other machines | Feb 15 16:27 |
| schestowitz__ | plugged in and the pi does not stream videos or anything | Feb 15 16:27 |
| Techrights-sec | Ok. I will work around a model of 800Mb/s tops | Feb 15 16:29 |
| schestowitz__ | :) Kbit would be better | Feb 15 16:29 |
| schestowitz__ | I am not a TEMPORA outpost :-) | Feb 15 16:29 |
| Techrights-sec | Sorry I mend 800kb/s | Feb 15 16:31 |
| Techrights-sec | Once a salesman was making a mistake in a contract proposal writing B instead | Feb 15 16:31 |
| Techrights-sec | of b and I almost let him write it out. | Feb 15 16:31 |
| schestowitz__ | sometimes people give away how little they understand about computing | Feb 15 16:31 |
| schestowitz__ | > "Although such advances make it possible for everyone to have access to advanced computer systems, Thompson believes #programming skills are being eroded." https://www.computerweekly.com/news/252496341/ENIAC-anniversary-What-75-years-of-computer-technology-have-delivered | Feb 15 16:32 |
| -TechrightsBN/#boycottnovell-www.computerweekly.com | ENIAC anniversary: What 75 years of computer technology have delivered | Feb 15 16:32 | |
| schestowitz__ | author noted, Microsoft booster | Feb 15 16:32 |
| schestowitz__ | I will post Daily Links shortly, then will do work on the gemini thing. We've attracted attention of some high-level folks, I have some unread emails in my box about it. radia.bortzmeyer.org reqs stopped some hours ago and all along it seemed like research-related, maybe even plan to index it | Feb 15 16:34 |
| schestowitz__ | they were spread about 10 secs apart, I think, so rated-limited so as to not hammer too much on the back end | Feb 15 16:35 |
| Techrights-sec | later today I might be able to add 2018, it depends on other things first | Feb 15 16:35 |
| schestowitz__ | excellent. In recent years we had many exclusive stories and some had massive impact, e.g. Lenovo, RasPi, EPO... | Feb 15 16:36 |
| schestowitz__ | BN was out first "success" story, but it took lots of energy, albeit it gave us credibility (never mind the anti-BN sites, these were a sign of us being effective, given who was pissed off) | Feb 15 16:37 |
| schestowitz__ | gemini@raspberrypi:~ $ grep radia.bortzmeyer.org log.txt | wc | Feb 15 16:40 |
| schestowitz__ | 134932 809594 12548723 | Feb 15 16:40 |
| schestowitz__ | gemini@raspberrypi:~ $ cat log.txt | wc | Feb 15 16:40 |
| schestowitz__ | 187773 998034 15134720 | Feb 15 16:40 |
| schestowitz__ | I did not even turn on the logging all the time, so the real number would be a lot higher, maybe quarter million, but it's not what matters. We need to get gemini noticed, not just our capsule. I sometimes run updates manually just so that I can link to the gemini:.// url of something just published. | Feb 15 16:41 |
| Techrights-sec | If things go well, I plan to add 1 year per day. That's about | Feb 15 16:42 |
| Techrights-sec | the rate which is feasible. It takes about 8 hours of unattended, rate-limite | Feb 15 16:42 |
| Techrights-sec | dowloads to get the URLs and the and hour of hand work to process them and | Feb 15 16:42 |
| Techrights-sec | upload to the RPi. | Feb 15 16:42 |
| Techrights-sec | Try wc -l | Feb 15 16:42 |
| Techrights-sec | wc -l log.txt | Feb 15 16:42 |
| schestowitz__ | I am familiar with that option, but was lazy... | Feb 15 16:42 |
| schestowitz__ | re the story about Microsoft recruiters, the only safe way to shed light on it is to bring it up routinely and repeatedly, quoting selective bits each time but never the whole lot | Feb 15 16:44 |
| schestowitz__ | as part of tidying, should we remove the broken sept. 2020 link for bulletins? Is it part of a sliding window of 6 months? | Feb 15 16:50 |
| Techrights-sec | Yes, a sliding 6 months. | Feb 15 16:57 |
| Techrights-sec | I can make it a sliding months. | Feb 15 16:57 |
| Techrights-sec | All set | Feb 15 16:57 |
| schestowitz__ | excellent, thanks... I thought it had been coded somewhere without yet checking. And it seems to be spidered/indexed, so good to be sure all is in tact | Feb 15 16:57 |
| schestowitz__ | ot: back in oct. when I looked into gemini i did not know if it was really 'going places', but now it seems to have gathered momentum/inertia, so my only regret is settling with ipfs alone and neglecting the rest, inc. gnunet | Feb 15 16:59 |
| schestowitz__ | I know of nobody who uses gnunet alreay | Feb 15 16:59 |
| schestowitz__ | todo: check how truly secure a connection over gemini is, in case we wish to do doc drops (or url/tip drops) through there | Feb 15 17:01 |
| schestowitz__ | this is where microsoft spying on github downloads and projects being on github (NSA) poses a risk to wbers | Feb 15 17:02 |
| Techrights-sec | Secure in the context depends on how the certs are verified or not. If you | Feb 15 17:03 |
| Techrights-sec | have Gemini with TLS, but as an Onnion service, that would be an idea. | Feb 15 17:03 |
| Techrights-sec | The anonymity is important even if it is not absolute. | Feb 15 17:03 |
| schestowitz__ | dns lookup is one issue | Feb 15 17:03 |
| schestowitz__ | gemini attack surface is lower than a www browser or worse, a whole distro like tails with systemd | Feb 15 17:03 |
| Techrights-sec | yes | Feb 15 17:04 |
| Techrights-sec | but the clients are not available in any repositories yet... | Feb 15 17:04 |
| Techrights-sec | people can't be expected to maitntain their own Git clone and compile | Feb 15 17:04 |
| Techrights-sec | regularly. | Feb 15 17:04 |
| schestowitz__ | if we host in our site a precompiled set of downloads, that would be gpl-compatible, I think | Feb 15 17:05 |
| schestowitz__ | then http and not https is a potential risk | Feb 15 17:05 |
| Techrights-sec | If Tails starts to support Gemini, then that would be a very good thing. | Feb 15 17:06 |
| Techrights-sec | Yes, but that's overhead and not relate to producing articles. Other | Feb 15 17:06 |
| Techrights-sec | project have the prioritization for that. | Feb 15 17:06 |
| schestowitz__ | correct | Feb 15 17:06 |
| schestowitz__ | port 1965 is probably not in the "toolset" of the NSAs and GCHQs of the world, YET. | Feb 15 17:06 |
| schestowitz__ | they will call it something like "dark web" and insist that it's not racist to call it that :-) | Feb 15 17:07 |
| Techrights-sec | They'll adapt quickly enough I expect. | Feb 15 17:08 |
| Techrights-sec | TLS is probably in the bag. | Feb 15 17:08 |
| Techrights-sec | Probably | Feb 15 17:08 |
| schestowitz__ | http://ipkitten.blogspot.com/2021/02/highlights-from-new-epo-guidelines-for.html?showComment=1613403745122#c8380797494215912787 | Feb 15 17:36 |
| -TechrightsBN/#boycottnovell-ipkitten.blogspot.com | Highlights from the new EPO guidelines for examination 2021: ViCo oral proceedings, description amendments and antibodies - The IPKat | Feb 15 17:36 | |
| schestowitz__ | " | Feb 15 17:36 |
| schestowitz__ | To the great dismay of Kant, I would like to draw the attention to an interesting document about the legality of virtual oral proceedings. | Feb 15 17:36 |
| schestowitz__ | https://www.meissnerbolte.de/de/news/legality-of-virtual-oral-proceedings-under-art-116-epc/ | Feb 15 17:36 |
| schestowitz__ | Please do not come with the argument that the attorney firm is sitting in Munich, but make the effort to reply reasonably and in substance to the arguments brought forward in this paper. | Feb 15 17:36 |
| -TechrightsBN/#boycottnovell-www.meissnerbolte.de | Legality of Virtual Oral Proceedings under Art. 116 EPC – Pros and Cons | Feb 15 17:36 | |
| schestowitz__ | " | Feb 15 17:36 |
| *schestowitz__ has quit (Read error: Connection reset by peer) | Feb 15 21:53 | |
| *schestowitz__ (~schestowi@unaffiliated/schestowitz) has joined #boycottnovell | Feb 15 21:54 | |
| *ChanServ gives channel operator status to schestowitz__ | Feb 15 21:54 | |
| *gry has quit (Ping timeout: 240 seconds) | Feb 15 22:17 | |
| *gry (~test@unaffiliated/gryllida) has joined #boycottnovell | Feb 15 22:37 | |
| *randomgry (~test@unaffiliated/gryllida) has joined #boycottnovell | Feb 15 22:43 | |
| *gry has quit (Read error: Connection reset by peer) | Feb 15 22:43 | |
| *randomgry is now known as gry | Feb 15 22:47 | |
| *gry has quit (Ping timeout: 240 seconds) | Feb 15 22:56 | |
| *gry (~test@unaffiliated/gryllida) has joined #boycottnovell | Feb 15 23:05 | |
| *gry has quit (Read error: Connection reset by peer) | Feb 15 23:07 | |
| *gry (~test@unaffiliated/gryllida) has joined #boycottnovell | Feb 15 23:11 | |
Generated by irclog2html.py 2.6 | ䷉ find the plain text version at this address.