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:

 undefined

    
{cat $HISTFILE | grep ...

  

Of course, you can use also just do:

 undefined

    
{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.

Nothing specific in mind, just wanted to get a general sense of how the work is progressing. Thanks for sharing your experience!

COSMIC is looking great! Do you have any comments about the state of the widgets and how those are working?

Same for me (also Firefox for Android).

Pop is not using Wayland yet ... the current GNOME based DE still uses Xorg. COSMIC, however, will use Wayland.

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

Yes, I've run into this issue recently. The /boot/efi folder is actually its own partition, so removing packages from / will not give your more space for the efi partition. On my recentish Pop install, the /boot/efi partition is about 512MB which is just about enough space for two kernels but... not much else (they may have increased this to 1GB for new installs).

The workaround I did was to simply delete one of the kernels in /boot/efi/EFI/Pop_OS-... (the ... is some string of letters). In this folder you should have the following:

 undefined

    
$ ls -l /boot/efi/EFI/Pop_OS-f2c685b9-a9c2-48f0-907b-ebe199e94a55
total 289256
-rwx------ 1 root root       167 Jul 12 15:24 cmdline
-rwx------ 1 root root 134046998 Jul 12 15:24 initrd.img
-rwx------ 1 root root 134449391 Jul 12 15:24 initrd.img-previous
-rwx------ 1 root root  13844192 Jul 12 15:24 vmlinuz.efi
-rwx------ 1 root root  13846496 Jul 12 15:24 vmlinuz-previous.efi

  

As you can see, Pop stores the current kernel (vmlinuz) and ramdisk (initrd) along with the corresponding previous versions in case you need/want to revert back to the previous kernel. To free up some space, you can simply delete either the initrd.img-previous or vmlinuz-previous.efi file if you are not using the previous kernel. That should allow you to then download the firmware and update it.

After the firmware update, if you want to restore the previous (backup) kernel, you can copy it from /boot back to the efi folder above. Otherwise, the next kernel update will replace it for you anyways.

I hope this helps, good luck.

According to @[email protected], they are still evaluating different CPUs... it's just that Intel provides information publically and so they can release it under the GPLv3 right now:

https://fosstodon.org/@soller/110701645325067411