Testing notifications

Not a bad idea… would be pretty cool and phtn.app is much more accessible than photon.xylight.dev.

I guess a related question is what is your vision for how users would typically use Photon. Do you want to host a single/main application that many users end up using or would you rather have instances (or individuals) deploy their own applications (ie. nu.lemdro.id)? or possibly both?

If the former, then phtn.app makes sense. Otherwise, just photon.xylight.dev is fine since it would sort of encourage others to deploy their own.

Another thought: if you follow through on making Photon into a PWA, then phtn.app would probably fit into that branding, more so than photon.xylight.dev.

My friend has deployed Phorge for himself and appears to be happy with it.

Not sure about studio quality, but for video conferencing and doing some Twitch streams, I’ve being using a Blue Yeti Nano USB microphone for a few years (since COVID) with no issues on Linux.

An alternative to making a shell script is to make an alias or a function instead. That way, it runs in your current shell session and you can access the history command.

Additionally, you could always dump the output of the history command outside the shell script and then run the shell script on that file after you have dumped it.

I think the issue is that history is a shell built-in and not an actual program (ie. external command) and it typically only works in an interactive shell session.

A workaround could be to access the $HISTFILE directly:

{cat $HISTFILE | grep ...

Of course, you can use also just do:

{grep -e ... $HISTFILE | ...}

if you are opposed to the cat at the beginning.

With all the recent fixes and features, Photon is now my default lemmy client :]

Thanks to @Xylight for starting this project and being so responsive on GitHub (I’m @pbui).

Hmm, sorry fixed now. I’m using a new lemmy client… which apparently is still a bit buggy :|

It’s unfortunate, but the reality is that many of the proprietary services are… free, convenient, and where the people are.

Most projects do not have a lot of funding, so it makes sense to use low cost platforms with the least amount of friction. I think most developers are aware of the risks and trade-offs, but make a pragmatic decision to use these proprietary services b/c the benefits for them outweigh the costs.

Same for me (also Firefox for Android).

Ok, good to know that it isn’t just me.