Yeah, there's a lot of context there that isn't obvious from the outside and is behind my feelings that Palm just had too little too late. They shouldn't have been blindsided by the iPhone, but with that happening they really did the best they could. I'll make some brief points, but maybe I should write a blog post at some point.
- Kernel talent was never a problem at Palm. The ex-Palm folks lead or are technical leaders at many mainstream unix-ish OSes today, plus Fuschia (Android, Apple, Chrome, Fuschia)
- Boot times weren't the highest priority (though we did spend time on it since they were _so bad_). Battery life was. We didn't even do that well by launch date, but if Android hadn't mainlined their power-management framework before the Pre launched it would have been a joke. It was all hands on deck to get that stuff integrated in time for launch.
- The webOS platform was actually a thin UI layer on top of an Android-like Java-based platform that never launched. The Java-based OS wasn't derivative of Android (it predated Android), but it had no differentiating features with Android already live. Booting the Java runtime _and_ the JS engine and webkit was a lot.
- We knew we couldn't have Java running on this phone long-term, so tons of effort was going into nascent node services instead of Java ones. So all those were launching too.
- Your memory is incorrect on the JS jit, or mine is. My memory is that we were adopting the latest v8 engines as fast as they would come out (although not as fast as chrome) because they were the only ones that could keep the thing performant.
- Webkit was a mess, I'll give you that, but I'm surprised you noticed. Were you at palm too? Did you build apps? We generally provided UI components that were the way to build apps that, hopefully, allowed you to ignore the intricacies of exactly which webkit version you were on (at least to build an app).
RM produce designs for a GPU called 'Mali'. This is incorporated in many SoCs and thus devices. It is used in a number of devices that can run Debian.
There are three major revisions of Mali GPUs: Utgard, Midgard, and Bifrost. See wikipedia page for reference.
Partial free drivers were developed for Utgard but were abandoned (lima). Work on Utgard has continued by a new set of developers (lima). Free drivers for Midgard and Bifrost are under active development but are not yet ready for Debian users (panfrost).
Proprietary drivers are also available from the vendor for each Mali version. Since 2016, the binary drivers put out by ARM have been redistributable and thus can be packaged for non-free. GPLed kernel shim drivers are also released by ARM, which is eligible for Debian contrib. As of March 2017, these have been packaged in Debian for Midgard devices; see MaliMidgard. Upstream proprietary drivers are available from The ARM developer site
For anyone using Ruby I'd recommend the (open-source) axlsx gem, I've had great results being able to treat Excel generation like I'm rendering a view.
The autoresponder is more of a "This domain accept OAuth" and sends back the email body.
That way, the autoresponder doesn't need to know anything about the process nor does it authenticate the user.
It merely sends back a mail that portier can interprete as "Ok, I send an auth email there and this response means they want me to construct an oauth link to this domain"
it's stateless and only requires a rather simple autoresponder that can include email bodies.
Furthermore, portier can also verify the login link, so that replay attacks aren't feasible and the sender and link-owner must have matching emails.
Protip: use pulse on top of jack. I can't get to my PA config right now, but the gist is
1) copy the default config to ~/.pulseaudio
2) edit out the device autodetection and add in loading just the jack module
3) if you have more than a single device, either add it to the pulseaudio config (i.e. bluetooth comm device for use with skype) or use alsa_in and alsa_out to connect an additional alsa device to jack, then add the device to the pulse config as an additional source/sink pair
4) keep the default alsa device pointing to an alsa-pulse bridge. Yes, this sounds crazy when you can just layer alsa on jack rather than on pulse->jack, but this way you get the per-application volume controls, which are one of the few really good features of pulse. If you don't care for per-application volume controls, just layer alsa on top of jack directly.
With this setup, pulse acts as a simple bridge to jack and jack does a much better job of controlling your sound card, remixing, etc. I have a hunch that the absolute single best sound setup on linux would involve patching jack to basically act like pulse w.r.t automatic device management and then add the native pulse protocol to it.
> I couldn't stand the PA process hanging around in the background eating 20% of my cpu...especially on laptops.
That's likely a artifact of you needing to configure these things yourself and not doing a very good job.
This is where distros that force users to configure basic features like audio do a real disservice. In 2016 nobody should be configuring anything to do with audio unless they are doing audio production. If a problem comes up the only thing that should be done is to file a bug so it can be fixed. Working around bugs by trying to configure something is nasty business, but unfortunately when distributions don't do the work it forces users to do it.
Going from a system that is configured to use Alsa and then trying to go to Pulseaudio is a PITA and is surprisingly difficult to get right.
Here are the basic steps:
* First you need to undo the damage caused by the usage of things like 'alsamixer'. Alsamixer does a very poor job exposing the low-level mixer controls on your hardware. A lot of the controls are only partially functional and turn on or enable some configurations in spooky ways that can't be undone. Bad configuration settings caused by things like alsamixer cause endless headaches because it jacks up Pulseaudio's ability to configure the hardware correctly sometimes.
To prevent current settings from carrying over to the next reboot you need to locate your 'asound.state' file were the alsa service stores your configurations between reboots. Delete that and symbolically link it to /dev/null, reboot, and then turn it back to a regular file.
* Find all your Alsa 'hacks' and get rid of them. Your .asoundrc files and the like. You definitely do not want to be doing things like setting bitrates or buffers or the like using Alsa configuration files. Get rid of dmix and any other alsa plugins you have configured. They are counter productive. You can do that by configuring PulseAudio if you really want to.
* Make sure that Pulseaudio is using hardware device directly and not going through something like 'dmix'.
* make sure that your init system is doing things correctly and that no sound gets kicked off before Pulseaudio latches to the hardware. Modern hardware has no hardware mixing features because they increase cost and lower audio quality.
* Make sure your software is configured to use Pulseaudio directly whenever possible. This can be very difficult, unfortunately, because there are a huge numbers of audio libraries and whatnot that applications use and they are all configured differently.
If CPU usage is still a issue after you have it setup initially you can control the type of resampling algorithm you use.
Alsa with DMIX uses as much CPU as Pulseaudio on 'Trivial' resampling method. A lot of the difference in cpu usage is psychological. When the default configuration of Alsa burns up cpu with resampling it doesn't show up in things like 'top'.
On a laptop, with Pulseaudio configured correctly, you should see a slight reduction in energy use.
While this is very impressive, it feels like trying to solve the wrong problem. The real problem is getting rid of passwords (Persona, anyone?).
Don't get me wrong, what's described there is super-important to secure the authentication of today, but what about a word for the authentication of tomorrow?
There already are various solutions. Passwordless[0] is a familiar one for nodejs, and I recently bumped into the promising Portier[1], which is, according to its authors, a "spiritual successor to Mozilla Persona".
- Kernel talent was never a problem at Palm. The ex-Palm folks lead or are technical leaders at many mainstream unix-ish OSes today, plus Fuschia (Android, Apple, Chrome, Fuschia)
- Boot times weren't the highest priority (though we did spend time on it since they were _so bad_). Battery life was. We didn't even do that well by launch date, but if Android hadn't mainlined their power-management framework before the Pre launched it would have been a joke. It was all hands on deck to get that stuff integrated in time for launch.
- The webOS platform was actually a thin UI layer on top of an Android-like Java-based platform that never launched. The Java-based OS wasn't derivative of Android (it predated Android), but it had no differentiating features with Android already live. Booting the Java runtime _and_ the JS engine and webkit was a lot.
- We knew we couldn't have Java running on this phone long-term, so tons of effort was going into nascent node services instead of Java ones. So all those were launching too.
- Your memory is incorrect on the JS jit, or mine is. My memory is that we were adopting the latest v8 engines as fast as they would come out (although not as fast as chrome) because they were the only ones that could keep the thing performant.
- Webkit was a mess, I'll give you that, but I'm surprised you noticed. Were you at palm too? Did you build apps? We generally provided UI components that were the way to build apps that, hopefully, allowed you to ignore the intricacies of exactly which webkit version you were on (at least to build an app).