[Hpr] Linux Inlaws
Dear community, First of all, the Inlaws would like to thank the HPR community for their feedback over the years and especially the last few days. Ken is of course right in pointing out the bootstrapping argument in Wednesday's reply to Yannick's mail (although we never really defined how long this "bootstrapping" period would last). In addition to the above, the assessment of the situation in our mail from Wednesday (republished in Ken's mail): the situation from an Inlaws' perspective hasn't changed since we published our first episode in early 2020. The content is published exclusively on HPR and our RSS feed points to HPR *only*. Having said that I cannot get rid of that sinking feeling that HPR and its community shy away from success. If Ken's analysis published recently [1] is anything to go by, we are one of HPR's most popular podcasts which regularly publishes content. In addition to the fact that we are syndicated left, right and center without any involvement of our own (as we found out a while ago, there's, for example, a Youtube channel republishing the audio content and giving HPR credit [2]). But let's take a look at the bigger picture. If our experience never mind the feedback we are getting through official and other channels are anything to go by, the vast majority of our listeners couldn't care less where they get their episodes from. They heard or read about the podcast, search for the RSS feed, subscribe to it and if they like what they hear downloaded from a server, they stick with us. End of story. In this light, any discussion about wording, podcasts vs hosting platforms, etc. is academic and thus irrelevant for these listeners (playing devil's advocate for the above of course never mind ignoring bylaws, etc. :-). Of course, bylaws are bylaws and feeling that we may have overstayed our welcome, we are happy to move the content elsewhere (probably archive.org as suggested by Ken) which also has the side effect of reducing the technical debt of the corresponding automation workflow significantly. But do so with a bitter-sweet feeling as we do believe in the true spirit of FLOSS communities and their welcoming / inclusive attitude, thus having made every effort to promote HPR and its cause as part of the episodes and elsewhere. Which is in stark contrast to the wording of some of the comments posted to the HPR ML over the last couple days. On an interesting side node: HPR seems to be actively soliciting podcasts from other platforms if, for example, the case of the Grumpy Old Coders is anything to go by. In its most recent episode [3], David speaks about HPR having reached out to them trying to move them over to HPR. Given the fact that this format is hosted on a proprietary platform (Soundcloud) with their format exhibiting far more restrictive aspects (for example, they publish their content under an "All Rights Reserved" license in contrast to CC-BY-SA as preferred by HPR) and knowing David (the producer of this format) quite well as he has been one of my colleagues for the last years, it would surprise me if such an endeavour would prove to be successful. Never mind the above, the Inlaws would like to thank HPR for having us for the last 2.5 years and wish this platform (our words :-) every possible success for the future. But it may help in order to avoid similar incidents in the future to be clearer about syndication never mind what the difference is between a show, a series and a podcast as far as HPR is concerned (as the wording in [4] is somewhat terse) Cheers, The Inlaws [1] http://hackerpublicradio.org/eps.php?id=3648 [2] https://www.youtube.com/channel/UC1j_uaAbB3magzPs4Z0Y-mg [3] https://soundcloud.com/user-498377588/grumpy-old-coders-ep18-rollercaster [4] https://hackerpublicradio.org/stuff_you_need_to_know.php#syndication -- This email account is monitored seven days a week. OpenPGP_0xE7EEC1C45FE2A7BB.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
[Hpr] New website / API design RfC
For those of you interested in progressing a possible API as part of the new HPR website, you find the (somewhat old) proposal at https://repo.anhonesthost.net/HPR/hpr-frontend/src/branch/master/API (please note that you will need an account for this gitea instance which can be requested by registering as usual). Feedback, improvements and counter-proposals :-) are welcome. In the interest of gauging the actual size of the community for this, it would be interesting to see which hosts (reading this ML) actually use some sort of workflow automation for publishing their content on HPR and thus perhaps might show an interest in such an API project. Cheers, Chris -- This email account is monitored seven days a week. OpenPGP_0xE7EEC1C45FE2A7BB.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] Changes to the website - please report odd, behaviour.
Hi Ken / Janitors, Any chance to get the old gitlab instance up once again? I suppose if you want to go down the route of Linux Inlaws S01E51, a git-like structure may come in handy... :-) Cheers, Chris -- This email account is monitored seven days a week. OpenPGP_0xE7EEC1C45FE2A7BB.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] Hpr Digest, Vol 166, Issue 3
Hi Rho'n, Thanks for seconding this. I've such a script based on a Python framework called Selenium which is an integral part of the Inlaw's publishing workflow around HPR. The trouble is that this is a pain to maintain as, for example, any change in the upload page structure / content has to potential to easily break this script. A couple of years back I came with a h/l design for such an API. I published this on the HPR gitlab instance (cf. my previous remark) but apparently this document has vanished in the midst of time as I haven't heard back from Dave / Ken on this after my previous mail. I'll see if I can dig this up and share it in a more public place so that we can take it from there... Cheers, Chris Message: 1 Date: Sun, 3 Jul 2022 16:22:26 -0400 From: Roan Horning To: Ken Fallon , hpr@hackerpublicradio.org Subject: Re: [Hpr] Source Code for the HPR website Message-ID: <5e8626c9-f7fd-ce97-bc9b-41f36883b...@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Hi Ken, I would be interested in helping develop an upload API. I have contemplated an HPR recording app that would help record, edit, and post the show from your phone or tablet. Also have ideas for a command line script which reads a file that has the various upload fields in it, and then posts to the website. From my Guix install adventures, I was looking to become more familiar with scheme (in particular Guile), so started working on a script to upload shows. I don't have anything working yet, but I now create a .scm file with the various fields defined when writing my show notes. Then I just copy and paste them into the browser input fields. Not that a script/program couldn't make the post calls to the same location that the webpage form does, but it is easier to parse the response, particularly error responses. Rho`n -- This email account is monitored seven days a week. OpenPGP_0xE7EEC1C45FE2A7BB.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] Source Code for the HPR website.
I second the above motion. -- This email account is monitored seven days a week. OpenPGP_0xE7EEC1C45FE2A7BB.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] Source Code for the HPR website
I concur with Ken that a rewrite is probably the easiest solution if the current is too shocking for the wider audience to view... :-) The Inlaws did a whole show on git-controlled static site generators a while ago (S01E51 / hpr3549), a concept that has been successfully deployed in quite a few projects over the years I was involved (the webpage of the local LUG I support probably being the most recent example: lugfrankfurt.de) for the following main reasons: - It scales extremely well: Based on a versioning control system which is aimed at planet-wide massive collaboration (ie. the Linux kernel) this is suitable from a few collaborators right up to the thousands (if HPR ever can attract this amount of developers... :-), - The generation of the HTML content is blindigly fast. Depending on the technology and size of the site (the LUG uses a golang-based generator called Hugo), website generation from a set of mark-up files typically only takes a few seconds (generating the LUG with a total of fifty pages clocks in around 2 seconds on an old Skylake i7 with 16 GB of main memory and 512 GB of SSD running Jammy - ballpark figure), - Seamless integration in the git workflow. Using machisms like webhooks or similar, a new version of the site is generated on the fly once a new version has been committed to the git repo of the site, - Website performance is awesome. As this is static HTML with JS & friends kept to a minimum, content delivery is only limited by network performance and local ie. client-side rendering performance. As I'm sure I'm not the only host using some background magic for automatic uploads of episodes as part of the Podcast production workflow (which is a pain due to potential changes in the upload page structure, etc. which can easily break the workflow) I volunteer for the API design / implementation. Ken and myself discussed this some years back and some initial design should be on the HPR gitlab instance (@Ken: This instance / server seems to be offline - do you have access to the document I am referring to?). While I dig this up: Would it make sense to establish a quorum / working group of volunteers dedicated to the creation a new HPR website via this ML? We can then take this offline and discuss design, implementation incliding work allocation, timelines, etc. via a separate ML / other means. Cheers, Chris -- This email account is monitored seven days a week. OpenPGP_0xE7EEC1C45FE2A7BB.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] https
I fully concur with the observations expressed by various members of the mailing list regarding security implications of, for example, man-in-the-middle (MITM) scenario type attacks when offering HTTP traffic (even when just offered in addition to HTTPS traffic). Take the scenario of malware injected into an MP3 or OGG stream by a MITM attack scenario as described, for example, in [1]. Albeit the fact this has yet to be observed in the wild, it takes only one flawed media player in combination with the scenario as described in the quoted paper (and may this be as a third-party component carrying a zero-day and not even intended by the author - as the recent log4shell example clearly shows) to wreak havoc on desktop environments, mobile devices and beyond... Switching to a HTTPS-only approach eliminates this risk once and for all - a small price to pay given that even today's mobile / embedded devices carry enough computing power to address this without much overhead. Given the fact that even legacy devices contain enough computing power (by offloading crypto-processing to GPUs, for example; [2] dates back more than ten years; a), I don't see an issue with even older hardware being powerful enough to support modern encryption used by, say, TLS. More recent FLOSS approaches prove to be even more powerful [3]. Just my $.02 :-). Cheers, Chris (CISSP, CSSLP, CEH) [1] https://www.researchgate.net/publication/288646143_Code_Injection_Attacks_on_HTML5-based_Mobile_Apps_Characterization_Detection_and_Mitigation [2] https://github.com/heipei/engine-cuda [3] https://github.com/intel/QAT_Engine -- This email account is monitored seven days a week. ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] https
https://developers.google.com/search/blog/2014/08/https-as-ranking-signal And that goes back seven years. It's safe to assume that search engines like Google nowadays put more and more emphasis on HTTPS vs. HTTP for the reasons mentioned. I concur with Jon and other people that the advantages of the use of HTTPS far outweigh the disadvantages - that's precisely the reason why top-ranking sites have moved to a HTTPS-only approach long ago. So if we are serious about the episodes being found on search engine result pages and thus improving HPR's popularity in general, I propose putting a 301 in place. Cheers, Chris -- This email account is monitored seven days a week. OpenPGP_signature Description: OpenPGP digital signature ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
[Hpr] https
Admins, Ever considered using an LE cert for https for the website and putting a redirect in place to avoid browser security warnings? Cheers, Chris -- This email account is monitored seven days a week. ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] Policy Change: Removal of "by arranged permission" when posting to HPR
Aye, given the fact that each and every show carries its explicit copyright notice even if submitted under the default license. Cheers, Chris -- This email account is monitored seven days a week. ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] Hpr Digest, Vol 147, Issue 6
Hi Ken, If HPR decides to participate, count at least one of the LIs in for half-day or so of booth duty. Cheers, Chris Message: 1 Date: Wed, 23 Dec 2020 16:26:08 +0100 From: Ken Fallon To: "hpr@hackerpublicradio.org" Subject: [Hpr] Fwd: [FOSDEM standholders] FW: [FOSDEM] Stands - Call for Participation Message-ID: Content-Type: text/plain; charset=UTF-8; format=flowed Is this something we should do ? Ken. Forwarded Message Subject: [FOSDEM standholders] FW: [FOSDEM] Stands - Call for Participation Date: Tue, 15 Dec 2020 17:48:53 + From: Alasdair G Kergon To: standhold...@lists.fosdem.org From: Pieter De Praetere To: fos...@lists.fosdem.org Hello, There can be no February without FOSDEM, and there can not be a FOSDEM without stands. We are currently inviting proposals for a stand at the virtual event taking place the 6th and 7th of February 2021. Stands allow projects to showcase their work to interested visitors, answer their questions, and in normal years, hand out swag to support their project. For obvious reasons, unfortunately we will be unable to run a physical conference in Brussels this year, but we would still like to give communities a place to meet online. We offer you: 1. A position on a special stands website (active during the event) for you to introduce your project. We will organise the stands per theme. 2. Hosting for a webpage and several short videos where you can introduce and demonstrate your project and show people the latest features, discuss your roadmap etc. 3. A chatroom facility to allow visitors to interact with you. (Details will be confirmed closer to the event.) Proposals should be submitted through the form at stands.fosdem.org/submission which contains further information. Questions or remarks? Contact us at sta...@fosdem.org. The deadline is the 25th of December. The FOSDEM Stands Team ___ standholders mailing list standhold...@lists.fosdem.org https://lists.fosdem.org/listinfo/standholders -- This email account is monitored seven days a week. OpenPGP_signature Description: OpenPGP digital signature ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
