Mozilla has their own password manager as part of their sync service.
And if you don't trust them, you can even sync using your own home server (I think I remember that you need WebDAV for that.)
And that one works *also* on Linux.
And in addition to a password manager, you should enable 2 factors on anything critical: Your banks, e-mail address that you use for password recovery, OAuth and OpenID providers that you use to log elsewehere (like Google or Facebook), etc.
This seems perfectly sensible to somebody making a media player, but for smartphones it means you have to come up with something else to do with your UI tones and notifications and whatnot (because you can't mix them into the mp3 stream without decoding and re-encoding, defeating the purpose of mp3 passthrough).
Or, the sound server/mixer in the phone could switch from MP3/AAC passthrough to mix-and-reecode whenever there are multiple streams, and switch back to passthrough once the music is the only remaining sound.
(As far as I know, pulse audio should be able to do it. It's already able to do with sample (only resampling and mixing audio if multiple channels, otherwise switching back to the music's sample rate if supported by the hardware), and is already used in several lesser known smartphone OS: as far back as the openmoko, and more recently in Palm/HP's webOS, and currently in Sailfish OS and Ubuntu Phone.
I suspect that Windows' sound mixing service should in theory be able to do it too...)
SBC was the first implemented because it's computationally trivial and royalty-free.
Speaking of which, FLAC and OPUS are royalty-free nowadays, and OPUS is even a IETF standard. Bluetooth should consider introducing them to Bluetooth...
I'm not sure it would have been practical to encode mp3 in real-time on a featurephone in 2004.
Trivially possible, but it would have required a MP3 *codec* core, instead of a purely MP3 decoding hardware core as done back then, which would have risen the cost of the SoC and thus of the feature phone. So nobody did it to stay competitive.
Anyway, the limiting factor of BT audio quality is the codec, not the radio. AptX is ~384Kbps for 16-bit stereo, and BT4.0 has a raw capacity on the order of 25Mpbs.
Correct me, if I'm wrong, but 25Mpbs figure is basically using AMP - Alternative MAC/PHY. Or in other words, using Bluetooth over a 802.11 transport (i.e.: over a Wifi transport).
That means the headset needs to have a more energy consuming "+HS" variant of bluetooth 3.0 that also features this "over Wifi" part.
(The same way that the low energy of Bluetooth 4.0 LE is bluetooth over WiBee)
This could mean shorter battery life on the wireless headsets.
aptX isn't exactly lossless.
It switches between lossless and lossy while trying to fit within bandwidth constrain.
Also, the codec is proprietary to Qualcomm.
IETF has already issued an open codec that beats most of its competition: OPUS.
It's not abnormal
The battery, not the motor, is the most expensive part in an electric car.
There are electric car makers who sell you only an empty car, and rent you the battery.
e.g.: Renault's Zoé
These cars are rather cheap.
(And in case of the Zoé, Renault have stated that:
- they DON'T do remote kills, even if they technically own the battery
- in fact they don't do any DRM on the battery
- you could in theory stop paying the battery, bring it back, and refit the car with something else (yup, they are open to the idea of 3rd party battery market that is eventually going to appear as e-cars get more popular) )
(Disclaimer: there are Zoé in pool of cars at the local car-sharing company that I often drive).
To over-simplify to the point of carricature :
In a gaz-powered car:
- The motor is a horribly complex high-precision mechanical piece with thousands of precise components, gearbox and transmission system, etc...
- The tank is basically a huge jerrycan, with a simple cap at one end to top up, and a glorified faucet at the other end to bring fuel into the car.
(Yup I'm over simplifying but you got the picture).
In an electical car:
- The motor is basically just a huge coil almost directly connected to the wheel (well, not quite. There's a fixed ratio gearbox), and that's about it. It just spins faster or slower depending on needs, no complex transmission in play.
- The energy storage is an awfully complex beast: complex (and explosive) chemistry in the battery that requires either custom parts or in Tesla's case a complex grid of thousands of simple common off-the-shelf 18650 elements, with a very complex battery manager to charge and top up the energy storage while keeping the longevity of the battery, and a high power circuit to convert the battery output into what high AC current is precisely needed at the time by the motor.
So yeah, take the energy storage out of the equation, and the rest of the electric car is cheap.
Or in a different perspective: adding 10% more energy to the storage is a complex task, that is going to cost a lot if you pay the battery upfront (like in Teslas)
It's not like extending the range 10% in a gaz powered car (where it's basically about increasing the the "glorified jerrycan" about ~10%)
It's more like extending the power or efficiency of a gaz powered car (where it would need an entirely new and better mottor, which is also going to cost a lot).
It's a bit complicated.
Once it hits 88MPH, the clock sometimes measures as low as -60 years.
Once the clock was even show the lowest point of -70 years, but it was after getting hit by ligthning.
But mileage is shitty, it eats 1.21 jigowatts.
I don't think you can call it patent trolling when Android is a direct competitor to a line of business they've continuously had for a couple of decades
Microsoft didn't as much had "competitors" and they didn't "had a business line for a couple of decades", as much as they've "continuously struggled, trying unsuccessfully to get a foot in a market that they don't even properly understand".
Nowadays, when Microsoft tries to do something out of their Windows 10 Phone, they've in practice lost to iOS and Android.
Back then, in the Windows Mobile era, Nokia's Symbian and Blackberry were the dominant platforms.
Back before, in the Windows CE era, Palm's PalmOS was the better platform.
They never actually owned the market.
And somebody who :
- is abusing their patent portfolio to get a share of the dominant in a marker that they can't conquest
- for something as trivial as exFAT (hey, it's just like fat, except with an allocation bitmap instead) or LFN (hey, lets invent filenames that are longer than 8.3, and call them something like VFAT)
- which is actually mandatory for some industry standard (SDXC is simply SDHC with mandatory exFAT. Other wise you can trivially plug a 256 GB SDXC card into a "up 32 GB only SDHC" reader as long as you either install a FUSE driver for exFAT or reformat the card into something that your OS can read - like UDF - but there is no physical difference between SDXC and SDHC (unlike the older plain SD))
that qualifies as a patent troll in my book.
You're missing the fact that Apple does a really good job on some things, like interfaces.
I'm not missing it. I'm simply not considering them the best at doing efficient interface.
They are good at making them nice looking.
They are very good at making them skeumorphic so user don't seem lost to new functionality.
But they are not that good at UI in general. They usually need to dumb things down to an abyssimal level, just so to make things understandable to joe-6-pack. (which is enough to sell tons of shit, so why try harder ?)
As opposed to make an interface that can also be picked quite quickly by joe 6 pack, but don't stand in the way of more advanced users.
The iPhone didn't do as much as previous smartphones, but it was a lot easier to get it to do what it did.
Depends on your point of reference.
- Microsoft Windows CE/Mobile, whatever it was called back then had an absolute craptastic interface. So yeah, there's no way that Apple could NOT do better with iOS.
- PalmOS was already a much older interface for PDA (and smartphones, starting with some Handsrping Visors and later Palm Centro), that already had everything iPhone had on offer, except for multitouch scrooling/zooming (its touch screen wasn't *capacitive*, so no 2-finger gestures) and for virtual keyboard only as a 2ndary input method (main input method was "Graffiti": scribling special gestures. kind of simplified alphabet. keyboard was an alternative mode) (later centro model featured a physical keyboard, which was caried over to webOS devices py Palm/HP).
It did feature a main launch screen with apps, supported 3rd party apps, had standard tools for the era (calendar, address book, notes taking, etc.)
iOS looked no more than a rehash of what already existed on the better devices.
The smartphone market is completely dominated by the iPhone and Androids, and Google copied a lot of Apple UI for Android.
Except for some limited gestures introduced by Apple, both are quite similar to what was already available in PalmOS, or before that in Apple's own Newton, or before that on EPOC (symbian's grandpa). Or the first GNU/Linux attempts on PDA back then (Zaurus). etc.
In fact, Apple failed to innovate badly.
There are OS contemporary to iOS like Palm's own webOS, which at least tried to innovate and make multitasking easy to use (their stack of cards metaphor, with gestures).
I had a conversation on this just Friday, so weird that it's on
Unfortunately, that transition is still going on today. It results in a paralysis of direction and focus. Qt used to, with widgets, have seamless theme management so that a KDE App would look native. Unfortunately, the QtQuick primitives that were initially released don't. The higher order QtQuick Controls, came later, and with not the best license or quality. Internally Qt has been pulled in many directions and a changed hands several times. Trolltech, Nokia, Digia and now the Qt Company.
That being said, I think we are there now, finally, 6 years later, to really do software transition to QtQuick. QtQuick 2 is amazing and up-coming Qt 5.8 will be that release which is the completion of the concept.The 5.6/5.7 that is out now is really great, 5.8 will be the last bit of polish.There are still some holes, there always will be, but QtQuick is something so new and different it took a while to figure out.
As a developer who uses Qt, and has been using Qt professionally since 2004, QtQuick makes it trivial to write applications. The next easiest was with PyQt.
Did you watch Citizenfour? There were a couple scenes in there, IIRC, where comments were made about a "second leaker". I believe there were also mentions in some of the Guardian articles as well. Not a lot in either, but definite indications the Snowden was not the only one.
I was wondering what happened to #2...
Market dominance snowballs in this kind of situations, as we regrettably know from the Windows story.
There's a key difference.
Android's source are available for anyone to use. (Only the Google-branded experience is protected).
And as a consequence of the above, it's possible to find solutions to run Android apps on other platforms too.
(Though it helps to have a Linux kernel, as Microsoft failed attemps at Android on Windows Phone (that morphed into WSL) has shown.
So Android apps on iOS might by a tiny bit more complicated than Android apps on Sailfish OS)
Most public domain software is free, at least at first glance.