[eiy5weiN]

I went a step further and spent most of my free time this year writing CGI/C apps.

This was not nostalgia either : the reason for doing that is because I was writing webapps for my pinephone. Toying with the phone, I decided I wanted my apps to be webapps rather than GTK apps, so that I can access them either from mobile or laptop (through local network), but I didn't want to have the apps running all the time, in order for them to consume less energy (which directly translates to battery lifetime on a mobile). Turns out that CGI is perfect for that : the only process always running are nginx and fcgiwrap, then all my apps are started only on demand, for the lifetime of the request.

I did expect a big performance hit, but I was surprised it was not so bad. I guess that's because they are C app rather than written in languages which require loading an interpreter before running anything. One app that I rewrote from libmicrohttpd had actually better perfs (although it was the first time I used libmicrohttpd, so it was probably something I didn't do correctly).

[nathcd]

> Turns out that CGI is perfect for that : the only process always running are nginx and fcgiwrap, then all my apps are started only on demand, for the lifetime of the request.

This is a really nice idea. It almost makes me wish browsers could just make a local CGI request directly, without a webserver at all. A quick search turns up an extension for ye olde Firefox: https://github.com/RufusHamade/lcgi. I suppose with native messaging APIs it's probably possible with new extension APIs too, if a bit more convoluted.

[alfiedotwtf]

My contract is up next month... how are you finding the pinephone? I just need web, gps, voice calls, email, camera, music, and a battery lasting over 24 hours mostly on standby. Is it a daily driver yet?

[eiy5weiN]

I would say that for battery life alone, that probably wouldn't be for you yet. Regarding other apps, while they do work, it's quite a severe downgrade from android/iOS - mostly, I think, because the pinephone is so low end hardware. I do use it as my main phone, but that's only because I find hacking it worth those sacrifices. In your case, you'll probably want to wait for the Librem 5 to see how it compares, or for pine64 to release a buffed up pinephone (if they ever do that).

[alfiedotwtf]

Thanks for that.

Nuts on the battery life. Yeah, I'm not too fussed on the apps though, because I did want to write my own in Rust.

Ok, will wait it out a bit longer :)

Thanks again

[Klinky]

>I just need web, gps, voice calls, email, camera, music, and a battery lasting over 24 hours.

Isn't this what most people use their phone for? What exactly are you compromising on in this list? You might as well say you just need a fully-functional smartphone, not a hacking project.

[mod]

Compared to me, he's compromising:

Video playback (Netflix), potentially choice of audio playback (I choose Spotify, not local mp3s or something), banking apps, authenticator, an app store, games, ridesharing, home security camera viewer. Probably the number 1 smartphone app wasn't included, Facebook.

I'm guessing 75% of most people's phone use is compromised, at least by changing to a web app. What the GP listed would be about 20% of my use, personally.

[Klinky]

Not having Google/Apple ecosystem is a feature, not a compromise for those going to the PinePhone. Those making that choice need to have realistic expectations on what they're getting, and be able to accept compromises on the availability/polish on services like web, gps, email, camera, music, and also battery life. If you have to ask, it's probably not for you.

[mro_name]

I love OCaml CGIs with a few hundred LOC, (almost) no build dependencies and zero runtime deps. Statically linked, stable forever.

e.g. https://demo.0x4c.de/geohash.cgi/u28br

[ivanhoe]

yup, that's how we used to do it in 90s, as long as code is compiled it has a fairly decent performances. Downside is that debugging is far harder than with the scripting languages.

[Frondo]

Heh, that takes me back! In 1994, I was a high schooler volunteering at a famous west coast science museum (it was either that or work at Taco Bell, thanks dad), and one of my tasks was to make a searchable employee directory...

I don't remember if there was any other option on the server we had, but I had to write that sucker in C! Reading and parsing a .csv file, handling search options, working as a CGI program, what a pain, especially for a dumb high schooler like me!

[ausjke]

I would use lighttpd for that as it supports fcgi natively, nginx is really odd for fcgi in my opinion, not to mention, lighttpd is only 4MB in memory

[eiy5weiN]

I _think_ I checked it but didn't find any way to run cgi apps, only fastcgi (maybe I should check again, I'm not 100% sure about that).

Although, now that I understand fastcgi better, I guess fcgiwrap could be adapted for lighttpd, if it doesn't work for it as is (my package manager's description mentions explicitly it's for nginx).

Thanks for the advice, I'll dig that.

[ausjke]

lighttpd works well for cgi directly https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_Mod...

and for fcgi as well, without fcgiwrap at all: https://github.com/jerryvig/lighttpd-fastcgi-c

[mro_name]

lighttpd here: https://demo.0x4c.de/geohash.cgi/u28br

[account42]

nginx can do fcgi natively too, fcgiwrap is a fcgi application that forwards requests to cgi scripts.