#pinetalk — Public Fediverse posts

@pine64 I subscribed to your #PineTalk podcast in AntennaPod, using the "Get the RSS feed" link on the podcast page;

https://pine64.org/podcast/

AntennaPod was able to find the podcast and add it, but the RSS feed doesn't seem to tell it where to download the audio files as normal.

What I get is a list of episodes with no download button, but when I click on an episode there's an embedded audio player, and a download link within the show notes (see screenshot). What's up with that?

#podcasting

@ademalsasa Me too! They mentioned it on the latest episode of #PineTalk. They'd spoken of it before but usually in a context where I wasn't sure if they were serious or not. I'm guessing I wasn't the only one that wasn't sure because they specifically came out and said that it was a real project. It's my understanding it's in initial stages, and there are still some significant hurdles, so it's not going to be tomorrow. @talkpine can probably throw in more details if they have them.

@PINE64

Latest Pinetalk (Pine64 Community) Podcast Episode:

#Pine64 #Pinephone #Pinetalk #Podcast #Mobian #Linux #Phones #Mobile
https://www.pine64.org/2022/06/03/6517/

@PINE64 Is there any movement on getting #PineTalk going again? I miss it! If not, what's the main thing missing? Hosts? Weekly research on what's happening? Something else?

While you are reading listen in to the latest Pinetalk (Pine64 Community) Podast! Episode 12.

I joined @Ezra @linmob to talk about Pine64 Hardware, Linux, open source, LoRa, and the importance of privacy.

#Linux #Pine64 #Pinetalk #Pinephone #Pinedio #Radio #SDR #Podcast #FOSS #floss

https://www.pine64.org/pinetalk/

I was hoping to publish the #LINMOBapps progress report for March and April today, but that will happen tomorrow, just like #PineTalk 008.

I did add a lot of appdata.xml/metainfo.xml links though, which is vital for the future of #LINMOBapps/#LinuxPhoneApps.

Another change, that I made happen today is working appstream:// links on https://linmobapps.frama.io/. Now, if you tap one of these links, software like Discover or GNOME Software may pop up and allow you to install the app right away!

Getting ready for #PineTalk (@talkpine)
#shotonpinephone
#megapixels

Just discovered #Pinetalk (Podcast on #Pine64 #Linux hardware) is now searchable/downloadable from my favorite #Pinephone/#Pinetab #Podcast app: #Gpodder! Playing on #Lollypop media player. Nice way to keep up with developments. 😀 And newer episode was released right after I uploaded this picture:

@leimon Thanks, will do!
#pinetalk CC @talkpine

After listening to the #PineTalk episode recently, I have had a long hard think about a particular subject that was brought up: “Do you really want a Linux Phone”

At the risk of alienating some of my followers on the fedi, here are my thoughts:

• We need to educate non-linux users, rather than getting annoyed at them for “not knowing” or “not doing the research”
• Developer and contributor ego needs to be left at the door. It’s unproductive.
• We need a universal unified design language, so that developers of apps can meet those minimum requirements, otherwise we end up with a ton of half complete, incompatible or non-conforming junk
• The name or ethos of a project or app, is less important than its discovery, security and usability
• Putting links; credits and project information in the “About” of an app, is enough. Confusing people with strange or non-generic app names, just makes your project or app seem pretentious, not unique
• Stability and efficiency are far more important than extraneous and non-core functions and features
• User experience needs to be paramount, not an afterthought
• We should work to make new users loyal and knowledgeable long term users, and we cant do that by discouraging them
• I dislike the “figure it out for yourself” attitude. Not everyone has the reasoning or research skills that we take for granted, and we should be helping these people learn

I have a little bit of an idea on how we can resolve some of these things:

1. We need a standard Icon Set that is immediately recognizable, so that no matter what distro you are using, you can find what you’re looking for quickly. Custom colors etc, is not the issue, it’s the recognizably that is important. Humans are visual beings. We look for things that are familiar.
2. Projects need to stop being so self interested in their own walled gardens. Apps are a part of a bigger ecosystem, they all need to communicate better, and stop the pretentious ego driven need to be different. One application is NOT always better than another, and unless you have massive brand recognition (on the scale of something like Firefox), then the only applications that should have extremely unique names and Icons are transient 3rd party apps and games. I know this is an ugly word, but conformity breeds familiarity. If you have a familiar interface; app name and icon, your application will be much more recognizable, and therefore receive much more use as a result.
3. There are only two core features of the #PinePhone (or #LinuxPhone) that absolutely MUST function, which are simply make and receive phone calls and send and receive SMS messages. Without these, all other projects are moot. If the PinePhone cannot receive phone calls or SMS messages in a reliable way, then the phone is dead in the water. Making these the highest priority for all LinuxPhone projects, should be an obvious step.
4. Projects need to work towards “feature complete”, not “almost complete”. Having an app that technically works, but requires editing of scripts to customize it, is absolutely ridiculous. No average end user is going to say “Sure, let me open the terminal, learn how it functions; learn how to navigate the file system using the cli; learn how to use nano or vim; learn the syntax of the language used for the config file; learn which variables need to be edited and how; then save, close and restart the app.
5. Forums; Wiki’s and Bug reports turn off prospective new users. We need to find an alternative that provides a more personal (and arguably more agreeable and centralized) method to how we look after our users. Telling people to “Search the forums”; “Fix it yourself” or “Have you searched the bug reports”, is an absolutely horrible way to deal with users. So you don’t like dealing with the same questions over and over, I get it, I do. But don’t punish new users because you’re frustrated.

On point #5 - I was thinking about this even more in depth. If some enterprising group were to create a general “Support Team” that lend their services to multiple projects, that could work as an intermediary between the end users and the dev teams, this could (at least partially) solve the issue. Dev teams only get properly logged bug reports without the hassle of dealing with repetitive questions (allowing them to focus on their work), and end users get immediate answers without the need to try and translate “developer speak”, and dealing with pissed off programmers.

What do you think? Would this help solve the support problem? Should I attempt to create such a group?

#Rant #Ethos #Pine64

@PINE64 @talkpine @linmob @purism

Getting ready for @talkpine/ #PineTalk 😎

Getting ready to play with #TwisterOS (https://twisteros.com/twisterarmbian.html) on my @PINE64 #rockpro64. All for @talkpine 😉 The stuff you have to do, it's crazy. 🤣

BTW: Would there be interest in a "LINnotMOB" video channel for, you know, "LINux, not MOBile"?
#PineTalk